May 16, 2026 · Troubleshooting Guide

Modbus RTU Troubleshooting: CRC Errors, Timeouts, and RS485 Wiring

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated November 1, 2026.

Modbus RTU is the workhorse of industrial communication. It runs on Modbus over RS485 serial lines, connecting PLCs, VFDs, energy meters, temperature sensors, and countless other devices on factory floors, solar plants, and building management systems. When it works, it is invisible. When it breaks, the symptoms are confusing and the documentation scattered across device manuals that contradict each other on pin labels.

This guide walks through how to diagnose and fix every common Modbus RTU communication error, from no-response timeouts and CRC checksum failures to intermittent dropouts and wrong register values. For the fundamentals of the protocol itself, see our introduction to Modbus and our comparison of Modbus RTU vs TCP.

Common Modbus RTU Error Symptoms

Before reaching for an oscilloscope, classify the symptom. Each pattern points to a different root cause:

• No response at all: The master sends a request and receives nothing back. Usually a wiring problem, wrong slave address, or serial parameter mismatch.
• CRC error: A response arrives but the CRC-16 checksum does not match. The frame was corrupted in transit. Electrical noise, bad termination, or ground loops are the usual suspects.
• Exception response: The slave responds with an error code (function code + 0x80). The frame is valid, but the device is rejecting the request. Wrong register address, unsupported function code, or value out of range.
• Wrong data values: Responses are valid but the values make no sense. Typically a byte order problem (big-endian vs little-endian) or wrong register map.
• Intermittent failures: Communication works sometimes but drops randomly. Often a timing issue, marginal wiring, or bus loading problem on multi-drop networks.

Physical Layer: RS485 Wiring Checks

The majority of Modbus RTU problems originate at the physical layer. Fix the wiring first before investigating protocol or timing issues.

A/B Polarity

RS485 uses a differential pair labeled A and B (sometimes D- and D+, or Data- and Data+). The single biggest source of no-response errors is swapped A and B lines. The problem is compounded because manufacturers do not agree on labeling:

• Some label A as Data+ (mark condition, idle high) and B as Data- (space condition, idle low).
• Others reverse this entirely. B&B Electronics, Modbus protocol specs, and many device manuals use opposite conventions.
• The safest approach: if swapping the two wires makes communication work, they were reversed.

On a properly wired idle bus, the voltage difference between A and B should be negative (B higher than A in the EIA-485 standard convention). Measure with a multimeter: if you see a positive idle voltage, swap the lines.

Termination, Bias, Shield, and Topology

These are the usual physical-layer causes of CRC errors and garbage on an otherwise correctly configured bus:

• Termination. A 120-ohm resistor across A and B at the two physical ends of the bus, and nowhere else. A missing terminator on a long run or at a high baud rate shows up as CRC errors; extra terminators overload the driver.
• Bias. Garbage characters on an idle bus mean the line is floating. Add fail-safe bias at one point, usually the master end, using the values in your adapter or transceiver documentation (A/B labels vary, so match the pull direction to the idle polarity you measured above).
• Shield. Shielded twisted pair, with the shield grounded at one point only to avoid ground loops.
• Topology. A daisy chain with stubs well under 0.3 meters. No stars.

The reasoning, resistor values, unit-load limits, and isolation guidance are in the RS-485 Wiring section of the Modbus RTU over serial guide.

Serial Parameter Verification

Every device on a Modbus RTU bus must agree on the serial configuration. A single mismatched parameter means no communication:

• Baud rate: 9600, 19200, 38400, 115200 are common. All devices must match exactly. Start at 9600 if you are unsure of the device configuration.
• Parity: Even, Odd, or None. Modbus specification recommends Even parity, but many devices default to None. This is a common mismatch.
• Stop bits: 1 or 2. The Modbus spec requires 2 stop bits when using no parity, and 1 stop bit with even or odd parity. Not all devices enforce this, but the master should be configured to match.
• Byte order (endianness): Modbus uses big-endian by default (most significant byte first). Some devices send registers in little-endian or swap the word order in 32-bit values. If your data looks wrong but communication succeeds, byte order is the likely culprit; see Modbus floating-point byte order.

The most reliable way to verify serial parameters is to connect a serial terminal and watch the raw bytes. If the baud rate is wrong, you will see garbage characters instead of structured frames. If parity is wrong, you may see occasional valid frames mixed with errors.

Reading Modbus RTU Frames

Understanding the raw hex frame is the core debugging skill for Modbus RTU. A frame consists of four parts: slave address, function code, data, and CRC. For background on the protocol structure, see what is Modbus, or Modbus RTU over serial for CRC and timing in depth.

Request Frame Example

A master requests 3 holding registers from slave 1, starting at register 107:

01 03 00 6B 00 03 74 17

• 01: Slave Address (1)
• 03: Function Code (Read Holding Registers)
• 00 6B: Starting Address (107, big-endian)
• 00 03: Quantity of Registers (3)
• 74 17: CRC-16 (low byte first)

Response Frame Example

The slave responds with 6 data bytes (3 registers x 2 bytes each):

01 03 06 02 2B 00 00 00 64 05 7A

• 01: Slave Address (1)
• 03: Function Code (Read Holding Registers)
• 06: Byte Count (6 bytes follow)
• 02 2B: Register 107 value (555)
• 00 00: Register 108 value (0)
• 00 64: Register 109 value (100)
• 05 7A: CRC-16

Exception Responses

A reply that arrives with a valid CRC but is only 5 bytes long is almost certainly an exception: the request's function code with bit 7 set (FC03 becomes 0x83), then one exception code byte. For example, a read of 3 registers at address 107 from a device that does not implement that address returns:

01 83 02 C0 F1

• 01: Slave Address
• 83: Function Code 0x03 + 0x80 (exception)
• 02: Exception Code 02 (Illegal Data Address)
• C0 F1: CRC-16

An exception is good news for troubleshooting: the wiring, baud rate, and slave address are all working, because the slave understood the frame well enough to refuse it. Triage by code:

• 01 Illegal Function: the device does not support that function code, or not for that table. Try FC04 instead of FC03 or the reverse.
• 02 Illegal Data Address: start address, or start plus quantity, is outside what the device implements. Check 0-based vs 1-based addressing and the register map.
• 03 Illegal Data Value: the quantity or value is not acceptable, for example too many registers in one read. Shorten the read.
• 04 Slave Device Failure, 05 Acknowledge, 06 Slave Device Busy: the device accepted the request but could not finish it. Retry after a delay; a persistent 04 points to a device fault.

The full code table is in the Exception Responses section of the function codes guide.

Timing Issues

Modbus RTU defines strict timing rules. Violating them causes devices to misinterpret frames or drop them entirely:

• Inter-character timeout: The maximum gap between consecutive bytes within a single frame. Must not exceed 1.5 character times. If a byte arrives after this gap, the receiver treats it as the start of a new frame. At 9600 baud with 11-bit characters (start + 8 data + parity + stop), one character time is about 1.15ms, so the inter-character timeout is roughly 1.7ms.
• Inter-frame delay (t3.5): A silent period of at least 3.5 character times must separate consecutive frames. At 9600 baud, this is about 4ms. Above 19200 baud the specification fixes the inter-character timeout at 750µs and the inter-frame delay at 1.75ms instead of scaling them. The master must wait this long after the last byte of a response before sending the next request.
• Turnaround delay: The time a slave takes to process a request and start transmitting a response. Slow devices can take hundreds of milliseconds, and the specification leaves the master's response timeout to the implementation. If your master timeout is set too short, it will give up before a slow device responds. Start with a 500ms timeout and increase if needed.

Timing problems are the most common cause of intermittent failures. A system that works at 9600 baud may break at 115200 because the inter-frame delays become proportionally shorter. If you are upgrading baud rates, verify that your master library inserts the correct t3.5 delay for the new speed.

Multi-Drop Bus Issues

RS485 supports up to 32 unit loads on a single bus (more with modern low-load transceivers). Multi-drop introduces problems that do not appear in a simple point-to-point setup:

• Address conflicts: Two devices with the same slave address will both try to respond simultaneously, corrupting the bus. Symptoms include CRC errors that only happen when certain devices are addressed. Verify each device has a unique address.
• Loading, topology, and isolation: too many nodes, star wiring, long stubs, and devices at different ground potentials all degrade the signal. Use a repeater near 32 devices, wire a daisy chain, and use isolated transceivers where grounds differ. Details are in the RS-485 Wiring section of the Modbus RTU over serial guide.

Using a Serial Monitor to Capture Frames

The most effective debugging technique for Modbus RTU is to capture the actual traffic on the bus. A serial terminal with hex view lets you see exactly what is being transmitted and received, byte by byte.

Using MacTools Serial Terminal or any serial tool with a hex view and timestamps:

1. Connect the USB-to-RS485 adapter to the bus. Wire it in parallel with the existing master so you can observe both request and response traffic.
2. Configure serial parameters to match the bus: baud rate, parity, stop bits.
3. Enable hex view to see raw bytes. ASCII mode is useless for Modbus RTU since most bytes are non-printable.
4. Capture traffic while the master polls. Look for: slave addresses that match your target device, function codes in each frame, and response timing relative to requests. Check the CRC of a suspect frame with a CRC-16 calculator; a serial terminal shows the bytes but does not validate Modbus CRCs for you.
5. Analyze failures by comparing the captured frames against the expected format described above. A missing response means the slave never received the request or could not transmit. A response with invalid CRC means the frame was corrupted. An exception response means the request was received but rejected.

Step-by-Step Troubleshooting Flowchart

Follow this sequence to systematically isolate any Modbus RTU problem:

Symptom, Cause, and Fix Reference

Further Reading

• Modbus RTU vs TCP: Which Protocol for Your Application
• Modbus RTU Over Serial: Frames, CRC, Timing, and RS-485 Wiring
• Modbus Function Codes Explained, Including Exception Responses
• Serial Terminal for macOS: Alternatives to screen, minicom, and CoolTerm
• What is Modbus: Protocol Basics, Function Codes, and Register Types