Multi-master RS485

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.

I'm thinking to "improve" this bus with a multi-master approach, but it 
doesn't appear simple. Do you know of real and working implementation of 
this type on half-duplex RS485 bus?

On 3/25/2021 9:27 AM, pozz 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.
> 
> I'm thinking to "improve" this bus with a multi-master approach, but it doesn't 
> appear simple. Do you know of real and working implementation of this type on 
> half-duplex RS485 bus?

Sure!  An easy way is to time-division-multiplex the bus and assign
specific slots to specific nodes.

You can also use a token-passing protocol to select the next master.

You have to address start-up issues to initialize the first
set of accesses.  And, you have to include provisions to handle
the case where things go wonky and resynchronization becomes
necessary.

But, you *can* handle things like a device failing to pass the token
or skipping its timeslot in the "normal" protocol.

Note that any approach requires pre-configuration; you can't just
arbitrarily add nodes to the bus and expect them to arbitrate
access (like CD/MA).

[This is a minor lie -- but, autoconfiguration is not trivial]

On 2021-03-25, Don Y <blockedofcourse@foo.invalid> wrote:
> On 3/25/2021 9:27 AM, pozz wrote:

>> Are there any *real* implementation of multi-master half-duplex RS485 bus?

> Sure!  An easy way is to time-division-multiplex the bus and assign
> specific slots to specific nodes.
>
> You can also use a token-passing protocol to select the next master.
>
> You have to address start-up issues to initialize the first
> set of accesses.  And, you have to include provisions to handle
> the case where things go wonky and resynchronization becomes
> necessary.
>
> But, you *can* handle things like a device failing to pass the token
> or skipping its timeslot in the "normal" protocol.
>
> Note that any approach requires pre-configuration; you can't just
> arbitrarily add nodes to the bus and expect them to arbitrate
> access (like CD/MA).
>
> [This is a minor lie -- but, autoconfiguration is not trivial]

Since the OP didn't specify async UARTs, I might mention that you can
CAN controllers with a half-duplex RS485 physical layer but it's a bit
of hack and easier to just use real CAN transceivers.

--
Grant

Il 25/03/2021 17:33, Don Y ha scritto:
> On 3/25/2021 9:27 AM, pozz 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.
>>
>> I'm thinking to "improve" this bus with a multi-master approach, but 
>> it doesn't appear simple. Do you know of real and working 
>> implementation of this type on half-duplex RS485 bus?
> 
> Sure!� An easy way is to time-division-multiplex the bus and assign
> specific slots to specific nodes.

This means assigning a predefined slot duration for each node. What 
happens if a node wants to transmit a big packet? It should split packet 
in multiple consecutive slots.

Moreover, is time-division-multiplex efficient? Now with master-slave 
polling mechanism I already have a time-division-multiplex: for each 
slave there's a time window in which master sends the token and slave 
reply with token (and probably data).
With a pure time-division-multiplex I will save only the time of the 
master request.


> 
> You can also use a token-passing protocol to select the next master.

Same, each node is an "active" node in every loop. I imagine a bus that 
is idle for most of the time and busy only when a node wants to transmit 
something.
In my case real data are very low. Anyway I have to face the event of a 
conflict.


> You have to address start-up issues to initialize the first
> set of accesses.� And, you have to include provisions to handle
> the case where things go wonky and resynchronization becomes
> necessary.
> 
> But, you *can* handle things like a device failing to pass the token
> or skipping its timeslot in the "normal" protocol.

This is why I'm searching a "ready-to-use" protocol, if any.


> Note that any approach requires pre-configuration; you can't just
> arbitrarily add nodes to the bus and expect them to arbitrate
> access (like CD/MA).
> 
> [This is a minor lie -- but, autoconfiguration is not trivial]

On 3/25/2021 9:38 AM, Grant Edwards wrote:
> On 2021-03-25, Don Y <blockedofcourse@foo.invalid> wrote:
>> On 3/25/2021 9:27 AM, pozz wrote:
> 
>>> Are there any *real* implementation of multi-master half-duplex RS485 bus?
> 
>> Sure!  An easy way is to time-division-multiplex the bus and assign
>> specific slots to specific nodes.
>>
>> You can also use a token-passing protocol to select the next master.
>>
>> You have to address start-up issues to initialize the first
>> set of accesses.  And, you have to include provisions to handle
>> the case where things go wonky and resynchronization becomes
>> necessary.
>>
>> But, you *can* handle things like a device failing to pass the token
>> or skipping its timeslot in the "normal" protocol.
>>
>> Note that any approach requires pre-configuration; you can't just
>> arbitrarily add nodes to the bus and expect them to arbitrate
>> access (like CD/MA).
>>
>> [This is a minor lie -- but, autoconfiguration is not trivial]
> 
> Since the OP didn't specify async UARTs, I might mention that you can
> CAN controllers with a half-duplex RS485 physical layer but it's a bit
> of hack and easier to just use real CAN transceivers.

CAN is considerably more flexible, in that regard.

The OP can (if the application lends itself) just create one
big "frame" initiated by the master and let all of the slaves
slip their contributions in at the appropriate places
(without having to formally take ownership of the bus) as
well as peeling-off any data intended for their consumption.

But this seems like a design decision that should have been
made early on; not shoehorned in after the design has begun!

On Thu, 25 Mar 2021 17:27:34 +0100, pozz <pozzugno@gmail.com> wrote:

>Are there any *real* implementation of multi-master half-duplex RS485 bus?

For instance Profibus-DP. Usually one master is used for real-time
data, while the other is mainly used for configuration.  A token is
passed between masters, so each master knows when it is allowed to
access the slaves.

On 3/25/2021 9:57 AM, pozz wrote:
> Il 25/03/2021 17:33, Don Y ha scritto:
>> On 3/25/2021 9:27 AM, pozz 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.
>>>
>>> I'm thinking to "improve" this bus with a multi-master approach, but it 
>>> doesn't appear simple. Do you know of real and working implementation of 
>>> this type on half-duplex RS485 bus?
>>
>> Sure!  An easy way is to time-division-multiplex the bus and assign
>> specific slots to specific nodes.
> 
> This means assigning a predefined slot duration for each node. What happens if 
> a node wants to transmit a big packet? It should split packet in multiple 
> consecutive slots.

Or, the next node defers claiming it's timeslot until it senses the bus has
gone idle.

You have to decide how much you want to put in the lower level protocol
and how much you're willing to put *above* it (e.g., packet reassembly)

> Moreover, is time-division-multiplex efficient? Now with master-slave polling 
> mechanism I already have a time-division-multiplex: for each slave there's a 
> time window in which master sends the token and slave reply with token (and 
> probably data).
> With a pure time-division-multiplex I will save only the time of the master 
> request.

It depends on how big your packets are, how high the bus utilization, etc.
Only *you* can make that determination, from *your* application.

>> You can also use a token-passing protocol to select the next master.
> 
> Same, each node is an "active" node in every loop. I imagine a bus that is idle 
> for most of the time and busy only when a node wants to transmit something.
> In my case real data are very low. Anyway I have to face the event of a conflict.

If there is nothing to transmit, a node just sends a "keep alive" packet.
This also lets other nodes know that the network (and other devices on it)
are intact.

[When should a node "get nervous" that it hasn't been polled, "recently"?]

>> You have to address start-up issues to initialize the first
>> set of accesses.  And, you have to include provisions to handle
>> the case where things go wonky and resynchronization becomes
>> necessary.
>>
>> But, you *can* handle things like a device failing to pass the token
>> or skipping its timeslot in the "normal" protocol.
> 
> This is why I'm searching a "ready-to-use" protocol, if any.

Dunno.  I always roll a protocol that is appropriate for the
application.  That lets me tailor it to get the best performance
for the cost invested.  (my designs are closed so I don't have
to worry about something being *added*, arbitrarily, at a later
date)

The exercise of thinking about the protocol often reveals
vulnerabilities in the design; "what if node X doesn't
take its time slot?  what does that mean for the system,
as a whole?  should the other nodes be able to independantly
detect this and bring the system to a safe/secure state
WITHOUT waiting for the master to command them to do so?"

(what does it *mean* when X is misbehaving?)

On 25/03/2021 17:38, Grant Edwards wrote:
> On 2021-03-25, Don Y <blockedofcourse@foo.invalid> wrote:
>> On 3/25/2021 9:27 AM, pozz wrote:
> 
>>> Are there any *real* implementation of multi-master half-duplex RS485 bus?
> 
>> Sure!  An easy way is to time-division-multiplex the bus and assign
>> specific slots to specific nodes.
>>
>> You can also use a token-passing protocol to select the next master.
>>
>> You have to address start-up issues to initialize the first
>> set of accesses.  And, you have to include provisions to handle
>> the case where things go wonky and resynchronization becomes
>> necessary.
>>
>> But, you *can* handle things like a device failing to pass the token
>> or skipping its timeslot in the "normal" protocol.
>>
>> Note that any approach requires pre-configuration; you can't just
>> arbitrarily add nodes to the bus and expect them to arbitrate
>> access (like CD/MA).
>>
>> [This is a minor lie -- but, autoconfiguration is not trivial]
> 
> Since the OP didn't specify async UARTs, I might mention that you can
> CAN controllers with a half-duplex RS485 physical layer but it's a bit
> of hack and easier to just use real CAN transceivers.
> 

The first CAN transceivers were basically RS-485 transceivers with the
CAN TX line connected to the driver's transmit enable input, the
driver's receive enable always on, and the driver's data in line
connected to 0.

You can also use UARTs along with CAN transceivers.  (I worked with a
propriety protocol like that a good while ago - it was a slightly odd
bus that evolved gradually from a Dallas one-wire bus.)

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

-- 
                              Waldek Hebisch

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.