Modbus
Modbus
Overview
Modbus is an open, serial communication protocol originally developed for use in programmable logic controllers (PLCs). It has since become one of the most widely deployed industrial communication protocols in the world, particularly in Building Management Systems (BMS), SCADA environments, energy metering, and industrial automation.
Modbus operates on a master-slave (also referred to as client-server in newer documentation) architecture, where a single master device initiates all communication and one or more slave devices respond. It is valued for its simplicity, robustness, and vendor-neutral design — making it ideal for integrating devices from multiple manufacturers into a unified control system.
In BMS applications, Modbus is commonly used to communicate with energy meters, variable frequency drives (VFDs), chillers, boilers, air handling units (AHUs), and a wide range of sensors and actuators.
History
Modbus was developed in 1979 by Modicon (now a brand of Schneider Electric) for use with their programmable logic controllers. It was designed as a simple and robust protocol for serial communication between controllers on a production floor.
In 1996, Modbus over TCP/IP (Modbus TCP) was introduced, allowing the protocol to be used over modern Ethernet networks. This dramatically expanded its use cases and kept it relevant into the internet era.
In 2004, the rights to the Modbus specification were transferred to the Modbus Organization, a non-profit trade association that maintains and promotes the standard to this day. The protocol remains publicly available and royalty-free, which is a significant reason for its continued adoption over proprietary alternatives.
Today Modbus exists in three primary variants: Modbus RTU and Modbus ASCII (both for serial communication), and Modbus TCP/IP (for Ethernet communication).
Protocol Architecture
Master-Slave Model
Modbus uses a strict master-slave architecture. There is always one master and up to 247 addressable slave devices on a single serial bus. Each slave is assigned a unique address between 1 and 247. Address 0 is reserved for broadcast messages, which all slaves receive but do not respond to.
The master is always the initiator of communication. A slave device never transmits data unless it has first been queried by the master. This eliminates bus collisions and keeps the protocol deterministic — an important quality in control systems where timing and reliability are critical.
In a BMS context, the master is typically the Building Management Controller (BMC) or a gateway device, and the slaves are field devices such as energy meters, controllers, or sensors.
Request-Response Cycle
Every Modbus transaction follows a simple two-step cycle:
- The master sends a request frame to a specific slave address (or broadcast to address 0).
- The slave receives the request, processes it, and returns a response frame to the master.
If the slave receives a valid request but cannot comply (e.g. the register address does not exist), it returns an exception response containing an error code. If the master receives no response within its configured timeout window, it may retry the request or log a communication fault.
A full Modbus RTU frame consists of the following fields in order:
| Field | Size | Description |
|---|---|---|
| Device Address | 1 byte | Slave address (1–247), or 0 for broadcast |
| Function Code | 1 byte | Defines the type of action requested |
| Data | Variable | Register addresses, values, or quantities |
| CRC | 2 bytes | Error checking (Cyclic Redundancy Check) |
Transmission Modes
Modbus RTU
Modbus RTU (Remote Terminal Unit) is the most common implementation of the protocol in BMS and industrial environments. Data is transmitted as binary bytes over an RS-232 or RS-485 serial connection.
Each byte of data is encoded as a single binary character. The framing of messages is defined by silent intervals (gaps) between characters — a gap of at least 3.5 character times signals the start or end of a message frame.
RTU is preferred over ASCII for most applications because it is more efficient: it transmits the same data in roughly half the number of bytes, making better use of available bandwidth.
Key characteristics:
- Binary encoding
- CRC-16 error checking
- Message framing via inter-character silence (3.5 character times)
- Physical layer: RS-485 (most common), RS-232, RS-422
Modbus ASCII
Modbus ASCII transmits data as ASCII text characters rather than raw binary. Each byte of data is represented as two hexadecimal ASCII characters (e.g. the byte 0x5B is sent as the characters 5 and B).
ASCII mode uses a colon (:) as a start delimiter and CR/LF characters as an end delimiter. It uses LRC (Longitudinal Redundancy Check) for error checking rather than CRC.
ASCII mode is less bandwidth-efficient than RTU but is easier to debug with simple terminal tools and is more tolerant of timing variations on noisy or slow serial lines. It is rarely used in modern BMS installations.
Modbus TCP/IP
Modbus TCP/IP wraps the standard Modbus PDU (Protocol Data Unit) inside a TCP packet and transmits it over a standard Ethernet network. It uses port 502 by default.
The serial-specific fields (device address and CRC) are replaced by a MBAP header (Modbus Application Protocol header), which contains a transaction identifier, protocol identifier, message length, and unit identifier.
Modbus TCP removes the need for RS-485 wiring and allows Modbus devices to be integrated into IP-based building networks. Many modern BMS gateways and energy meters support Modbus TCP natively or via an RS-485-to-Ethernet converter.
Communication Parameters
Communication parameters are the settings that define how data is physically transmitted between the master and slave devices on a serial Modbus network. All devices on the same bus must be configured with identical parameters — a mismatch in any one setting will cause communication failures.
The parameters covered here apply primarily to Modbus RTU and Modbus ASCII (serial variants). Modbus TCP uses standard IP networking parameters instead.
Baud Rate
Baud rate defines the number of signal changes (symbols) per second on the communication line. In the context of Modbus serial communication, one symbol corresponds to one binary bit, so baud rate is effectively the number of bits transmitted per second (bps).
Common Baud Rate Values
| Baud Rate | Bits per Second | Typical Use Case |
|---|---|---|
| 1200 | 1,200 bps | Legacy devices, long cable runs with poor quality cable |
| 2400 | 2,400 bps | Older meters and sensors |
| 4800 | 4,800 bps | Moderate speed legacy devices |
| 9600 | 9,600 bps | Most common default — widely supported by all devices |
| 19200 | 19,200 bps | Standard BMS installations with moderate device counts |
| 38400 | 38,400 bps | Higher performance systems |
| 57600 | 57,600 bps | Fast networks, shorter cable runs |
| 115200 | 115,200 bps | Maximum practical speed for RS-485 in most installations |
The default baud rate for Modbus RTU is 9600 bps, though 19200 bps is very common in BMS environments.
How Baud Rate Looks in Binary
Each bit occupies a fixed time window called the bit period, calculated as:
Bit Period = 1 / Baud Rate
At 9600 baud, each bit lasts approximately 104 microseconds. At 115200 baud, each bit lasts approximately 8.7 microseconds.
|
Binary Signal Breakdown — Baud Rate Example Below is what the byte Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Stop
Value: 0 1 0 0 0 0 0 1 0 1
___ ___
____| |________________________| |________ (idle high = 1, start bit pulls low)
What each position means:
Total bits per byte at 8N1 = 10 bits (1 start + 8 data + 1 stop). At 9600 baud, one full byte takes: 10 × 104µs = 1.04 milliseconds. |
Effect on Cable Length
Higher baud rates require better quality cabling and are more sensitive to signal degradation over distance. As a general rule:
- 9600 baud — reliable up to approximately 1200 metres on good RS-485 cable
- 19200 baud — reliable up to approximately 600 metres
- 115200 baud — reliable up to approximately 100 metres
Parity
Parity is a basic error detection mechanism. It adds a single extra bit to each transmitted byte, allowing the receiver to detect single-bit transmission errors.
The parity bit is placed after the 8 data bits and before the stop bit(s). It adjusts the total number of 1s in the data frame to be either always even (Even parity) or always odd (Odd parity).
Parity Modes
| Mode | Abbreviation | Description |
|---|---|---|
| Even Parity | E | The parity bit is set so that the total number of 1 bits in the data byte + parity bit is even |
| Odd Parity | O | The parity bit is set so that the total number of 1 bits in the data byte + parity bit is odd |
| No Parity | N | No parity bit is transmitted. Error checking relies on CRC only. Requires 2 stop bits in Modbus RTU to maintain frame timing. |
| Mark Parity | M | Parity bit is always 1, regardless of data. Rarely used. |
| Space Parity | S | Parity bit is always 0, regardless of data. Rarely used. |
The Modbus specification recommends Even parity as the default. However, 8N1 (8 data bits, No parity, 1 stop bit) is extremely common in practice and is the de facto standard for most BMS devices.
How Parity Looks in Binary
|
Binary Signal Breakdown — Parity Bit Example Example byte: Count of 1 bits: 3 (three 1s in the data byte) Even Parity: Since there are already 3 ones (odd count), the parity bit is set to 1 to make the total even (3 + 1 = 4, which is even). Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Par Stop Value: 0 1 0 0 0 1 1 0 0 1 1 Odd Parity: Since there are already 3 ones (odd count), the parity bit is set to 0 to keep the total odd (3 + 0 = 3, which is odd). Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Par Stop Value: 0 1 0 0 0 1 1 0 0 0 1 No Parity (8N1): No parity bit at all. An extra stop bit is added to maintain frame length. Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Stop Stop Value: 0 1 0 0 0 1 1 0 0 1 1 What each position means:
|
Parity Limitation
Parity can only detect an odd number of bit errors. If two bits flip simultaneously (double-bit error), the parity check will still pass even though the data is wrong. This is why Modbus RTU also uses CRC-16 at the message level — the two mechanisms complement each other.
Data Bits
Data bits refers to the number of bits used to represent each unit of data (one character or byte) within a single serial frame.
In Modbus, this value is virtually always 8 data bits. Using 8 bits allows each frame to carry one full byte of information, which aligns directly with how Modbus RTU encodes its binary protocol data.
The only exception is Modbus ASCII, which can operate with 7 data bits because it uses only printable ASCII characters (all of which fit within 7 bits).
How Data Bits Look in Binary
|
Binary Signal Breakdown — Data Bits Detail Example byte: The 8 data bits are transmitted LSB first (D0 is the least significant bit): Bit position: Start D0 D1 D2 D3 D4 D5 D6 D7 Stop Binary value: 0 0 0 1 0 1 1 0 1 1 Reading the data bits from D0 to D7: 0, 0, 1, 0, 1, 1, 0, 1 Reversing to MSB order (D7 to D0): 1, 0, 1, 1, 0, 1, 0, 0 = What each data bit position represents: { |
Stop Bits
Stop bits mark the end of a character frame. After the data bits (and optional parity bit) have been transmitted, the transmitter sends one or two stop bits by holding the line in the HIGH (idle) state for the duration of those bit periods.
Stop bits give the receiver time to process the incoming byte and prepare for the next start bit. They also provide a guaranteed idle state between characters so that the receiver can reliably detect the falling edge of the next start bit.
Stop Bit Configurations
| Configuration | Stop Bits | When Used |
|---|---|---|
| 8N1 | 1 stop bit | No parity — most common Modbus RTU configuration |
| 8E1 | 1 stop bit | Even parity |
| 8O1 | 1 stop bit | Odd parity |
| 8N2 | 2 stop bits | No parity — provides additional recovery time; used on noisy lines |
The Modbus specification states: if no parity is used, 2 stop bits are recommended to maintain equivalent frame length. In practice however, 8N1 (1 stop bit, no parity) is by far the most common configuration encountered in BMS installations.
How Stop Bits Look in Binary
|
Binary Signal Breakdown — Stop Bit Comparison Example byte: 8E1 — Even Parity, 1 Stop Bit: Number of 1s in data = 4 (even), so parity bit = 0 Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Par Stop
Value: 0 1 0 1 0 1 0 1 0 0 1
←————————————————— 11 bits total ——————————————————→
8N2 — No Parity, 2 Stop Bits: Bit: Start D0 D1 D2 D3 D4 D5 D6 D7 Stop Stop
Value: 0 1 0 1 0 1 0 1 0 1 1
←————————————————— 11 bits total ——————————————————→
Both configurations result in 11 bits per character frame, maintaining the same total frame length and timing compatibility. Key rule: The line must be idle (HIGH) for the entire stop bit period before the next start bit (LOW) can be recognised. If the line goes low before the stop bit period ends, the receiver flags a framing error. |
Flow Control
Flow control is a mechanism that manages the rate of data transmission between devices, preventing a fast sender from overwhelming a slow receiver. In Modbus serial communication, flow control is relevant primarily in RS-232 connections and in RS-485 half-duplex bus switching.
Flow Control Types
| Type | Method | Description |
|---|---|---|
| None | — | No flow control. The most common setting for Modbus RTU on RS-485. |
| Hardware (RTS/CTS) | Physical signal lines | The sender asserts RTS (Request To Send); receiver replies with CTS (Clear To Send). Data flows only when CTS is active. |
| Software (XON/XOFF) | In-band control bytes | Special ASCII characters (0x11 = XON, 0x13 = XOFF) are inserted into the data stream to pause and resume transmission. Not compatible with binary protocols like Modbus RTU. |
| RTS toggle (RS-485) | RTS line used for direction control | In half-duplex RS-485, the RTS line is used to switch the transceiver between transmit mode and receive mode. This is a driver enable signal, not true flow control. |
RS-485 and Half-Duplex Direction Control
RS-485 is inherently a half-duplex medium — devices cannot transmit and receive simultaneously. To prevent bus contention, the RS-485 driver must be enabled only when transmitting and returned to receive mode immediately after.
In many Modbus RTU implementations, the RTS signal from the UART is wired to the DE/RE (Driver Enable / Receiver Enable) pins of the RS-485 transceiver chip. This is often called RTS flow control in software configuration, even though it is technically a bus direction control mechanism rather than data flow control.
|
Binary Signal Breakdown — RS-485 RTS/Direction Control Sequence when a Modbus master sends a request: Time →
RTS: ___________________
| |
_______| |_______ (RTS HIGH = transmit mode enabled)
TX: | [Modbus Frame Data............] |
^ ^
RTS asserted RTS released
(driver enabled) (driver disabled, line released)
RX: _______________________________________
|
| ← Slave response begins here
What each signal does:
Timing of RTS is critical — releasing too early can truncate the last stop bit of the frame. Releasing too late blocks the slave response. Most modern USB-RS485 adapters handle this automatically. |
In most BMS applications using RS-485, flow control is set to None in the software configuration, with the hardware adapter managing direction control automatically. Only when using older RS-232 point-to-point wiring is explicit hardware flow control (RTS/CTS) typically required.
Data Model
Modbus organises data into four distinct object types, each with a defined address space. The master accesses these objects using function codes.
Coils
Coils are single-bit read/write values. They represent binary output states such as a relay, a digital output, or an on/off command. The address range is 1–9999 (using 1-based Modbus convention) or 0x0000–0xFFFF (using the 0-based PDU addressing).
Examples in BMS: Fan on/off command, valve open/close output, alarm reset.
Discrete Inputs
Discrete inputs are single-bit read-only values. They represent binary input states such as a digital sensor, a status contact, or a switch position. Address range: 10001–19999.
Examples in BMS: Door open sensor, high temperature alarm contact, filter dirty status.
Holding Registers
Holding registers are 16-bit read/write registers. They are the most commonly used data type in Modbus and can hold values such as setpoints, configurations, and output values. Address range: 40001–49999.
A single holding register holds values from 0 to 65535 (unsigned) or -32768 to 32767 (signed). For larger values (e.g. floating point temperatures or energy readings), two consecutive registers are used together to form a 32-bit value.
Examples in BMS: Temperature setpoint, VFD speed reference, valve position command.
Input Registers
Input registers are 16-bit read-only registers. They represent measured or computed values provided by the slave device. Address range: 30001–39999.
Examples in BMS: Supply air temperature, room CO₂ concentration, energy meter active power reading.
Function Codes
Function codes tell the slave device what action to perform. They are carried in the second byte of every Modbus frame.
Read Functions
| Function Code | Hex | Name | Reads |
|---|---|---|---|
| 01 | 0x01 | Read Coils | Coils (1-bit, read/write) |
| 02 | 0x02 | Read Discrete Inputs | Discrete Inputs (1-bit, read-only) |
| 03 | 0x03 | Read Holding Registers | Holding Registers (16-bit, read/write) |
| 04 | 0x04 | Read Input Registers | Input Registers (16-bit, read-only) |
Write Functions
| Function Code | Hex | Name | Writes |
|---|---|---|---|
| 05 | 0x05 | Write Single Coil | Single coil ON (0xFF00) or OFF (0x0000) |
| 06 | 0x06 | Write Single Register | Single holding register |
| 15 | 0x0F | Write Multiple Coils | Multiple coils |
| 16 | 0x10 | Write Multiple Registers | Multiple holding registers |
Diagnostic Functions
| Function Code | Hex | Name | Purpose |
|---|---|---|---|
| 07 | 0x07 | Read Exception Status | Returns device error status byte |
| 08 | 0x08 | Diagnostics | Various sub-functions for testing comms |
| 11 | 0x0B | Get Comm Event Counter | Returns count of successful messages |
| 17 | 0x11 | Report Server ID | Returns device type and status |
Error Handling
CRC and LRC Checking
CRC-16 (Cyclic Redundancy Check) is used in Modbus RTU. It is a 16-bit error detection value calculated from all bytes in the message (excluding the CRC bytes themselves). The master calculates the CRC before sending, and the slave recalculates it upon receipt. If the values do not match, the message is discarded silently — no response is sent, and the master will timeout.
The CRC polynomial used is: 0xA001 (reflected form of CRC-16-IBM).
LRC (Longitudinal Redundancy Check) is used in Modbus ASCII. It is calculated as the two's complement of the sum of all byte values in the message. It is simpler but less robust than CRC-16.
Exception Codes
When a slave receives a valid request but cannot fulfil it, it returns an exception response. The function code in the response has its most significant bit set to 1 (i.e. the original function code + 0x80), followed by an exception code byte.
| Exception Code | Hex | Name | Meaning |
|---|---|---|---|
| 01 | 0x01 | Illegal Function | The function code is not supported by this device |
| 02 | 0x02 | Illegal Data Address | The register address does not exist on this device |
| 03 | 0x03 | Illegal Data Value | The value in the data field is not permitted |
| 04 | 0x04 | Slave Device Failure | An unrecoverable error occurred in the slave |
| 05 | 0x05 | Acknowledge | Slave accepted the request but needs more time (long operation) |
| 06 | 0x06 | Slave Device Busy | Slave is busy processing a previous request |
| 08 | 0x08 | Memory Parity Error | Slave detected a parity error reading extended memory |
| 10 | 0x0A | Gateway Path Unavailable | Gateway could not allocate a path (Modbus TCP) |
| 11 | 0x0B | Gateway Target No Response | Target device on gateway failed to respond |
Modbus in BMS Applications
Typical Devices
Modbus is one of the most commonly encountered protocols when integrating third-party field devices into a BMS. The following device types frequently use Modbus RTU as their primary or secondary communication interface:
- Energy meters — active power (kW), reactive power (kVAR), energy (kWh), power factor, voltage and current readings via input registers
- Variable Frequency Drives (VFDs) — speed reference (Hz or %), run/stop command, fault status, output frequency and current feedback
- Chillers and heat pumps — leaving water temperature, setpoint, mode command, alarm status
- Air Handling Units (AHUs) — supply/return air temperature, damper position, fan speed feedback
- CO₂ and air quality sensors — CO₂ concentration (ppm), temperature, humidity
- Heat meters — flow rate, inlet/outlet temperatures, cumulative energy
- UPS systems — battery voltage, charge level, load percentage, alarm status
- Generator controllers — run status, fuel level, output voltage, frequency
Wiring and Topology
Modbus RTU on RS-485 uses a daisy-chain bus topology. Devices are connected in series from the first to the last node. The two conductors of the RS-485 pair are labelled A (−) and B (+), though manufacturers often use inconsistent naming (some label them D− / D+, or even reverse the A/B convention).
Key wiring rules:
- Termination resistors of 120Ω must be fitted at both physical ends of the RS-485 bus to prevent signal reflections. Only the two end devices are terminated — never intermediate devices.
- Bias resistors (typically 560Ω to 1kΩ) are recommended to hold the bus at a defined state when no device is transmitting, preventing false start bit detection.
- Maximum cable length depends on baud rate (see Baud Rate section), but 1200 metres at 9600 baud is a typical practical limit for standard twisted pair cable.
- The maximum number of addressable slave devices is 247, though the RS-485 electrical standard supports up to 32 unit loads on a single segment without repeaters (256 with 1/8 unit load devices).
- Shielded twisted pair (STP) cable is strongly recommended in BMS environments due to electrical noise from motors, VFDs, and other inductive loads.
Common Issues and Troubleshooting
The following are the most frequently encountered Modbus communication problems in BMS installations:
No response from slave / timeout
- Verify slave address matches the configured address on the physical device
- Check baud rate, parity, data bits, and stop bits match on master and slave
- Check A/B wiring polarity — reversed polarity is a very common installation error
- Verify termination resistors are fitted at the correct endpoints only
CRC errors / corrupted data
- Inspect cable routing — avoid running alongside power cables or VFD output cables
- Check for missing or incorrectly placed termination resistors
- Reduce baud rate to test if the issue is speed-related
- Check for ground loops (ensure shield is grounded at one end only)
Intermittent communication
- Often caused by missing bias resistors — the bus floats to an indeterminate state when idle
- Check for multiple termination resistors incorrectly fitted to intermediate devices
- Investigate RTS/driver enable timing issues if using a custom RS-485 adapter
Incorrect register values
- Confirm register addressing convention — some devices use 0-based addressing, others 1-based
- Check byte order (endianness) for 32-bit floating point values — some devices use Big Endian, others Little Endian or mixed (byte-swapped) formats
- Verify scaling factors — a register reading of 1234 may represent 12.34 depending on the device's register map