RS485 bus and auto-addressing

On 04/29/2013 01:26 AM, Vladimir Vassilevsky wrote:

> Assigning addresses in Plug-and-Play manner is only a half of the
> problem. You need to make sure that devices would always be enumerated
> in the same way. Also, the master should somehow identify the roles of
> the devices; i.e. which device does what.

Correct, that's why mentioned that too. But it can help to first 
discover all the devices. If the master knows all the devices, and let's 
say each device has a LED, the master can blink each LED in succession, 
and ask the operator for more information about the device.

> One obvious solution is assigning globally unique ID to every device.
> Like EEPROM with pre-programmed MAC address or serial number.

Yes. I have used that technique before. Each device was programmed with 
a unique ID, and then tagged with a physical label with the same ID. 
After the plug-and-play sequence, the operator could assign a 
name/function to the device using the unique ID as a reference.

Arlet Ottens wrote:

[...]

>Assign each unit a unique serial number. This can be done during 
>manufacturing, or using an external ID chip. If that's too expensive, 
>you can use a random number. For instance, you can use the LSB of an ADC 
>input to generate a random number. If you make the serial number big 
>enough, the chance of duplicates is very unlikely (32 bit for instance). 

Observe the "birthday paradox": With increasing number of nodes you
get an unexpected high probability of collisions!

[...]

>To avoid collision, clients use a random backoff time before sending, 
>and only send when the bus is idle.

"Random backoff" doesn't avoid collisions.

RS485 is IMO not suitable, because it doesn't even support collision
detection with standard transceivers.

There are better solutions. CANopen was mentioned, I've done it also
UART based.

Oliver
-- 
Oliver Betz, Munich http://oliverbetz.de/

On Mon, 29 Apr 2013 08:23:19 +0200, Oliver Betz <OBetz@despammed.com>
wrote:

>
>>To avoid collision, clients use a random backoff time before sending, 
>>and only send when the bus is idle.
>
>"Random backoff" doesn't avoid collisions.

It does not directly avoid collisions, but a s far as I understand,
all RS-485 transceivers are collision tolerant (i.e. doesn't emit he
"magic" smoke) for short collisions. 

>RS485 is IMO not suitable, because it doesn't even support collision
>detection with standard transceivers.

Any message with CRC should give a rejected message when received, if
there is a collision.

>There are better solutions. CANopen was mentioned, I've done it also
>UART based.

CanOpen can be implemented with ordinary RS-485 transceivers by tying
the Transmit Data input to "0" and connecting the actual transmit data
to the Transmit Enable pin, thus, the transmitter will be actively
driven to the Dominant state, while the fail safe termination will
drive the bus to the Recessive state, when the RS-485 transmitter is
disabled. 

On 04/29/2013 08:23 AM, Oliver Betz wrote:

>> Assign each unit a unique serial number. This can be done during
>> manufacturing, or using an external ID chip. If that's too expensive,
>> you can use a random number. For instance, you can use the LSB of an ADC
>> input to generate a random number. If you make the serial number big
>> enough, the chance of duplicates is very unlikely (32 bit for instance).
>
> Observe the "birthday paradox": With increasing number of nodes you
> get an unexpected high probability of collisions!

Yes, but if you know the maximum number of nodes on the bus, you can 
figure out how many ID bits you need to reduce this probability to 
acceptable levels.

>
> [...]
>
>> To avoid collision, clients use a random backoff time before sending,
>> and only send when the bus is idle.
>
> "Random backoff" doesn't avoid collisions.
>
> RS485 is IMO not suitable, because it doesn't even support collision
> detection with standard transceivers.

But the master can detect a collision, and retry the probe request until 
it gets a valid response.

All that you need is bus drivers that don't get physically damaged 
during a collision.

Il 28/04/2013 16:31, Hans-Bernhard Br�ker ha scritto:
> On 27.04.2013 23:33, pozz wrote:
>> I'm thinking about an alternative method to implement in the master
>> that, during the start-up phase, assigns automatically the addresses to
>> the slaves.
>
> For truly identical slaves, that would be somewhat obviously either
> pointless, or impossible.  There must be _something_ that differentiates
> the slaves from each other --- otherwise, why would you have more than
> one in the first place?

The network is a very simple access control.  I have many points where 
users can enter in a protected space if they type a correct "password" 
(in practice, they should have a valid RFID tag).  The logic of the 
system is in a central board (the master on the network).

The central board doesn't need to know where the slaves are positioned, 
because the behaviour of all of them are identical: if a correct 
password is typed, open the gate.  Nothing else.

So the master polls each node if someone is at the gate.  If the slave 
answers with a password, the master check its validity and answer with 
an ack (open the gate), otherwise with a nack (gate is keeped closed).

In this simple scenario, the slaves are effectively identical and should 
be nice if the installer can wire a new slave in the network without 
worrying about addressing methods.



> How best to address individual slaves depends on what that
> differentiating "something" is.  It could be the type of node (--> I2C
> addresssing by device type), a physical ID assigned to the node
> beforehand (--> dip-switch, configurable EEPROM), a universally unique
> ID like in Maxim's 1-wire bus devices, or even just its position along
> the cable connecting all nodes (--> "auto-addressing", "cable select").
>
> So it's really your choice to make, depending on the specifics of your
> situation.

Arlet Ottens wrote:

("birthday paradox")

>Yes, but if you know the maximum number of nodes on the bus, you can 
>figure out how many ID bits you need to reduce this probability to

of course. It just has to be known and calculated, that's what I
wanted to point out.

[...]

>>> To avoid collision, clients use a random backoff time before sending,
>>> and only send when the bus is idle.
>>
>> "Random backoff" doesn't avoid collisions.
>>
>> RS485 is IMO not suitable, because it doesn't even support collision
>> detection with standard transceivers.
>
>But the master can detect a collision, and retry the probe request until 

not necessarily, but in most cases. It's simply not that elegant as
the CAN method (dominant / recessive) since you have to address much
more problems.

Oliver
-- 
Oliver Betz, Munich http://oliverbetz.de/

On 30.04.2013 07:45, pozz wrote:

> The network is a very simple access control.  I have many points where
> users can enter in a protected space if they type a correct "password"
> (in practice, they should have a valid RFID tag).  The logic of the
> system is in a central board (the master on the network).
>
> The central board doesn't need to know where the slaves are positioned,
> because the behaviour of all of them are identical: if a correct
> password is typed, open the gate.  Nothing else.

Actually, the system as described seems overly complex for the task.  If 
there's only one security zone, thus no need to know _which_ door is 
being asked to open, then there's no need for node identification at 
all, thus no need for an addressing scheme.

The master could just as easily poll on a broadcast basis, i.e. "master 
to all slaves: do you have activity?"  Slaves that do, reply with their 
data.  Add collision detection and a randomized back-off mechanism, et 
voila.

On 04/27/2013 08:14 PM, Michael Karas wrote:
> The way I've implemented auto addressing in the past is to arrange the
> serial bus connection to pass through the slave units on a gated pass
> through. Initially all slaves wake up with the pass through gated open.
> This causes just one slave to "see" the master. He gets the first
> address and then after a confirmation step with the master closes his
> pass through. The process repeats till the master realizes that no
> further devices respond on the serial chain. This works like a champ and
> is reliable.

We have a winner!

This is the best solution *AND* it remains within
the original design specs.... unlike other ideas
which ignore the original problem and start chasing
collision detection, etc.  And it can be built so
that the Master does a periodic poll to see if
any new Slave nodes have joined the network.

This one gets printed & placed in my RS-485 folder
for future use.



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

"David K. Bryant" <dbryant_94585@earthlink.net> writes:

> On 04/27/2013 08:14 PM, Michael Karas wrote:
>> The way I've implemented auto addressing in the past is to arrange the
>> serial bus connection to pass through the slave units on a gated pass
>> through. Initially all slaves wake up with the pass through gated open.
>> This causes just one slave to "see" the master. He gets the first
>> address and then after a confirmation step with the master closes his
>> pass through. The process repeats till the master realizes that no
>> further devices respond on the serial chain. This works like a champ and
>> is reliable.
>
> We have a winner!
>
> This is the best solution *AND* it remains within
> the original design specs.... unlike other ideas
> which ignore the original problem and start chasing
> collision detection, etc.  And it can be built so
> that the Master does a periodic poll to see if
> any new Slave nodes have joined the network.

Depends on the application doesn't it? And how the gating is done I
suppose. For example it looks like a node that is switched off or faulty
will bring down the whole network (or a big part of it). May be OK for
systems where everything has to be working at once anyway. But for
something like machine monitoring you need more flexibility.

> This one gets printed & placed in my RS-485 folder
> for future use.

-- 

John Devereux

In article <87vc11iq2l.fsf@devereux.me.uk>, john@devereux.me.uk says...
> "David K. Bryant" <dbryant_94585@earthlink.net> writes:
> 
> > On 04/27/2013 08:14 PM, Michael Karas wrote:
> >> The way I've implemented auto addressing in the past is to arrange the
> >> serial bus connection to pass through the slave units on a gated pass
> >> through. Initially all slaves wake up with the pass through gated open.
> >> This causes just one slave to "see" the master. He gets the first
> >> address and then after a confirmation step with the master closes his
> >> pass through. The process repeats till the master realizes that no
> >> further devices respond on the serial chain. This works like a champ and
> >> is reliable.
> >
> > We have a winner!
> >
> > This is the best solution *AND* it remains within
> > the original design specs.... unlike other ideas
> > which ignore the original problem and start chasing
> > collision detection, etc.  And it can be built so
> > that the Master does a periodic poll to see if
> > any new Slave nodes have joined the network.
> 
> Depends on the application doesn't it? And how the gating is done I
> suppose. For example it looks like a node that is switched off or faulty
> will bring down the whole network (or a big part of it). May be OK for
> systems where everything has to be working at once anyway. But for
> something like machine monitoring you need more flexibility.
> 
I agree.
I've seen too many HI'Z network transceivers get stuck when something 
"bad" happens.  I'm kind of fond of the "Screw Auto detect" and go with 
fixed addresses for special stuff and a couple BCD knobs for everything 
else.  Sure stops a lot of head aches, and if someone is too stupid to 
know how to twist a knob, maybe they shouldn't be installing the thing 
in the first place.