Why don't RS485 hubs include termination resistors?

[Siwastaja]

The added biasing resistors just give you more margin for noise/error. It's all dependent on whether your intended environment is noisy, like the worst case industrial environments.

This is technically correct but how you use the word "more margin" is easily misleading. The point is, without the biasing resistors (using standard transceivers), you start with no noise margin at all. So yeah, you need more margin for the thing to operate at all except by sheer luck. Many discussions on topic make it sound like bias resistors would be giving some extra margin on top of something which already works, but this isn't the case. In fact, even with optimized resistor values, you would still be limited to 1/10th (or maybe 1/5th, check the math, don't trust my word) to what is claimed to be the noise margin of RS485 bus.

Just to add as well, I've seen quite a few diagram from Texas Instruments et al, showing fairly low values like 330 ohms to 5V and GND, but I've never used anything that low. 10k or 4.7k sets the lines just fine for my needs

You can find appnotes that dive deeply into calculating bias resistor values, how they affect the noise margins and max unit loads. Without re-checking the math, I would handwave that 10k is still in the zero-ish noise margin which you don't want. Somewhere around 500-1000 ohms should be the correct range; the idea is you have to bias the receivers beyond the hysteresis band. After your idle levels go beyond the hysteresis band, only then you are in a defined state, and at that point noise margin is zero and starts increasing as you decrease the resistor values further.

With no resistors at all, or 10k resistors, you would be in the hysteresis band, noise margin is zero (or negative if you allow it to be defined that way), and the line state is undefined.

Really, without the bias resistors the system "works" by the fact that the 120-ohm termination resistors tie the lines together so that not many mV of noise easily couples, and in the typical implementation whoever shouts sets their UART to IDLE level before disasserting its DRIVER ENABLE signal, so that line is strongly driven into IDLE state before being released. This sets all receivers to output the idle state, which then remains when the line goes into undefined state (within hysteresis band) - the receivers "remember" the last valid state which was IDLE. All you need is a single noise event of a few mV to disrupt that memorized state and "kill" the receivers into receiving endless START bit. You see, being right in the middle of the undefined range, in the hysteresis band, means that the wrong state will be remembered indefinitely, too.

[Salitronic]

The problem is that people think RS485/modbus is an "industrial quality" "very robust" "against noise" and "long wiring" and whatever marketing bullshit. In real systems with real misunderstandings (e.g. lack of biasing, grounding through parasitics) it's closer to a Arduino tutti frutti dupont cable contraption: works on the lab table and often works on the field with near-zero noise margin.

People overestimate how demanding industrial environments are. Often crappy hobbyist kludges would work well in industrial environments if they were allowed. RS485/modbus has social acceptance in industry, but in practice is often on the same level as those kludges, people just don't know it. Until it fails, and then RS485/modbus specialists are brought in. Or problem sidestepped without them, doing random changes until it seemingly works again, hobby way.

That is also my experience, many think as long as you're using RS485 you can wire it up in whatever way is convenient and she'll be alright! The truth is if someone does not understand the fundamentals of RS485 wiring, termination, biasing, layout, shielding, etc... he shouldn't be doing RS485 wiring in the first place.

So I fully agree with all that of course, but I think this strengthens my view that all of this is a 'wiring installation problem' not an 'RS485 hardware problem'. When I am doing an RS485 installation, I want the wiring to be in place, with all terminations, biasing, etc.. independently of any hardware that will be attached to it. I'm not relying on a mix of inconsistent devices from different manufacturers, with a possibly undocumented implementation, to handle bus termination and biasing for me. None of this is standardized in RS485 so all I expect from a device manufacturer is to stick to the lowest common denominator of an RS485 transceiver with adequate protection. That is the same reasoning that I apply in RS485 hardware design.

[tszaboo]

Edit again: Using 330 ohms on each line to 5V and GND respectively, then 150 across the lines should give a termination close to 120 ohms?

ie ((2x330)^-1 + 150^1)^-1 ~= 122 ohms

So I guess you could hard-wire that combination of resistors on your master device.

Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends. No branches, no Ys. No I'm going to invent new stuff that's not in the standard, no getting creative about the termination.
Failsafe biasing is not for the RS485 line. It's for your device. It's there, in case the wire would break, or only one wire would be connected, the random noise isn't going to write your temperature controller to a million degree for example. Because that two resistor sets the A and B and therefore the R pins default to a fixed state instead of floating randomly.

RS485 is a very reliable system if designed and installed correctly, but you have to follow the rules. If you do that, the wire could be kilometer long and you could install dozens of nodes and it's just going to work properly to eternity.

[Doctorandus_P]

You write you want to use a "hub" (repeater, whatever) to make a local star point. If you do not have termination resistors in the star point, then you can route two branches from one "output" of your hub.

I don't really understand why termination resistors are built into nodes in the first place. It is the end of the cable that needs termination, and not the nodes.

For a while I have used CAT-5 cables and two RJ-45 connectors for my nodes, and I also made a few RJ-45 connectors which just have a resistor in them. So a node receives either two cables, or it receives a cable and a termination resistor. This works quite well, but it also has some disadvantages. My (custom protocol) bus has both power (24Vdc) and data, and with this setup whole sections of the bus are temporarily disconnected from the bus if I want to add or remove a node. The power is now also routed through all the connectors and the PCB's.

I think one of the best solutions is to use the plug-able 3.81mm pitch phoenix headers The holes are big enough to accept two wires, or a wire and a leg of a wired resistor. You can even insert such connectors in the middle of a cable by stripping the insulation and doubling it up without cutting the copper. This is probably a bit of a nuisance to do, but probably also good for reliability.

[ejeffrey]

Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends.

You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state.  Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition.  Read the messages above.

[Siwastaja]

No I'm going to invent new stuff that's not in the standard, no getting creative about the termination.

Biasing is in standard. In Modbus standard:

If one or several devices need polarization, one pair of resistors must be connected on the RS-485 balanced pair :
- a Pull-Up Resistor to a 5V Voltage on D1 circuit,
- a Pull-Down Resistor to the common circuit on D0 circuit.
The value of those resistors must be between 450 Ohms and 650 Ohms. 650 Ohms resistors value may allow a higher number of
devices on the serial line bus.
In this case, a polarization of the pair must be implemented at one location for the whole Serial Bus. Generally this point is to
choose on the master device or on its Tap. Other devices must not implement any polarization.

https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

If your device uses bias-less transceivers, you MUST per modbus standard document it, so that installers can see if all devices on a bus use such transceivers and leave bias resistors out. In practice this is risky because someone can add another device later which needs biasing.

Failsafe biasing is not for the RS485 line. It's for your device.

It is for all devices and complete functioning of the bus.

It's there, in case the wire would break, or only one wire would be connected,

No, failsafe biasing has nothing to do with wires breaking. This is a very common misconception because of the poorly chosen name. Either "Failsafe biasing" (standard solution per modbus standard) or using biasless transceiver ICs FOR EVERY DEVICE on the bus is mandatory for normal operation under all normal operating conditions, not failures or special cases.

RS485 is a very reliable system if designed and installed correctly, but you have to follow the rules.

Including the rule of having biasing which you clearly have trouble with understanding. You would have understood all of this if you did not routinely ignore those who try to explain how things work.

Read the messages above.

He won't, because he puts sensible people into his ignore list and brags about it. Insteads, he concentrates on confusing others with incorrect information instead of simply ever questioning himself. He has managed to build his own one-person echo chamber where bullshit leaks out and no corrections flow in.

--

And everything said in modbus standard applies to any other UART-based protocol over RS485. But Modbus is by far most popular.

[tszaboo]

Why would you do that? You place 2x 120 Ohm resistor between A and B, at the two ends.

You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state.  Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition.  Read the messages above.

No, you need 200mV or more voltage level to say it's a 0 or a 1.
You need the 120Ohm resistors, because thats how the entire thing works.
It has to be no less and no more than two 120Ohm resistors.
You don't need any other fail safe-ing, unless you used a transceiver from the 1980s.
https://www.analog.com/en/resources/technical-articles/rs485-cable-specification-guide--maxim-integrated.html
It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.

[Siwastaja]

Note also that the modbus standard does not leave much room for creativity here:

First, modbus standard does not use term "fail-safe biasing",
Second, inclusion of pull-up and pull-down resistors is mandatory unless every device on the bus is specifically documented not to need them
Third, the value of resistors must be between 450 - 650 ohms. Not 10kohm, not 1kohm, not 330 ohm.

Of course that leaves non-modbus protocols using RS485 but as long as they are asynchronous serial depending on start bit detection, the same advice holds.

[uer166]

It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.

This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors. I've personally debugged a stubborn link that was failing in a box, was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.

Compare these double digit mV headrooms with what CAN has (~volts), and re-consider using it unless absolutely mandatory, or you can hard-wire the direction.

[Siwastaja]

This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems

If he actually looked at those very same biasless "modern" transceiver ICs he claims everybody should be using, he would instantly see they offer 50mV of threshold, not 200mV, one quarter of what he claims.

Best option really is try to use biasless ICs whenever available AND use the standard bias resistor values as described in the Modbus specification - combination of the two measures is quite acceptable -, AND remember that RS485 is a three-wire, not two-wire bus. It's still not the greatest thing on Earth at all but at least then it works.

[tszaboo]

It's really not "any amount" of noise. There needs to be a metric shitton of noise to induce a 120 Ohm terminated shielded twisted pair to more than 200mV.

This is obviously not true if you glanced at transceiver datasheets: on the receive side, the negative going threshold ain't 200mV in general, it's some bullshit value that starts at VTt+ - Vhysteresis, and ends at -200mV. You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors. I've personally debugged a stubborn link that was failing in a box, was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.

Compare these double digit mV headrooms with what CAN has (~volts), and re-consider using it unless absolutely mandatory, or you can hard-wire the direction.

That's a lot of words for describing that "I failed to connect the ground of an isolated transceiver properly", and "I don't understand how CMRR would effect my input sensitivity".
With some assumptions and personal attacks mixed in.

[5U4GB]

You do that so that when the bus is connected correctly and in operation but idle the bus is held in the space state.  Otherwise A and B will be at the same voltage and any amount of noise can be interpreted as a mark transition.

However if you're using your RS485 bus to run modbus then random noise, even if it does cause a transition, is never going to be mistaken for a valid modbus-serial PDU.

[Siwastaja]

However if you're using your RS485 bus to run modbus then random noise, even if it does cause a transition, is never going to be mistaken for a valid modbus-serial PDU.

... at least it shouldn't, if the slave checks for CRC and is not buggy.

However, the question if slave misbehaves, while important, is secondary. Primary consequence even with perfectly designed slave is that the slave will not receive the intended message. The UART sees the false start bit and keeps listening, a little bit later setting framing error flag or similar. The situation is rectified when the master makes a new transmission - which gets missed by the slaves! - and then the transceivers leave at the correct idle state (latching the last state actively driven on the line), and hopefully get the next master transaction right.

But if the master polls e.g. once a second, there is a whole lot of time and opportunity for a repeated glitch. Hence opportunity for the comms to fail permanently.

Usually this is caused by combination of poor grounding and lack of biasing. Fixing just grounding usually seems to fix it, but with no biasing the noise margin is negative, the system always operates inside the hysteresis band.

Think about it this way: it is equal to communicating with 5V microcontroller GPIO by using a signal which sits at 2.5V all the time, utilizing the fact that when it's periodically 5V and returns to 2.5V, the value read does not go to '0' inbetween because the hysteresis of the IO logic.

The bus is not designed to work like this. But what people miss is the layered specification. RS485 spec leaves the biasing question to be solved by the next layer (which makes sense, because if the protocol chooses "one always active" strategy then there is no problem). Next layer, e.g. modbus then specificies the bias resistors (because it depends on all transmitters idle being normal, and start bit detection).

Just follow the standards.

[PGPG]

And everything said in modbus standard applies to any other UART-based protocol over RS485. But Modbus is by far most popular.

I see that you have big experience with practical Modbus usage, but this sentence is not true. Everything about modbus may be applies to some UART-based protocols but not to all.
OSDP standard (that I don't know perfectly and I hate it because after it got EN-IEC number forces us to increase 100x current consumption on RS485 transmissions) is UART-based protocol and need not biasing. The problem of false start bit is solved by keeping by transmitter bus in logic high state for longer than one byte time before first byte is send so whatever error byte receiving was started it is finished before start bit of first byte of frame.
How a problem of such 'wrong' bytes at the beginning is solved - I don't know but it's not an unsolvable problem.

When reading once more what I have written I remind that they start each communication with specified byte what certainly helps a lot.

You don't need any other fail safe-ing, unless you used a transceiver from the 1980s.

I'm not sure what you have in mind. I have never made a statistic, but when I need to find transceiver with fail-save receiver (for open and short) than only few can be found among hundreds of RS485 chips. So problem with biasing is not only with transceivers from 1980s. I have noticed that transceivers I can accept are (by chance) much more expensive than transceivers I don't accept.

Of course that leaves non-modbus protocols using RS485 but as long as they are asynchronous serial depending on start bit detection, the same advice holds.

It is the same what I commented above.

You obviously haven't dealt with real RS485 systems because in real life these buses fail all the frickin time without the bias resistors.

Since (at the end of 90s) we started to use fail-save (very important - for open and shorted bus) transceivers we not notice any problem (we don't use biasing). There are probably about 5000 of our RS485 buses working all the time. Most in office environment, but I believe some in industry.
About 10..15 years ago we got the mail from one of installers that the building they recently installed our system was hit directly by lightning and all systems with long cables (alarms, telephone exchange) failed. Also more than 50% of ethernet ports in computers were damaged. Only our system was still working. Installer finished with: "Now everyone will earn money and we will get nothing."

was really short and isolated! The designers failed to consider the common mode voltage ranges, as well as the biasing.

I don't understand you. When (20 years ago) I was using isolation at RS485 (4kV, 4.2pF in trafo + may be 3pF (I'm not sure) in ADuM isolator) I blocked by transils the transceiver common mode voltage tolerances. If I have up to 8kV (isolations at both ends) common mode voltage difference than adding 7V to it is pointless. Those time I was asking to connect third GND wire, but now I think it was an error. If in GND loop you have two about 7pF breaks you need not to connect GND between transceivers. Having common mode input voltage in accepted by receiver range is done by elements protecting A, B lines.

[Siwastaja]

OSDP standard (that I don't know perfectly and I hate it because after it got EN-IEC number forces us to increase 100x current consumption on RS485 transmissions) is UART-based protocol and need not biasing. The problem of false start bit is solved by keeping by transmitter bus in logic high state for longer than one byte time before first byte is send so whatever error byte receiving was started it is finished before start bit of first byte of frame.

This is very clever and same could be done on modbus. But since it's not on the standard, nothing can be done, it's not like modbus standard could be significantly changed anymore.

We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus. But it's easy to dream.

[PGPG]

But since it's not on the standard, nothing can be done,

I don't suggest anything be done with modbus.
I have only said that conclusion that everything (about hardware) that is needed by modbus will also be needed by any other UART based RS485 communication is unjustified.

Our own communication (anyone can send if have something to say) I will also understand as UART based. We use UART to send and receive bytes, but to find that bus is busy we use direct detecting start bit at bus (microcontrollers (not sure, but may be all) allow the input pin being connected to UART and also read/generate interrupt as GPIO).

[sw_guy]

How to calculate/know component values for AC termination? I believe R still equals to the impedance of a cable. The optimal C depends on parameters - at least the cable length. On one of the Analog's app note values are 120R/3n3 for 222ft.

sw

[5U4GB]

We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus.

While I agree that'd be a good idea, the problem with these second-system-effect updates is that it's almost impossible to stop once you've got started (I mean it's like cocaine mixed with heroin), and then you end up with something like the newer Bluetooth specs.

For an interesting example of not falling prey to this too much, look at the I2C to I3C update... although like IPv4 vs IPv6 there still seems to be a lot more I2C being deployed than I3C.

[Siwastaja]

We could dream about a better protocol. I would use a header such as U8 slave_id, U16 length of payload in bytes, U8 CRC of the header, then rest of the message with another CRC at the end. Knowing validness of length and recipient in advance allows skipping whole messages (after that short header), allocating buffers, reading just for the correct number of bytes without weird inter-message timers like in modbus.

While I agree that'd be a good idea, the problem with these second-system-effect updates is that it's almost impossible to stop once you've got started (I mean it's like cocaine mixed with heroin), and then you end up with something like the newer Bluetooth specs.

For an interesting example of not falling prey to this too much, look at the I2C to I3C update... although like IPv4 vs IPv6 there still seems to be a lot more I2C being deployed than I3C.

Yeah. However if you take a closer look, Modbus is incredibly complex for what it achieves (exchange of data at numbered addresses). It is almost surprising it is coming from 1970's with that much complexity. Not only you need two timers for the timeout management, on software level you have multiple address spaces (one for each function code). Super weird +1 addressing notation no one except one manufacturer out of 100 follows for maximized confusion. Both 1-bit registers almost no one use and 16-bit registers, where the only purpose is premature optimization of performance for reading a lot of 1-bit statuses, but the whole protocol isn't performance optimized anyway so it makes no sense whatsoever anyway. Separate incompatible functions for write multiple and write one register when you could just always use write multiple with n=1. For example it is normal to see that product A only accepts function code 0x06 and product B only 0x10.

The whole protocol screams of no design at all and ad hoc feature creep.

The "new modbus" should not be shinier and fancier v2.0, it should be more primitive and simpler; it should be how modbus is actually used, only a tiny subset of the spec. Problem right now is that everybody implements different subset (unlike those few who license a complete modbus implementation).

But I also would not use RS485 for that new shiny bus. CAN would be cleaner.

But this is just meaningless shitposting I'm doing here, we can dream. I'm dealing with home automation and building management stuff and it's total ad-hoc mess, I have actually never seen a single even nearly modbus standard compliant device, everybody does what they want to get some test product to work with another test product on a lab and then sell it. We write separate integration guides (connection guidelines) to every product we support because the manufacturers can't do that, and then every driver follows different conventions. But there is no way to just come up with an alternative system and somehow make the manufacturers use it. And maybe there is no need, the current system works quite OK once you grasp it.

Excellent example of the second-system effect you mention is SunSpec, which is basically useless because it's so much v2.0-by-committee that less than 5% of the target audience (solar or battery system inverter manufacturers) actually use it because it is so complex and difficult. And I'm glad no one uses it so that we have avoided supporting it, too. They also require a certification process to call your product SunSpec compliant, because they know it is so difficult and complex. Yet the only SunSpec product I have had to deal with claiming to be SunSpec compliant was not complying to the spec so that I had to add workarounds anyway 

[PGPG]

But I also would not use RS485 for that new shiny bus. CAN would be cleaner.

I remember reading CAN controller description once (20+ years ago). It was extremely complicated from my point of view.

I have never used CAN, but in my opinion it is worse than RS485.
I just want to say my opinion and not to start a discussion on this topic.

I don't like that one state in CAN is 'strong' while second is 'weak'. My intuition tells me that weak state is more susceptible to interference. When testing burst you capacitively couple them to cable. They can do more when the wires have a weak forced voltage.
In small RS485 system (controller + 2 readers), assuming 4 device attendance control frames in each 4 seconds, I estimate collision risk for asynchronous frame being about 0.000006 (6us risk time happening 4 times in each 4s). If you imagine (one door small system) 100 people in/out each day (400 frames a day - in/out and confirmation) the frame collision will happen once per year. So once per year you will lose one frame time (1..2ms) at bus. For big system (like 50 devices on bus) it is of course bigger but even you lose 2ms each minute it is all the time 0.0033% bus time lost. I suppose that CAN losses about 50% of bus throughput just because each bit have to be stable at whole bus length before next bit can be send.

[Siwastaja]

I remember reading CAN controller description once (20+ years ago). It was extremely complicated from my point of view.

Oh, CAN is very simple for user. You don't have to deal with coming up with arbitration, addressing etc. code as you need on RS485 because that's all standardized and easily available in hardware (on every $1 MCU peripheral). You were probably reading documentation on how to implement such  controller, but the point is you don't have to.

Plus, if you write similar detailed specification about modbus over RS485 (including flow diagrams of all function codes) it's going to be much longer.

I don't like that one state in CAN is 'strong' while second is 'weak'. My intuition tells me that weak state is more susceptible to interference.

Intuition easily leads you wrong. CAN has excellent signal integrity. It's similar to always-driven RS422/485, so approx ten times better than RS485/modbus which relies on either 50mV shifted hysteresis transceivers or those bias resistors which are ten times weaker than the termination resistance.

I suppose that CAN losses about 50% of bus throughput just because each bit have to be stable at whole bus length before next bit can be send.

You are very correct that CAN compromises simplicity of its arbitration system, baud rate and maximum physical bus length. Number of devices is not a problem, but if you want a kilometer long bus then you are limited to something like 50kbps IIRC or so due to arbitration delay.

CAN goes to 1Mbps no problem but only within a vehicle / limited floor area at industrial site. I think something like 30 meters.

Then again most RS485 systems I deal with communicate at 9600bps. Streaming high bandwidth data like video, I suggest Ethernet instead.

CAN systems are reliable because they truly only need termination resistors (no bias resistors), and naming conventions are coherent and strong. Unlike the A/B/+/- mixup mess of RS485, nobody disagrees on the meaning of CANH and CANL, and forgetting GND is quite rare*. I don't think I have ever seen non-functional CAN system, unlike non-functional RS485 systems which are commonplace.

*) the GND thing is more social than technical; but with modbus/rs485 there is so much misinformation and wrong practice out there that it's very hard to fight against it. CAN started over from a clean table and does not have this legacy.

[H.O]

RS485 and missing GND wire...
At work, we're at the device level, not compontent level and most of the RS485/422 interface I come across has been done without GND wire. Mostly, I believe, this is because 95% of the "interface documentation" from manufacturers of various devices "always" just shows two (or four) wires and "never" shows a GND wire.

I'm trying to get the point across that it's "wrong" and that from now on we should implement a GND wire. Needless to say, it's hard....

Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".

[Siwastaja]

Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".

If the protocol is Modbus, then the modbus standard. It's a pretty authoritative document with strong must wording:

https://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

"a third conductor must also interconnect all the devices of the bus : the common"

There is no discussion about it. If the device has no connector for ground/common wire, it is not modbus compliant. If the wiring does not use ground wire, it is not a modbus bus.

Also, if the bus does not have bias resistors and there is even single device on the bus which does NOT document it can be used bias-less, the bus is not modbus compliant. It is broken by standard and needs to be fixed.

Be very careful with appnotes published by Texas and other chip manufacturers. Some are very good; but some are utterly wrong (rehearsing old industry hearsay instead of correct facts) like the one tzsaboo linked to earlier.

If the protocol is not modbus, then it's more difficult to give authoritative statements about necessity of biasing and ground wire.

When we encounter these shit devices, which is more common than it should be, we assume they use PE for RS485 common and instruct our install partners to connect the RS485 GND of our box to PE as well. The signal common path is a mess from EMC and probably the combination would fail tests, but it's not our responsibility; our box has the connectors and it passes EMC.

[H.O]

Thank you!
We deal with various protocols. It might be MODBUS, it might be NME0183 or it might be some unknown protocol riding a RS485 or RS422 bus between two devices from the same manufacturer where my task is simply to interconnect the two. At the wiring level this has mostly been done without a separate GND wire and it seems we've gotten away with it. Now that I'm trying to say it's "not correct" I'm having a bit of a hard time building my case so to speak :-)

Be very careful with appnotes published by Texas and other chip manufacturers. Some are very good; but some are utterly wrong (rehearsing old industry hearsay instead of correct facts) like the one tzsaboo linked to earlier.

This bothers me deeply. How should one know what's good and what's utterly wrong. For example, my goto reference TI AN-1057 says

Although the potential difference between the data-pair conductors determines the signal without officially
involving ground, the bus needs a ground wire to provide a return path for induced common-mode noise
and currents, such as the receivers' input current. A typical mistake is to connect two nodes with only two
wires. If you do this, the system may radiate high levels of EMI, because the common-mode return current
finds its way back to the source, regardless of where the loop takes it. An intentional ground provides a
low-impedance path in a known location, thus reducing emissions.

This is at the hardware level, what rides on the bus (be it MODBUS, NMEA or whatever) is secondary.
Could one argue that this is simply not correct and that a GND wire is just optional extra?

[PGPG]

Can anyone point me to a good reference that clearly explains the fact that a GND reference is indeed needed (or at least the proper way) that I can use to to convince colleagues of this fact. The best reference I've found so far is Texas Instruments AN-1057 but I'm still having a hard time convincing my colleagues because "it's been working fine before".

I looked (not reading) through AN-1057 and Figure 8 is one that is most important in this matter.
It is more the problem of EMC and less (but still) the problem 'it's been working fine'.
RS485 drivers generate unneeded common mode voltage. Looking in MAXIM MAX3082 datasheet the sources of Vcm are ΔVoc (max 200mV) and t_DSKEW (max 200ns). Connect driver outputs A to B with two identical resistors in serie and observe with oscilloscope voltage at point between resistors when transmitting. ΔVoc is typically small but skew generates pulses of about 1V amplitude or more.
Not sure at that moment (I was doing such calculations 20 years ago) but if CM return path is not along A,B wires about 20mV Vcm is enough to exceed the emission limits specified in EMC standards while here we can have it much bigger. What makes emission bigger also makes sensitivity bigger. If receiving area is big (because of no GND connection along bus wires) then CM current generated by external disturbances is bigger and (because not 100% symmetry) it is partially converted into differential signal what is added to useful signal and at some level...
What counts is the common mode current times common mode circuit area. If you add GND wire along your signal wires you limit the problem by making area small. If you isolate driver (but with so small isolation capacitance that it breaks current in frequencies you operate) than you limit the problem by making current small.
I use slew-rate limited drivers (like MAX3082) so I don't have high frequency in my common mode signals. For them isolation barier having about 8pF is practically a break reducing common mode current to almost 0. In such case I think GND connection is not needed and only 2 wires are OK.
But when you transmit power to driver through isolation you generate common mode current by your DCDC isolated converter. To limit it you can break isolation with for example 1nF capacitor and you not have the isolation with very small capacitance so you are back at need of using GND wire between devices.
I used MAX845 to have as symmetry as possible (to limit CM voltage) isolated supply for transceiver and I used  trafo having only 4pF and I have used ferryte beads in serie with DCDC. This construction passed EMC tests even without 1nF capacitor across isolation so it allowed to use only 2 wires without GND wire.
At least in my opinion.

Just imagine RS485 driver as Common mode voltage generator connected from your PCB GND (GND connected to Earth) to A,B (A,B imagine as single wire). If you have isolated RS485 than imagine also second noise generator connected (with DCDC capacitance in serie) between Earth and your GND. You should see that breaking isolation with capacitor you reduce noise from one source increasing noise from the second source.