Complete analysis of Modbus communication protocol messages

1.Core Overview of Modbus Protocol

Modbus is a typical master-slave architecture communication protocol. The master initiates instructions and the slave responds to data to realize read and write interaction between devices. The protocol is mainly divided into three commonly used modes: Modbus RTU, Modbus ASCII, and Modbus TCP. Among them, the RTU mode has high transmission efficiency and occupies fewer bytes, serving as the mainstream mode for industrial equipment, intelligent instruments, and serial communication. The ASCII mode features better readability and is mostly used for debugging and learning. The TCP mode relies on Ethernet and adapts to remote network collection scenarios.

The core carrier of all Modbus communication is "message". All data reading, parameter writing, and status query between devices are essentially the sending, transmission and analysis of messages. Standard Modbus messages uniformly follow a four-segment structure: slave address, function code, data field, and check code.

2.Disassembly of Standard Modbus Message Frame Structure

A complete Modbus-RTU message consists of 4 core fields with fixed byte lengths and clear division of labor. The standard message frame structure is sorted below for quick query and practical application:

The complete Modbus message has a fixed logical structure with clearly divided fields, which is the core basis for message analysis.

2.1 Slave Address (1 Byte)

It is used to distinguish different devices on the bus, with an address range of 0-255, and 1-247 are commonly used valid addresses in field devices. The master accurately specifies communication devices through addresses to avoid multi-device communication conflicts, which is the basis for multi-device network communication.

2.2Function Code (1 Byte)

It determines the type of communication operation and is a key identifier for message analysis. Commonly used core function codes in industrial scenarios include: 01 for reading coil status, 02 for reading discrete inputs, 03 for reading holding registers, 04 for reading input registers, 06 for writing a single register, and 10 for batch writing registers. Different function codes correspond to different data formats and analysis rules.

2.3 Data Field (Variable Length)

The length of the data field is determined by the function code, including the starting register address, read/write quantity, and specific data content. The request message informs the slave of the operation position and range, while the response message returns real-time device data or execution results.

2.4 Check Code (2 Bytes)

It is used to verify data transmission integrity. The RTU mode adopts CRC16 check, and the ASCII mode adopts LRC check. It can accurately identify packet loss, interference, data garbling and other problems during transmission, ensuring the stability of industrial communication.

3.Analysis of Differences in Mainstream Communication Mode Messages

The three mainstream Modbus communication modes adapt to different industrial control scenarios, with great differences in message structure, encoding mode and check rules. The core differences are sorted in the table below for easy selection and distinction:

3.1 Modbus RTU (Industrial Mainstream)

RTU adopts binary encoding with compact frame structure and high transmission efficiency without redundant characters. It is the default communication mode for RS485/232 serial devices. It judges the start and end of messages through frame interval time and ensures data accuracy via CRC16 check, adapting to most intelligent instruments and industrial control equipment.

3.2  Modbus ASCII (Debugging Preference)

It adopts ASCII character encoding, with messages starting with colon ":" and ending with carriage return and line feed, featuring high character visibility and low difficulty in manual analysis. However, it has large transmission redundancy and low efficiency, only suitable for learning, debugging and fault analysis scenarios, and rarely used in mass-produced equipment.

3.3 Modbus TCP (Network Communication)

Based on Ethernet transmission, it adds an MBAP message header on the basis of the original RTU message, including transaction identifier, protocol identifier, message length and other information, without CRC check. It adapts to remote and cross-network segment industrial IoT data collection scenarios.

4.Analysis Examples of Common Function Code Messages

The frequently used function codes for Modbus industrial debugging are fixed. The common function codes and their descriptions are sorted below for practical operation, memory and application:

Taking the most commonly used Function Code 03 (Read Holding Registers) as an example, the complete message analysis logic is restored to fit on-site practical scenarios.

Master request message composition: Slave Address + 03 Function Code + Starting Register Address + Number of Reading Registers + CRC Check.

Normal slave response message composition: Slave Address + 03 Function Code + Data Length + Register Data + CRC Check.

In case of equipment exceptions, the slave will return an abnormal response message, with the function code automatically increased by 0x80 and accompanied by an exception code for rapid fault location. The common exception code interpretations for quick fault troubleshooting are sorted as follows:

5.Common Message Faults and Troubleshooting Methods

In actual engineering debugging, most Modbus communication abnormalities can be quickly located through message analysis. The core common problems are as follows:

5.1 Communication Timeout:

Mostly caused by incorrect slave address, wiring faults, mismatched baud rate/parity bits, resulting in no equipment response;

5.2 Data Garbling:

Caused by CRC check failure, transmission interference or message truncation; check line shielding and communication parameter consistency;

5.3  Exception Code Return:

Troubleshoot register address range, equipment function support and data write permissions according to the corresponding exception code;

5.4 Batch Data Packet Loss:

 Mostly caused by excessive register reading quantity and overlong message length; data needs to be read in segments.

6.Summary: Engineering Value of Message Analysis

The essential nature of the Modbus protocol is standardized message interaction. Proficiency in message frame structure, function code meanings, check rules and exception handling logic is an essential capability for industrial control debugging, instrument docking and IoT collection development. Accurate message analysis can quickly solve equipment communication faults, improve data collection stability, reduce on-site debugging costs, and is widely applicable to power meters, industrial control, building automation, new energy equipment and other industrial scenarios.