Question about RS485 topology

[ogoun]

Hi,
I am designing a multidrop 2 wire RS485 network, running Modbus RTU at 19.2kbps,  with about 20 nodes (including master rx/tx).

I plan to use a true loop for the cabling (this is dictated by several things, and cant be changed easily, due to existing infrastructure).

The Modbus master/host controller will use 4 wire RS485, with separate driver and receiver connections, both terminated in 120r. and each connected to one end of the loop.

The loop will be about 50 metres long.

The Modbus slave nodes will use the same driver/receiver chip, but will use 2 wire RS485 (driver in parallel with receiver, no termination), connected to the loop by short 2 wire stubs (less than 20cm).

The RS485 driver is a TI part, THVD2412V, running at 5 volts.

I have been unable to find any references online to this type of RS485 configuration, possibly due to weak google-fu on my part!

Is there any reason that this topology might cause me grief? Maximum expected speed will be 230.4kbps, during non-Modbus diagnostic comms.

Things I care about are signal integrity and EMC. Things I dont care much about are comms speed, and physical cabling convenience.

It also occurs to me that with such a setup, a broken loop could be detected by the lack of host reception of the host's own transmit data.

Thanks for reading this!

Cheers,

Pete

[Siwastaja]

Modbus RTU by definition is always three wires. I don't see any advantage of separating RX/TX over some stubs. Just either use transceivers which parallel them internally, or if parallel close to the transceiver pins yourself. Return wire (circuit ground) is mandatory. Surprisingly large number of commercial circuits are broken-by-desisn, non-compliant disasters, which use parasitics through protective earthing etc., but don't be fooled by their sheer number. Million flies and so on; you can design your circuit correctly.

Also don't forget biasing (incorrectly called "fail-safe" biasing). It is also mandatory for modbus (and many other RS485-based protocols, all the UART-based), unless you use bias-less special transceiver chips but then you have no interoperability with any other modbus devices as you have no control over what transceiver chips they use - and you can rest assured no one uses those biasless chips so their marketing claims are thus meaningless.

What do you mean by "true loop" and how it differs from a normal bus topology (terminated at both ends, with short stubs going into devices)?

20 nodes might be probably too much for RS485. RS485 is generally poorly understood and many claims incorrect. Requirement of biasing drops the claimed noise margins to one tenth, and same happens for the claimed number of unit loads. You can find appnotes about this. If you are designing your own system from scratch, consider something else e.g. CAN. If you have to interoperate, consider smaller buses (e.g. 10 units each). And if the modbus devices are third-party, it is always a risk they are buggy.

[PCB.Wiz]

...
I plan to use a true loop for the cabling (this is dictated by several things, and cant be changed easily, due to existing infrastructure).
The Modbus master/host controller will use 4 wire RS485, with separate driver and receiver connections, both terminated in 120r. and each connected to one end of the loop.
The loop will be about 50 metres long.

I think you are describing a ring-bus, where the signal travels in a circle ?   MasterTX -> Rx [Slave1] Tx -> Rx [Slave2]Tx...Rx[LastSlave]Tx -> Master RX
RS422 Rx/Tx parts are commonly used here, as there is no need to tri-state the driver.

I see TI call THVD2412V 1-Mbps, full-duplex RS-485 transceiver, which many used to call RS422, but I guess full-duplex RS485 may be a better description.

I have been unable to find any references online to this type of RS485 configuration, possibly due to weak google-fu on my part!
Is there any reason that this topology might cause me grief?
It also occurs to me that with such a setup, a broken loop could be detected by the lack of host reception of the host's own transmit data.

You should be fine at the HW level.
Another advantage of this design is you can simply count the slaves and their loop position is their address.
We did a MCU ring bus using the 9th data bit as a leading edge flag.
All nodes wait for the rising 9th bit, and extracted N bytes, replying with their echo, with 9th bit clear. All other bytes simply pass on.
The next node thus swallows the next N bytes etc . If you send more packets than nodes, yet get back some 9th bit set echoes.

There are ring field-bus systems out there.

I'm not sure how MODBUS translates to this, as a ring bus is a natural pipeline that takes many bytes before any final reply appears on the host Rx.

[ogoun]

Modbus RTU by definition is always three wires. I don't see any advantage of separating RX/TX over some stubs. Just either use transceivers which parallel them internally, or if parallel close to the transceiver pins yourself. Return wire (circuit ground) is mandatory. Surprisingly large number of commercial circuits are broken-by-desisn, non-compliant disasters, which use parasitics through protective earthing etc., but don't be fooled by their sheer number. Million flies and so on; you can design your circuit correctly.

Also don't forget biasing (incorrectly called "fail-safe" biasing). It is also mandatory for modbus (and many other RS485-based protocols, all the UART-based), unless you use bias-less special transceiver chips but then you have no interoperability with any other modbus devices as you have no control over what transceiver chips they use - and you can rest assured no one uses those biasless chips so their marketing claims are thus meaningless.

What do you mean by "true loop" and how it differs from a normal bus topology (terminated at both ends, with short stubs going into devices)?

20 nodes might be probably too much for RS485. RS485 is generally poorly understood and many claims incorrect. Requirement of biasing drops the claimed noise margins to one tenth, and same happens for the claimed number of unit loads. You can find appnotes about this. If you are designing your own system from scratch, consider something else e.g. CAN. If you have to interoperate, consider smaller buses (e.g. 10 units each). And if the modbus devices are third-party, it is always a risk they are buggy.

Thanks for the quick response!

Sorry, I just assumed(oops!) that readers would know that there is a 0v reference wire along with the differential pair! I always run this, and I usually don't "hard ground" it at either end..

Not too interested in suggestions on how I could have physically rewired the loop, I inherited this. I will tackle this only if there is a critical flaw in this topology, as described.

My question relates to whether the proposed topology has any glaring problems (apart from my omission of the ground reference wire in my description!)

A "normal" 2 wire rs485 topology would have the master look identical to the slaves, and use a bus with termination at each end of the bus, which is usually done in conjunction with a (terminated) transceiver node.

This setup is much the same, except at one end there is only a terminated transmitter, which is half of node 0 (the master in my case), and at the other end is the receiver half of node 0.

Usually, this doesn't make a lot of sense from a wiring perspective.. Why would one separate node 0's tx and rx driver and receiver, and put the two halves at the far ends of the bus? Sounds physically impractical.

Unless the bus is physically a loop. The two ends of the loop end up at the same place, node 0, the master/host. Hence my original question.
 
BTW, the THVD2412 is a nice chip.. 70volt tolerant(!) unconditional fail safe (loop open, loop short, etc), lots of drive.

Cheers,

Pete

[ogoun]

...
I plan to use a true loop for the cabling (this is dictated by several things, and cant be changed easily, due to existing infrastructure).
The Modbus master/host controller will use 4 wire RS485, with separate driver and receiver connections, both terminated in 120r. and each connected to one end of the loop.
The loop will be about 50 metres long.

I think you are describing a ring-bus, where the signal travels in a circle ?   MasterTX -> Rx [Slave1] Tx -> Rx [Slave2]Tx...Rx[LastSlave]Tx -> Master RX
RS422 Rx/Tx parts are commonly used here, as there is no need to tri-state the driver.

This is almost exactly how I am doing it.. The loop structure is as you describe, but the slave nodes do not receive and retransmit to the next slave node, they are not full duplex. The slave nodes are electrically half duplex (in the slave nodes, the full duplex THVD2412V rx and tx pairs are electrically joined to make a half duplex rs485 pair), and each slave node just sits on the bus with about a 10 to 20cm stub between the loop and the slave node's (unterminated) driver/receiver. Thus, a slave node cannot alter the transmitted data from the master (or any other node).

The loop has conductive continuity across all the slave nodes drivers and receivers.

The idea here is to make the loop more robust against failure of node(s). So long as the failed node doesn't jabber the link with garbage tx data, of course!

I did like the idea of using the old 9th bit address flag trick, though! Cool way to use physical location to define the address of the node! Pity I cant do that here. Modbus (broadcast and unicast) will have to do

I seem to recall that when dinosaurs roamed the earth, and velociraptors were occasionally known to write assembly code for 8051 micros (!!!), that there was a variant of the 8051 that would go to deep sleep until it saw the 9th bit set in a serial rx packet, whereupon it would (in hardware!) check the other 8 bits for a matching address, and only wake up the micro if the address matched what had been set earlier by the program code...

Cheers,

Pete

[PCB.Wiz]

This is almost exactly how I am doing it.. The loop structure is as you describe, but the slave nodes do not receive and retransmit to the next slave node, they are not full duplex. The slave nodes are electrically half duplex (in the slave nodes, the full duplex THVD2412V rx and tx pairs are electrically joined to make a half duplex rs485 pair), and each slave node just sits on the bus with about a 10 to 20cm stub between the loop and the slave node's (unterminated) driver/receiver. Thus, a slave node cannot alter the transmitted data from the master (or any other node).

Ahh, so that's like two party lines. An outgoing line, and a reply line. Devices still require an address identifier.
You may want to pre-bias the reply line, to improve the noise immunity when no slave is ON.

The idea here is to make the loop more robust against failure of node(s). So long as the failed node doesn't jabber the link with garbage tx data, of course!

Such BUS topology is more tolerant of TX-RX turnaround.
Proper manage of classic RS485 TX-RX turnaround is getting more difficult as more elasticity and software layers are added.
I see TI now offer more CAN-Like RS485 parts that enable drive using a inbuilt monostable, so the BUS auto-floats without needing the HOST MCU to follow bit-level timing.
Some designs drive the TX.OE line from !TXD to do a similar thing.

I did like the idea of using the old 9th bit address flag trick, though! Cool way to use physical location to define the address of the node! Pity I cant do that here. Modbus (broadcast and unicast) will have to do

I seem to recall that when dinosaurs roamed the earth, and velociraptors were occasionally known to write assembly code for 8051 micros (!!!), that there was a variant of the 8051 that would go to deep sleep until it saw the 9th bit set in a serial rx packet, whereupon it would (in hardware!) check the other 8 bits for a matching address, and only wake up the micro if the address matched what had been set earlier by the program code...

9th bit address mode is still widespread in modern 8051 clones, tho they go into idle only, not deep sleep, as the UART Baud clock needs to continue to run.
Some MCUs support special timing for 9600 baud from 32.768kHz RTC clocks, that allow very low idle energies.

[Siwastaja]

Just draw a schematic and show us. I still think PCB.Wiz did not understand it correctly and probably me neither.

[H.O]

Like this?

[PGPG]

Unless the bus is physically a loop. The two ends of the loop end up at the same place, node 0,

Your description is... confusing.
If I understand well your connection is only geometrically a loop, but physically (from electrons point of view) is a standard bus with terminations at both ends.

Why would one separate node 0's tx and rx driver and receiver, and put the two halves at the far ends of the bus? Sounds physically impractical.

I think it can be very practical if the protocol allows spontaneous transmission by devices other than just the master. If master had TXD and RXD connected at the same bus end it will not notice frame collisions but with such connection seeing its own frame corrupted it knows collision take place.

We use RS485 at up to 300m bus with up to 50 devices at 115200 bps over standard Ethernet 100Ω cable and without pulling. Anyone who wants to send something just sends (provided it sees bus is idle). 2us after entering bus start bit is issued. So typically in 3..4us all devices at bus know bus is busy. Risk of collision extremely small. Confirming all messages ensures that in case of collision message will just be repeated several ms later.

[Doctorandus_P]

With RS485 you should always use a single long cable with termination resistors at both ends of the cable.
Using a GND wire is also mandatory. RS485 does not work properly if there is no GND reference.
The RS485 wires must also be twisted pair. You can't use "regular signal cable".

If you deviate from these simple rules, your data integrity will be compromised. With how much of a compromise you can get away with before the whole system becomes unreliable depends on the circumstances.

In general, you can use wire stubs between the long cable and the nodes, provided they are not too long (less then a meter or so), but this also depends on the baudrate. Using slew rate limited RS485 drivers can be a benefit to reduce EMC problems and ringing, but it also limits the baudrate.

For the rest, it is unclear how you actually want to connect all the nodes together. Draw a schematic diagram that shows the way everything (inclusive termination resistors) is connected to your cable(s).

Your description is... confusing.

Yes indeed. Modbus RTU implies half duplex over a single RS485 wire pair, while you write you want to use full duplex with two RS485 wire pairs. So create and post that wiring diagram, or just just Modbus RTU in a normal implementation.

[PGPG]

Using a GND wire is also mandatory. RS485 does not work properly if there is no GND reference.

It is at least debatable
Information is in A,B lines voltage difference so theoretically GND reference is not needed to detect information.
But if A,B having the correct difference between them are offset to much from GND receiver can have a problem with finding if A>B or B>A.
Assume we have floating GND at receiving side. If using transils you ensure none of A and B lines will go more high than 12V and more low than -7V regarding your GND then your floating GND have to get such potential that both signal lines are between -7 and+12. And their voltage difference is determined by sender. Receiver will not have a problem to detect information.

GND connection is needed because drivers except differential mode send also common mode (one line changes state before the second one) and for EMC this common mode have to get way back as close to wires containing this common mode signal. As this are A, and B than return path should be along with them so need to GND connection in RS485 cable.

But if you isolate RS485 than generated by driver common mode noise can be blocked by this isolation.
The other solution is to use common mode choke to insert so high common mode impedance that common mode current becomes negligible.

[PGPG]

Also don't forget biasing (incorrectly called "fail-safe" biasing).

What incorrect you see in calling it "fail-safe"?
English is not my first language than I can understand something wrongly but for me 'fail' need not to be read as 'damage' but can be read as 'fault' (in reading idle bus as '1'). So biasing protecting you against making such fail bus state reading makes your reading fail-save.

[Siwastaja]

What incorrect you see in calling it "fail-safe"?
English is not my first language than I can understand something wrongly but for me 'fail' need not to be read as 'damage' but can be read as 'fault' (in reading idle bus as '1'). So biasing protecting you against making such fail bus state reading makes your reading fail-save.

In engineering context, fail-safe means that if something fails, it fails in a safe manner. E.g., Y capacitor fails as open-circuit.

In (edited to add: modbus over) RS485, fail-safe biasing refers just to normal operational biasing, so that communication is possible by establishing a defined idle state which gives positive noise margins. In this configuration, having idle state is not "failure" of any kind, but perfectly normal state.

[PGPG]

In RS485, fail-safe biasing refers just to normal operational biasing,

As you think it is 'normal operational biasing' you think there is no idea to give it special name. But it is not 'normal operational biasing'.
RS485 originally is intended to be used without this biasing.
EN IEC Standard I mentioned in Reply #4 in thread:
https://www.eevblog.com/forum/beginners/circuit-to-drive-wiegand-output/
do not assume RS485 bus being biased.
But as people like to make things simpler they invented biasing.
We tried to do it in 90s but there are lot of problems with it if you want to allow people to connect 2..100 your devices on the bus and to allow them terminate bus by only connecting termination resistors at bus ends.
Fortunately at end of 90s MAXIM fail-save drivers became available so we replaced biasing with using fail-save drivers.
These drivers do not have biasing. What would be your proposition how to distinguish these drivers from standard ones other than naming them 'fail save'? They just protect you from fail bus state reading.

[tooki]

I see TI call THVD2412V 1-Mbps, full-duplex RS-485 transceiver, which many used to call RS422, but I guess full-duplex RS485 may be a better description.

RS-485 and RS-422 are closely related but are not the same thing. It's certainly not that full-duplex RS-485 "used to be called RS422". RS-485 signal levels are essentially RS-422 signal levels with tighter transmission tolerances and looser receiving tolerances, meaning that an RS-485 transceiver can be used for RS-422, but not vice versa. RS-485 describes how to do half-duplex bidirectional buses; RS-422 does not. For all intents and purposes, one could consider RS-485 to be an extension and refinement of RS-422.

[ogoun]

Like this?

Yes, that is it except that the master has 120r termination on both tx and rx (the 2 ends of the bus).

Cheers,

Pete

[Siwastaja]

As you think it is 'normal operational biasing' you think there is no idea to give it special name. But it is not 'normal operational biasing'.
RS485 originally is intended to be used without this biasing.

But we are not just discussing RS485, we are discussing MODBUS RTU, so that design and rules from both layers apply. RS485 does not specify biasing because it does not specify protocol, and some protocols might not need any definite idle state. Then biasing does not matter and you can call it banana biasing if you so wish. And with some imaginary protocol X the biasing could indeed have something to do with failing safely, but I'm not aware of any such protocol.

But Modbus RTU does need the idle state so that UART transceivers can detect the start bit transition correctly, therefore biasing is in the spec - not RS485 but modbus - for a good reason.

The question to ask yourself is: would you also say "I2C fail-safe pullup"? If not, then it's time to stop defending the very poor choice of words.

[Siwastaja]

Fortunately at end of 90s MAXIM fail-save drivers became available so we replaced biasing with using fail-save drivers.
These drivers do not have biasing. What would be your proposition how to distinguish these drivers from standard ones other than naming them 'fail save'? They just protect you from fail bus state reading.

There is so much incorrectness in your text that it's not funny anymore. No other driver I'm aware of have any biasing either like you imply. The real difference between some newer transceiver ICs are adjustments of detection thresholds of receivers so that they have positive - albeit still small - noise margin even when the two lines are pulled to the same voltage by the termination resistors.

If you design every device in the network, such transceivers are a great idea. You can either get rid of the bias resistors completely, or use resistors of larger values, or use classic resistor values and get even more noise margin.

But the big thing in the whole Modbus scene is the interoperability. Say you are designing a Modbus master. Since you can't control what transceivers other slaves use, they would still mis-detect the start bit from any noise, and possibly then miss the actual message (or misbehave in other ways). So then you need the bias resistors anyway.

I think building modbus RTU buses with 100 devices on a single bus is generally a bad idea even though it can work with some compromises like poor noise margins, or careful control over list of supported devices. No interoperability at all with 3rd parties makes life much easier of course.

do not assume RS485 bus being biased.

Of course I do not assume it, just like I don't assume there is a ground wire. I fix and work around broken-by-design stuff on a daily basis and RS485 and Modbus are constant grieves because everyone does what they want, not what they should. This being said, broken TCP/IP stacks in Modbus TCP are even bigger pain because you can't fix it with wires and resistors, so 

If CAN was more popular in automation, it would simplify a lot of things. It's just basically RS485 done right.

[PCB.Wiz]

Like this?

Yes, that is it except that the master has 120r termination on both tx and rx (the 2 ends of the bus).

That's not really a 4 wire design at all. 

It uses 2 core cable and the only change is the master RX connects to the cable end, but could equally connect to the cable start.

That change permits wire-break detection and some 'far end' signal integrity check too.
None of the slaves are aware of that detail.
To the slaves, it is just a bog-standard half duplex, 2 wire, RS485 system.

[H.O]

As far as I'm aware nobody's said it was a 4-wire design  - only that the master/host will connect to the 2-wire bus using all 4 connections on the tranceiver. First post, first three lines:

I am designing a multidrop 2 wire RS485 network, running Modbus RTU at 19.2kbps,  with about 20 nodes (including master rx/tx).

I plan to use a true loop for the cabling (this is dictated by several things, and cant be changed easily, due to existing infrastructure).

The Modbus master/host controller will use 4 wire RS485, with separate driver and receiver connections, both terminated in 120r. and each connected to one end of the loop.

Then, as is often the case, everybody goes off on a tangent :-)

[Perkele]

1. Use twisted-pair cables.
2. Don't use cable shield as GND connection.
3. If this will be a commercial  product, use slew rate control, otherwise with this transceiver you might get surprised by EMC test results.
4. If you plan to use 250kbit/s model, and if this is not a cost-sensitive project, use two pairs (one for RX, one for TX) and GND if you don't want do implement RE/DE switchover for RS-485 transceiver.
5. Use galvanic isolation if you'll have several devices on the bus connected to separate earth points and separate power sources.
6. Additional fail-safe biasing is not needed at short distances and with a low number of transceivers.

A "loop" is nothing special, it's just a transceiver on the opposite end of the line that's used to compare received and transmitted data.
In more advanced systems you can also change the direction of communication if there's a breakage on the line.
If this is a Modbus network, you can also use read timeouts for line failure detection, but some of devices have long timeouts, and that might affect the overall system throughput.

19200 bit/s is nothing special. On 50 metre distance with a good set of transceivers I was able to get 115200 bit/s over a set of H05 wires and no termination at all.
In my day-to-day $WORK it's normal to have non-twisted-pair cables, no termination, sometimes without GND (two wires only), running on distances up to one kilometre, with more than 64 nodes connected.
Apparently, lowest cost bidders that do the cabling don't care about project requirements or specifications for life safety systems.

Btw. 4-wire RS-485 is NOT the same thing as RS-422.

[PCB.Wiz]

As far as I'm aware nobody's said it was a 4-wire design

Actually, the OP said  exactly that :   

The Modbus master/host controller will use 4 wire RS485

[mariush]

I'm surprised there aren't more solutions out there using plain old ethernet

These days you can get 5 port 10/100 mbps ethernet switch chips for 1$ : https://www.lcsc.com/product-detail/Ethernet-Switches_IC-Plus-IP175G_C80220.html
Magnetics are also super cheap...
You'd use 3 ports on every switch - incoming, outgoing, to your node ... and each node can connect to other nodes or broadcast data and the switches would pass the data along.

You could easily use a plain cat5e ethernet cable for your "network" , use 2 pairs for connection between two switch chips (you only need 2 pairs for 100mbps) and the other two pairs could be used to carry power to the switch chips (ex 5v or 12v or something like that, like passive poe, each switch runs on 3.3v and consumes up to 0.45w) - this way the ethernet switch chips won't rely on node power, if node fails or crashes, the ethernet switch would be isolated by magnetics so the other nodes would work.

May seem janky to have 20 ethernet switches connected on 50 meters of ethernet cable but it would work. No looping ... but the ethernet switch chip will probably have some spanning tree or something to detect loops and still work (quick google search says spanning tree may be limited to 7 hops so it wouldn't work well with 20 switches?)


A microcontroller with a built in mac / phy / ethernet plus the 1$ ethernet switch chip and magnetics is probably still gonna be cheaper than a 5$ THVD2412V transceiver

[PGPG]

No other driver I'm aware of have any biasing either like you imply.

I didn't know that.
I was speaking only about 'fail-save' term and this term is used to describe transceivers independent on protocol they are then used with. So if in any place you assume that I had in mind MODBUS it is not true. I was not thinking about MODBUS. I don't know MODBUS and have never dony anything with it.

I think building modbus RTU buses with 100 devices on a single bus is generally a bad idea

As I don't know modbus I have no opinion on it. But in system where you have all devices with fail-save drivers there should be no special problem with it. In our current system we use not isolated RS485 and because caused by it stronger protecting circuits I decided to reduce the distance to 300m and number of devices at bus to 50.

It is 1 am here and I can't spend more time on net (will be off line at least for one day).

[ogoun]

Like this?

Yes, that is it except that the master has 120r termination on both tx and rx (the 2 ends of the bus).

That's not really a 4 wire design at all. 

It uses 2 core cable and the only change is the master RX connects to the cable end, but could equally connect to the cable start.

That change permits wire-break detection and some 'far end' signal integrity check too.
None of the slaves are aware of that detail.
To the slaves, it is just a bog-standard half duplex, 2 wire, RS485 system.

Exactly correct!

Also, while I am using Modbus RTU, it is being used in a closed network, i.e. the only devices on this mini network are ones that I have designed, and this is to interconnect a set of what are essentially peripheral devices to my controller (the master node). Again, all designed by me, and all going into a non user accessible "box". So interop with other Modbus masters or slaves from other manufacturers is not an issue in my case.
Cheers,
Pete.