I have been trying to get a definitive answer on the possibility to use RS-422 for connecting one master and several slaves in a pseudo-multipoint/bus fashion, with slaves being able to send some data back to the master.
My intended usecase is:
- 1 master
- 4 slaves
- one Tx pair driven by the master, connected to all slaves (i.e. RS-422 multi-drop topology)
- one shared Rx pair driven by (all) the slaves, back to the master
- only the master would initiate communications.
- full duplex communication is not required.
- the master would include a target slave address in the messages broadcasted on the Tx bus, so that only one specific slave processes it, others would discard it.
- the targeted slave sends back some data to the master over the single/shared Rx bus
Now, I do know that RS-485 would be more appropriate, but would still like to understand how far I can push RS-422. I only have 4 target nodes, well below the limit of 10 allowed by RS-R422. The only problem I see is with having all slaves permanently connected to/driving the Rx bus, even if they only talk one at a time: will this work ?
I also understand that should any slave fail, my Rx bus is gone for good.
I have read conflicting statements about what RS-422 cannot/should not be used for (with a gray area about using RS-422 for the usecase above), so any enlightment would be appreciated.
Regards,
Julien
Best Answer
What you describe could be made to work, but each slave would have to be able to enable and disable driving the one return bus, and that bus would need to passively float to the idle level. RS-422 is not intended for this.
Since the master is only either transmitting or receiving at any one time, you might as well use a single RS-485 bus. It doesn't seem you are getting any advantage from two signals instead of a single RS-485 signal.
That all said, it's not the 1990s anymore. Use CAN. Think of it as a grown-up version of RS-485. Electrically, it's still a multi-drop differential pair. However, the standard covers how whole packets are transmitted, including a 16 bit CRC checksum, collision detection, retry, and a few other nice things. Since this is all part of the standard, you can easily find microcontrollers with CAN peripherals built in. At the firmware level, you send and receive whole packets, and the hardware takes care of everything below that. This is way better than RS-485, which pretty much just tells you how to signal a 0 and 1 and leaves the rest to you.
Designing a truly robust multi-device protocol on RS-485 is a lot harder than most people realize. Lots of amateurs have been here before and solved 80% of the problem nicely. Then when the corner cases happen that they didn't properly think about, the system hangs, the data gets corrupted, etc. One way to do it right is to use the CAN protocol, but then you might as well use CAN all they way. Again, leave RS-485 to the historians.