Modbus RTU Timeouts Are Usually a Wiring Problem: An RS-485 Commissioning Walkthrough

The SCADA driver shows five power meters on one RS-485 segment. Three read fine, two go bad-quality every few minutes, and the integrator has already spent an afternoon changing register offsets. That's the wrong afternoon. Modbus RTU is trivial at the application layer — function code 3, a start address, a quantity, a CRC — so when a link is flaky, the fault is almost always electrical, not a bad register map. RS-485 is a differential bus with real rules about impedance, biasing, and grounding, and it punishes shortcuts quietly: the frame just never arrives, and the master logs a timeout.

So commission in the order the signal actually travels: wire, then framing, then registers. Prove the segment can carry a clean differential signal, prove every device agrees on baud/parity/stop, and only then argue about whether it's holding registers or input registers. Skip a layer and you'll troubleshoot all three at once, which is how a two-hour job becomes two days.

First, draw what's actually installed

Before you change a single timeout, walk the segment and sketch it. RS-485 is a daisy-chained bus, not a star — one cable in and out of each device, two ends, no spurs. The TIA/EIA-485-A driver is specified to drive 32 unit loads over up to ~1200 m (4000 ft) at low speed, but that budget assumes a clean chain. Half the "intermittent" segments I've been called to were stars left over from old 4-20 mA instrument wiring: fine with two meters, unstable the day someone landed a VFD drop off a mid-span junction.

Write down, per segment:

• Cable type and run length end to end (a proper run uses 120 Ω twisted pair with a drain — Belden 3106A or 9841, 22 AWG, not spare thermostat wire).
• Device order along the chain and which two devices are the physical ends.
• Where the shield is bonded — one end only, or you build a ground loop that couples every VFD transient onto the pair.
• Which two ends have the 120 Ω terminator enabled, and where any fail-safe bias lives.
• Which converters or ports are galvanically isolated.

If the topology is a star and you can't rechain it today, don't bury it — note it as a known risk on the drawing. Otherwise the next person spends their own afternoon on register offsets.

Polarity: measure, don't trust the silkscreen

RS-485 terminal labels are a mess across vendors. One device calls the non-inverting line A, the next calls the same line B, and a third prints D+/D-. There is no convention you can rely on — the "A/B" naming in the original standard is actually inverted from how most chip vendors label their pins, which is why the field is a coin flip.

So don't reason about it, test it. Reduce to master plus one slave, set the real baud/parity/data/stop, and send one documented read (FC03 against a register you know exists). No response? Swap the pair at one end only, retry. When it answers, mark the conductors with the site convention and move on.

Watch for the tell that a slave works only when you swap: if fixing one device breaks another, you've got mixed polarity spliced somewhere mid-chain. Fix the wire. Do not "solve" it by inverting one device in the driver config — you'll have papered over a splice that the next added device will trip over.

Termination goes on two ends, period

A 120 Ω terminator across the pair kills the reflection from the far end of the line. It matches the cable's characteristic impedance, so it belongs at exactly the two physical ends of the bus — nowhere else. The single most common RS-485 mistake I see is a terminator (often a DIP switch) left enabled on a device sitting in the middle of the chain, which slices the segment in two as far as the signal is concerned and starves everything downstream.

The symptoms all point at "physical layer," not "software":

• Works on a 2 m bench cable, fails on the 300 m installed run.
• CRC errors climb as you raise baud — reflections that were tolerable at 9600 aren't at 38400.
• Rock-solid with three devices connected, unstable once all twelve drops are landed.
• Low signal amplitude on a scope because four terminators in parallel are dragging the driver down.

Quick field check with the bus powered off: measure resistance across the pair. Two correct terminators read as two 120 Ω in parallel, so you should see ~60 Ω (a little off depending on internal bias networks). Read ~30 Ω and someone left extra terminators on; read open and you have none.

Biasing keeps the idle line from lying to the receiver

Here's the failure that eats hours because it looks like corruption, not silence. Modbus RTU frames are delimited by silence — the spec (Modbus over Serial Line V1.02, §2.5.1) requires at least 3.5 character times of idle between frames and no more than 1.5 character times between characters within a frame. At 9600 8N1 a character is 11 bits, so 3.5 chars ≈ 4.0 ms. During that idle gap every driver is tri-stated and the pair floats. If it isn't biased, noise pulls it across the receiver threshold, the UART sees phantom start bits, and you get framing/CRC errors before a real request even begins.

Fail-safe bias is a pull-up on the non-inverting line and a pull-down on the inverting line, sized to hold the idle differential above the ~200 mV that guarantees a defined 1. Put it in one controlled place per isolated segment:

• Many masters and gateways have it built in (sometimes switchable).
• Converters usually expose pull-up/pull-down DIP switches.
• Some field devices carry fixed bias you can't disable — worth knowing before you add more.

Resist the urge to enable bias at every cabinet. Each bias network loads the bus, and stacking them drops your noise margin instead of raising it. If repeaters split the run, each segment is electrically separate and needs its own single bias source.

Then match the framing, then the registers

Now the boring layer that's genuinely fast to check. Every device on the segment must agree on baud, parity, data bits, stop bits, and address; the driver must also agree on response timeout and the inter-request/turnaround delay. The classic trap is 9600 8E1 on the meter and 9600 8N1 on the master — wiring perfect, UART framing mismatched, every response discarded. Even parity plus one stop bit and no parity plus two stop bits are both 11-bit frames, but they aren't interchangeable; the receiver rejects the frame it wasn't configured for.

On multi-drop, commission slow. Get the whole chain stable at a conservative baud first, then raise it only if scan time demands it and the cable quality and CRC counters say you have the margin. There's no prize for running 115200 on a 400 m run that only needs to poll every second.

Poll for the slowest device on the bus, not the fastest

A Modbus RTU master waits for each slave to turn its driver around and answer. Power meters and drives usually reply in a few ms; protection relays, weigh indicators, and protocol bridges can take tens of ms, more when busy. Set the response timeout for the slow one — but don't let the slow one set the scan.

Capture during commissioning: normal and worst-case response time per slave, timeout and CRC counts per hour, retries-before-bad-quality, and the largest register block each device tolerates (some cap FC03 well under the 125-register protocol limit). If one relay's diagnostic register that changes once a minute is dragging your 500 ms process poll, split it into its own slow poll group. Making fast tags wait on a slow one is self-inflicted latency.

The four calls you'll actually get

"One device answers, the rest are silent." Duplicate slave addresses, reversed polarity past the first device, or a terminator left on at device #1 as if it were the end of the line. Check those before anything in software.

"It only drops when the motor starts." Textbook coupling. Look at shield bonding, how close the pair runs to VFD output cables, converter grounding, and whether the port is isolated. Fix routing and grounding — a longer timeout just hides it until the next start.

"Values update but quality flickers bad." Intermittent CRC errors, a timeout set too tight, or a block read larger than the device supports. Confirm your retries aren't masking a persistent problem that operators still see as quality noise on the graphic.

"USB dongle works, the installed gateway doesn't." Compare serial settings, polarity, bias, and isolation — and check register base convention. A test tool that treats 40001 as offset 0 and a gateway that treats it as offset 1 will read one register apart and look like garbage data.

Leave evidence, not folklore

The point of writing anything down is that the next person doesn't repeat your afternoon. Leave the topology sketch with terminator and bias locations marked, the device address list with serial settings, the driver's timeout/retry/poll-group config, the baseline timeout and CRC counters after a stable run, photos of every converter and device DIP switch, and an honest note on any non-ideal topology you couldn't fix. That last one is the most valuable thing on the page — it's the difference between a documented compromise and a mystery.