Modbus RTU CRC errors and timeouts
On a serial line there are three ways a request can fail: no answer, a damaged answer, or an exception. This page shows how to tell them apart and what to check first.
Three different failures
| What you see | What it means |
|---|---|
| Response timeout | Nothing valid arrived in time. The device did not hear the request, did not accept the address, or the answer was lost. |
| CRC error (RTU) or LRC error (ASCII) | Bytes arrived, but the checksum does not match. The frame was damaged or the line settings do not match. |
| Exception response | A clean frame with function code plus 0x80. The device works and refuses the request; fix the request. See Modbus exception codes. |
About the checksum
Modbus RTU ends every frame with a 16-bit CRC (polynomial A001, start value FFFF), sent with the low byte first. Modbus ASCII uses a one-byte LRC instead. A checksum error does not tell you where the damage happened. It only says the frame you received is not the frame that was sent.
Check in this order
- Line settings. Baud rate, data bits, parity and stop bits must match the device exactly. A wrong baud rate or parity usually gives a timeout or checksum errors, rarely both a clean frame and wrong data. Many devices ship with 9600 baud, even parity, 1 stop bit; some use no parity with 2 stop bits.
- Slave ID. A request to an ID that does not exist is silent. Check the ID in the device menu.
- Protocol mode. RTU and ASCII frames look different and are not understood by the other mode.
- Cable and adapter. A and B swapped, no ground reference, a missing terminator or a bad USB adapter cause lost and damaged bytes. See RS-485 troubleshooting.
- Another master. Two masters on one bus corrupt each other's frames.
- Response timeout. Slow devices need more than the default time, especially on large reads or when the device is busy. Increase the timeout, then reduce the quantity per request.
See it in Busscope
Busscope reports the failure in the poll window status line, for example Response timeout or CRC error, and the traffic panel (F4) lists the sent and received frames as hex with a time stamp. If frames go out and nothing comes back, the problem is the request, the address or the wiring. If bytes come back but fail the check, look at the line settings and the cable.
In the RTU connection settings the response timeout (50 ms to 60 s, 1000 ms by default) and the delay between polls are adjustable. Raising them is a quick way to test whether a slow device is the cause.
Related guides
Try Busscope
Install Busscope and run it without a license key to see whether it fits your work. Evaluation mode is for trying the tool, not for production or commercial use.