The Modbus protocol is a widely used serial communication protocol in the field of industrial automation, primarily designed to facilitate data exchange between different devices (such as PLCs, sensors, instruments, and frequency converters). Its fundamental working principles can be understood from the following core dimensions:
1. Master-Slave Communication Structure
Modbus employs a “master-slave” communication model, where there is only one master device (such as a PLC or SCADA system) that can actively initiate communication requests; the remaining devices are slaves (such as sensors and actuators) that can only respond passively to requests from the master device and cannot actively send data.
Each slave device has a unique address (1-247, with 0 being the broadcast address), and the master device selects the slave device to communicate with by specifying its address.
2. Request-Response Mechanism
The communication process is completed through a “request-response” mechanism, as follows:
• The master device initiates a request: The master device sends a frame (data packet) to the target slave device containing the “slave address, function code, operation data, and checksum,” clearly requesting the slave device to perform a specific operation (such as reading or writing data).
• The slave device responds: Upon receiving the request, the slave device first checks if the address matches its own. If it matches, it executes the operation specified in the request (such as reading the value of a specified register) and then returns a response frame containing its “own address, function code, result data, and checksum”; if the address does not match, it ignores the request.
3. Data Frame Structure
The Modbus protocol defines a unified data frame format to ensure that devices can correctly interpret the information. Depending on the transmission method, the frame structure varies slightly, with the two most common modes being:
• RTU Mode (binary encoding, suitable for serial communication such as RS485):
The frame structure is: slave address (1 byte) + function code (1 byte) + data (n bytes) + CRC checksum (2 bytes).
Example: The master device requests to read holding registers from the slave device with address 1, the frame might be 01 03 00 00 00 01 84 0A (01 is the address, 03 is the function code, 00 00 is the starting register address, 00 01 is the number of registers to read, and 84 0A is the CRC checksum).
• TCP/IP Mode (based on Ethernet, suitable for network communication):
The frame structure adds an “MBAP header” (7 bytes, containing transaction identifier, protocol identifier, length, etc.) to the RTU structure and removes the CRC checksum (ensured by the TCP protocol for reliability).
4. Function Codes: Defining Operation Types
The function code (1 byte) is the core of the request frame, used to specify the operation that the master device requests the slave device to perform. Common function codes include:
• 01: Read “Coils” (1 bit, such as relay output status, 0=off, 1=on);
• 02: Read “Discrete Inputs” (1 bit, such as sensor input status, read-only);
• 03: Read “Holding Registers” (16 bits, such as set values, cumulative amounts, read/write);
• 06: Write a single “Holding Register”;
• 16: Write multiple “Holding Registers”.
5. Data Objects: Unified Data Access Method
The Modbus protocol abstracts the data from slave devices into four types of “data objects,” which the master device operates on using function codes:
• Coils: 1 bit, address range 1-9999 (read/write, such as control signals);
• Discrete Inputs: 1 bit, address range 10001-19999 (read-only, such as sensor inputs);
• Input Registers: 16 bits, address range 30001-39999 (read-only, such as analog value acquisition);
• Holding Registers: 16 bits, address range 40001-49999 (read/write, such as parameter settings).
Conclusion
The core of the Modbus protocol is to achieve standardized communication between industrial devices through the “master-slave structure + request-response mechanism + unified frame format + function codes.” Its advantages include simplicity of implementation and strong compatibility (devices from different manufacturers can interoperate), making it one of the most commonly used communication protocols in industrial settings.