Modbus is everywhere. It runs solar inverters, VFDs, PLCs, power meters, and half the sensors in a typical SCADA system. It was published in 1979 by Modicon, and it is still the default way to talk to industrial equipment. In this post I’ll walk through the protocol with real bytes — every frame below was generated by a minimal Python stdlib server and client I wrote for this article.
What Modbus is
Modbus is a master/slave protocol. One master (your PLC, a Raspberry Pi, a Python script) sends requests; slaves (sensors, drives, meters) respond. The original runs over serial RS485; the modern variant, Modbus TCP, wraps the same protocol in a TCP connection on port 502.
The data model is tiny — four tables of 16-bit values:
| Table | Access | Typical use |
|---|---|---|
| Coils | read/write | digital outputs |
| Discrete inputs | read only | digital inputs |
| Holding registers | read/write | configuration, setpoints |
| Input registers | read only | measurements, status |
Each address is 16-bit, so a device can have up to 65,536 entries per table. In practice most devices expose a few hundred.
The numbering confusion
Here’s where everyone trips: the Modbus spec uses 1-based addresses in its documentation (coils at 00001, holding registers at 40001), but the wire protocol uses 0-based offsets. So “holding register 40011” is sent as offset 0x000A (decimal 10). The function code already implies the table — 0x03 always means holding registers — so the address in the request is just the offset into that table.
Modbus TCP: the MBAP header
Modbus TCP adds a 7-byte MBAP (Modbus Application Protocol) header before the PDU:
00 01 00 00 00 06 01| Bytes | Field | Value | Meaning |
|---|---|---|---|
| 0–1 | Transaction ID | 00 01 | Matches request to response |
| 2–3 | Protocol ID | 00 00 | Always 0 for Modbus |
| 4–5 | Length | 00 06 | Bytes following this field |
| 6 | Unit ID | 01 | Slave address (often ignored on TCP) |
Then comes the PDU: function code + data. A read holding registers request (function 0x03) for 2 registers starting at offset 10:
PDU: 03 00 0a 00 02Full frame on the wire:
00 01 00 00 00 06 01 03 00 0a 00 02The server I wrote responds with:
00 01 00 00 00 07 01 03 04 12 34 56 78PDU 03 04 12 34 56 78 breaks down as: function 0x03, byte count 04 (4 bytes = 2 registers), then two big-endian 16-bit values: 0x1234 and 0x5678. As signed 16-bit those are 4660 and 22136.
Exception responses
Ask for a register that doesn’t exist and the server returns an exception. The function code gets 0x80 OR’d in, followed by an exception code:
00 01 00 00 00 03 01 83 02PDU 83 02: function 0x83 (= 0x03 | 0x80), exception code 0x02 = illegal data address. My server sent this when I requested 10 registers starting at offset 95 (only 100 registers exist).
Writing a register
Function 0x06 writes a single holding register. I wrote 0xABCD to offset 20:
Request: 00 02 00 00 00 06 01 06 00 14 ab cd
Response: 00 02 00 00 00 06 01 06 00 14 ab cdThe server echoes the request back — that’s the acknowledgment. Reading it back:
00 01 00 00 00 05 01 03 02 ab cdReturns 0xABCD. As a signed 16-bit value that’s −21555 — the same bits, just interpreted differently.
Modbus RTU over RS485
Modbus RTU is the same protocol without the MBAP header. Instead, frames are:
[slave address] [function code] [data] [CRC16]The CRC16 (polynomial 0xA001, init 0xFFFF) is computed over everything before it and sent little-endian. I verified this with a real pty pair — Python’s pty.openpty() with tty.setraw() on both ends, which is a reasonable simulation of an RS485 half-duplex link for protocol-level work.
My RTU read request for the same 2 holding registers:
01 03 00 0a 00 02 e4 09CRC of the first 6 bytes is 0x09E4, sent as e4 09. The server received it, verified the CRC, and responded:
01 03 04 12 34 56 78 81 07CRC 0x0781 sent as 81 07. The client verified it — match.
A second read, function 0x04 (read input registers):
Request: 01 04 00 00 00 02 71 cb
Response: 01 04 04 00 ff 01 00 ca 24Returns two input registers: 0x00FF and 0x0100.
If the CRC is wrong, the slave stays silent. A corrupted frame:
01 03 00 0a 00 02 00 00The correct CRC is e4 09, not 00 00 — the slave sees the mismatch and does not respond. This is the primary error-detection mechanism on RS485; there is no retransmission built into Modbus itself.
RS485: the physical layer
RS485 is a differential serial bus — two wires (A and B) that reject common-mode noise. It runs at 9600 or 19200 baud in most industrial settings, though 115200 is common for shorter runs. Key properties:
- Half-duplex: one pair of wires carries both directions, so only one device transmits at a time. The master polls in turn; slaves never speak unless asked.
- Multi-drop: up to 32 devices on a single bus (more with repeaters), each with a unique slave address.
- Termination: a 120 Ω resistor at each end of the bus prevents signal reflections. Without it, data gets corrupted at higher baud rates or longer cable runs.
A serial sniffer on an RS485 bus sees exactly the bytes above — address, function, data, CRC — with no framing. That’s why Modbus RTU needs the 3.5-character silence between frames to know where one message ends and the next begins.
Practical advice
Read the register map. Every Modbus device ships (or should ship) a register map — a PDF or spreadsheet listing which offset holds what, at what scaling. Without it you’re guessing. With it, you’re just reading offsets.
Mind the 32-bit values. Many devices store 32-bit integers or floats across two consecutive 16-bit registers. The word order varies by manufacturer: some send high word first (big-endian), some low word first. Check the manual. If you’re getting nonsense values, try swapping the two registers.
Use a real library in production. For Python, pymodbus handles reconnection, endianness, and the edge cases. For a quick read, mbpoll or modpoll give you a CLI. Writing your own stack (as I did above) is educational but misses years of accumulated quirks.
One master per bus. On RS485, two masters will collide and corrupt each other’s frames. On TCP, multiple clients can connect, but the device may serialize requests — check its concurrency spec.
Timeout and retry. Modbus TCP has no built-in retry. If you send a request and get no response within your timeout, retry. Three misses and mark the device offline.
Summary
Modbus endures because it is small enough to implement in a microcontroller’s sleep cycle and simple enough to debug with a serial monitor. The TCP variant put it on Ethernet without changing the protocol. The bytes I showed above — the MBAP header, the function codes, the CRC16 — are the same bytes flowing through factories, power plants, and building automation systems every second. Once you’ve seen them, you can’t unsee them.
For more on debugging TCP connections in embedded contexts, see Debugging TCP on embedded. If you’re interested in how serial protocols work at the byte level, Decoding a serial protocol covers the fundamentals.