Understanding the Modbus Protocol in One Article: The Classic Universal Language for Industrial Communication
In the field of industrial automation, for devices such as PLCs, sensors, frequency converters, and instruments from different brands to achieve data interoperability and collaborative operation, a unified "communication protocol" is essential—among which the Modbus protocol stands as the most widely adopted and classic solution. From traditional factory workshops to modern industrial IoT systems, Modbus has emerged as the "universal language" for industrial equipment due to its simplicity, openness, and stability.
Ⅰ、What is the Modbus protocol? Its origin and core purpose
The Modbus protocol was developed in 1979 by the American company Modicon (now acquired by Schneider Electric) for communication between its PLC products. It is an industrial application-layer communication protocol designed with a straightforward objective—to address interoperability issues between industrial devices from different manufacturers, enabling devices to perform data acquisition and command transmission without requiring customized drivers. From a network layer perspective, Modbus belongs to the application layer of the OSI seven-layer model. It does not specify the underlying physical transmission medium but defines the format of data exchange frames, functional commands, and response rules. Consequently, it can flexibly accommodate various physical layers such as RS-232, RS-485, and Ethernet, meeting the communication requirements of diverse industrial scenarios.
Ⅱ、Modbus Core Architecture: Master-Slave Communication Mode
Modbus employs a master-slave architecture, which constitutes its core communication logic, the key to its simplicity and ease of use, and the foundation for understanding frame formats—all frame designs are built around this master-slave interaction mechanism.
￭Master Station: The "command center" of the entire communication network, which can be a PLC, industrial PC, SCADA system, IoT gateway, etc., actively initiating data requests and issuing control commands. A network must have at least one master station (Modbus TCP supports multiple master stations), and all frames are initiated by the master station.
￭From Slave: The "executor" in the network, such as sensors, frequency converters, instruments, or actuators, passively receives commands from the master station, executes operations, and returns response frames. Multiple slaves can be connected in a network, each with a unique address (1–247) for precise identification by the master station; non-target slaves will directly ignore received frames.
The communication process is remarkably straightforward: the master station sends a request frame → the corresponding slave station receives and deciphers the frame content → the slave station executes the instruction and returns a response frame. This approach completely eliminates bus conflicts in multi-device communication, ensuring maximum stability.
2.1 Master Station (Master) Quantity Rules
Modbus RTU / ASCII（RS485 bus）
￭Only one master station can be on a bus.
￭Multiple master stations are not permitted to send commands simultaneously, as this may cause bus conflicts and data corruption.
￭The master station performs polling on all slave stations, while slave stations never initiate data transmission.
Modbus TCP (Ethernet)
￭Theoretically supports multiple master stations (multiple clients connecting to port 502 simultaneously).
￭In practical implementations, to avoid register contention and logical confusion, the system is typically designed with a single master station for control.
￭Multi-master scenarios are generally managed uniformly via gateways, SCADA systems, or dedicated servers.
2.2 Slave Quantity Rules
The number of slaves is determined by their slave addresses (Slave IDs):
￭Address range: 1–247
￭Address 0: Broadcast address received by all slaves but without response
￭Addresses 248–255: Reserved addresses, generally not used for device identification Therefore:
￭A single Modbus RTU/ASCII bus supports up to 247 slaves
￭In practical applications, the maximum slave count is typically limited to 32 due to constraints such as 485 communication capabilities, polling frequency, and cable length
￭The slave address cannot be duplicated, as duplication can lead to communication abnormalities and response confusion
2.3 Typical Quantity Configurations in Practical Engineering
￭Small-scale acquisition scenarios: 1 master station + 4–16 slave stations (instrumentation devices/sensors)
￭Medium-scale field applications: 1 master station + 16–32 slave stations (inverter systems, PLCs, electricity meters)
￭Large-scale multi-device networks: Utilizes multiple 485 or serial-port servers with expanded bus configurations, each comprising 1 master and multiple slaves
￭Modbus TCP scenarios: 1 server + dozens to hundreds of slave devices
2.4 Fundamental Limitations of Quantity Constraints
￭Serial bus (RS485) is a half-duplex shared bus, allowing only one device to transmit data at any given time
￭The master station's polling mechanism results in slower refresh rates as the number of slaves increases
￭The fixed 1-byte address field limits the maximum number of slave devices to 247
Ⅲ、Analysis of Frame Format Differences Among the Three Main Variants of Modbus
Based on the underlying transmission medium and encoding method, Modbus primarily consists of three variants: RTU, ASCII, and TCP. These variants are fully compatible in their application-layer functional commands, with core differences lying in frame format, encoding method, and parity checking logic—allowing for flexible selection in engineering applications. Below, we provide a detailed breakdown of each variant's frame format, illustrated with practical examples for intuitive understanding.
3.1 Modbus RTU (Most Commonly Used, Key to Master)
Modbus RTU is the most widely adopted serial communication protocol in industrial settings. Utilizing binary encoding, it offers compact data transmission, high efficiency, and strong interference resistance, making it ideal for low-cost, short-distance networking of field devices in workshops.
￭Transmission medium: RS-485 (主流), RS-232;
￭Verification method: 16-bit CRC verification (ensures data transmission integrity);
￭Core features of frame format: No start/end characters; frame boundaries are determined by inter-frame idle time (typically ≥3.5 character cycles).
Modbus RTU frame format (request frame + response frame):
|
field |
Byte count |
Field Description |
Example (request frame) |
|
Slave Address |
1 byte |
A unique identifier for slaves, ranging from 1 to 247; 0 is a broadcast address (received by all slaves but not responded to). |
0x01 (Slave Station 1) |
|
Function Code |
1 byte |
Define the master station operation types, such as reading registers and writing coils (explained in detail later). |
0x03 (Read Hold Register) |
|
Data Field |
N bytes (variable) |
Request frame: register address, number of reads/writes; Response frame: returned data, status information |
0x00 0x00 (starting register address 0),0x00 0x02 (read two registers) |
|
CRC |
2 byte |
16-bit cyclic redundancy check covering all bytes from the slave address to the data field, with the lower bits first and the higher bits last. |
0x95 0xCB (corresponding to the CRC check value of the above field) |
Complete example breakdown: Request frame 【0x01 0x03 0x00 0x00 0x00 0x02 0x95 0xCB】
Analysis: The master station sends a "Read Hold Register" instruction to the slave station with address 1, reading two registers starting from address 0, yielding a CRC checksum of 0x95CB. If the slave station responds normally, it returns a response frame containing its address, function code, data length, register data, and CRC checksum.
3.2 Modbus ASCII Modbus ASCII employs ASCII character encoding, with messages starting with a colon (:) and ending with a carriage return (CRLF, 0x0D 0x0A). It offers excellent readability and can be directly viewed via a serial port viewer, facilitating debugging. However, due to its high data redundancy and low transmission efficiency, it is rarely used in practical industrial deployments.
Verification method: LRC verification (vertical parity check);
Frame format:
|
field |
Byte count |
Field Description |
Example (corresponding to the RTU example) |
|
Start |
1 byte |
Fix to colon（:，0x3A） |
: |
|
Station Address
|
2byte（ASCII code） |
1 byte hexadecimal number, converted to 2 ASCII characters |
01 (corresponding to 0x01) |
|
function code |
2byte（ASCII code） |
1 byte hexadecimal number, converted to 2 ASCII characters |
03 (corresponding to 0x03) |
|
data field |
2N byte（ASCII code） |
Convert each byte of data into 2 ASCII characters |
00000002 (corresponding to 0x00 0x00 0x00 0x02) |
|
LRC |
2byte（ASCII code） |
8-bit LRC verification, covering ASCII characters from station address to data field, converted to 2 ASCII characters |
38 (corresponding to LRC checksum 0x38) |
|
End |
2byte |
Fixed as carriage return (0x0D)+line break (0x0A) |
CR+LF |
It is evident that ASCII frames contain greater redundancy than RTU frames (for the same data, ASCII frames require nearly twice as many bytes as RTU frames), making them suitable only for debugging, troubleshooting, and low-speed communication scenarios.
3.3 Modbus TCP (The Mainstream in Industrial Internet)
Modbus TCP, built on the Ethernet TCP/IP protocol, is the preferred choice in the industrial internet era. It offers fast transmission speeds, unlimited range, compatibility with both LANs and the Internet, uses port 502 by default, and supports multi-master communication.
Key features: No CRC/LRC verification is required (as it relies on the TCP layer's reliable transmission mechanism). The traditional RTU frame is enhanced with a "MBAP header" (Modbus Application Protocol Header) to identify Modbus frames in TCP communications.
Modbus TCP frame format (MBAP header + RTU core frame):
|
field |
Byte count |
Field Description |
example |
|
Transaction ID |
2 bytes |
Used to identify a communication transaction, it increments when initiated by the master station and remains consistent when responded by the slave station |
0x00 0x01 |
|
Protocol ID |
2 bytes |
Set to 0x00 0x00, indicating the Modbus TCP protocol |
0x00 0x00 |
|
Length |
2 bytes |
Represents the number of subsequent bytes (slave address+function code+data field), i.e. "1+1+N" |
0x00 0x06 (Subsequent 6 bytes: 1+1+4) |
|
Slave Address |
1 bytes |
Consistent with RTU, range 1-247 |
0x01 |
|
Function Code |
1bytes |
Consistent with RTU, define operation types |
0x03 |
|
Data Field |
N bytes (variable) |
Consistent with RTU, the request frame/response frame data format is the same |
0x00 0x00 0x00 0x02 |
Complete example breakdown: TCP frame【0x00 0x01 0x00 0x00 0x00 0x06 0x01 0x03 0x00 0x00 0x00 0x02】
Analysis: The transaction ID is 0x0001, the protocol ID is 0x0000, and the subsequent data length is 6 bytes. Send the "Read Hold Register" instruction to the slave at address 1 to read the two registers starting from address 0. When the slave responds, the transaction ID and protocol ID in the MBAP header match the request, and the length field is adjusted according to the returned data.
Ⅳ、Modbus Core Message: Detailed Explanation of Function Codes and Data Fields
In all variants, the core of a Modbus frame consists of a "function code + data field": the function code specifies the operation type, while the data field provides operational details. Together, they enable precise communication between master and slave devices. This section focuses on high-frequency, practical function codes, complemented by data field formats to help you quickly get started with development and debugging.
4.1 Common Function Codes (Essential for Development)
The function code is 1 byte, ranging from 0x01 to 0xFF. The values 0x01–0x10 represent common standard function codes, while codes above 0x80 indicate abnormal response codes (the most significant bit is 1, indicating a failed instruction execution by the slave device).
|
function code |
function declaration |
Applicable data types |
Data field format (request frame) |
|
0x01（Read coil） |
Read the status of the slave coil (digital output) |
Switch value (0 = open, 1 = closed) |
Start coil address (2 bytes) + Number of reads (2 bytes) |
|
0x02（Read input status） |
Read the slave input status (digital input) |
Switch value (read-only) |
Initial input address (2 bytes) + Number of reads (2 bytes) |
|
0x03（Read hold register） |
Read the slave hold register data (most commonly used) |
Analog quantity, equipment parameters (readable and writeable) |
Start register address (2 bytes) + Read count (2 bytes) |
|
0x04（Read input register） |
Read the data from the slave input register |
Analog value (read-only, such as sensor readings) |
Start register address (2 bytes) + Read count (2 bytes) |
|
0x05（Write a single coil） |
Control the on/off state of a single coil |
Switching output |
Coil address (2 bytes) + Control value (2 bytes: 0x0000 = open, 0xFF00 = closed) |
|
0x06（Write to a single hold register） |
Set the value of a single hold register |
Device parameters (e.g., inverter frequency, sensor threshold) |
Register address (2 bytes) + Set value (2 bytes) |
|
0x10（Write multiple hold registers） |
Batch-set multiple values for retention registers |
Batch configuration of multiple device parameters |
Start address (2 bytes) + Quantity (2 bytes) + Data length (1 byte) + Batch data (2 × quantity bytes) |
4.2 Abnormal Response Frame Format
When a slave station cannot execute the master station's instructions (e.g., due to incorrect address, unsupported function code, or data exceeding the range), it returns an exception response frame characterized by "function code position 1 being the highest" and carries an exception code in the data field.
The abnormal response frame structure (using RTU as an example): Station address (1 byte) + Abnormal function code (1 byte, original function code + 0x80) + Abnormal code (1 byte) + CRC check (2 bytes).
Common error codes: 0x01 (function not supported), 0x02 (register address does not exist), 0x03 (data length error), 0x04 (slave device failure).
Ⅴ、The Advantages and Application Scenarios of the Modbus Protocol
Why do industrial applications favor Modbus? The key lies in its "simple, versatile, and low-cost" characteristics, coupled with its concise frame format and exceptionally low development and debugging complexity.
core advantage:
￭Simple and Easy to Implement: The frame structure is concise, requiring minimal code for embedded development adaptation without complex protocol stack development;
￭Open Source and Free: No patent fees allow small and medium-sized manufacturers and projects to use it cost-free, reducing device integration costs;
￭Excellent Compatibility: Over 90% of industrial devices on the market natively support Modbus, enabling seamless integration across brands;
￭Broad Adaptability: The serial version (RTU/ASCII) is suitable for fieldbus, while the TCP version is designed for Ethernet connectivity, covering all scenarios from the device layer to the management layer;
￭Stable and Reliable: The master-slave mode prevents communication conflicts, and the parity check mechanisms (CRC/LRC) ensure data accuracy, making it suitable for complex industrial electromagnetic environments.
Common Application Scenarios:
￭Industrial automation production line: The PLC collects temperature, humidity, and pressure sensor data via Modbus RTU, controlling frequency converters and relays.
￭Intelligent building automation: The building system monitors air conditioners, water pumps, and electricity meters through Modbus, enabling energy consumption monitoring and equipment control.
￭New energy sector: Photovoltaic inverters and charging stations transmit operational data via Modbus TCP for remote monitoring.
￭IoT data acquisition: The industrial gateway collects field device data via Modbus, converts it, and uploads it to the cloud platform.
Ⅵ、The Limitations and Development Trends of the Modbus Protocol
While Modbus offers significant advantages, it also has certain limitations, primarily concerning security and real-time performance:
￭Insecurity shortcomings: Traditional Modbus lacks encryption mechanisms, transmitting data in plaintext that is vulnerable to tampering and theft, making it unsuitable for high-security scenarios;
￭Average real-time performance: The serial version (RTU/ASCII) employs a master station polling method, resulting in increased response latency in multi-slave configurations.
To meet the demands of modern industry, Modbus continues to be upgraded:
￭Modbus Security Protocol: Incorporates encryption and authentication mechanisms to enhance communication security and mitigate risks associated with plaintext transmission;
￭Integrated Solution: Modbus + MQTT/OPC UA enables seamless integration of traditional Modbus devices into the Industrial Internet, facilitating cloud-based management;
￭Hardware Optimization: An increasing number of MCUs now feature built-in Modbus controllers, significantly reducing development complexity and improving communication efficiency.
Despite the proliferation of industrial Ethernet protocols (e.g., Profinet, EtherNet/IP), Modbus remains the preferred protocol for small-to-medium industrial projects and device data acquisition due to its simplicity, versatility, and low cost, earning it the reputation as an "evergreen" solution in industrial communications.
Ⅶ、Summary
For professionals in industrial automation and IoT development, the Modbus protocol is a fundamental skill that must be mastered, with its frame format being the core component. By understanding the frame structures of the three variants—RTU, ASCII, and TCP—and grasping the meanings of function codes and data fields, one can effortlessly handle tasks such as device debugging, message parsing, and development adaptation.