that I'd like to use to create a 2-wires RS485 bus with 10 nodes.
However this transceiver isn't true fail-safe, so the receiver, if enabled, has an undefined output (with wrong data received from the UART) if the inputs are open or shorted.
This is a 2-wires bus, so only one node transmits at one time. After transmitting it disables the transmitter. In the period from the disabling of the transmitter of one node and the enabling of the transmitter of another node, the bus is in high-impedance (idle) state.
Of course, I use resistors between the two wires of the bus (as illustrated in Figure 15 of the datasheet), but in idle state the receivers reads 0V so the output is undefined!
How this bus could work with transceiver like the SN75176?
That is "background" information that you are supposed to know about. Just like there is no amplifier design tutorial in the datasheet of a transistor. It would lead to massive duplication of material.
Having said that I got bit by this the first time I implemented RS485.
But that was a long time ago, before everything was a google search away. (Kids of today...)
It's a surprise to you that if you want to make sure an undriven line floats to a certain state you should bias it with a pull-up or pull-down resistor?
What are they teaching in universities these days?
--
Grant Edwards grant.b.edwards Yow! I'm wearing PAMPERS!!
at
gmail.com
With or without pullups, a networked device should handle random garbage at the input at the protocol level. As well as check integrity of the packets.
Since we are talking about RS-485 and hence half duplex, any retransmission will degrade the troughput significantly, especially at high line speeds (due to various turn around delays), every means should be used to keep the bus in good condition.
Even if a frame always starts with a known character and hence noise characters can be ignored, the problem is false start bits less than a character time before the frame, such as reflections from a previous frame, will completely garble the frame.
One problem that really addresses these issues is Modbus RTU *IF* implemented according to the book. To send a frame, the first thing is to turn on the transmitter and actively drive it to the Idle/Mark ("1") state. Then you wait at least 3.5 character times, during which any reflections should die out and all receivers should see a healthy Idle/Mark. Only after this, there is the start bit Space ("0") of the first character in the frame.
After the actual message has been transmitted and the stop bit Mark ("1") of the last character has been sent, the line remains actively driven in the Mark/Idle ("1") state for an additional 3.5 character times, effectively killing any reflections and also ensuring a reliable end of frame detection. Only after this, is the transmitter put into tri-state and let the line float.
Thus, _if_ Modbus RTU is properly implemented, it should also work on networks that do not use fail-safe termination and even if the termination is done badly or the network topology is bad. Other protocols on the same network would most likely suffer more retransmissions.
Unfortunately, it often is not. Many slave implementations seem to ignore the 3.5 byte-time requimrent and will answer immediately following a command. Even worse, I've run into masters that will send a command immediately after receiving the last byte of a slave response -- which, on a 2-wire system makes it hard for other slaves to determine where the command actually began.
Of the implementations that do provide a 3.5 byte time gap, many of then don't drive the line to the Mark state during that gap -- they just don't transmit.
It's a shame, because the gap requirement was actually a very clever idea.
--
Grant Edwards grant.b.edwards Yow! Hey, waiter! I want
at a NEW SHIRT and a PONY TAIL
gmail.com with lemon sauce!
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.