ModbusLab

Field diagnosis

Modbus RTU troubleshooting

Diagnose one layer at a time. First establish whether a complete serial frame arrived, then decide whether the Modbus response is normal, exceptional or absent. This prevents a register-map issue from being mistaken for a wiring fault.

No response or timeout

  1. Verify that the intended device is powered and connected to the expected serial port.
  2. Confirm the unit identifier, baud rate, parity, data bits and stop bits against the device configuration.
  3. Check that the master and server share the same half-duplex bus and that only one master is transmitting.
  4. Inspect the RS-485 adapter wiring and polarity against the interface manufacturer's labeling; A/B labels are not used consistently across all products.
  5. Verify that the request uses a function code and address range implemented by that device.

A timeout alone cannot identify which item failed. If possible, compare a capture at the master with one at the receiving side.

CRC or garbled characters

Check serial format at both ends before changing protocol data. Then inspect the physical connection, bus topology and adapter configuration. Incorrect polarity, poor connections, electrical noise or timing that splits a frame can cause corrupted bytes. Confirm that the analyzer is aligned to complete RTU frames and that it treats the CRC low byte as first on the line.

RTU uses silence to delimit frames. See RTU timing and frame format for the specification's inter-character and inter-frame rules.

Exception response

An exception response means the server received and processed enough of the request to return a protocol-level error. The function code has its high bit set. Common codes are Illegal Function (01), Illegal Data Address (02), Illegal Data Value (03) and Server Device Failure (04).

  • Illegal Function: verify the function code is supported by the device.
  • Illegal Data Address: verify data area, PDU offset, start address and requested quantity.
  • Illegal Data Value: check quantity, encoded values and any device-specific limits.

Valid response, wrong value

When CRC and function are valid, check whether the client asked for the right data area and offset. Documentation may use one-based references such as 40001, while a PDU carries a zero-based address in a common convention. Then confirm signedness, scaling, engineering units, and byte or word order for multi-register values.

Duplicate or inconsistent replies

Look for a second master, duplicate unit identifiers, local echo from an interface, or requests sent too close together for the target. On a half-duplex RS-485 bus, two masters can collide. A serial adapter may also echo transmitted bytes; whether the application filters echo depends on its settings and driver behavior.

Recommended capture workflow

  1. Capture one request and response with timestamps and raw bytes.
  2. Separate the transport frame from the PDU, then decode the function and address.
  3. Classify the result as a valid response, exception, timeout or invalid frame.
  4. Change one variable at a time and repeat the same known request.

For application-specific steps, see ModbusLab getting started. Its scanner is read-only, but a physical-bus scan still requires other masters to stop transmitting.

Sources