Modbus RTU on RS-485 Not Responding: Field Troubleshooting Procedure

intermediate · 15 min

A dead Modbus RTU segment tells you one of two things: nothing came back, or something came back broken. Those two symptoms point at opposite halves of the problem. This procedure splits them apart, then fixes each — polarity, common, termination, biasing, frame settings and the one mis-set slave that takes the whole multidrop down.

ℹ️ Stop thinking of "no comms" as one fault. Modbus RTU only ever fails two ways, and they mean opposite things. A timeout means your frame never reached a device that was listening — that is an addressing, configuration or continuity problem. A CRC error means the frame did arrive, but damaged — that is a physical-layer or collision problem. Sort your symptom into one of those two buckets before you loosen a single terminal screw, and you have already eliminated half the causes without touching the machine.

An RS-485 segment wants exactly two 120 ohm terminators, one at each physical end. A third fitted at a middle station drops the bus load to 40 ohm — below the 54 ohm load RS-485 drivers are specified into — and plants an impedance step mid-span, so edges sag and ring back across the 200 mV receiver window until frames fail CRC and the master times out on all three slaves.

Tell the two failures apart first

Timeout — the master sent a request and heard nothing inside its response window. On most masters the transmit LED pulses and the receive LED stays dark.

CRC error — something came back and failed its checksum. CRC (Cyclic Redundancy Check) is the 16-bit value on the end of every RTU frame. The receiver recomputes it, and on a mismatch discards the frame silently — Modbus never sends an exception code for a bad CRC. So a CRC fault often also ends as a timeout. The difference is whether your master counts CRC/parity errors separately from timeouts. Some do; plenty of PLC Modbus masters expose only a single comms-fault bit, in which case you need a line monitor or the slave's own FC 08 counters to tell the two apart.

That last row matters, with one qualification. An exception reply (function code with the high bit set, plus code 01–04) proves that one transaction got through intact in both directions: the request reached the slave with a valid CRC and the reply reached the master with a valid CRC. That is strong evidence the physical layer works. It is not proof the link is healthy — a marginal bus can pass 60% of frames and still return the odd exception. And exception 04 is an internal device fault, not a register-map fault. So: an exception among otherwise clean traffic sends you to the request; an exception mixed into a rising CRC count still leaves you on the wiring.

The A/B polarity trap

The two data conductors have no universally agreed letters, and this is not sloppiness by one vendor — it is a genuine conflict between two documents.

• TIA/EIA-485 and the Modbus serial spec: the inverting line is A, the non-inverting line is B. The Modbus over Serial Line spec avoids relying on the letters and mandates the circuit names D0, D1 and Common, mapping D1 → B/B′ and D0 → A/A′. Its own table defines D1 as the terminal where V1 > V0 for the binary 1 (OFF) state — that is, D1/B is the line held positive when the bus is idle.
• RS-485 transceiver chip datasheets: almost universally the opposite — A is the non-inverting pin, B is inverting. The SN75176 truth table and its descendants set this convention and it is now entrenched.

So a panel builder reading a chip datasheet and one reading the Modbus spec will silk-screen the same terminal with opposite letters. Both are "correct."

Ignore the letters. Match on function: inverting to inverting, non-inverting to non-inverting, or simply – to – and + to + where the vendor prints signs. When the terminal only gives you letters, confirm against the manual's signal description, not the label.

The field test: stop the master polling — genuinely idle, not merely between transactions — and with biasing active put a multimeter on DC volts across the pair. D1/B(+) should sit a few hundred millivolts positive with respect to D0/A(–). RS-485 receivers resolve a valid level down to about 200 mV of differential input; below that the receiver output is undefined. Read a similar magnitude negative at a device and that device's two wires are swapped.

Read close to zero and interpret with care — it means no external biasing, or a shorted pair, or a driver stuck on. Note also that many modern transceivers have internal fail-safe receivers and run correctly with no external polarization at all, so a near-zero idle reading is a prompt to investigate, not a verdict.

Reversing the pair damages nothing. Swapping to test is safe electrically — but see the safety warning below.

Why the common conductor is not optional

RS-485 is differential, so technicians assume two wires suffice. The Modbus serial spec is explicit: "a third conductor must also interconnect all the devices of the bus: the common."

Transceivers only reject noise while both lines stay inside a limited common-mode voltage range — nominally –7 V to +12 V with respect to the receiver's own ground. Without a shared reference, two panels fed from different distribution boards can drift outside it, and the receiver stops resolving a signal that looks perfectly good on a scope. Symptom: works on the bench, throws CRC errors in the plant, or fails only when a large drive starts.

Use shielded twisted pair with a third conductor or a separate pair for common. The spec requires the common to be tied to protective ground at one point only for the entire bus — generally at the master or its tap — and the shield likewise bonded at a single point.

How many devices the segment will carry

A standard RS-485 driver is specified to drive 32 unit loads on a segment, and the Modbus spec states that 32 devices are always permitted without a repeater. Transceivers rated at a fractional unit load (1/2, 1/4, 1/8 UL) let you exceed 32 physical devices within the same drive budget — check the transceiver rating in each device's manual rather than counting boxes. Overloading the driver flattens the differential swing toward the 200 mV threshold and produces exactly the "worsens as baud rises" signature.

Termination and biasing do different jobs

They are constantly confused. They are not the same thing.

Termination kills reflections. Fit it across the pair at the two physical ends of the trunk — and nowhere else. The Modbus spec gives the value as 150 Ω (0.5 W), and offers 120 Ω (0.25 W) in series with a 1 nF (10 V minimum) capacitor as the better choice where the pair is polarized, because the capacitor blocks the DC path that would otherwise drag the bias down. In practice 120 Ω is the value most installations use, since it matches the characteristic impedance of typical RS-485 cable. Every extra resistor loads the driver further; terminate mid-span devices and you can flatten the signal until nothing decodes.

Biasing (polarization) pulls the idle bus to a defined state so receivers do not read noise as data. Pull-up to +5 V on D1, pull-down to common on D0, at one location only for the whole serial bus — normally the master or its tap. The Modbus spec puts these between 450 Ω and 650 Ω, and notes that 650 Ω loads the bus less and so may allow a higher device count. Two devices biasing simultaneously fight each other.

Every device must agree on the frame

Baud rate, data bits, parity, stop bits and a unique slave ID must match across the entire segment. Modbus RTU's default is 8 data bits, even parity, 1 stop bit — an 11-bit character. With no parity, the spec requires 2 stop bits so the character stays 11 bits long. This is why 8-N-1 and 8-E-1 devices on one bus misbehave in ways that look random.

Slave IDs run 1 to 247. 0 is broadcast — every device acts and none replies, so a device left at 0 appears permanently dead. Addresses 248–255 are reserved and some stacks will refuse them outright.

The silent interval

RTU has no start or stop character. Frames are delimited by silence. A gap of 3.5 character times (t3.5) marks the end of a frame; a gap over 1.5 character times (t1.5) inside a frame makes the receiver declare it incomplete and bin it. Above 19200 baud the spec recommends fixed values instead of calculated character times: 750 µs for t1.5, 1.75 ms for t3.5.

This is why USB-to-serial converters cause phantom timeouts. Buffering inserts gaps mid-frame. On FTDI-chipset adapters (vendor-specific) the Windows driver exposes a Latency Timer, default 16 ms, under Device Manager → the COM port → Port Settings → Advanced. Reducing it fixes a class of faults that looks exactly like a wiring problem.

How one device disrupts the others

Not all mis-settings are equal, and the difference decides where you look.

Self-limited — the device damages only itself. Wrong ID, wrong parity, wrong baud rate. An RTU slave transmits only after a frame arrives whole and passes the CRC-16 check. A device on the wrong baud rate sees a garbage byte stream; the odds it both matches that device's address and passes CRC are on the order of 1 in 65,536 per candidate frame, and parity or framing errors usually reject it first. So it stays silent. That is a dead slave, not a poisoned segment — do not chase a baud mismatch to explain faults on other devices.

Segment-wide — the device corrupts transactions it is not part of. Three real mechanisms:

• Duplicate ID. Two devices answer the same poll, drive the line simultaneously, and mangle each other. CRC errors concentrated on one address.
• A driver that will not let go. A stuck or late-released transmit enable — firmware turnaround bug, a converter doing automatic direction control badly, or a converter driven by RTS with the wrong timing — leaves that device holding the bus into the next transaction. Corruption appears on whichever slave happens to be answering next, so it looks random.
• A master polling faster than turnaround. The master re-keys before the previous slave has released the line. Same signature, different culprit.

The diagnostic tell for the segment-wide class is corruption scattered across unrelated slaves with no pattern by address. Test it cheaply first: raise the master's inter-request delay to ~1000 ms. If the corruption stops, you have a turnaround/contention problem, not a cable problem — then find which device or converter is the slow one.

Step-by-step

1. Read the master's counters before changing anything. Note timeouts versus CRC/parity errors separately if your master separates them. Changing settings first destroys your evidence.
2. Check for an exception reply. Codes 01–04 mean that transaction's link was clean — go and read the request. Code 04 means go and read the device's fault log, not the register map.
3. Confirm the physical segment is a daisy chain, not a star. Stubs must be short. Confirm termination at exactly the two ends, nowhere between. Count devices and check unit-load ratings against the 32 UL budget.
4. Meter the idle pair on DC volts at the master and at the far device, with the master stopped. A few hundred millivolts, D1 positive to D0. Reversed sign means a swapped pair at that device.
5. Verify biasing exists at exactly one point on the segment.
6. Halve the baud rate. This is free and instantly reversible, so do it before anything invasive. If CRC errors vanish at 9600 but return at 19200, the cause is physical: termination, stub length, cable quality, unit loading, or the converter.
7. Raise the master's inter-request delay to ~1000 ms. Also free and reversible. If scattered corruption stops, you have a bus turnaround/contention fault — suspect the converter's direction control or a slow-releasing slave, not the cable.
8. Compare frame settings device by device against a written list: baud, data bits, parity, stop bits, slave ID. Do not trust the drawing — read each device's own display or config tool.
9. Query the diagnostic counters with function code 08 if the device supports it: 0x0A to clear first, then 0x0B (did it hear anything at all), 0x0C (CRC errors it received), 0x0D (exceptions it sent). Not all stacks implement FC 08 — many return exception 01.
10. ⚠️ Safety — everything from here stops communications and can drop outputs, freeze a drive at its last commanded value, or fault the PLC. Obtain a permit, confirm the machine is safe to lose comms, then isolate. Disconnect all slaves and reconnect them one at a time, polling each as you go. The device that reintroduces the fault is your culprit.
11. Under the same permit, check for a ground potential difference. You cannot see it with the common landed — the conductor is already tying the two references together and carrying whatever circulating current exists, so a meter across it reads near zero by definition. Lift the common at the far panel and meter, AC and DC, between the lifted conductor end and that panel's own 0 V/PE. (During first commissioning, measure PE to PE between the two panels before the common is landed.) Any meaningful reading means you need an isolated converter or repeater, not a longer cable.
12. Poll the suspect in isolation with an independent master over a known-good USB-to-RS-485 converter — Modbus Poll, QModMaster, or mbpoll -a 5 -b 9600 -P even -t 4 -r 1 /dev/ttyUSB0 on Linux (COM3 style ports on Windows). This separates a device fault from a master-configuration fault.
13. Fix, then re-run steps 1, 6 and 7 to confirm the error counters stay at zero under load and at the working baud rate.

Never do this

Never let the RS-485 common be the plant's earth. This is the expensive one. Omitting the third conductor and relying on machine earth as the return path — or bonding the common to PE in more than one panel — creates a ground loop. Circulating current flows through the transceivers, and they fail: sometimes immediately, more often one panel at a time over months, with intermittent CRC errors in between while people replace cable. Run a dedicated common, bonded to protective ground at exactly one point for the whole bus, and bond the shield at one point only. Where panels are on different supplies or far apart, use isolated converters or isolated repeaters.

Never fit termination at every device. "More termination must be safer" is the most common self-inflicted RS-485 fault. Each resistor loads the driver; enough of them and the differential voltage never reaches the receiver's ~200 mV threshold.

Never swap the A/B pair on a running machine to "see what happens." The swap harms no hardware, but losing comms mid-cycle can freeze a drive at its last speed reference, drop I/O held by a remote block, or fault the controller. Break communications only under the same permit you would use to stop the machine.

Never change a slave's baud, parity or ID without a written record of the old value. A device you cannot talk to and whose previous settings you do not know usually requires a physical reset procedure — and on some hardware, the vendor's own tool and cable.

Never assume the terminal labels are right. Verify against the manual's signal description or the idle voltage, every time.