Question about RS485 topology - Page 1
Forum section: electronics / projects

author: ogoun
author_rank: Contributor
timestamp: September 04, 2024, 04:50:56 am
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: September 04, 2024, 06:08:02 am
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 04, 2024, 06:36:32 am
content: Quote from: ogoun on September 04, 2024, 04:50:56 amI think you are describing a ring-bus, where the signal travels in a circle ? MasterTX -> Rx  Tx -> Rx Tx...RxTx -> Master RXRS422 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.Quote from: ogoun on September 04, 2024, 04:50:56 amYou 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.

author: ogoun
author_rank: Contributor
timestamp: September 04, 2024, 06:49:58 am
content: Quote from: Siwastaja on September 04, 2024, 06:08:02 amThanks 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

author: ogoun
author_rank: Contributor
timestamp: September 04, 2024, 07:41:43 am
content: Quote from: PCB.Wiz on September 04, 2024, 06:36:32 amThis 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 doI 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 04, 2024, 07:57:25 am
content: Quote from: ogoun on September 04, 2024, 07:41:43 amAhh, 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.Quote from: ogoun on September 04, 2024, 07:41:43 amSuch 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.Quote from: ogoun on September 04, 2024, 07:41:43 am9th 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 04, 2024, 08:35:48 am
content: Just draw a schematic and show us. I still think PCB.Wiz did not understand it correctly and probably me neither.

author: H.O
author_rank: Frequent Contributor
timestamp: September 04, 2024, 11:10:17 am
content: Like this?

author: PGPG
author_rank: Frequent Contributor
timestamp: September 04, 2024, 11:56:58 am
content: Quote from: ogoun on September 04, 2024, 06:49:58 amYour 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.Quote from: ogoun on September 04, 2024, 06:49:58 amI 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.

author: Doctorandus_P
author_rank: Super Contributor
timestamp: September 04, 2024, 12:03:36 pm
content: 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).Quote from: PGPG on September 04, 2024, 11:56:58 amYes 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 04, 2024, 12:47:18 pm
content: Quote from: Doctorandus_P on September 04, 2024, 12:03:36 pmIt is at least debatableInformation 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 04, 2024, 01:10:08 pm
content: Quote from: Siwastaja on September 04, 2024, 06:08:02 amWhat 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 04, 2024, 01:21:05 pm
content: Quote from: PGPG on September 04, 2024, 01:10:08 pmIn 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 04, 2024, 02:57:36 pm
content: Quote from: Siwastaja on September 04, 2024, 01:21:05 pmAs 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.

author: tooki
author_rank: Super Contributor
timestamp: September 04, 2024, 04:04:41 pm
content: Quote from: PCB.Wiz on September 04, 2024, 06:36:32 amRS-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.

author: ogoun
author_rank: Contributor
timestamp: September 04, 2024, 04:57:37 pm
content: Quote from: H.O on September 04, 2024, 11:10:17 amYes, that is it except that the master has 120r termination on both tx and rx (the 2 ends of the bus).Cheers,Pete

author: Siwastaja
author_rank: Super Contributor
timestamp: September 04, 2024, 06:16:52 pm
content: Quote from: PGPG on September 04, 2024, 02:57:36 pmBut we are not just discussing RS485, we are discussing MODBUS RTU, so that design and rules fromboth layersapply. RS485 does not specify biasingbecause it does not specify protocol, and some protocols might notneedany 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 04, 2024, 06:27:30 pm
content: Quote from: PGPG on September 04, 2024, 02:57:36 pmThere 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 geteven morenoise 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.QuoteOf 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 theyshould. This being said, broken TCP/IP stacks in Modbus TCP are even bigger pain because you can't fix it with wires and resistors, soIf CAN was more popular in automation, it would simplify a lot of things. It's just basically RS485 done right.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 04, 2024, 08:04:40 pm
content: Quote from: ogoun on September 04, 2024, 04:57:37 pmThat's not really a 4 wire design at all.It uses2 core cableand 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-standardhalf duplex, 2 wire, RS485 system.

author: H.O
author_rank: Frequent Contributor
timestamp: September 04, 2024, 08:16:54 pm
content: 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:QuoteThen, as is often the case, everybody goes off on a tangent :-)

author: Perkele
author_rank: Regular Contributor
timestamp: September 04, 2024, 09:02:48 pm
content: 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 04, 2024, 09:07:11 pm
content: Quote from: H.O on September 04, 2024, 08:16:54 pmActually, the OP saidexactlythat :The Modbus master/host controller will use4 wire RS485

author: mariush
author_rank: Super Contributor
timestamp: September 04, 2024, 10:16:35 pm
content: I'm surprised there aren't more solutions out there using plain old ethernetThese 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.htmlMagnetics 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

author: PGPG
author_rank: Frequent Contributor
timestamp: September 04, 2024, 10:58:58 pm
content: Quote from: Siwastaja on September 04, 2024, 06:27:30 pmI 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.Quote from: Siwastaja on September 04, 2024, 06:27:30 pmAs 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).

author: ogoun
author_rank: Contributor
timestamp: September 05, 2024, 12:44:41 am
content: Quote from: PCB.Wiz on September 04, 2024, 08:04:40 pmExactly 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 02:17:13 am
content: Quote from: Siwastaja on September 04, 2024, 06:08:02 amGetting 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.

author: ejeffrey
author_rank: Super Contributor
timestamp: September 07, 2024, 03:33:04 am
content: Quote from: PGPG on September 07, 2024, 02:17:13 amFail-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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 07, 2024, 06:20:02 am
content: Quote from: ejeffrey on September 07, 2024, 03:33:04 amYeah. And unlike I2C which does not workat allwithout 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...

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 11:32:09 am
content: Quote from: ejeffrey on September 07, 2024, 03:33:04 amOK. 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 threadQuote from: ejeffrey on September 07, 2024, 03:33:04 amI 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.Quote from: Siwastaja on September 07, 2024, 06:20:02 amI 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.

author: tooki
author_rank: Super Contributor
timestamp: September 07, 2024, 11:58:46 am
content: Quote from: PGPG on September 07, 2024, 11:32:09 amThat’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”.

author: Perkele
author_rank: Regular Contributor
timestamp: September 07, 2024, 11:59:38 am
content: Quote from: mariush on September 04, 2024, 10:16:35 pmThe 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.

author: tooki
author_rank: Super Contributor
timestamp: September 07, 2024, 12:04:47 pm
content: Quote from: mariush on September 04, 2024, 10:16:35 pmWell, both regular and industrial Ethernethavebeen 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.

author: tooki
author_rank: Super Contributor
timestamp: September 07, 2024, 12:12:02 pm
content: See e.g.https://en.wikipedia.org/wiki/Industrial_Ethernethttps://www.ti.com/lit/wp/spry254b/spry254b.pdf

author: Siwastaja
author_rank: Super Contributor
timestamp: September 07, 2024, 12:36:09 pm
content: Quote from: PGPG on September 07, 2024, 11:32:09 amAgain, 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 12:36:46 pm
content: Quote from: tooki on September 07, 2024, 11:58:46 amAfter 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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 01:14:49 pm
content: Quote from: Siwastaja on September 07, 2024, 12:36:09 pmI 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.Quote from: Siwastaja on September 07, 2024, 12:36:09 pmI 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.Quote from: Siwastaja on September 07, 2024, 12:36:09 pmRight. 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 07, 2024, 01:25:25 pm
content: Quote from: PGPG on September 07, 2024, 01:14:49 pmWhat "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, andcertainis that slave will not be able to detect arealframe 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.)

author: tooki
author_rank: Super Contributor
timestamp: September 07, 2024, 02:03:39 pm
content: Quote from: PGPG on September 07, 2024, 12:36:46 pmWell “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 “failto asafestate”.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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 02:27:52 pm
content: Quote from: tooki on September 07, 2024, 02:03:39 pmSorry.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.

author: PGPG
author_rank: Frequent Contributor
timestamp: September 07, 2024, 02:56:52 pm
content: Quote from: Siwastaja on September 07, 2024, 01:25:25 pmTransition 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.Quote from: Siwastaja on September 07, 2024, 01:25:25 pmExactly. 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:Quote from: PGPG on September 07, 2024, 01:14:49 pmI 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: September 07, 2024, 03:57:33 pm
content: Quote from: PGPG on September 07, 2024, 02:56:52 pmThis 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 astandard changeis 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.