RS-485 Diagnostic Checklist: How to Find the Intermittent Fault on Your Modbus RTU Bus

A few months ago an integrator wrote to us on the verge of losing his best customer. His installation — a PLC polling twelve Modbus RTU slaves over RS-485 — had run for weeks on end in the workshop without a single error. On the plant floor: timeouts, invalid CRCs, and corrupted frames every few hours, with no pattern at all. He'd spent three weeks rewriting code. The code was fine.

The fault was in the physical layer: a star topology, terminations in the wrong places, one branch run with unshielded twisted flex sharing a tray with a VFD output, and slaves powered from different points across the plant with no common reference. He rebuilt the bus as a straight line, with shielded twisted pair, two 120 Ω terminations at the actual physical ends, and a third reference conductor. Zero errors since.

That story (we told the full version in the newsletter) carries an uncomfortable lesson: RS485 problems are almost never a software issue, and they're almost always diagnosed by looking at the cable before the code. This article turns that failure into what we promised: the step-by-step diagnostic guide our support team uses on any unstable RS-485 bus, plus the design rules to keep yours off that list.

Why RS-485 Fails "Sometimes": Understanding the Enemy

RS-485 (formally TIA/EIA-485) is a differential physical layer: information travels as the voltage difference between two wires (A/B or D+/D−), not between one wire and ground. That's its great strength — noise coupled equally onto both wires cancels out — and also the root of every misunderstanding about it:

• It's a transmission line. At the speeds and lengths typical on a plant floor, the cable stops being "just a cable" and becomes a line with a characteristic impedance (~120 Ω for typical twisted pair). Any impedance discontinuity — a star point, a long stub, a missing or duplicate termination — creates reflections that superimpose on the signal and corrupt bits.
• Differential doesn't mean isolated. Standard RS-485 transceivers tolerate a common-mode voltage range of −7 V to +12 V relative to their own ground. If two nodes on the bus sit at different ground potentials (separate power supplies, different areas of the plant), that margin runs out and the transceiver stops reading correctly — even if the A−B difference itself is perfect.
• The failure rate tracks the environment, not the test bench. That's why the test bench lies to you: three meters of bus, one power supply, zero VFDs. The plant floor multiplies length, noise, and potential differences. What looked like generous margin turns into an intermittent fault.

With that in mind, RS485 communication failures group into five physical root causes: topology, termination, biasing, common reference/isolation, and cable/shielding. The checklist below walks through them in order of likelihood and ease of verification.

The Diagnostic Checklist, Step by Step

Before touching anything: write down the symptoms. Do all slaves fail, or only some? Does the farthest node fail more often? Do the errors line up with motor starts, machine cycles, or specific time windows? Even a faint pattern is half the diagnosis.

Step 1 — Draw the Real Topology (Not the One on the Drawing)

Physically trace the cable and draw how it's actually routed. What you're looking for:

• RS-485 is a line (daisy chain): master to slave 1, slave 1 to slave 2, and so on to the last node. No branches.
• Every stub is an antenna for reflections. Rule of thumb: keep stubs as short as possible, ideally under 30 cm; at 9,600–19,200 baud there's a bit more margin, but a star with stubs tens of meters long is a guaranteed intermittent fault at any speed.
• If the installation genuinely requires several long branches, the fix isn't crossing your fingers — it's an RS-485 repeater per branch, with each branch terminated as its own independent bus.

If you find a star topology, you've already got suspect number one. Keep going through the checklist anyway — bus faults rarely travel alone.

Step 2 — Verify Termination (the 60 Ω Test)

The bus must carry two 120 Ω termination resistors, one at each physical end of the line. Not one, not three, and not two in the middle of the bus.

Two-minute check: with the system powered off, measure the resistance between A and B at any point on the bus with a multimeter.

Watch out for "invisible" terminations: many devices (PLCs, VFDs, gateways) have the resistor built in, enabled via a DIP switch or jumper. Inventory which units have it enabled. The classic case: someone swaps out a VFD in the middle of the bus, and the replacement ships with termination enabled by default.

When can you skip termination? Only on very short buses (a few meters) at low speed. On a plant floor, always terminate: the cost is zero, and it eliminates an entire family of failures.

Step 3 — Check Biasing (Fail-Safe Biasing)

When no node is transmitting, the bus floats and the A−B difference can drop to zero: receivers sit in an undefined zone and interpret any noise as start bits. Typical result: garbage bytes between frames, framing errors, and slaves that "answer to no one."

The fix is bus biasing: a pull-up resistor on one line and a pull-down on the other — typically 450 Ω to 1 kΩ, at a single point on the bus, usually the master — guaranteeing more than 200 mV of idle-state difference.

Check: with the system powered on and the bus idle (no traffic), measure the DC voltage between A and B. You should see at least 200–300 mV, stable. If you measure close to 0 V, the bus is unbiased. As with termination, many devices have switchable biasing: enable it at a single point — biasing spread across multiple points loads the transmitters and distorts levels.

Step 4 — Common Reference and Isolation: the Fault With "No Pattern"

This is the least-known cause and the one that produces the most maddening symptoms, because it depends on which motors happen to be starting somewhere else in the plant.

• RS-485 is differential, but the transceiver's common-mode range is finite (−7 V to +12 V). Between two buildings, two cabinets on different supplies, or two grounding points far apart, you can easily have more difference than that — and it can vary.
• Design fix: a third common-reference conductor connecting all nodes (the third core of the cable, tied to each transceiver's signal common). On long buses, it's worth running this through a ~100 Ω resistor per node to limit loop currents.
• Robust fix for large plants, inter-building buses, or environments full of VFDs: galvanically isolated RS-485 transceivers. Isolation breaks the ground loop entirely — each node sees the bus, not its neighbor's ground. If the bus connects areas with independent power supplies, isolation isn't a luxury; it's the difference between a stable bus and a chronic fault.

Rough check: measure AC and DC voltage between the signal ground of two distant nodes (with the bus disconnected at one of them). If you see several volts — or the reading jumps when machinery starts — you have a common-mode problem.

Step 5 — Cable and Shielding: the Part Decided in a Drawer Somewhere

• Twisted pair, always. Twisting is what guarantees noise couples equally onto both wires and cancels out. Reusing parallel power flex as a bus = an antenna.
• Characteristic impedance ~120 Ω (cable rated for RS-485/Modbus, or equivalent shielded twisted pair). The termination must match the cable; terminating a 100 Ω cable with 120 Ω already introduces residual reflection.
• Shield grounded at one end (the main cabinet) to avoid loops through the mesh; in installations with a genuinely good equipotential bonding system, it can be grounded at both ends — but only if that bonding actually exists. An unconnected shield shields nothing.
• Routing: separate tray from power cabling; where crossing motor cables is unavoidable, cross at 90°. A VFD output is the most aggressive noise source in the cabinet: keep distance, and shield the motor cable from the VFD side (that's part of your bus too, even if it doesn't look like it).
• Length and speed: the classic rule is 1,200 m at ≤100 kbps. At 9,600 baud there's plenty of margin; the problem is almost never total length — it's everything above.

Step 6 — Only Now, Look at the Software

If the physical layer has passed all five steps and errors persist, it's time for the protocol layer:

• Inter-frame silence: Modbus RTU requires 3.5 character-times of silence as a frame separator. Masters that chain requests too fast, or USB-RS485 converters with aggressive buffering, violate this.
• Timeouts matched to the slowest slave, capped retries, and per-slave error counters exposed in diagnostics. A per-node counter tells you in an afternoon whether the problem is a stretch of bus or one specific device.
• Duplicate addresses and identical serial parameters (baud rate, parity, stop bits) across all nodes: a five-minute check that turns up more often than we'd like to admit.

And if you have access to an oscilloscope, use it before any software tool: the differential waveform at the farthest node shows reflections, weak levels, and coupled noise at a glance. Clean edges and solid levels mean a healthy physical layer.

The Golden Rules So Your Next Bus Doesn't Fail

1. Design the bus on paper before cutting cable: line topology, location of the 2 terminations, single biasing point, common reference, and routing.
2. Shielded twisted pair of the right impedance, shield grounded with judgment.
3. Short stubs or repeaters — never star topologies.
4. Common reference between nodes always; galvanic isolation if the bus crosses areas with separate power supplies.
5. Document which devices have termination and biasing enabled. Your future self (or the technician who swaps out a VFD) will thank you.
6. In the code: timeouts, capped retries, and accessible error counters. The bus will fail eventually — the difference is whether you find out.

Intermittent communication failures are almost never a software problem. If the error can't be reproduced on demand, start with the cable: five of the six steps in this guide only need a multimeter and a morning.

Download the checklist: "From Arduino prototype to industrial installation"
The full checklist from this article, plus the rest of the wiring, power, and communications checks our support team uses, in a printable PDF to bring to the cabinet.
👉 Download the free checklist →

What about the hardware? M-Duino PLCs come with Ethernet and RS-485 (Modbus) built in, with isolated I/O, designed for Modbus RTU buses exposed to real plant-floor noise. Technical detail on the M-Duino 21+: https://www.industrialshields.com/technical-features-industrial-m-duino-plc-arduino-ethernet-21-ios-analog-digital-plus (product: https://www.industrialshields.com/shop/is-mduino-21-m-duino-ethernet-plc-arduino-21-3670).