Modbus RTU not responding: a diagnostic sequence

A Modbus bus that will not answer is a miserable thing to debug, because every layer can produce the same symptom. Wrong baud rate, reversed A and B, a missing terminator, a duplicated unit ID and a dead device all present identically: the master waits, nothing comes back, the log says timeout.

The way out is to stop guessing at causes and start from what you can actually observe. Three symptoms, three different searches — and the first two measurements take a multimeter and about two minutes.

Nothing answers, ever#

If no device on the bus responds, the fault is almost certainly common to all of them: the wiring, the electrical layer, or the serial settings. Two measurements narrow it down before you open any software.

Power everything down and measure resistance across A and B.

Too many terminators is the one people do to themselves. Five devices with their jumpers on present about 24 Ω, the drivers cannot pull that hard, and the differential signal collapses.

Power up, poll nothing, and measure DC volts across A and B. An idle bus with fail-safe biasing sits a few hundred millivolts positive. Zero means no biasing anywhere, and noise on a floating bus gets read as the start of a character. Bias at one point only, normally the master.

If both measurements are good, work through the settings that must match on every device: baud rate, data bits, parity — the one people forget, and 8N1 versus 8E1 produces exactly this symptom — and stop bits. Then check A/B polarity at the master, because reversing it there kills the whole bus while reversing it at one device kills only that device.

One more, easy to miss: the signal common. RS485 transceivers have a common-mode range of about −7 V to +12 V relative to their own ground. Two devices in the same panel always sit inside it. A device in a building 200 m away, fed from a different board, may not — and it will be silent for reasons no amount of configuration will fix. Run a third conductor.

Some devices answer, some do not#

This is the useful symptom, because it proves the bus itself works. The wiring, the baud rate and the termination are all fine, or nothing would answer. The fault is specific to the devices that are quiet.

Duplicated unit IDs are the commonest cause, and they produce a characteristic mess: two devices transmit simultaneously, the frames collide, and the master sees corrupt data that looks like electrical noise. Meters that reset to a default address after a power failure will do this to you weeks after commissioning, which makes it hard to connect to any change.

A/B reversed at one device kills that device and nothing else.

The device is not at the address you think. Some meters expose their unit ID only on the front panel, and it does not always match the label somebody stuck on the enclosure.

To find any of these on a bus of twenty: disconnect half. If the remaining half works, the problem is in what you removed. Halve again. Four or five iterations locate a bad device or a bad spur faster than any amount of staring at a wiring diagram.

It works, then drops out#

Intermittent faults are physical until proven otherwise, and there is a single test that proves it.

Drop the baud rate. If errors disappear at 9600 that were present at 38400, the problem is the physical layer — reflections, stubs, length, or noise — and no configuration change will fix it. If the errors persist at every speed, look at the devices instead.

CRC errors mean frames are arriving corrupted. The bus is delivering something, so this is noise or reflection rather than a dead link. Usual causes, in order: a star topology or a long spur; a shield earthed at both ends, which turns it into a current loop rather than a screen; the pair run alongside VFD or contactor cabling; or a length beyond what the baud rate supports. The cable length calculator gives the limit for your baud rate and derates it for the environment.

Timeouts that appear under load are often not the bus at all. If a VFD starting correlates with the errors, it is conducted or radiated noise. If the errors correlate with nothing visible, check the poll cycle: twenty devices at five requests each with a one-second timeout is a cycle far longer than the interval it was configured for, and requests start colliding with the previous round.

One dead device slows everything. With a one-second timeout and two retries, a single unresponsive meter adds three seconds to every pass. Back failing devices off to progressively longer intervals rather than hammering them each cycle.

It answers, but the numbers are wrong#

That is not a communication fault and none of the above applies. The bus is working — you are decoding what it sends incorrectly. Register offset, byte and word order, data type and scaling are a separate problem with a separate method: Modbus RTU on energy meters covers it, and the float decoder and address converter settle the two commonest cases in seconds.

Exception codes are good news#

If you get an exception rather than silence, the device heard you and disagreed. That is enormous progress.

Code 02 is the offset problem in disguise, and it is the most common of the set.

Quick reference#

The last row is worth designing for rather than diagnosing. A single dead meter with a one-second timeout and two retries adds three seconds to every pass, so one broken device makes twenty healthy ones look broken too.

The order that saves time#

1. Resistance across A and B, powered down.
2. Idle voltage across A and B, powered up.
3. Serial settings, parity included.
4. A/B polarity at the master.
5. Halve the bus if some devices work.
6. Drop the baud rate if it is intermittent.
7. Only then open the register map.

Steps 1 and 2 take two minutes and account for most silent buses. The design rules that prevent all of this — daisy chain, terminate both ends only, earth the shield once — are in RS485 wiring for Modbus.