The fields of a request

Four fields

A request is a short run of bytes with no separators: address, function, data, then two bytes of check value. Here is one, in hexadecimal.

01 03 00 00 00 01 84 0A

01 is server 1. 03 is the function, read holding registers. 00 00 00 01 is the data: start at register 0, read 1 register. 84 0A is the check value.

The reply, when register 0 holds 123:

01 03 02 00 7B F8 67

The same address and function, 02 for the byte count, 00 7B for 123, and the reply's own check value.

Function and data

The function says what to do: 03 reads holding registers, 06 and 16 write them, 01 reads coils, 05 writes one coil. The specification writes function codes in decimal, so 16 is 10 in a frame. What the data bytes mean depends on the function. A read puts a start and a count there, and a reply puts a byte count and the values.

The check value

The last two bytes are a 16-bit CRC, worked out by the sender from every byte before them. The receiver repeats the sum and compares. It is the one field that goes out low byte first: 84 0A is the value 0x0A84.

A CRC is a check value, not a proof. It catches almost every damaged frame, not every one.

A bad check value gets no reply

A server that finds a mismatch ignores the frame and sends nothing. The client sees silence, and after its timeout reports a failure that looks like a missing server.

A frame is at most 256 bytes: the address, the check value, and a function and data of at most 253. What marks where a frame ends is silence, in lesson 11.

Common mistakes

• Sending the CRC high byte first. 0A 84 is a different frame and the server ignores it. Low byte first.
• Reading a timeout as an absent server. A damaged frame, or a CRC computed wrongly, gets the same silence. Check the bytes before the wiring.
• Computing the CRC over the wrong bytes. It covers address, function and data, not the two check bytes.