Modbus RTU frame builder and CRC-16
Build a Modbus RTU request for function codes 1 to 6, 15 and 16, see every byte labelled, and get the CRC-16 in wire order.
Request frame
Loading the calculator.
What goes into a Modbus RTU request
Every request is the slave ID, the function code, the data for that function, and a two-byte CRC. The address, quantity and register values are sent high byte first. The CRC is the one exception: it is sent low byte first.
| Field | Bytes (hex) |
|---|---|
| Slave ID | 01 |
| Function code (read holding registers) | 03 |
| Start address | 00 00 |
| Quantity of registers | 00 0A |
| CRC (low byte first) | C5 CD |
How the CRC-16 is calculated
Modbus RTU uses CRC-16 with the reflected polynomial 0xA001 and a starting value of 0xFFFF. For each byte of the frame, XOR it into the low byte of the CRC, then shift the CRC right eight times. After each shift, if the bit that fell out was 1, XOR the CRC with 0xA001. The two bytes left at the end go on the wire low byte first. Run the same calculation over a received frame, CRC included, and a good frame gives 0.
Mistakes that stop a slave from answering
- CRC bytes swapped. The low byte goes first, unlike every other field.
- Off-by-one addresses. Manuals often list register 40001; on the wire that is holding register address 0.
- The wrong function code for the data type, such as 03 for a value the device keeps as an input register.
- Baud rate, parity or stop bits that don't match the slave. The frame can be perfect and still get no reply.
- Two masters on one RS-485 line, or a missing termination resistor on a long run.
Need this done properly on your machines?
If you are planning a PLC, HMI or Modbus integration job, tell me about the job. I reply within 1 working day.