Question about RS485 topology

[PGPG]

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

Getting back after I was off-line for some time.

I am at EEVblog not a long time (may be a month). And I sow this sentence (that it is incorrectly called) at least 2 times in past and third time now. I don't know if these was always said by you but it is probable.
As I always thought of fail-save term as being very concise and accurate definition I just wanted to know what can be the reason someone says that it is incorrect.
This is why I asked.

My question has nothing to do with protocol used as fail-save is parameter specified for ICs irrelevant of protocol they are then used. So fail-save is the hardware parameter of IC (or a parameter of bus obtained by biasing). One protocol can need it, other not, but it is not protocol that make bus or IC fail-save.
The explanation that as this term is used for such things as Y-capacitors than it can't be used for RS485 bus idle state reading is some justification, but it doesn't fully convince me. One might as well argue that since the term fail-save is used in RS485 it cannot be used for Y-capacitors. It is normal that the same term can be used in different situations in different meanings (I suppose term 'hot' has also more than one meaning).

For me fail-save term simply says that the IC having this parameter will read idle bus always as '1' state. So it protects you (save) from faulty (fail) reading the idle bus as '0' state. So for me fail-save is the shortest possible and self explanation term that can be used here. I can't imagine the better one so I have a problem to agree that it is incorrect.

If someone says that the term is incorrect than I suppose he knows better term to be used in place of this one. So my question about that other term.

[ejeffrey]

not protocol that make bus or IC fail-save.
The explanation that as this term is used for such things as Y-capacitors than it can't be used for RS485 bus idle state reading is some justification, but it doesn't fully convince me. One might as well argue that since the term fail-save is used in RS485 it cannot be used for Y-capacitors. It is normal that the same term can be used in different situations in different meanings (I suppose term 'hot' has also more than one meaning).

Fail-safe normally means something "fails" in a way that is "safe" (doesn't produce harmful behavior) even though it is not working.  The point is that the idle state of RS485 is not a failure.  It's part of normal operation. 

And the common use of the term definitely causes confusion and real problems.  People misunderstand, they think that the purpose of "failsafe biasing" is protect against things like cut cables.  So they reason that if they are not routing their cables somewhere that could be damaged or if the thing they are controlling can't do anything hazardous they don't need it, and leave them out.  This happens *all the time* and I think it is in large part caused by the misleading name. 

As for a better name, I would call them something like "idle state pull ups".  That accurately describes what they are and why they are needed, and I don't think people would omit them if that is what they were called.  For instance nobody implementing I2C or CAN bus is confused into thinking the pullups are unnecessary.

[Siwastaja]

And the common use of the term definitely causes confusion and real problems.  People misunderstand, they think that the purpose of "failsafe biasing" is protect against things like cut cables.  So they reason that if they are not routing their cables somewhere that could be damaged or if the thing they are controlling can't do anything hazardous they don't need it, and leave them out.  This happens *all the time* and I think it is in large part caused by the misleading name. 

Yeah. And unlike I2C which does not work at all without the pull-up, a non-biased RS485 bus sometimes/often works - just with no noise margin by sheer luck. Then people think "oh this is the robust RS485 used in the industrial noisy applications, this is great!" But having to provide the idle state by biasing already cuts the noise margin to like one tenth of the "advertised". Failure to provide those resistors then cuts it even further, maybe by another order of magnitude.

Add stuff like lack of proper ground wire but some weird parasitic route to maybe barely get the transceivers into common mode range and you have your typical RS485 system which "works" and then the customer calls back it's not working, working, not working, working...

[PGPG]

Fail-safe normally means something "fails" in a way that is "safe"

OK. And I got the answer I was asking for.
As I met this term at the end of 90s and only in context of RS485 (even I know what are Y-capacitors I didn't noticed using fail-save term there) and I adapt the meaning of English terms to the situation I see them then I just translated fail-save for me as 'being protected against fails (fail readings)' and not 'failing in save way'.
And everything about this term seemed fine to me until this thread

People misunderstand, they think that the purpose of "failsafe biasing" is

I understand what you are speaking about, but to tell you the truth I am extremely surprised that "failsafe biasing" is still used by anyone.
We tried it in 90s and it was in my opinion simply impossible to use. For example we wanted our RS485 to be robust to switching off power of one of devices on bus. In this situation, the rest should function normally. If in device terminating the bus you switch on termination resistor it still works when device is not powered, but if you have biasing there...
To allow for making a bus having from 2..100 devices I was trying to add 'some biassing' to each of them.
We use protocol (no pulling, anyone who wants to say something just transmits) needing failsave to let devices to see if bus is busy or idle.
When at the end of 90s MAXIM introduced failsave ICs all my problems were solved.
Since then I was sure that when people use protocol needing failsave than they just use failsave ICs and if they need not failsave they use ICs without failsave.

I have never followed any electronic international forum (since 2017 I am only at KiCad forum). After entering EEVblog I am shocked to hear that failsave biasing is still used by someone while from my point of view there were already 25 years to withdraw from this complicated solution.

calls back it's not working, working, not working, working...

I can imagine it as I noticed that problem in 90s in small system (about 10 devices) connected at my desk. Frame were continuously colliding because devices couldn't correctly identify bus idle state.
Because of this we 'invented' biasing and then found failsave ICs. I had also to learn that some manufacturers call failsave devices that are failsave only when bus is 'opened' and not 'shorted' so you have to select them very carefully. Now we use only HVD72 ICs.

I understand that with failsave biasing you can make noise margin higher, but margin offered by failsave ICs was always enough for us. I use diode bridge + 2 transils + 4.7 mH common mode choke at each node and never noticed real noise problems but it is not heavy industry where our devices work. Buses with up to 40 devices rarely, but happens.

[tooki]

Fail-safe normally means something "fails" in a way that is "safe"

OK. And I got the answer I was asking for.
As I met this term at the end of 90s and only in context of RS485 (even I know what are Y-capacitors I didn't noticed using fail-save term there) and I adapt the meaning of English terms to the situation I see them then I just translated fail-save for me as 'being protected against fails (fail readings)' and not 'failing in save way'.
And everything about this term seemed fine to me until this thread

That’s understandable: Outside of engineering circles, I think most native English speakers actually mistakenly think “fail-safe” means “resistant to failure”, and not “fails to a safe state”.

[Perkele]

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

The cost of cabling is not negligible, and also the cost of labour.
You can't daisy-chain BASE-T Ethernet, and you need some additional devices for longer distances.
Even 802.3cg (single pair) is limited this way.
Which means that you'll need hubs, switches and power supply for them.
Longer cables mean more copper, more complexity means more skilled technicians to assemble the whole setup.

With plain old RS-485 you can go up to 1km, daisy-chain a bunch of devices, and have a relatively low-paid half-competent electrician to connect all of that.

There won't be a simple solution until the industrial sector starts demanding higher bandwidths.

[tooki]

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

Well, both regular and industrial Ethernet have been steadily growing for automation purposes. But due to the higher electrical noise of industrial environments, and the frequent need for extra-robust connections (both from a physical and data transmission perspective), industrial environments have been using industrial Ethernet. That equipment is much more robust, but costs more. You cannot risk a critical piece of equipment going down because of Ethernet packet loss, for example.

[tooki]

See e.g.
https://en.wikipedia.org/wiki/Industrial_Ethernet
https://www.ti.com/lit/wp/spry254b/spry254b.pdf

[Siwastaja]

I understand what you are speaking about, but to tell you the truth I am extremely surprised that "failsafe biasing" is still used by anyone.

Again, as I said already, it is mandatory in Modbus RTU if you want interoperability. Not everyone designs every device on the bus. When I have that luxury, I don't use RS485 maybe at all, and definitely not Modbus. Everything RS485 for me has been for communicating with existing products on the market (e.g., nowadays power meters, EV chargers, solar inverters, battery systems), and as you have no control over what transceiver ICs they use, you can't assume they use those with shifted thresholds where A-B = 0V is a well defined idle state.

We use classic transceivers too as they offer best price and second-sourcability, pretty important aspects today. You can always substitute with a better IC, but not the other way around unless you have provisioned for the resistors.

[PGPG]

That’s understandable: Outside of engineering circles, I think most native English speakers actually mistakenly think “fail-safe” means “resistant to failure”, and not “fails to a safe state”.

After I have written my last message I was still thinking about these terms and came back to write something like you wrote.
According to my English language feeling the correct would be for Y capacitor a term failingsave and for RS485 failsave.

[PGPG]

Again, as I said already, it is mandatory in Modbus RTU if you want interoperability.

I don't know 'Modbus" standard but I am simply surprised that it was not modified with some transition time allowed to have it now be failsafe biasing free.

When I have that luxury, I don't use RS485 maybe at all,

I like RS485 very much. Fast, long distance, noise robust. You don't need state be stable at whole bus before you send next bit.
I don't like CAN as one state and slope have to be weak.
When trying to estimate a collision risk in our system I got that in small system collision will happen once per 9 years with the only effect of after not receiving confirmation a frame will be repeated several ms later. The bigger system the risk is higher but still one frame collision per month is not noticeable by users.

We use classic transceivers too as they offer best price and second-sourcability, pretty important aspects today.

Right. It was also very big problem for us when TI:SN65HVD72 disappeared. I didn't found any fully satisfactory equivalent. Other have internal ESD protection at lower voltage so my external Surge protection will not took 100% of pulse current away from IC internal protection. We ended these crisis times with having in all PCBs a double footprints (SO8 + VSON8). Now we have some not fully satisfactory equivalent ICs (bought just in case) to use up.

[Siwastaja]

I don't know 'Modbus" standard but I am simply surprised that it was not modified with some transition time allowed to have it now be failsafe biasing free.

What "transition time"? If you don't understand the problem, then you don't see the solution either. So I'll explain the problem: with no biasing and no noise margin, you have UART receiving random bit sequences. This causes slaves to detect random frame starts. In worst case a frame could be interpreted as some command, but with CRC16 this is unlikely. More likely is that slave malfunctions somehow, and certain is that slave will not be able to detect a real frame start during the time its UART is processing the noise frame, before giving up with framing error.

I have seen an RS485 system which was completely nonfunctional due to this random garble that hogged the line. Every now and then a valid frame got through.

If the protocol is based on UART having to listen to asynchronously arriving commands in a single master, multi slave system, there is not much more to do than to have a valid idle state, either by using a transceiver for which A-B=0V is a valid state as you do, or biasing the lines with resistors into valid state. ("valid" in this context means also something with sufficient noise margin.)

[tooki]

That’s understandable: Outside of engineering circles, I think most native English speakers actually mistakenly think “fail-safe” means “resistant to failure”, and not “fails to a safe state”.

After I have written my last message I was still thinking about these terms and came back to write something like you wrote.
According to my English language feeling the correct would be for Y capacitor a term failingsave and for RS485 failsave.

Well “save” is not a part of either meaning, because “save” is a verb, and we need “safe”, the adjective.

“Failingsafe” (which we would never say, and never write as one word) and “failsafe” don’t really contrast with each other in meaning. They just use different tenses of the verb “fail”.

In the true meaning, “fail-safe” can be viewed as being short for “fail to a safe state”.
The other meaning is just people misinterpreting it as “failure-proof”. But this meaning is so widespread that it is in the dictionaries, and even though the strict nerd in me considers it wrong, we have to accept it as normal usage now, too.

[PGPG]

Well “save” is not a

Sorry.
I read save and safe the same so make such mistakes when try to write from how I hear in head what I want to write.
Also lower or lover I never know which one mens smaller. Each time I have to check in translator.
Also I read 'what' with 'o' in the middle so for 2..3 years I was wrongly writing whot (few times a year) at KiCad forum until someone pointed it out to me. I think I didn't made this mistake there since then, but once I noticed at last moment that I have written it once more wrongly so may be other time I just didn't noticed and simply don't know it.

[PGPG]

What "transition time"? If you don't understand the problem,

Transition time - for example 10 years where it would be forced that all new devices have to use failsafe ICs but buses were also failsafe biased. After these period all new installed buses would be not failsave biased. After next 10..20 years the problem with failsafe biasing would be in my opinion only history.

Why you suppose I don't understand technical problem? I understand it.
What I don't know is how long devices live at market. For me information that 'you have 10 years and then each new bus will not have failsafe biasing' is not to be seen as restrictive. So if you will not change transceivers in your production to failsafe your devices will not be used at new installations. I think no one creates a 10-year stock of finished products so it should be no problem to anyone, specially that failsafe ICs are pin-to-pin compatible with standard onse.

to have a valid idle state, either by using a transceiver for which A-B=0V is a valid state as you do, or biasing the lines with resistors into valid state.

Exactly. But in my opinion solution with failsafe ICs generates much, much less problems (with installation doubts) than solution with biasing bus with resistors.
It is why I have written:

I am simply surprised that it was not modified with some transition time allowed to have it now be failsafe biasing free.

I just suppose that if standard would be modified in 2000 and biasing will be stopped in 2010 than now all failsafe biasing problems would be gone.

[Siwastaja]

Transition time - for example 10 years where it would be forced that all new devices have to use failsafe ICs but buses were also failsafe biased. After these period all new installed buses would be not failsave biased. After next 10..20 years the problem with failsafe biasing would be in my opinion only history.

This is totally delusional. RS485 and modbus is totally all over the place, even simple engineering practices seem impossible to device manufacturers. Even the current modbus standard is totally ignored, I think I have never seen a ****ing single Modbus standard compliant device.

Orchestrating a standard change is not possible. Assigning it a totally new name, say Modbus RXU meaning Modbus eXtra Good Over RS495, could theoretically be possible, but .... nah, there are other modern solutions if everybody has to switch.

There is only one real way for interoperability: do what is needed to interoperate, instead of dreaming about some process optimization/modernization. Use those two freaking resistors and the job is done.