Modbus TCP Message Parsing

Modbus TCP is a mainstream communication protocol in the field of industrial Ethernet, based on the TCP/IP protocol stack for data transmission. It simplifies the verification mechanism based on Modbus RTU (relying on the TCP protocol’s own verification instead of CRC16), and implements device addressing and request-response matching in an Ethernet environment through the MBAP message header. This article systematically analyzes the core logic of the Modbus TCP protocol from the dimensions of protocol characteristics, message structure breakdown, instruction meaning interpretation, and comparison with Modbus RTU, using actual Tx (client request) and Rx (server response) message examples, providing a reference for industrial device debugging and protocol development.

1. Basic Information of the Example Message

This analysis selects a typical interaction scenario of “reading holding registers“, the message is as follows (note: the prefixes “1972-“ and “1973-“ are timestamp identifiers, not fields of the protocol itself, and should be ignored during parsing):

• Tx (client sends request):1972-00 05 00 00 00 06 01 03 00 00 00 05
• Rx (server returns response):1973-00 05 00 00 00 0D 01 03 0A 00 0B 00 16 00 21 00 2C 00 37

2. Core Structure of Modbus TCP Message

The Modbus TCP message consists of the MBAP message header (Modbus Application Protocol Header) and PDU (Protocol Data Unit), with a variable total length (the MBAP header is fixed at 7 bytes, while the PDU length varies with the data content). The structural framework is as follows:

Message Composition	Fixed Length	Included Fields	Core Function
MBAP Header	7 bytes	Transaction Identifier, Protocol Identifier, Length, Unit Identifier	Matches requests and responses, identifies protocol type, defines data length, and addresses devices
PDU	Variable	Function Code + Data Field (in request message, it is “register address/quantity“, in response message, it is “data length+register values“)	Defines specific operation types (e.g., reading registers) and the content of the interaction data

3. Tx Message Parsing (Client Request Instruction)

The Tx message is the request sent by the client to the server for “reading holding registers“, with a total length of 12 bytes (including the MBAP header of 7 bytes + PDU of 5 bytes). The functions and meanings of each field are broken down as follows:

1. MBAP Message Header (first 7 bytes)

The MBAP header is the core identifier that distinguishes Modbus TCP from RTU, used to locate target devices in an Ethernet multi-device environment and match requests with responses. The specific field breakdown is as follows:

Byte Position	Hex Value	Field Name	Parsing Explanation
0-1	00 05	Transaction Identifier	A unique identifier generated by the client (decimal 5), used to match “request–response“. The server must keep this value unchanged in its response to avoid data confusion
2-3	00 00	Protocol Identifier	Fixed as 0x0000, which is the exclusive identifier for the Modbus TCP protocol (if it is another value, it indicates a non-standard Modbus protocol)
4-5	00 06	Length	Indicates the total byte count of the subsequent “unit identifier+PDU“ (decimal 6), here “unit identifier (1 byte) + PDU (5 bytes) = 6 bytes“, consistent with the field value
6	01	Unit Identifier	Compatible with Modbus RTU’s “slave address“, used to identify specific devices on the bus (decimal 1), enabling multi-device addressing

2. PDU (last 5 bytes)

The PDU defines the specific operation instruction, here it is a “read holding register“ request, field breakdown:

Byte Position	Hex Value	Field Name	Parsing Explanation
7	03	Function Code	0x03 is the standard function code for Modbus, representing “read holding registers“ (holding registers are used to store core data for long-term operation of devices, such as temperature, pressure, etc.)
8-9	00 00	Starting Register Address	The starting address for the read operation is 0 (decimal), Modbus register addresses typically support “0 base address“ or “40001 base address“, here it is 0 base address
10-11	00 05	Number of Registers to Read	The number of holding registers to be read continuously is 5 (decimal), i.e., reading the 5 registers from address 0-4

3. Meaning of Request Instruction

The client sends the instruction to the “server with unit identifier 1“: “Please read the 5 holding registers starting from register address 0, and return the current values of these registers“.

4. Rx Message Parsing (Server Response Instruction)

The Rx message is the normal response from the server to the client’s request, with a total length of 19 bytes (including the MBAP header of 7 bytes + PDU of 12 bytes), containing “response status“ and “register data“, the field breakdown is as follows:

1. MBAP Message Header (first 7 bytes)

The MBAP header of the response message must match the corresponding fields of the request message to ensure the “request–response“ match:

Byte Position	Hex Value	Field Name	Parsing Explanation
0-1	00 05	Transaction Identifier	Identical to the request message (0x0005), ensuring the client can identify the response corresponding to that request
2-3	00 00	Protocol Identifier	Fixed as 0x0000, maintaining protocol type consistency
4-5	00 0D	Length	The total byte count of the subsequent “unit identifier+PDU“ (decimal 13), here “unit identifier (1 byte) + PDU (12 bytes) = 13 bytes“, consistent with the field value
6	01	Unit Identifier	Identical to the request message (0x01), indicating that it is the response from the “unit 1 device“

2. PDU (last 12 bytes)

The PDU of the response message contains “function code (confirming operation type)“, “data length (indicating the number of subsequent data bytes)“, and “register values (actual returned data)“ three parts:

Byte Position	Hex Value	Field Name	Parsing Explanation
7	03	Function Code	Identical to the request message (0x03), indicating “normal response to read holding register request“; if the highest bit of the function code is 1 (e.g., 0x83), it indicates that the request failed (e.g., address out of bounds)
8	0A	Data Length	The total byte count of the subsequent “register values“ field (decimal 10), since each register occupies 2 bytes, the 5 registers total 5×2=10 bytes, consistent with the field value (0x0A)
9-10	00 0B	Register 0 Value	Hexadecimal 0x000B converted to decimal is 11, which is the current value of register at address 0
11-12	00 16	Register 1 Value	Hexadecimal 0x0016 converted to decimal is 22, which is the current value of register at address 1
13-14	00 21	Register 2 Value	Hexadecimal 0x0021 converted to decimal is 33, which is the current value of register at address 2
15-16	00 2C	Register 3 Value	Hexadecimal 0x002C converted to decimal is 44, which is the current value of register at address 3
17-18	00 37	Register 4 Value	Hexadecimal 0x0037 converted to decimal is 55, which is the current value of register at address 4

3. Meaning of Response Instruction

The server returns the response to the client: “Successfully read the 5 holding registers starting from address 0 in unit identifier 1, with decimal values of 11, 22, 33, 44, 55, data transmission is complete and correct“.

5. Core Differences Between Modbus TCP and Modbus RTU

To better understand the protocol characteristics of Modbus TCP, the following table compares its key differences with Modbus RTU (based on this case and the Modbus RTU message parsing logic):

Comparison Dimension	Modbus TCP	Modbus RTU
Transport Layer Protocol	Based on TCP/IP (Ethernet), port number is usually 502	Based on serial communication (RS-485/RS-232), requires configuration of baud rate and parity
Message Identification and Separation	Relies on the MBAP header (7 bytes fixed) to define message boundaries	Relies on time intervals (≥3.5 character times) to separate frames, with no fixed header
Verification Mechanism	Relies on the TCP protocol’s own verification (no additional checksum required)	Requires adding a CRC16 checksum at the end of the message (2 bytes) to ensure reliability of serial transmission
Addressing Method	Unit Identifier (in MBAP header, 1 byte)	Slave Address (first byte of the message, 1 byte)
Data Transmission Efficiency	High Ethernet bandwidth (e.g., 100Mbps/1Gbps), suitable for large data transmission	Limited serial baud rate (e.g., 9600bps/19200bps), lower transmission speed
Typical Application Scenarios	Industrial Ethernet devices (e.g., PLCs, industrial computers, smart gateways)	Sensor, actuator, small controller connected via serial bus
Message Length Flexibility	PDU length is variable, supporting batch read/write of many registers	Limited by serial frame length, fewer registers can be read/written at once

6. Key Considerations for the Protocol

1. Uniqueness of Transaction Identifier: The client must ensure that each request’s transaction identifier is unique (e.g., an incrementing sequence) to avoid mismatches between responses and requests when multiple requests are sent simultaneously.
2. Error Response of Function Code: If the server cannot execute the request (e.g., register address out of bounds, insufficient permissions), it will return a response with the highest bit of the function code set to 1 (e.g., for request function code 0x03, the error response would be 0x83), and add an “exception code“ in the PDU to explain the error reason.
3. Compatibility of Unit Identifier: The unit identifier is essentially designed for compatibility with Modbus RTU’s “slave address“. In a pure TCP environment, devices can be located directly via IP address, and the unit identifier can be set to 0x00 (only when there are no RTU devices in the system).
4. Port Number Specification: The standard port number for Modbus TCP is 502, if the device manufacturer customizes the port, it must be modified in the communication configuration, otherwise, a connection cannot be established.

7. Modbus TCP Exception Response Message Parsing

1. Basic Information of the Example Message

The interactive message analyzed this time involves an exception response scenario, as follows:

• Tx (client sends request):: 1989-03 E4 00 00 00 06 01 03 00 00 00 32
• Rx (server returns response):: 1990-03 E4 00 00 00 03 01 83 02

2. Tx Message Parsing (Client Request Instruction)

1) MBAP Message Header (first 7 bytes)

Byte Position	Hex Value	Field Name	Parsing Explanation
0-1	03 E4	Transaction Identifier	A unique identifier generated by the client (decimal 996), used to match requests and responses
2-3	00 00	Protocol Identifier	Fixed as 0x0000, indicating the Modbus TCP protocol
4-5	00 06	Length	The total byte count of the subsequent fields (unit identifier + PDU) is 6 bytes
6	01	Unit Identifier	The target device address is 1 (decimal)

2) PDU (last 5 bytes)

Byte Position	Hex Value	Field Name	Parsing Explanation
7	03	Function Code	0x03 indicates “read holding register“ operation
8-9	00 00	Starting Register Address	The starting address for the read operation is 0 (decimal)
10-11	00 32	Number of Registers to Read	The number of holding registers to be read is 50 (0x32 converted to decimal)

3) Meaning of Request Instruction

The client sends the instruction to the “device with unit identifier 1“: “Read the current values of 50 holding registers starting from address 0“.

3. Rx Message Parsing (Server Exception Response)

1) MBAP Message Header (first 7 bytes)

Byte Position	Hex Value	Field Name	Parsing Explanation
0-1	03 E4	Transaction Identifier	Matches the request message (0x03E4), ensuring request and response match
2-3	00 00	Protocol Identifier	Fixed as 0x0000, maintaining protocol consistency
4-5	00 03	Length	The total byte count of the subsequent fields (unit identifier + PDU) is 3 bytes
6	01	Unit Identifier	Matches the request message, indicating it is the response from unit 1 device

2) PDU (last 2 bytes)

Byte Position	Hex Value	Field Name	Parsing Explanation
7	83	Exception Function Code	0x83 indicates an exception response to 0x03 function code (the highest bit of the function code being 1 is a flag for exception response)
8	02	Exception Code	0x02 indicates “illegal data address“ exception (the server does not exist in the specified register address range in the request)

3) Meaning of Exception Response

The server returns the exception information: “Cannot execute the request to read holding registers, because the specified register address range in the request (0-49) exceeds the valid register address range of this device“.

4. Exception Code Explanation

The Modbus protocol defines various exception codes, the exception code 0x02 means:

• Exception Code0x02: Illegal Data Address
• Indicates that the register address requested by the client exceeds the valid address range of the server
• Possible reasons: The actual number of available registers on the server is less than 50; the starting address 0 itself is an invalid address
• Solution: Check the server device manual to confirm its valid register address range, and adjust the requested register address and quantity

• If you are interested in industrial control technology and want to get more valuable content, don’t forget to like, share, and “see more”, this will be the greatest support for me!

  👇👇Follow me👇👇You can get first-hand programming tips for upper-level machines, application cases of industrial robots, and other exclusive content, and explore the mysteries of industrial control technology with me, unlocking more possibilities.