Il 31/03/2021 10:23, David Brown ha scritto:
> On 31/03/2021 00:34, pozz wrote:
>> Il 28/03/2021 00:37, pozz ha scritto:
>>> Il 26/03/2021 16:54, antispam@math.uni.wroc.pl ha scritto:
>>>> pozz <pozzugno@gmail.com> wrote:
>>>>> Are there any *real* implementation of multi-master half-duplex
>>>>> RS485 bus?
>>>>>
>>>>> I often use half-duplex RS485 and I always use a master-slave polling
>>>>> protocol. This choice dramatically reduce the complexity of the system
>>>>> and it works well with a limited number of nodes.
>>>>>
>>>>> When the nodes are 10 or 20 and they usually send only a few bytes in a
>>>>> minuted, the polling scheme is inefficient. The bus is alway busy for
>>>>> polling, but the real data are very small.
>>>>
>>>> What do you really want?� That is what is your "efficiency"
>>>> criterion.� For embedded system a lot of folks consider
>>>> worst case delay.� For normal design worst case is when
>>>> all nodes have data to transmit.� Clearly, "last node"
>>>> have to wait on all previous nodes.� So, best "efficiency"
>>>> would be sum of transmit times for data.� On top ot that
>>>> you have various overhead: bus turnaround times, time
>>>> for polling or token passing, possible timeout in case
>>>> of fixed time slots.� AFAICS polling messages from master
>>>> to slave may be very small, so they should at most
>>>> double time: you have twice as many messages compared
>>>> to case when each node "magically" knows when to
>>>> transmit.� You can play some tricks, like group poll,
>>>> when nodes are ordered (numbered) and each node in
>>>> the group is supposed to send its data, starting from
>>>> first.� Of course, it means that each node must be
>>>> capable of detecting end of transmission from
>>>> lower numbered node.� Token passing may be slightly
>>>> more efficient, as data messages may serve double
>>>> duty of passing token to next node: so you save
>>>> cost of polling messages.
>>>>
>>>> But you basically fight with constant factor of 2.
>>>> If you need more improvement, then you need bigger
>>>> change.� Say faster links or star topology.� In
>>>> star topology intermediate nodes may aggregate
>>>> messages, so you can significantly decrease number
>>>> of messages going to maser node.� And it is easier
>>>> to provide fast links to limited number of "hub"
>>>> nodes, than to have fast links everywhere.� But
>>>> as downside, there is more complexity and potentially
>>>> lower reliability...
>>>>
>>>
>>> Suppose you have a bus with 20-30 nodes: one master is the central
>>> unit, the other are slaves that get a code from a keypad. When a code
>>> is typed on the keypad, it is transmitted to the master. If it is ok,
>>> master sends an ack to the slave that get the code so it enabled an
>>> electric lock and the door is unlocked.
>>>
>>> With a polling scheme, master must sends a poll request continuously
>>> and the the slaves answer, most of the time, with no data. It appears
>>> to me a very inefficient approach.
>>>
>>> What's the worst case, i.e. the delay between pressing OK button on
>>> the keypad and the door opening? It is the sum of 30 (number of
>>> slaves) polling requests and replies. If a single request takes 100ms,
>>> the worst case should be around 3 seconds.
>>> I'd like to reduce this time to 100ms.
>>>
>>> It is impossible with polling approach. However the bus is idle
>>> (without real data) most of the time. I could avoid polling at all and
>>> instruct the slave to transmit when it wants. I think the probability
>>> of a conflict with another slave is very low and I could reach the
>>> requirement of 100ms above. However I sholud design the behaviour with
>>> a conflict, even rare, happens.
>>
>> Many thanks to all of you that spent some time to answer my question.
>>
>> Some additional details. The example I wrote is... just an example and
>> not exactly the real application. The system has a central unit and many
>> slaves installed in different places of a building (imagine a keypad, a
>> sensor and so on). This is a home/building automation application.
>>
>> After first connection the master sends many configuration data to
>> slaves (around 2-4kB), so CAN bus is not ideal because of its small
>> packets (however I can split data on different packets).
>> Then the bus stays idle for most of the time. The user could interact
>> with a slave and only in that case the slave has something to tell to
>> the master.
>
> CAN is a short-range protocol. If your bus is over about 20-30 m,
> forget CAN. (People do use it for longer distances, at low speeds, but
> it's horrible for the task. And CANOpen and other "standards" look like
> they were designed specifically to be as complex and inefficient as
> possible.) For a short range, small message bus on a closed network
> entirely under your control, CAN is great.
>
>>
>> Yes, you are right when you say that putting a known limit on the worst
>> case can be done with a polling approach. However my goal is not limit
>> the worst case, but minimizing the "normal"/mean delay in the
>> slave->master->slave transaction.
>> I know this mean of delays can be reduced a lot, because the bus is idle
>> most of the time, so the probability of a conflict is very very low.
>>
>> Even number of slaves was just an example. I can think of systems with
>> 50 or 100 slaves and in those cases the polling approach performance
>> would be very bad.
>>
>
> You should try to think about having multiple bus segments with fewer
> nodes per segment, and some sort of aggregator or gateway that combines
> them.
>
>> Do you know of real wired cable used in home/building automation? I
>> heard about KNX on twisted pair, but I think the complexity and cost of
>> the system would increase very fast.
>>
>
> I think KNX is mainly used in lifts, but I'm not sure. There are a
> large number of "standards" used for building automation, with a variety
> of pros and cons, standardisation processes, membership fees,
> complexities, etc.
>
> As Don said, often the cost of the wiring is the real price. But that
> can depend on where you are (the ratio of electrician hourly rate to
> cable price per meter varies hugely around the world) and the stage the
> building is at. Pulling one more cable while the building is being
> constructed, is practically free. Installing hidden wiring in a
> building in heavy use is massively expensive.
>
> So sometimes using existing Ethernet networks, wireless networks (either
> Wifi or a dedicated wireless network), or even power-line communication
> can be cheaper than wiring.
>
> If you want the newest and coolest solution, try two-wire Ethernet.
> Long-range does 2 km point to point, while short range is (IIRC) 40 m on
> a multi-drop bus - though I haven't seen any PHYs for short range
> two-wire Ethernet as yet.
>
Do you mean 10BASE-T1L and 10BASE-T1S?
Actually my RS485 bus is wired without great care in normal condition:
star, bus, tree or mixed topology.
Does T1L support only point-to-point, i.e. star topology? Is the center
of the star a switch/hub with N ports?
T1S could be great because of multi-drop, but 40m can be limiting.