Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #30400

Re: Multi-master RS485

Show all headers | View raw

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.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:27 +0100
  Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:33 -0700
    Re: Multi-master RS485 Grant Edwards <invalid@invalid.invalid> - 2021-03-25 16:38 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 09:57 -0700
      Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-25 20:28 +0100
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-25 17:57 +0100
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-25 10:04 -0700
  Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-25 19:02 +0200
  Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-26 15:54 +0000
    Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-28 00:37 +0100
      Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-27 20:14 -0400
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 07:32 +0300
          Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 07:20 -0400
            Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-28 14:59 +0300
              Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 08:09 -0400
      Re: Multi-master RS485 antispam@math.uni.wroc.pl - 2021-03-28 02:01 +0000
      Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-27 19:57 -0700
      Re: Multi-master RS485 Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2021-03-28 15:52 +0200
        Re: Multi-master RS485 Richard Damon <Richard@Damon-Family.org> - 2021-03-28 13:06 -0400
      Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 00:34 +0200
        Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-30 18:51 -0700
        Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 06:42 +0300
          Re: Multi-master RS485 Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2021-03-31 09:50 +0200
        Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 10:23 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 12:27 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:43 +0200
          Re: Multi-master RS485 pozz <pozzugno@gmail.com> - 2021-03-31 13:39 +0200
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:46 +0200
            Re: Multi-master RS485 Don Y <blockedofcourse@foo.invalid> - 2021-03-31 06:20 -0700
          Re: Multi-master RS485 upsidedown@downunder.com - 2021-03-31 15:29 +0300
            Re: Multi-master RS485 David Brown <david.brown@hesbynett.no> - 2021-03-31 14:49 +0200

csiph-web