RS485 bus and auto-addressing

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

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

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

Well, lets think this thru.

Master says "Whos New?" 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!" 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 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

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

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.

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.

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.

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.

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.

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.