Switch "On"/"Off" RS485 data lines

Question

i'm doing some researches about how to close/open RS485 data line in my RS485 multi device bus.

I'm following this nice research-document: Link Here.

Basically i'm thinking how to solve this problem in a real-world environment, as you can see in page 43, the strategy is very simple: every slave, using a microcontroller and a relay, will have A-B data lines normally closed, and when the master want to set/reset/reconfigure the slaves address it will manage the relay coil and sends to the respective slave the "configuration" messages.

I wish to receive some advices in how i can manage the RS485 data lines using a low cost and effective solution without using a relay: my goal is to develop the same system using smd components.

EDIT: WHY?

I have 10 contact sensors that are placed around my home, they monitor the door open/close status and using RS485 trancievers the slaves (that are equipped with an ATMEGA328P) will expose those information to the master of the bus. Now, i want to be free to position those devices in my home without worrying to set a slave address hardcoded in my firmware or using hardware dip-switches.

They are connected using a CAT5e cable and the total length is around 20 meters, the cable will transport: A-B-VCC-GND.

Every device is wired in daisy chain mode and the preceding device will control the power up of the following sensor, using a mosfet on GND controlled by the MCU (as reported in the image below):

I don't know if that can really work: the RS485 data lines are connected anyway, also if the circuit is not powered on...

Basically, this "sequential power up" is intended to solve the issue to know "where (for example) is located the device with id 3?"

Any suggestions?

Answer 1

You will need a switch of some sort. Maybe a relay, but an analog mux is probably better if you can find a suitable one (low enough resistance and rugged enough for RS-485 (aka high working voltage and ESD protected).

If you can't find higher voltage switches with low enough resistance, you may need to add a repeater in each slave so that the series resistance of the switches doesn't accumulate.

The sequence (which I concocted just now) that happens is this:

1. All slaves boot up with the next slave connected to the chain.
2. Master sends a "count-in start" command that is received by all slaves.
3. In response to the "count-in start" command, all slaves go into a mode expecting count-in communications from the master and disconnect the next slave from the chain leaving only the first slave connected to the master.
4. Master communicates with the first (and only connected) slave and counts it in.
5. Upon completion of count-in, the first slave connects the next slave to the chain and waits for a "count-in finished" command. Otherwise it ignores all messages.
6. The master starts sending count-in messages which are only responded to by the most recently connected slave (since all the others are either disconnected or ignoring everything except for the "count-in finished" command) and counts itself in.
7. Upon completion of count-in, the slave connects the next slave up and waits for a "count-in finished" command. Otherwise it ignores all messages.
8. Repeat steps 6 through 7 until all slaves are counted in. You can detect when there are no slaves left with a time-out.
9. Master sends "count-in finished" command which causes all slaves.

^{simulate this circuit – Schematic created using CircuitLab}

The way the temrination resistors are portrayed here isn't quite what it needs to be for RS-485. But hopefully it gives you an idea of how to use the DPDT switch to disconnect the next slave while swapping it in for a termination.

I do not recommend using the RS-422 method (mentioned by others) where there is only a dedicated bus running between two adjacent slaves and there is no global bus running to all slaves. I did this on an old project of mine so that the slaves could count themselves in and though it did work, there were problems.

First, it was very slow to propagate messages down the chain in a game of telephone.

Second, sometimes hiccups would happen and messages would stop propagating down the chain mid-way, especially when the system was busier doing other things). It was a DMA, interrupt driven system and I was never able to pinpoint what exactly caused this to be able to fix it. I ended up adding message verification and sending the command in multiple times but never did find the root cause.

Third, it could not repeat long messages down the chain (i.e. data logs) because they the message would get interrupted. I don't know why this happened to this day since the DMA buffer should have been able to handle it. Then again, I can't remember if it sent complete data logs for the slave nearest to the master. It might not have been a fault of the forwarding down the chain.