May 16, 2026 · Troubleshooting Guide

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

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 Resistors

RS485 signals travel as voltage waves along the cable. When the signal reaches an unterminated end, it reflects back and interferes with the original signal. This causes data corruption and CRC errors, especially at higher baud rates.

• 120-ohm resistor between A and B at each end of the bus. Not at every device — only at the two physical endpoints.
• Required when cable length exceeds roughly 10 meters or baud rate is above 19200.
• Many USB-to-RS485 adapters and Modbus devices have built-in termination that can be enabled via jumper or DIP switch.
• Do not add more than two termination resistors. Over-termination loads the bus and reduces signal amplitude.

Bias Resistors

When no device is transmitting, the RS485 bus is in an undefined state (floating). This can cause the receiver to interpret noise as start bits, generating garbage frames. Bias resistors hold the bus in a known idle state:

• Pull-up resistor (680Ω to 1kΩ) from B to VCC (+5V).
• Pull-down resistor (680Ω to 1kΩ) from A to GND.
• Place biasing at one point on the bus, typically at the master end.
• More critical on buses that use parity = None, since the receiver has fewer error-detection mechanisms.

Shield Grounding

Use shielded twisted-pair cable for Modbus RTU. Ground the shield at one point only (typically the master end) to prevent ground loops. Grounding at both ends creates a path for circulating currents that inject noise into the data lines. In environments with high electromagnetic interference (VFDs, motor controllers), proper shield grounding is the difference between reliable communication and constant CRC errors.

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.

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.

Request Frame Example

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

01 03 00 6B 00 03 76 87

• 01 — Slave Address (1)
• 03 — Function Code (Read Holding Registers)
• 00 6B — Starting Address (107, big-endian)
• 00 03 — Quantity of Registers (3)
• 76 87 — 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 F8 64

• 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)
• F8 64 — CRC-16

Exception Response

When a slave rejects a request, it responds with the function code + 0x80 and an exception code:

01 86 02 C3 A1

• 01 — Slave Address
• 86 — Function Code 0x03 + 0x80 = 0x86 (exception)
• 02 — Exception Code 02 (Illegal Data Address)
• C3 A1 — CRC-16

Modbus Exception Codes

When you receive an exception response, the exception code tells you exactly what the device rejected:

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. 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. The Modbus specification allows up to 1 second. 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.
• Cumulative loading — Each device adds input impedance to the bus. With many devices, the signal amplitude drops below the receiver threshold. Use a repeater for buses approaching 32 devices or long cable runs.
• Daisy-chain topology — RS485 must be wired as a daisy chain (line), not a star. Stubs (short branches off the main trunk) should be kept under 0.3 meters. Star wiring causes reflections at every junction.
• Galvanic isolation — Devices powered from different sources can create ground potential differences that exceed the RS485 common-mode range (±7V). Isolated RS485 transceivers or repeaters solve this. This is a frequent issue in solar plants and building management systems where devices are spread across large physical areas.

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 a similar tool with protocol analysis:

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, CRC validation status, and response timing relative to requests.
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
• Serial Terminal for macOS: Alternatives to screen, minicom, and CoolTerm
• What is Modbus: Protocol Basics, Function Codes, and Register Types