RS485 bus and auto-addressing

[pozz]

I have a small RS485 two-wires network with about ten nodes. I have a
master that initiates the communication on the bus. All the other nodes
are always in receiving state and start transmitting only if the message
from the master is addressed to them.

A simple method to assign an address to a slave is to have a set of
jumpers/dip-switch on the board, but during the installation/setup
phase, the technician must be careful to avoid duplicate addresses.

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.
However, at the moment, I didn't find a good solution.

Any suggestion or experience on this topic?

[Rich Webb]

I don't believe there are any techniques that are guaranteed to
produce unique addresses for each slave if the slaves are otherwise
identical.

An approach that will work most of the time is:

master to slaves: Send "First one to answer is assigned address #1."

slaves: All wait a random interval while listening for another to
claim #1. One (or more!) with the shortest wait time claim #1.

Since there's a non-zero chance that two (or more) slaves replied at
exactly the same time:

master to slaves: Send "Okay, confirm address #1."

slaves: The one (or more) that think it/they has/have #1 wait for
another random interval. The first to speak, gets #1 and the possible
others relinquish it.

Repeat for the remaining addresses. However, I don't believe there is
a way to make the probability exactly zero that more than one slave
does not behave in an identical fashion throughout the process (even
given an arbitrary number of confirmation cycles).

[Michael Karas]

[This followup was posted to comp.arch.embedded and a copy was sent to
the cited author.]

In article <klhg1d$4u7$4...@dont-email.me>, pozz...@gmail.com says...

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.

--

Michael Karas
Carousel Design Solutions
http://www.carousel-design.com

[Reinhardt Behm]

There may be some methods that will work, like some random scheme to assign
addresses.
But you still face the problem how your master will have to know who is who.

If your nodes are otherwise identical, i.e. several temperature sensors, you
need to know which reported temperature belongs to which physical point.

If your nodes are not identical then you could of course assign addresses
using the character of the node.

--
Reinhardt Behm, Bodenheim, Germany
r...@rbehm.de

[upsid...@downunder.com]

On Sat, 27 Apr 2013 23:33:36 +0200, pozz <pozz...@gmail.com> wrote:

>I have a small RS485 two-wires network with about ten nodes. I have a
>master that initiates the communication on the bus. All the other nodes
>are always in receiving state and start transmitting only if the message
>from the master is addressed to them.
>
>A simple method to assign an address to a slave is to have a set of
>jumpers/dip-switch on the board, but during the installation/setup
>phase, the technician must be careful to avoid duplicate addresses.

In addiction DIP switches are unreliable in harsh conditions.

>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.
>However, at the moment, I didn't find a good solution.
>
>Any suggestion or experience on this topic?

If the master has persistent memory and each slave is initially known
slave address (say 255), build the network by adding one node at a
time (e.g. by powering up the devices one by one). The master checks
for slave 255 and assigns it an other slave address. This is repeated
for all slaves.

If a faulty node needs to be replaced, the new replacement unit is
again at address 255 and the master then commands it to the same slave
ID as the original device.

If each slave has a unique vendor:serial_number, either readable
through the ordinary bus or some configuration port there are various
methods.

The address data base could be done by adding one device at a time, as
in the previous case or using some off-line configuration (running on
a laptop) to run a point-to-point connection with a new slave, either
to the network port or through some configuration port and command the
slave address.

Take a look at CanOpen Layer Setting Services (LSS).

-----

If the slave has a unique vendor:sertial_number, generate a hash code
and use it for slave address. The master runs through all possible
slaves by asking e.g. "Slave 37, report your serial". If there is a
timeout, none is there, if there is a garbled reply, there is a
duplicate, there is a collision and if there is a clean response,
assign the address. Repeat the scans but ask "slave 37, report serial
except serial37" and if you got a response, force the slave address to
a free slave address.

If there still are garbled responses, refine your search "Slave 37
report your serial ending in 0" up to serial ending in 9. Of course,
this requires that you are able to differentiated between no response,
garbled response and valid response.

[Arlet Ottens]

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).
Once you have a known good serial number, program it into the
EEPROM/Flash if you have it.

The master then broadcasts a probe:

"any device that's not initialized, please respond with your serial
number".

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

If the master receives a valid response from serial number X, it sends a
packet: "device with serial number X, you are now initialized with bus
ID Y". This device then stops responding to the probe broadcasts.

The master repeats this process until it gets no response. After that,
it can send an occasional probe during normal operation to detect new
attachments to the bus.

Of course, like somebody else remarked, you still may need to figure out
which device is which, depending on your application.

[Les Cargill]

I've never seen a case where the address of a 485 node wasn't part
of the node's configuration identity - we always had to know what
the role of the thing at address <x> was. It therefore had to be
static.

It's also usually preferable to have the address stored on the device
in some way other than dip switches.

--
Les Cargill

[Hans-Bernhard Bröker]

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?

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.

[Vladimir Vassilevsky]

On 4/27/2013 5:35 PM, Rich Webb wrote:
> On Sat, 27 Apr 2013 23:33:36 +0200, pozz <pozz...@gmail.com> wrote:
>
>> I have a small RS485 two-wires network with about ten nodes. I have a
>> master that initiates the communication on the bus. All the other nodes
>> are always in receiving state and start transmitting only if the message
>>from the master is addressed to them.
>>
>> A simple method to assign an address to a slave is to have a set of
>> jumpers/dip-switch on the board, but during the installation/setup
>> phase, the technician must be careful to avoid duplicate addresses.
>>
>> 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.
>> However, at the moment, I didn't find a good solution.
>>
>> Any suggestion or experience on this topic?
>
> I don't believe there are any techniques that are guaranteed to
> produce unique addresses for each slave if the slaves are otherwise
> identical.
>
> An approach that will work most of the time is:
>
> master to slaves: Send "First one to answer is assigned address #1."

[...]

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.

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

The other solution is token ring network topology. The devices are
automatically numbered in their order in the ring. Done that with
RS-232; very simple and elegant.


Vladimir Vassilevsky
DSP and Mixed Signal Designs
www.abvolt.com

[Vladimir Vassilevsky]

On 4/27/2013 10: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 could be done even simpler: use connectors with built-in switch. If
nothing is plugged into the output connector, this device is last in line.

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

Yes, this is simple and works great. But, if a device somewhere in the
middle of the chain is broken, it could cut off all netvork devices behind.

[Arlet Ottens]

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.

[Oliver Betz]

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/

[upsid...@downunder.com]

On Mon, 29 Apr 2013 08:23:19 +0200, Oliver Betz <OB...@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.

[Arlet Ottens]

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.

[pozz]

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.

[Oliver Betz]

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.

[Hans-Bernhard Bröker]

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.

[David K. Bryant]

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: ne...@netfront.net ---

[John Devereux]

"David K. Bryant" <dbryan...@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

[WangoTango]

In article <87vc11i...@devereux.me.uk>, jo...@devereux.me.uk says...

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.

[hamilton]

I am looking at an RS485 network/buss.

Does anyone have a good link for collision detect and timeouts.

Google finds lots, but not very definative.

thanks
hamilton

[upsid...@downunder.com]

While mechanical switches are OK in "friendly" environment (IP20), but
still there are problems with unreliable DIP switches for address
selection.

However, in some harsh environment such as IP65, using an external
mechanical switch for address setting is problematic. Opening the
device in the field for address selection might (let the inert gas out
and) let moisture in, not to mention the risk of damaging the seals by
enclosure opening.

So there are legitimate reasons for avoiding mechanical address
selection switches.

[Grant Edwards]

On 2013-10-14, WangoTango <Asga...@mindspring.com> wrote:

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

That's fine, except that "a couple BCD knobs" can be _very_ expensive
in many environments (e.g. explosion-proof or water-proof
requirements).

--
Grant Edwards grant.b.edwards Yow! I'm into SOFTWARE!
at
gmail.com

[Mike Perkins]

On 15/10/2013 15:31, Grant Edwards wrote:
> On 2013-10-14, WangoTango <Asga...@mindspring.com> wrote:
>
>> 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.
>
> That's fine, except that "a couple BCD knobs" can be _very_ expensive
> in many environments (e.g. explosion-proof or water-proof
> requirements).

Except the address could be programmed using RS485 in a standalone setup.

--
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

[Arlet Ottens]

It's also possible to come up with a design for auto detect that doesn't
demand any additional reliability compared to normal communication.

[Grant Edwards]

True, but now you've added a device commissioning step that has to be
done on a bench somewhere.

--
Grant Edwards grant.b.edwards Yow! Did I do an INCORRECT
at THING??
gmail.com

[Fredxx]

I was merely thinking of a way to eliminate switches and knobs.

Any reliability will be down environmental noise and judicious use of
CRCs. The CRC for setting the address could even be different to one
used in normal communications.

[Fredxx]

It would be relatively easy to incorporate all the RS485 and programming
utility in a small enclosure with a few AA batteries for field programming.

It all depends on whether you want DIP switches or other means of
setting the address?

[Mike Perkins]

On 15/10/2013 19:35, Arlet Ottens wrote:

I was thinking of simplicity where peripherals are dumb units, where all
each unit needs to do is match an address and accept the data, and
possibly transmit a reply.

The alternative is to program each peripheral with details of its
functionality, to tell the master what it is, and have the provision for
reducing effects of clashes and cope with power-downs / brown-outs
(forgetting address) etc.

I've always liked the simple approach for overall system reliability.

[Les Cargill]

We do it after the devices are installed. It is a pain, but it's only
done once for the life of the device. I put an "autodetect" design
on paper, but it got deprioritized, and would be almost as much trouble
as programming the devices one by one anyway. You have to
connect them one at a time, walk to the master controller, do stuff off
a sheet, repeat lather rinse. And if you make a mistake,
it's no fun to debug.

--
Les Cargill

[Arlet Ottens]

Sure, reliable communications and setup require a bit of extra software.
However, dip switches and other configuration require a bit of extra
hardware, and manual configuration on the bench requires extra operator
steps. Getting a human operator involved is likely to introduce more
errors in the system than having an automatic procedure.

[Mike Perkins]

I've never known a RS485 system put together by the client himself, and
whilst my knowledge is limited to security, an installer will generally
set the addresses as per the customer's needs on site. He'd also ensure
that termination was appropriate to the wiring style of the network.

The installer wouldn't leave the job unless it was all working.

To be honest, the idea of plug and play automatic process on a RS485
network fills me with horror.

[Arlet Ottens]

On 10/16/2013 09:15 PM, Mike Perkins wrote:

>>
>> Sure, reliable communications and setup require a bit of extra software.
>> However, dip switches and other configuration require a bit of extra
>> hardware, and manual configuration on the bench requires extra operator
>> steps. Getting a human operator involved is likely to introduce more
>> errors in the system than having an automatic procedure.
>
> I've never known a RS485 system put together by the client himself, and
> whilst my knowledge is limited to security, an installer will generally
> set the addresses as per the customer's needs on site. He'd also ensure
> that termination was appropriate to the wiring style of the network.
>
> The installer wouldn't leave the job unless it was all working.
>
> To be honest, the idea of plug and play automatic process on a RS485
> network fills me with horror.

It doesn't have to be any different. Installer comes to the site, plugs
in RS485 unit, and verifies that it is automatically detected and that
everything is working correctly.

[hamilton]

How many devices are usually in a building network ?

How fast do those device enumerate with the master ?

Is this discussion about a trivial function that takes a few minutes at
most during install, and can be re-done automatically ever few hours
with out intervention ?


Seems like a problem that is not a problem.

hamilton

[Arlet Ottens]

The answers depend entirely on the situation, of course. Some networks
are pretty much fixed after initial installation. Others support hot
plugging by the user, and require new devices to be recognized and
running within seconds.

[WangoTango]

In article <l3i1ro$53s$1...@dont-email.me>, hami...@nothere.com says...

It's really dependent on your application.
Things like turn around time and maximum inter-byte spacing are just the
beginning. How much data are you sending and how often at what rate.
You know your problem domain better than anyone here.

[WangoTango]

In article <akhp59tc925681mm7...@4ax.com>,
upsid...@downunder.com says...

Sure, but is this one of those cases?
And I've seen some really nice 'O' Ring sealed and internally lubed BCD
switches that would be pretty hard to screw up.

[WangoTango]

In article <l3jjkr$j8i$1...@reader1.panix.com>, inv...@invalid.invalid
says...

> On 2013-10-14, WangoTango <Asga...@mindspring.com> wrote:
>
> > 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.
>
> That's fine, except that "a couple BCD knobs" can be _very_ expensive
> in many environments (e.g. explosion-proof or water-proof
> requirements).
>
>

OK, but *I* don't have to worry about that and the OP is pretty sketchy
on just WHY this is needed, or maybe I missed that part of the thread.
You can cherry pick specific reason why my suggestion won't work, but
for a shit load of cases, it's just fine.

[Grant Edwards]

On 2013-10-18, WangoTango <Asga...@mindspring.com> wrote:

>> So there are legitimate reasons for avoiding mechanical address
>> selection switches.
>
> Sure, but is this one of those cases? And I've seen some really nice
> 'O' Ring sealed and internally lubed BCD switches that would be
> pretty hard to screw up.

But have you paid for any of those switches? :)

[WangoTango]

In article <l3u7np$a1k$2...@reader1.panix.com>, inv...@invalid.invalid
says...

Yes, I have, and we do.
Small price to pay for a reliable system.

[f.mo...@bassocosto.it]

> Any suggestion or experience on this topic?

My suggestion is to avoid the collision check cause rs485 was not designed to detect a collision in a reliable way. Of course you could design your own hardware, but commercial tansceivers ICs are not suitable.

So let's immagine a simple scenario for both the addressing and the installer.

The master device will turn on and do this:

1) Broadcast (address 0) an hello message
2) Waits for replies
3) If someone replies "I'm new" send the address in broadcast
4) Do stuffs addressing slaves (his main job)
5) Waits for the answer
6) go to 1

The slave device will turn on and do this:

1) Do I have an address?
If NO switch to wait for address state
else we are in normal slave mode
2) Waits to be addressed
3) Answer request
4) go to 2

In "wait for an address state":

1) Wait for master hello
2) Reply "I'm new"
3) Wait for the address broadcasted
4) switch to normal slave mode


The scenario is simplified 'cause the only fullfillment you should take is to connect one new device at a time. Maybe you can provide an address reset button in each slave to be readdressed and a massive ping in the master loop to find who's lost.

[hamilton]

Adding one slave at a time may not be practical.
A large building with many sensors can not have someone waiting at each
location to connect their sensor.

I would add to you psudo-code:

1. Broadcast "Hello" message
2. wait for replies
3. All new devices will broadcast "I'm new"
4. master will detect something has responded, but will not understand
that new message.
If( many new devices attached)
{ enter a successive approximation function
address each new node separately.
}

5 etc...

Creating code in the master and slave to respond to addresses like:
Does any un-configured slave have an address with the highest bit set ?
yes/no
Does any un-configured slave have an address with the second highest
bit set ?

etc, until all device have been configured.

This may sound complicated, but it does work.
( been there, done that :-) )

Good Luck

[John Devereux]

hamilton <hami...@nothere.com> writes:


[...]

>
> Adding one slave at a time may not be practical.
> A large building with many sensors can not have someone waiting at
> each location to connect their sensor.
>
> I would add to you psudo-code:
>
> 1. Broadcast "Hello" message
> 2. wait for replies
> 3. All new devices will broadcast "I'm new"
> 4. master will detect something has responded, but will not
> understand that new message.

Is it guaranteed not to understand? What if one driver is
closer/stronger and "wins"?

> If( many new devices attached)
> { enter a successive approximation function
> address each new node separately.
> }
>
> 5 etc...
>
> Creating code in the master and slave to respond to addresses like:
> Does any un-configured slave have an address with the highest bit set ?
> yes/no
> Does any un-configured slave have an address with the second
> highest bit set ?
>
> etc, until all device have been configured.
>
> This may sound complicated, but it does work.
> ( been there, done that :-) )
>
> Good Luck
>

--

John Devereux

[hamilton]

On 12/18/2013 11:00 AM, John Devereux wrote:
> hamilton <hami...@nothere.com> writes:
>
>
> [...]
>
>>
>> Adding one slave at a time may not be practical.
>> A large building with many sensors can not have someone waiting at
>> each location to connect their sensor.
>>
>> I would add to you psudo-code:
>>
>> 1. Broadcast "Hello" message
>> 2. wait for replies
>> 3. All new devices will broadcast "I'm new"
>> 4. master will detect something has responded, but will not
>> understand that new message.
>
> Is it guaranteed not to understand? What if one driver is
> closer/stronger and "wins"?

Well, lets think this thru.

Master says "Whos New?<cksum>" That's 10 bytes, at 9600 baud, that's
more then 10 mSec before the sensors sees all the bytes and responds.

Three new devices respond, "I'm New!<cksum>" That's 9 bytes. at 9600
baud that's more then 9 mSecs before the master knows what happened.

Even if the response is just one byte, each sensor device can respond
within 100 uSec ( 1 bit time) and the rest of that one byte will be garbled.

With three (or more ) devices responding, that single byte <cksum> at
the end will be wrong.

So unless the sensors are very slow, there will be a collision and the
last byte will be wrong.

Having done this type of RS-485 system, I know it works.

Yes, the code on the sensors and in the master is complicated, but a new
device can be added at any time and the system will just automagically
deal with it.

Our system sends out a "Whos New!" message every 10 seconds.
Most of the time its a timeout as there is no new devices.

By the time the installer (new or replacement) walks back to the main
console, its connected.

This is not rocket science.

hamilton

[Robert Wessel]

On Wed, 18 Dec 2013 18:00:56 +0000, John Devereux
<jo...@devereux.me.uk> wrote:

>hamilton <hami...@nothere.com> writes:
>
>
>[...]
>
>>
>> Adding one slave at a time may not be practical.
>> A large building with many sensors can not have someone waiting at
>> each location to connect their sensor.
>>
>> I would add to you psudo-code:
>>
>> 1. Broadcast "Hello" message
>> 2. wait for replies
>> 3. All new devices will broadcast "I'm new"
>> 4. master will detect something has responded, but will not
>> understand that new message.
>
>Is it guaranteed not to understand? What if one driver is
>closer/stronger and "wins"?

It's only necessary to be able to reasonably reliably detect that
someone has answered. The proper way to do the query is to specify a
range in which you'd like devices to respond. For example, let's say
you have a sixteen bit serial number (too short, but it keeps the
example short). The first "Are You There" query would specify
0x0000-0xffff, so any device would respond. If the host got no
response, it's done. If it got a good response* (say 0x1234: "I'm
Here"), then it would record that and then re-query for the ranges
left and right of the response (IOW, 0x000-0x1233 and 0x1235-0xffff).
If it got a gibberish response (a collision), it would simply split
the range in two (IOW, a binary search) and re-query thosesub ranges
(IOW, 0x0000-0x7fff and 0x8000-0xffff). The process repeats until all
queried subranges return nothing.

The performance is usually only slightly worse than linear with the
number of devices to find, although you can construct pathological
cases where it's O(n*lg(m)), where m is the number of possible serial
numbers. So much longer serial numbers have only modest impact.

Repeating the whole process several times can help compensate for less
than perfect collision detection.

If you don't have a reasonable chance of detecting a collision, the
problem is much harder.


*Either because that was the only device in the subrange, or it
"overpowered" all the other devices in the subrange, and the host got
a good message from it.

[John Devereux]

Hi Robert,

Yes, that was the possibility I was concerned about. The
nearest/strongest RS485 driver might *always* win. But as long as the
master can detect a response at all, I guess the successive
approximation algorithm still works, when you use the serial number as a
guaranteed unique node number.



--

John Devereux

[Richard Damon]

If I was going to try something like this, and had control over the
protocol, I would have the master broadcast a message meaning something
like "Any new devices with serial numbers between x and y), and the
response would be a message of a break character or a series of nulls.
Don't try to send any information except for something marking yes and
just detect that something was sent. Since RS485 doesn't have "Dominant"
state, collision detection is unreliable.

RS485 buses are generally biased to a 1, so when nobody drives them you
get an inter-character space. When a device wants to talk, it enables it
driver (forcing the bus to the 1 state) and then starts sending its
data. When done, it again forces the bus to the 1 state for a little bit
then releases the bus. As long as the initial drive time before the
character being sent is well less then the time of a character, the
sending of a null or break character WILL be seen (as something) by the
receiver even if multiple units respond. If the initial enable time is
as long or longer than a character time, you will need to send a long
break, of duration longer than preamble time

Note that if you have differing devices on the bus, then each device
needs to send a bus low for longer than the longest allowed preamble time.

[upsid...@downunder.com]

If you have full control of all devices on the bus, why not run it as
a CAN bus style Dominant/Recessive system. Simply connect th Tx-data
also to the Driver Enable (DE). When transmitting idle or "1" the bus
is in "1" recessive state (driver disabled) due to "fail safe"
termination. When sending "0", the driver is activated and the bus is
driven to the dominant "0" state.

In order to also have collision detected, you need an RS-485 chip with
an independent Rx-Enable pin that is driven constantly ON.

This was how CANbus systems were initially implemented prior to real
CAN driver chips.

[John Devereux]

Great, yes that should work. Trying to send more information, or detect
collisions in the response confuses the issue, because then you need to
worry about what happens if the information is garbled or if collision
is not detected.

The other pathological case would be an unbiased bus, but that can be
avoided.



--

John Devereux

[Richard Damon]

On 12/22/13, 3:44 AM, John Devereux wrote:

> The other pathological case would be an unbiased bus, but that can be
> avoided.
>
>
>

An RS485 bus that is left unbiased should not be used in a system that
has any significant time undriven. The issue being that being unbiased
if left floating it can very well generate "noise" characters, so you
need a lot more checking in the system.