In short: A Modbus transaction is one master request (slave address, function code, data, CRC) answered by exactly one slave response with the same address and function code, or an exception with bit 7 set, and the master must enforce a response timeout and a bounded retry policy because the protocol itself never retransmits.
Why Modbus still matters
Modbus was published by Modicon in 1979 for PLCs, and it is still the lingua franca of energy meters, VFDs, UPS units, chillers and sensors. It is a strict master/slave (client/server) protocol: only the master initiates, and a slave speaks only when addressed. That simplicity makes it easy to implement on a small microcontroller, and it makes the failure modes very predictable, which is why interviewers love asking about it. If you can walk through one transaction byte by byte, you understand the whole protocol.
Anatomy of an RTU frame
On a serial RS-485 line, Modbus RTU frames a message as four fields:
- Slave address (1 byte): 1 to 247 for individual devices; 0 is broadcast (no reply is ever sent); 248 to 255 are reserved.
- Function code (1 byte): what to do, for example 0x03 read holding registers, 0x06 write single register, 0x10 write multiple registers. See Modbus function codes for the full list.
- Data (0 to 252 bytes): start address, quantity, byte count or values, depending on the function.
- CRC-16 (2 bytes): polynomial 0xA001 (reflected 0x8005), initial value 0xFFFF, sent low byte first. Forgetting this byte order is the classic first-day bug.
Key fact: the maximum RTU frame is 256 bytes (1 + 1 + 252 + 2), which is why one read can return at most 125 holding registers (250 data bytes).
One transaction, step by step
Take the request above: 11 03 00 6B 00 02 B7 47. The master asks slave 17 for two registers starting at address 0x006B (protocol address, which a device manual may call register 40108 because of the legacy 4xxxx numbering plus an off-by-one convention; always check the manual's addressing base).
- The master waits for the line to be idle for at least 3.5 character times, then transmits the eight bytes.
- Every slave receives the frame; each checks the address byte. Only slave 17 continues. The others discard it and keep listening.
- Slave 17 verifies the CRC. A mismatch means silent discard: no reply, no error. The master will only learn about it through a timeout.
- The slave validates function, address range and quantity, reads its registers, and replies
11 03 04 02 2B 00 64 CRC. Registers are big-endian: 0x022B = 555 and 0x0064 = 100. - The master checks the address, function code and CRC, then confirms the byte count equals 2 x quantity before trusting the data.
If the slave understands the frame but cannot comply, it echoes the function code with bit 7 set (0x83) and one exception byte: 01 illegal function, 02 illegal data address, 03 illegal data value, 04 slave device failure, 06 slave busy.
Timing: the 3.5-character rule and turnaround
RTU has no start or stop delimiter; frame boundaries are defined by silence. A gap of at least 3.5 character times ends a frame, and a gap above 1.5 character times inside a frame means the frame is corrupt. A character is 11 bits (start, 8 data, parity, stop), so at 9600 baud one character is 1.146 ms and 3.5 characters is about 4.0 ms. Above 19200 baud the standard fixes the values at 750 µs (1.5 char) and 1.75 ms (3.5 char) because OS timers cannot do better.
| Item | At 9600 8E1 | Note |
|---|---|---|
| Request on wire (8 bytes) | 9.2 ms | 88 bits |
| Inter-frame silence | 4.0 ms | 3.5 chars |
| Slave processing | 1 to 50 ms | device dependent |
| Response on wire (9 bytes) | 10.3 ms | 99 bits |
| Typical round trip | about 30 ms | so roughly 30 polls per second maximum |
Key fact: polling 30 devices at 9600 baud, 30 ms each, takes about a second per sweep. Raising baud rate or batching registers into one 0x03 read helps far more than polling faster.
Timeouts and retries
Modbus has no acknowledgements at the link layer, so reliability is entirely the master's job. A sensible policy:
- Response timeout: request time plus slave worst-case processing plus response time plus margin. 200 to 500 ms is common on serial; 1 s for slow or battery devices. Too short causes the master to overlap the next request with a late response and corrupt both.
- Retries: 2 to 3 retries on timeout or CRC failure. Never retry a write blindly if it is not idempotent: 0x06 writing a setpoint is safe to repeat, but a coil toggle or counter increment is not.
- Do not retry exceptions 01, 02, 03. They are deterministic; asking again returns the same answer. Exception 06 (busy) is worth a retry after a delay.
- Back-off and offline marking: after N consecutive failures, mark the slave offline and poll it at a slower rate so one dead meter does not steal 3 x 500 ms from every sweep.
- Broadcast turnaround: after a broadcast write, wait roughly 100 to 200 ms; no slave will answer.
Modbus TCP differences
Over Ethernet (port 502) the CRC and silence rules vanish because TCP provides integrity and framing. A 7-byte MBAP header precedes the PDU: transaction ID (2), protocol ID (2, always 0), length (2) and unit ID (1). The transaction ID lets a client pipeline several requests; the unit ID is the old slave address, still important when a TCP gateway fronts an RS-485 bus. Timeouts still apply, since a TCP connection can stall without a reset.
Debug with Wireshark's Modbus dissector for TCP or a USB-RS485 adapter with a serial capture tool for RTU. For engineers building embedded firmware for such devices, Avecas design services covers the RTL and firmware side, and the RS-485 physical layer article explains the bus electrical rules that cause many CRC errors in the first place (termination, biasing and ground reference).
Key fact: most field "Modbus problems" are physical, not logical: missing 120 ohm termination, no bias resistors, or swapped A/B wires show up as sporadic CRC errors and timeouts.
Interview checklist
- State the four RTU fields and the CRC byte order.
- Explain the 3.5-character silence and why it becomes fixed 1.75 ms above 19200 baud.
- Describe the exception frame (function | 0x80) and which exceptions merit a retry.
- Calculate poll time for N devices at a given baud rate.
Practice these with real timing numbers in the CourseTron courses; for hands-on training, see ChipXpert.
Want to go deeper on industrial and embedded protocols? Enrol in the CourseTron protocols course and build working Modbus master and slave code with guided exercises.
FAQ
Does a slave answer a broadcast request?
No. Address 0 is broadcast and valid only for write functions; every slave acts on it, but none replies, so the master must wait out a turnaround delay before the next request.
What happens if the CRC is wrong?
The receiver silently discards the frame. The master sees a timeout, not an error code, and retries according to its policy.
Why does the CRC appear low byte first?
The Modbus RTU specification transmits the CRC-16 least significant byte first, unlike the big-endian register data; mixing these up produces a permanently failing link.
How many retries are reasonable?
Two or three, with the response timeout sized to the baud rate, and a slower re-poll once a device has failed repeatedly.