What Is Modbus?

Detailed Explanation

Modicon published the Modbus protocol specification in 1979 to connect its PLCs to peripheral devices over a shared serial bus. Unlike proprietary industrial protocols of the era, Modbus was openly documented and free to implement — a deliberate choice that made it the dominant industrial communication protocol worldwide. It remains in active use in building management systems, energy meters, motor drives, SCADA systems, solar inverters, and process automation equipment throughout Australia and globally.

Modbus variants

Three variants exist, all sharing the same register model and function code set:

• Modbus RTU — binary encoding over RS-485 or RS-232. The most compact and widely deployed variant. Uses CRC-16 for error detection. Frame boundaries are identified by the inter-frame silence gap (3.5 character times). This is the variant most embedded engineers will implement.
• Modbus ASCII — ASCII hex encoding over RS-485 or RS-232. Frames are human-readable (each byte is two ASCII hex characters) but roughly twice the size of RTU frames. Uses LRC (longitudinal redundancy check) for error detection. Rarely used in new designs; survives in legacy installations where older host software requires it.
• Modbus TCP/IP — Modbus data wrapped in a TCP/IP packet over Ethernet, on port 502. TCP handles error detection; no CRC is required. Widely used in SCADA and industrial Ethernet networks where RS-485 infrastructure is absent or being replaced.

Master/slave model

Modbus uses a strict master/slave architecture (also called client/server in recent Modbus documentation):

• There is exactly one master on a Modbus RTU network. The master initiates all communication.
• Each slave has a unique address (1–247) and responds only to requests addressed to it — or to address 0, which is broadcast.
• Address 0 is broadcast: the master sends to all slaves simultaneously, and no slave responds.
• The master must wait for the addressed slave to respond before sending the next request. Only one transaction is in flight at a time on the bus.

This polling model is predictable and simple to implement, but poll-cycle time grows linearly with the number of slaves and poll frequency. A network with 20 slaves, each requiring 10 ms to respond, completes a full scan in approximately 200 ms — important to factor into latency-sensitive control loops.

Register model

Modbus organises device data into four tables. Each table has a 16-bit address space (up to 65536 entries) and a defined access type:

Holding Registers (4x) are by far the most commonly used data type — many instruments expose all data as holding registers to simplify configuration.

Address offset convention: Modbus documentation uses 1-based register numbers (holding register 40001 = offset 0 in the protocol frame). In firmware, register addresses are always 0-based — the function code data carries the 0-based offset, not the 40001-style display number. Subtract 40001 from a 4x register number, or subtract 1 for other table types, to get the protocol address.

Function codes

A function code (FC) defines the operation the master requests. The most commonly implemented:

When a slave cannot process a request — illegal function code, address out of range, or internal device failure — it returns an exception response: the function code byte has bit 7 set (0x80 OR'd with the original FC), followed by a single exception code byte. Common exception codes: 0x01 (Illegal Function), 0x02 (Illegal Data Address), 0x03 (Illegal Data Value), 0x04 (Server Device Failure).

Modbus RTU frame structure

A Modbus RTU request frame:

The slave's response uses the same layout: device address, function code (or FC | 0x80 for an exception), response data, and a new CRC computed over the complete response frame. Maximum frame size is 256 bytes including address and CRC — requests for more data must be split into multiple transactions.

Inter-frame gap timing

Modbus RTU relies on silence on the RS-485 bus to mark frame boundaries — there is no start-of-frame byte. A new frame may only begin after at least 3.5 character times of silence have elapsed on the bus. At common baud rates (assuming 11 bits per character: 1 start + 8 data + 1 parity + 1 stop, or 1 start + 8 data + 2 stop):

At 19200 baud and above, the Modbus specification permits a practical minimum gap of 1.75 ms. Firmware must use a hardware timer — not software polling — to detect the inter-frame gap reliably. Receiving any character within a frame (the inter-character timeout is 1.5 character times) resets the timer; when the timer fires without a new byte arriving, the frame is considered complete and ready to process.

The UART peripheral handles the actual bit timing; the MCU timer handles the gap detection logic above the UART layer.

Modbus TCP/IP

Modbus TCP prefixes the standard function code and data with a 7-byte MBAP (Modbus Application Protocol) header:

No CRC is included — TCP provides error detection at the transport layer. Port 502 is the IANA-registered Modbus TCP port. Modbus TCP allows multiple simultaneous connections and removes the strict single-master constraint, but implementations that connect multiple SCADA clients to the same device must manage concurrent register access at the application layer.

Design Considerations

• Response timeout: the master must implement a configurable per-slave timeout (typically 300 ms to 1 s for slow PLC devices, 50–100 ms for modern instruments). When a slave fails to respond within the timeout, log the failure and advance to the next poll — do not block the poll loop indefinitely. After a configurable number of consecutive failures, mark the slave offline and reduce polling frequency.
• CRC-16 implementation: the Modbus CRC uses polynomial 0x8005, initialised to 0xFFFF. A precomputed 256-entry lookup table is the standard MCU approach — this avoids bit-by-bit computation in the poll loop. CRC bytes are sent LSB first; appending them MSB-first causes every frame to fail validation at the receiver.
• DE/RE signal timing: Modbus RTU masters must correctly manage the RS-485 driver-enable (DE) signal. Assert DE before transmitting the first byte; de-assert it only after the UART transmission-complete (TC) interrupt fires, not the transmit-buffer-empty (TXNE) interrupt. See RS-485 for the detailed timing and bias resistor requirements.
• Poll table design: build a configurable poll table with device address, register address, register count, and poll interval per device. Cycle through the table sequentially; skip offline devices after a failure threshold rather than retrying every cycle.
• Modbus TCP gateways: many RS-485 Modbus RTU installations are bridged to Ethernet using a serial gateway (protocol converter). The gateway presents a TCP/IP interface to SCADA software while translating to RTU frames for field devices. The Unit ID byte in the MBAP header carries the RS-485 slave address through the gateway, allowing the SCADA client to address individual RS-485 devices via a single TCP connection.

If you're building a Modbus RTU master or slave from scratch, Zeus Design's embedded firmware team can implement the full protocol stack including RTU framing, CRC, inter-frame timing, exception handling, and a configurable register map.

Practical Examples

A solar farm monitoring system polls 32 string inverters over a 400 m RS-485 bus at 19200 baud. The monitoring computer uses function code 0x03 to read 10 holding registers from each inverter every 60 seconds: DC input voltage and current, AC output power, energy total, and fault status. Each poll completes in approximately 20 ms including response; a full 32-device scan takes under 700 ms.

A building management system controller implements Modbus RTU master firmware on an STM32 MCU, polling 20 fan coil unit (FCU) controllers for room temperature, valve position, and setpoint. Each FCU exposes its data as holding registers. The master firmware uses the UART peripheral with hardware RS-485 DE control, a CRC lookup table stored in flash, and a 500 ms response timeout per device — leaving the CAN bus free for time-critical control loops running at 1 ms cycle times.

Common Mistakes

• Missing the inter-frame gap: transmitting the next request before 3.5 character times of silence have elapsed causes the slave to treat the start of the new request as a continuation of the previous frame. The resulting malformed frame generates a CRC error or no response, and the master times out. Enforce the gap with a hardware timer before asserting DE for the next transmission.
• Register address offset confusion: Modbus documentation uses 1-based display numbers (40001 = holding register 0). Using 40001 as the data address in a function code 0x03 request instead of 0x0000 will address register 40000, which does not exist on most devices. Firmware must use the 0-based protocol address; apply the 4x display convention only in user interfaces.
• Not checking for exception responses: a function code with bit 7 set in the response (e.g. 0x83 in reply to a 0x03 Read Holding Registers request) is an exception response, not a data response. Parsing it as data produces corrupted values in the application. Always verify that the response function code matches the request function code before parsing the data payload.
• Broadcast without suppressing response handling: address 0 is broadcast — slaves do not respond to broadcast writes. Code that sends a broadcast frame and then blocks waiting for a reply will time out every time. Only use broadcast for one-way setpoint commands where confirmation is not required.
• CRC byte order: Modbus RTU appends the CRC LSB first. Sending the CRC MSB first causes every frame the receiver validates to report a CRC error, even though the frame data is otherwise correct.