Modbus troubleshooting: timeouts, exceptions and wrong values

Before you change a setting, capture the raw bytes. A master that shows only "timeout" or "bad value" hides the evidence that separates the causes below. This is a read of two holding registers from device 1 in Modbus RTU, and the two replies it can get:

No reply at all is the fourth outcome. Each outcome has its own section below.

1. No response

A timeout means that no valid reply arrived. The request did not reach the device intact, it went to an address that nothing answers, or the reply was lost or arrived after the master stopped waiting. The application protocol specification (section 7) says that a device that detects a parity, LRC or CRC error in a request sends no reply. A timeout can therefore mean a corrupted request as well as a missing device.

On a serial bus (Modbus RTU), check these items in this order:

1. Set the same baud rate, parity and stop bits on every device. The serial line specification (section 2.5.1) makes even parity the default and requires 2 stop bits when parity is off. Some meters ship set to no parity with 1 stop bit, so set the master to match the meter.
2. Give each device a unique address from 1 to 247. Two devices with the same address answer together and corrupt both replies. Address 0 is broadcast: devices act on a broadcast write but never reply to it.
3. Swap the two signal conductors at one device and test again. Manufacturers do not label A and B consistently.
4. Make sure that only one master polls the bus. A laptop or a BMS that polls at the same time causes collisions.
5. Check the adapter. A 2-wire USB adapter without echo suppression returns the master's own request to it, and some masters read that as a bad reply. An adapter that switches its driver off too slowly after a request clips the first bytes of the reply.
6. Check termination and bias. CRC errors that increase with baud rate and cable length point to missing termination. Framing errors or a spurious first byte after the bus has been idle point to missing bias. The RS-485 wiring guide covers both.
7. Set a timeout that covers the reply time on the wire plus the device's processing time. The calculation follows this list.

On Modbus TCP, check the IP address, the port (502 unless the device uses another), firewall rules between the client and the device, and the unit identifier. The TCP implementation guide (section 4.4.1.2) recommends unit identifier 0xFF for a device connected directly to the network and also accepts 0. Behind a TCP-to-RTU gateway, the unit identifier selects the serial device, from 1 to 247. Some direct TCP devices answer only to one specific value, so read the manual.

The TCP guide does not set a connection limit, so each device has its own. Some meters accept only one connection at a time. If a client disappears without closing its connection, for example after a power cut, the connection stays half-open and holds its slot (section 4.2.2). With the default TCP keepalive timers that the guide quotes (section 4.3.2), the first probe goes out after 2 hours of idle time, and the stack gives up after 8 more probes at 75 s intervals. The slot can therefore stay blocked for more than 2 hours. During that time the device refuses new connections or does not answer them. The guide recommends that a server closes its oldest connection when a new client arrives and the pool is full (section 4.2.1.1), but not every device does this. Power-cycle the device, or read its manual for a shorter idle timeout.

Test with the smallest request that should work: one register that the map says exists, with the function (03 or 04) that the map gives. Use the Modbus CRC and LRC calculator to check an RTU frame that you captured.

Timeout arithmetic

In RTU mode, each byte is 11 bits on the wire: a start bit, 8 data bits, a parity bit (or a second stop bit) and a stop bit. At 9600 baud, one byte takes 1.15 ms. The largest read is 125 registers (function 03 or 04), and its reply is 255 bytes: address, function, byte count, 250 data bytes and the 2-byte CRC. That reply takes 292 ms on the wire. The request takes a further 9 ms, and the device needs time to prepare the reply. A 200 ms timeout therefore fails on every full-block read, although the device answers correctly.

The serial line specification (section 2.4.1) gives a typical response timeout of 1 s to several seconds at 9600 baud. Start at 1 s, measure the real reply time, and then reduce the timeout if the polling budget needs it.

Frame timing also matters. An RTU frame ends after a silence of 3.5 character times, which is 4.0 ms at 9600 baud. A gap of more than 1.5 character times inside a frame makes the receiver discard it as incomplete. Above 19,200 baud, the specification recommends fixed values of 1.75 ms for the frame gap and 750 µs for the gap inside a frame (section 2.5.1.1). A master or converter that pauses inside a frame causes a timeout with no other symptom. The Modbus RTU timing calculator calculates these values for other baud rates and block sizes.

2. An exception response

An exception response proves that the device received the request intact and rejected it. The reply carries the function code plus 0x80, then an exception code. A reply of 83 02 means "function 03, exception 02":

The specification gives a worked example of exception 02. A device with 100 registers (addresses 0 to 99) accepts a read of 4 registers from address 96. It rejects a read of 5 registers from address 96, because register 100 does not exist. Check the address convention first (register 40001 is protocol address 0), then the length of the block. Many meters also reject a block that crosses a gap in their map. Split the block at the gap.

Do not send the same request again in a loop. The device gives the same answer every time. The exception is 06: the device is busy, and the same request can succeed later.

A write can succeed at the protocol level without changing the device. A normal reply to function 06 is an echo of the request, and a normal reply to function 16 (0x10) contains the start address and the quantity. Neither reply confirms that the device applied the value. Read the register back after the write.

3. A value that looks right but is wrong

A valid response proves only that the link works. It does not prove that you decoded the value correctly. When a value is plausible but does not match the device display, compare the raw register words with the register map:

The frame at the top of this guide shows why a swapped word order is easy to miss. The words 435C 8000 decode as 220.5 in ABCD order. In CDAB order (words swapped), they decode as -2.4 × 10⁻⁴¹, which most displays show as 0. A voltage of 0 looks like a meter with no supply. On an integer the error is obvious: a value of 10 with swapped words reads as 655,360.

The Modbus register decoder shows a pair of registers in all four byte orders (ABCD, CDAB, BADC and DCBA). The register map guide explains each field of a map.

Prove a fix at a second operating state as well, for example with a load switched on and off, or with a value that goes negative. A reading of exactly 0 decodes the same in every byte order, so it proves nothing about the order.

4. Values that freeze or jump

If the link and the decoding are correct but values freeze, jump or go missing, the cause is in the polling.

A gateway can return the last value that it read after the device behind it stops answering. Check the gateway for a stale-value timeout. Also check the device's own update rate in its manual. If a register refreshes once per second, a faster poll returns the same value several times.

A 32-bit counter that is read with two separate requests can combine the high word from one moment with the low word from the next. The total then jumps by 65,536 and comes back. Read both registers in one request.

On Modbus TCP, the MBAP transaction identifier pairs each reply with its request. The TCP guide (section 4.4.1.3) says that a client must discard a reply whose transaction identifier matches no pending request. A client that ignores the identifier can accept a late reply as the answer to its next request. The value of one point then appears in another point from time to time.

Regular gaps occur when the polling cycle is longer than the reporting interval. An offline device makes this worse, because each poll of that device waits for the full timeout and every retry. For example, 10 meters on one bus at 9600 baud, each read with one 60-register request, take about 210 ms each. This includes 143 ms for the reply, 9 ms for the request, the frame gaps and an assumed 50 ms of device processing. The cycle is about 2.1 s. If one meter goes offline with a 1 s timeout and 2 retries, it adds 3 s. The cycle becomes 5.1 s, and a 5 s reporting interval then has gaps for all 10 meters. The polling and retries guide explains how to set this budget.

Duplicated or late records usually come from the data path after the gateway. Compare the gateway's local record with the receiving system. A retry can also duplicate a read on the Modbus side if the original reply arrives after the timeout.

Close the fault with evidence

When the fault is fixed, record:

• the symptom, with the raw request and response;
• the cause that you found, and the one change that you made;
• the test that passed afterwards, at two operating states;
• a test with one device switched off, to show that the other devices continue to report.

Keep it in the acceptance record from the Modbus RS-485 commissioning guide.

Diagnostics in Edge

Edge tests a Modbus connection in stages. For Modbus TCP, the connection test pings the host, resolves its name and opens a TCP connection to the port, and it shows the result and latency of each step. The ping result is advisory, because many devices and firewalls block ICMP. The test passes when the TCP connection opens. For a serial connection, it checks that the serial port exists and is a serial device. It does not prove that a device on the bus answers. The sensor test does that: it sends one real read with the unit identifier, function code (01 to 04) and address that you enter, and it waits 5 s for the reply. It then applies the word-swap and byte-swap options and shows the decoded value, so you can compare byte orders against the device display. After you add the device, each sensor shows a data-quality figure: the percentage of expected readings that arrived in the last 15 minutes. Use the three in that order. The first one that fails shows where the fault is.

This guide is part of the Modbus and RS-485 series.