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

Groups > comp.arch.embedded > #30374 > unrolled thread

Multi-master RS485

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#30396

On 3/30/2021 3:34 PM, pozz wrote:
> 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.

Ethernet and industrial variants.  The cost of running the cable typically
far exceeds the cost of the device(s) placed along the cable!

And, bandwidth is sort of like disk space -- there's always SOMETHING
you can use it for!

[toc] | [prev] | [next] | [standalone]

#30397

On Wed, 31 Mar 2021 00:34:45 +0200, pozz <pozzugno@gmail.com> 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.

In CanOpen (a protocol built on CAN) has one option of transferring
127 x 7 bytes or up to 889 bytes before being acknowledged. These big
transfers run with low priority identifiers, so it does not delay high
priority messages during the big and slow transfer.
 
>
>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.

With standard 1 Unit Load (UL) RS-485 transceivers, you can only have
31 slaves on the bus. You would need 1/2 UL or 1/4 UL transceivers to
run such networks. It would be better to have multiple serial ports on
the master and split the network between 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.

[toc] | [prev] | [next] | [standalone]

#30398

On 2021-03-31 upsidedown@downunder.com wrote in comp.arch.embedded:
> On Wed, 31 Mar 2021 00:34:45 +0200, pozz <pozzugno@gmail.com> wrote:
[RS485 home/building automation system]
>>
>>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.
>
> With standard 1 Unit Load (UL) RS-485 transceivers, you can only have
> 31 slaves on the bus. You would need 1/2 UL or 1/4 UL transceivers to
> run such networks. It would be better to have multiple serial ports on
> the master and split the network between them.

Splitting up the network may also make your cabling easier. If you use
a single 485 bus for the entire building, your single cable has to pass
every node and has to go in and out every room. And when installing
additional nodes, they have to be placed in te same loop. Cable length
will also be an issue with such a setup. A single break in the cable
disables the entire network and you have no easy way to determine where
to start looking for the fault. 

With a single controller with multiple ports, you can poll all ports
simultaneously.

You can also create a tree network, but that requires additional branch
controllers. Have for example a central controller connected to the 
trunk and then a branch controller on each floor/room. With 10 branch
controllers, the master only has to poll 10 nodes. And if you have 10
nodes on each branch, the branch controllers also have to poll only 10
nodes. So you still poll 100 end nodes, but in 1/10th of the time. And
because you require shorter bus cables, the baudrate can be increased
as well, further reducing required poll time.

-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Do you guys know we just passed thru a BLACK HOLE in space?

[toc] | [prev] | [next] | [standalone]

#30399

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.

[toc] | [prev] | [next] | [standalone]

#30400

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.

[toc] | [prev] | [next] | [standalone]

#30403

On 31/03/2021 12:27, pozz wrote:
> Il 31/03/2021 10:23, David Brown ha scritto:

>> 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?
> 

Yes, that's it.

> Actually my RS485 bus is wired without great care in normal condition:
> star, bus, tree or mixed topology.

That can be fine, if the bus is short enough with a small enough loading
in comparison to the speed.  (Another thing I have done long in the past
to make wiring easier is support auto-swapping of D+ and D-, correcting
some wiring errors automatically.)

> 
> Does T1L support only point-to-point, i.e. star topology? Is the center
> of the star a switch/hub with N ports?
> 

Yes, AFAIK.  I haven't used it yet, however.

Of course you could have switches anywhere, giving you a tree just like
normal Ethernet.

You can drive power over the two lines as well.

> T1S could be great because of multi-drop, but 40m can be limiting.

It's hard to get /everything/ you want from a bus!

[toc] | [prev] | [next] | [standalone]

#30401

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.
> 

Another question on 10BASE-T1L. What is the complexity of a single node?

Actually RS485 can be managed by a very cheap MCU with a simple embedded 
UART and a very cheap external half-duplex transceiver.

What will I need to have 10BASE-T1L in a node? I think at the minimum an 
Ethernet MAC and an external T1L transceiver.

[toc] | [prev] | [next] | [standalone]

#30404

On 31/03/2021 13:39, pozz wrote:
> Il 31/03/2021 10:23, David Brown ha scritto:

(Appropriate snipping makes Usenet much nicer!)

>> 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.
>>
> 
> Another question on 10BASE-T1L. What is the complexity of a single node?
> 

It's 10 Mbps Ethernet.  You need something that has an Ethernet MAC.

> Actually RS485 can be managed by a very cheap MCU with a simple embedded
> UART and a very cheap external half-duplex transceiver.

You'll need a few dollars for the MCU, and I think the PHY's are about
three dollars last I looked.  Expect prices to come down as popularity
and competition increases.  Ethernet on an MCU is not expensive these
days, but it's still a good deal more than RS-485.

> 
> What will I need to have 10BASE-T1L in a node? I think at the minimum an
> Ethernet MAC and an external T1L transceiver.
> 

Yes.

[toc] | [prev] | [next] | [standalone]

#30406

On 3/31/2021 4:39 AM, pozz wrote:
> Another question on 10BASE-T1L. What is the complexity of a single node?

There are lots of ways to evaluate complexity.

Your hardware costs (for the "slaves") will likely increase.  You will
also likely incur the cost of a switch -- which may also impact deployment
logistics and costs (e.g., if you were hoping to daisy chain from one
node to the next NEARBY node, a switch forces duplication of cable).

You'll need an MCU with a MAC and, hopefully, external PHY interface.
Then, the actual PHY, itself.

Your software complexity will likely increase at the driver level.
Instead of a Linux "master" and /ad hoc/ slaves, you will likely run
something *like* Linux on the slaves, as well (to benefit from the
network stack).

OTOH, the whole polling issue becomes moot.  It's just as easy
(and reliable/scalable) to have each "slave" act as initiator
when *it* wants to talk to the "master" (let's call it a "controller"
and them, "motes")

Depending on the power requirements of your motes, you may be able
to source power centrally (from the switch) and thus eliminate the
need for locally sourced power at each mote.

[It is incredibly liberating to be able to place a mote anywhere
that is convenient -- instead of having to make considerations
for how you'll access power.  E.g., I have devices up at ceiling level,
inside walls, *above* the ceiling, etc.  I have neither the
unsightliness of "power supplies" scattered all around -- nor the
regulatory issues (e.g., hidden boxes).  Likewise, one less
aspect of an attack surface]

You may end up rethinking the application's feature set.  E.g.,
perhaps you incorporate provisions for two-way audio (intercom)
between each mote and ????.  Or, a fingerprint sensor -- with
the authentication performed by transferring the image to the
controller at the enhanced throughput available.

With (likely) more smarts at a mote, there are other options
available to enhance reliability.  I.e., what happens when your
controller is not accessible (perhaps the network has been subverted
or the controller has crashed or the system is in overload)?

> Actually RS485 can be managed by a very cheap MCU with a simple embedded UART 
> and a very cheap external half-duplex transceiver.

If your focus is exclusively on the (recurring) cost of comms, you
will end up chasing an /ad hoc/ bastardization of *some* protocol
to "make it work".  You should, instead (IMO) think about what you can
do with a different capability suite.

> What will I need to have 10BASE-T1L in a node? I think at the minimum an 
> Ethernet MAC and an external T1L transceiver.

[toc] | [prev] | [next] | [standalone]

#30402

On Wed, 31 Mar 2021 10:23:43 +0200, David Brown
<david.brown@hesbynett.no> wrote:

>On 31/03/2021 00:34, pozz wrote:

 
>> 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.  

If you try to run CAN at 1 Mbit/s it is quite critical with limited
distance and strict rules how long branches you can connect from the
main bus. Ideally the main bus should be routed through all nodes
without branch cables.

At 250 kbits/s you can still run about 250 m and the branch lengths
are not that critical. Should be sufficient for home automation,

>And CANOpen and other "standards" look like
>they were designed specifically to be as complex and inefficient as
>possible.)  

CanOpen is great for setting up the system with EDS (Electronic Data
Sheet) or inquiring the node capabilities with SDOs request messages.

For real-time communication the PDOs are mapped directly to real-time
CAN-frames, so no performance issues.

>For a short range, small message bus on a closed network
>entirely under your control, CAN is great.

I  assumed that the OP is designing both the master and slaves.

>> 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.

I have designed both CAN as well as RS-485 networks with 60 - 100
nodes and in practice, most problems were related to the electro-
mechanical reliability of the cabling harnesses.

For this reason, it is a good idea to split the network  into multiple
segments, each with own independent master.

If the master doesn't have sufficient number of serial ports one
solution is to connecting multiple Ethenet/RS-485 or Ethernel/CANbus
converters with ordinary Ethernet cabling and Ethernet switches. This
may also simplify RS-485 or CAN cable length issues by inserting the
converters closer to the nodes,

[toc] | [prev] | [next] | [standalone]

#30405

On 31/03/2021 14:29, upsidedown@downunder.com wrote:
> On Wed, 31 Mar 2021 10:23:43 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 31/03/2021 00:34, pozz wrote:
> 
>  
>>> 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.  
> 
> If you try to run CAN at 1 Mbit/s it is quite critical with limited
> distance and strict rules how long branches you can connect from the
> main bus. Ideally the main bus should be routed through all nodes
> without branch cables.

Yes.

You can be a little loser if you can impose some rules on the messages
you send (like avoiding collisions).

> 
> At 250 kbits/s you can still run about 250 m and the branch lengths
> are not that critical. Should be sufficient for home automation,

I wouldn't want to rely on CAN for anything like that distance/speed
combination - my experience is not as good.  However, there are all
kinds of details involved such as the type of cable, grounding, driver
power, EMC protection, etc.

> 
>> And CANOpen and other "standards" look like
>> they were designed specifically to be as complex and inefficient as
>> possible.)  
> 
> CanOpen is great for setting up the system with EDS (Electronic Data
> Sheet) or inquiring the node capabilities with SDOs request messages.
> 
> For real-time communication the PDOs are mapped directly to real-time
> CAN-frames, so no performance issues.
> 
>> For a short range, small message bus on a closed network
>> entirely under your control, CAN is great.
> 
> I  assumed that the OP is designing both the master and slaves.
> 
>>> 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.
> 
> I have designed both CAN as well as RS-485 networks with 60 - 100
> nodes and in practice, most problems were related to the electro-
> mechanical reliability of the cabling harnesses.
> 
> For this reason, it is a good idea to split the network  into multiple
> segments, each with own independent master.
> 

Agreed.

> If the master doesn't have sufficient number of serial ports one
> solution is to connecting multiple Ethenet/RS-485 or Ethernel/CANbus
> converters with ordinary Ethernet cabling and Ethernet switches. This
> may also simplify RS-485 or CAN cable length issues by inserting the
> converters closer to the nodes,
> 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web