Autodetect slave devices on a bus network (RS485)

I think you have to consider the situation where several slaves reply together, but one "wins" (because it has stronger drivers or is closer). So that replies get lost without any error detected.

You could build in a random reply time delay element (seeded with the serial number perhaps).

Or consider switching to CAN if that is still possible, which has arbitration built-in.

--

John Devereux

If you get a clean response, this slave should be locked out (not respond) to any further searches.

You may have to run this bit search a few times, each time locking out any successful matches, until there are no conflicts.

Regarding collisions, with some CANbus style dominat/recessive style RS-485 like communication, it should be possible to detect one station correctly and lock it out from the search and try again.

Yes, if two slaves answer at exactly the same time, this could be a problem . One answer could hide the other.

As you suggest later, I can add a delay (calculated from the serial number) to the answer, but there's a not-null probability the delay time for two s laves on the bus are the same. So those slaves will answer always at the sa me time and the problem remains.

I have to use a RS485.

Not really. If you make the backoff unit time greater than the reply message length / time, then you guarantee that reply frames never overlap, assuming that all serial numbers are unique...

Chris

A much better way is to stick closer to the 1-wire discovery algorithm.

First, ask on the bus if there are any slaves with 0 in bit 0. All slaves that want to answer, should check the bus for communication (i.e., check that they are not currently reading a byte, and check that the UART start bit is not on the line already). If the bus is free, they start sending with a fixed "Yes" reply. If the slaves are fast enough (in comparison to the baud rate), then there should be no problems with overlap - any slaves that are a bit late compared to other repliers will keep quiet, and if there are several "winners" in the reaction time race, then each sends an identical message and there is no corruption.

If the master sees any "Yes" replies, then it knows there is at least one node on the bus with 0 in bit 0. It then asks if there are any slaves with 00 on the first two bits. Suppose there are no replies within the timeout - then it knows 00 is a dead-end. It can ask for 01 and search down that tree branch. You continue in this way, doing a depth-first search until you have identified all nodes (each at a depth of 32 down the tree). Whenever a node has been fully identified, the master sends a "shut up for now" message specifically to that node, so that it does not reply to the rest of the search.

The slaves never send their serial numbers - they only send a "Yes" message - this keeps the replies corruption-free. The serial numbers are found by the search mechanism.

Alternatively, you might consider allowing corruption - slaves should send "Yes", immediately followed by their serial number and a CRC check. If only one (still unidentified) node exists in the current branch, then the CRC should pass - you can confirm it when you send a "shut up for now" message (if this fails, you've hit an unlucky corruption). If two or more nodes are on the branch, the CRC will most likely be corrupted and you continue with your bit-search.

ber)

o

he

,

Are you sure?

A message of 8 bytes on a 9600bps bus takes 80 / 9600 = 8.33ms. If I use

10ms as the delay step (as you suggested, a little bigger than the message length) and the delay must be different for each serial number, I will have a maximum delay of 2^32 * 10ms = 42 million of seconds!!!

If the delay is only derived/calculated from the serial number, the probabi lity to have two slaves with the same delay on the bus is not null.

Do you think this approach works well? I never tried to check the bus statu s before sending a message. Can a long cable (100meter) cause some problem with this method? Consider the bus is running at 9600bps.

Good suggestion. I'll try to think to the best solution.

It's strange this kind of descovery mechanism isn't already implemented.

Depends on how many nodes you have on the network. Is it really necessary to have the address defined as 2^32, or would fewer bits returned get the job done ?. It's a bit of an extreme example.

You have to design the address protocol to suit the expected number of nodes + a margin and the latency of the network. Design is about optimising this juggling act :-)...

Chris

try a "binary search" on address space:

the master must be able to send request of this kind:

"Is there ANY slave with address between Value1 and Value2 ?"

the slaves reply with a break on serial port ( long low signal ) if the address match the range

start with request with Value1=0 and Value2=0xffffffff

next step is ( low half ) Value1=0 and Value2=0x7fffffff and ( upper half ) Value1=0x80000000 and Value2=0xffffffff

and so on

if no slave reply for a request the block is empty if ( at least ) a slave reply for a request the block is not empty and the interval must be halved and visited

If you are allowed to set the TX/DE on the slaves in I/O mode, you could just send an acknowledge level. Or use the UART break function to send an ACK instead. The fixed level prevents colision problems when your slaves are not fast enough in comparison with the bitrate.

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

Charm is a way of getting the answer "Yes" -- without having asked any 
clear question.

100 m is not long, and 9600 is not fast.

With 100m, the propagation delay will be a few microseconds (depends on the capacitance and inductance of the line, of course), while a bit time is 100 us at 9600 baud. So you should have no problem with the this bus.

As a rule of thumb, if CAN can work on the bus, then this sort of bus status checking should work (again, assuming the slave microcontrollers are fast enough that there is no significant delay between checking the state of the line as a GPIO input, and starting the UART transmission). At 100 m, CAN runs fine at 500 kBaud.

It /is/ already implemented - I have used it in an application. (For weird "historical" reasons, the bus had CAN drivers rather than RS-485 drivers, but used UARTs rather than CAN controllers. That bus ran with several hundred meters at 38400 baud.)

BTW: Please limit your line length to 70 characters.

It would be also a problem, if two slaves answer at different time, because they will try to drive the bus to opposite levels causing high currents, reflections, corrupted UART frames.

...unless the delay step is larger than the bus delay. But you can't wait so long.

that's the problem. As I wrote already in "RS485 bus and auto-addressing" 2013-04-29, EIA485 likely is not a good choice for your application.

Oliver

--
Oliver Betz, Munich 
despammed.com is broken, use Reply-To:

If you can reliably detect that overlapping responses have occurred (either by detecting gibberish - bad CRC, formatting, etc. - or line noise - framing errors, etc.), this isn't too hard.

Broadcast an "identify" a query, with a range of addresses, initially the whole address space. Any device with an address in the specified range should respond. If you get one good response (or several, if you're timing constraints allow that), life is good, record those and move on. If, OTOH, you get an error, divide the range in half, and resend the query for the half range. Continue the binary-like search until each range returns either nothing, or good responses. Of course you have to probe both sides of the division.

You need to allow enough time between queries to allow the line to settle (IOW, the slowest possible response plus a bit).

At worst that will run in O(m*n), where m is the number of devices to be found, and n is the number of bits in the address space. Actually I think for cases where both n and m are not close to unity, the runtime has to be considerably smaller than that.

For robustness, you need to have a little chat with each device to verify it's existence after you've found it, and then you should tell each found device to stop responding to ident queries. And then repeat the whole process a few times (starting with the "whole address space" query).

If you can't detect collision reliably, but with some probability, an appropriate number of repetitions would allow you to reduce the probability of missing a device to an arbitrarily low value. This assumes that there are no systemic problems that would prevent you from ever detecting a collision between two specific devices (explicitly adding some random timing jitter to the responses may help with that).