I have an RS-485 network that was installed without adhering to proper cabling spec. such that it's not a twisted pair with the associated characteristic impedance of 120 ohms. As a result, I'm guessing the SWR is not equal to 1.
This may sound like an elementary question, but does the existence of a standing wave on the transmission line result in data sent or received being corrupted?
In a word, yes.
For a graphic illustration of such, look here:
For another explanation, try here:
Thanks, these links were very helpful. Can you tell me if the cable twist adds to the cables impedance. It strikes me that it would add additional capacitance since twisting would make the cable longer and the twist would add inductance.
These are distributed capacitance and inductance, so making the cable longer doesn't change it's surge impedance. I can't say that it wouldn't have some effect because twisting might well cause closer spacing and dielectric compression, but I doubt the per unit inductance would change much. These would be incidental effects.
That is, a perfect parallel line could be twisted with little or no effect except for the balancing effect on noise coupling. In a "real" shielded cable for example the twisting might affect how closely the shield contacts the cable. But if you take a piece of 300 Ohm twin lead (The most perfect parallel transmission line commonly seen) and twist it in free space, it's still a 300 Ohm transmission line.
More lossy, less consistent, cables with shields and other conductors, might do all kinds of things which would be extremely difficult to analyze. This doesn't mean that it won't act as a transmission line. Take for example the common Cat5 or 6 Ethernet cable, with multiple pairs and fairly loose physical layout and strung all over in the most haphazard way, it still works _amazingly_ well.
In my experience, rational layout of a 485 network as a linear transmission line and playing by the rules is more important than precise impedance matching. A few stubs or a wye will cause more havoc than a 15% mismatch.
cww Who does not regret the time spent trying to make the signal on the far end of the wire look something like the signal on the near end.
Curt, thanks for the transmission line primer; the information was quite helpful.
I have a small 485 network that includes a modbus master with two 485 ports for two separate networks. Each network has only one node; the nodes are identical remote I/O modules. One is 50' from the master and it is connected via 485 cabling. The other is only 1' from the master and is connected with two #18 single conductors.
Intermittently, this node – the closer one - will generate a CRC error, which I think is telling me there could be noise on the line since the sent data does not match the received data. Cycling power on the node clears the error until the next CRC event. I have changed the cable to match the cable type used for the 50' node and the issue seems to have disappeared. I'm necessarily satisfied with the solution unless I have some empirical data that says this is better.
Can I look at the A B signals referencing signal common with a scope and make an assessment that says this is better? Any thoughts would be appreciated. I should mention that I have not used terminators since distance for both is relatively short. Baud rate is 38400.
>...I'm necessarily satisfied
>with the solution unless I have some
>empirical data that says this is better.
Should have said: I'm NOT necessarily satisfied with the solution unless I have some empirical data that says this is better.
Agreed, Curt does give great explanations.
Oscilloscope for RS-485 differential signals
- need a dual channel scope
- use 'add' mode (ch 1 and ch 2)
- invert ch 2 so the result is ch 1 minus ch 2 (or vice versa, invert ch 1)
Thanks Dave. Yes, I do have a two channel scope and will set this up next week. Might you know what I might look for in terms of assessing healthy comms?
They use an "eye" display to assess jitter which is generally the limiting factor in the speed vs distance conundrum. I doubt you would see much timing scatter at 1'. Indeed it can be a problem to have too
short a cable as it doesn't have enough distributed reactance to swamp the irregularities that necessarily occur with connections. At 38,400 or more I've been known to coil 10' of cable between adjacent nodes, But usually anything reasonable works over panel distances. I've gone from PLC to drives with silver satin simply because the PLC used RJ plugs and it was convenient. For some really good info, google "ten ways to bulletproof your RS485 network".
There's an old National Semiconductor application note for 485 drivers by that name or similar. Last time I looked it up It was a Texas Instruments pub so Nat Semi must be no more. They show the eye test and a lot of good info on RS485.
My experience with RS485 has been characterized by success in spite of varied implementations and wiring configurations, for some basic reasons:
1) We ALWAYS used twisted pair wires, regardless of wire length.
2) We ALWAYS used termination resistors at the end of each length, again regardless of wire length. In a star config we would terminate at each end of the star, using values of resistance that, when all taken in parallel, resulted in an impedance closely matching the characteristic impedance of the cable. In a point to point situation we would typically use a 120 ohm resistor at each end, for a net impedance of 60 ohms. For a 4 point star, for example, we would terminate with 4 240 ohm resistors. And so on...
3) We ALWAYS biased the differential lines with a pull up and pull down resistor at some single point in the system. The plus differential line to Vcc and the other to Common. Something like a 1K resistor typically sufficed.
4) And finally, even though this is a differential system, there is limited common mode capability, so the RS485 drivers and receivers must share a common ground connection, using a THIRD conductor.
There actually exists special RS485 cable that has a single or dual shielded, twisted pair, as well as a common conductor for just such a purpose.
Many of you will have had varied degrees of success without following one or more of the above recommendations. However, I have never had a failure when I followed ALL of them. And conversely, I've had plenty of issues attributed to NOT following one or more of the above steps.
www.bb-elec.com has some good articles on RS485, check it out.
I think I have bulletproofed the install now based on many of your recommendations. Thank you everyone.
I have come across some slave settings that I'm not able to reconcile. In the first case, I have a modbus master that communicates to a single Wago I/O slave. It runs at 38400 with an end of command frame quiescent time of frame time x 3.
In the second case, I use the same slave hardware using a different master (Prosoft Prolinx) and I am not able to successfully communicate at a baud rate of 38400 with the command frame quiescent time set to frame time x 3. Again, there is only one slave attached to the master and the slave is identical to the first application. The results of my testing (shown below) indicate that I would have to drop my baud rate to 4800 to utilize the command frame quiescent time set to frame time x 3. Or, I can run at the desired 38400 but need to set the command frame quiescent time to 50 milliseconds to achieve successful communications.
using a Wago I/O moodbus slave.
Any thoughts on why two different masters might perform so differently? Maybe not the right question but at the moment, I see the masters as the the only difference between these two applications.
Baud Quiescent Time Communication Status
4800 Frame time x 3 Pass
9600 Frame time x 3 Fail
1 milliSec Fail
10 milliSec Fail
50 milliSec Pass
19200 Frame time x 3 Fail
1 milliSec Fail
10 milliSec Fail
50 milliSec Pass
38400 Frame time x 3 Fail
1 milliSec Fail
10 milliSec Pass
50 milliSec Pass
Some devices just have horribly inefficient firmware or less powerful processors, or very commonly, bad software that uses so much of the processor that it misses packets. It takes a good systems programmer with processor knowledge to do protocols well. Or they could prioritize the other aspects or they just didn't get the timing right, data from the other side must be available, any number of reasons. But it is inexcusable for a gateway product not to support a common configuration.
I would bring the point up to them, perhaps there is some obscure feature, with or without which it can support the _specification_ parameters at speed. There are quite a few older devices that won't support anything much higher than 9600 or 19200 baud. I don't count on anything higher, But I don't think it unreasonable to expect high performance from something sold as a communication device.
I've been running RS485 flawlessly at 38400 Baud for months now on a network of $99 Clicks. I fully expected to have to back it down, but no need.