To understand the communication processes of Modbus TCP and Modbus RTU, we need to consider their frame structures, transmission mechanisms, and master-slave interaction logic. The former relies on the TCP/IP protocol stack for “reliable transmission,” while the latter transmits “binary data” directly over serial ports. The core differences lie in the “data encapsulation” and “link interaction” stages. Below, we break down the specific communication processes in different scenarios (using the most common “read registers” example with function code 03):
1. Communication Process of Modbus RTU (Based on RS485 Serial Port)
Modbus RTU is a “serial-level” communication protocol without a lower-layer protocol stack. Data is transmitted directly on the RS485 bus in “binary frames,” requiring slave address and CRC check to ensure accurate delivery to the target device. Taking the example of the “master (e.g., PLC) reading two holding registers (addresses 40001, 40002) from the slave (e.g., inverter),” the specific steps are as follows:
1. Preparation Before Communication: Unified Serial Port Parameters
The master and slave devices must agree on the serial port parameters in advance (which must be identical; otherwise, communication will fail):
- Baud rate: Common rates are 9600bps, 19200bps, 115200bps (lower rates are more resistant to interference, suitable for long distances);
- Data bits + Stop bits: Default is 8 data bits + 1 stop bit;
- Parity: None / Even / Odd (usually “no parity” is selected, relying on CRC for integrity);
- Slave address: Each slave device is assigned a unique address (1~247, 0 is the broadcast address). In this example, the inverter address is set to “1.”;
2. Master Sends “Read Register Request Frame”
The master encapsulates the request data according to the Modbus RTU frame structure and broadcasts it over the RS485 bus (all devices on the bus can receive it, but only the slave with the matching address responds):Modbus RTU Request Frame Structure (Total 8 Bytes):
| Field | Byte Count | Value in This Example (Hex) | Description |
|---|---|---|---|
| Slave Address | 1 | 0x01 | Target slave (inverter) address |
| Function Code | 1 | 0x03 | Function code 03 = “read holding registers” |
| Starting Register Address (High Byte) | 1 | 0x00 | Register 40001 corresponds to “relative address 0000” (40001=40000+1), high byte 00 |
| Starting Register Address (Low Byte) | 1 | 0x00 | Low byte 00, meaning the starting address is 0x0000 |
| Number of Registers to Read (High Byte) | 1 | 0x00 | Reading 2 registers, high byte 00 |
| Number of Registers to Read (Low Byte) | 1 | 0x02 | Low byte 02, meaning the count is 0x0002 |
| CRC Check (Low Byte) | 1 | 0xC4 | CRC16 check calculated on the first 6 bytes (to ensure data is error-free) |
| CRC Check (High Byte) | 1 | 0x0B | Same as above |
Actual Sent Binary Stream (Hex):<span>01 03 00 00 00 02 C4 0B</span>
3. Slave Receives and Responds
- Slave Filtering: All slaves on the bus receive the frame data and first check the “slave address”—only the inverter with address 0x01 (the slave in this example) continues processing, while other slaves discard the frame;
- Legitimacy Check: The slave recalculates the CRC check on the first 6 bytes and compares it with the CRC byte at the end of the frame—if they do not match, it determines that the data is erroneous and does not respond; if they match, it executes the “read register” operation;
- Slave Sends Response Frame: The inverter reads register 40001 (value 0x1234) and 40002 (value 0x5678), encapsulating the data according to the RTU response frame structure and sending it back to the master:
Modbus RTU Response Frame Structure (Total 10 Bytes):
| Field | Byte Count | Value in This Example (Hex) | Description |
|---|---|---|---|
| Slave Address | 1 | 0x01 | Confirming its own address |
| Function Code | 1 | 0x03 | Matches the request function code (no error) |
| Data Length | 1 | 0x04 | Number of subsequent data bytes (2 registers × 2 bytes/register = 4 bytes) |
| Register 40001 Value (High Byte) | 1 | 0x12 | High byte of register value 0x1234 |
| Register 40001 Value (Low Byte) | 1 | 0x34 | Low byte |
| Register 40002 Value (High Byte) | 1 | 0x56 | High byte of register value 0x5678 |
| Register 40002 Value (Low Byte) | 1 | 0x78 | Low byte |
| CRC Check (Low Byte) | 1 | 0x7A | CRC16 check on the first 8 bytes |
| CRC Check (High Byte) | 1 | 0x3A | Same as above |
Actual Sent Binary Stream (Hex):<span>01 03 04 12 34 56 78 7A 3A</span>
4. Master Receives and Parses
After the master receives the response frame, it performs two verification steps:
- Check CRC: Confirm that the data has not been tampered with;
- Verify “Slave Address + Function Code”: Confirm that it is a valid response from the target slave (if the highest bit of the function code is 1, such as 0x83, it indicates an error in execution by the slave, and troubleshooting is required);Upon successful verification, the master parses the “data field”—extracting 0x1234 (40001) and 0x5678 (40002) for subsequent control logic (e.g., displaying on HMI, determining device status).
2. Communication Process of Modbus TCP (Based on Ethernet)
Modbus TCP is an “Ethernet-level” protocol that relies on the TCP/IP protocol stack (IP layer + TCP layer) for data transmission. The core is to add an “MBAP header” before the Modbus PDU (function code + data) and utilize TCP’s “three-way handshake” to ensure reliable communication.Again, taking the example of the “master (e.g., SCADA server) reading two holding registers (40001, 40002) from the slave (e.g., PLC),” the specific steps are as follows:
1. Preparation Before Communication: Establishing TCP Connection
- Network Parameter Configuration: The master (SCADA) and slave (PLC) must be on the same local area network (or interconnected via routers), with unique IP addresses configured (e.g., master 192.168.1.100, slave 192.168.1.200), and the slave must open the default Modbus TCP port 502;
- TCP Three-Way Handshake: The master actively initiates a TCP connection request to the slave’s port 502 (SYN), the slave responds (SYN+ACK), and the master confirms (ACK)—establishing a stable TCP connection (RTU does not have this step and broadcasts directly).
2. Master Sends “Read Register Request Frame”
The master encapsulates the data according to the Modbus TCP frame structure and sends it through the established TCP connection (not broadcast; only the target slave receives):Modbus TCP Request Frame Structure (Total 12 Bytes):
| Field | Byte Count | Value in This Example (Hex) | Description |
|---|---|---|---|
| MBAP Header | 7 | —— | TCP-specific “header” used to identify requests/responses |
| Transaction Identifier (High Byte) | 1 | 0x00 | Custom transaction ID (e.g., 0001) used to match requests and responses |
| Transaction Identifier (Low Byte) | 1 | 0x01 | Same as above |
| Protocol Identifier | 2 | 0x0000 | Fixed as 0000 (indicating Modbus protocol) |
| Length | 2 | 0x0005 | Number of subsequent bytes (unit identifier 1 byte + PDU 4 bytes = 5 bytes) |
| Unit Identifier | 1 | 0x01 | Similar to RTU’s “slave address,” compatible with RTU devices |
| Modbus PDU | 4 | —— | Identical to RTU’s PDU |
| Function Code | 1 | 0x03 | Read holding registers |
| Starting Address | 2 | 0x0000 | Starting address of register 40001 |
| Number of Reads | 2 | 0x0002 | Read 2 registers |
Actual Sent Binary Stream (Hex):<span>00 01 00 00 00 05 01 03 00 00 00 02</span> (Note: No CRC check—TCP layer already has a “checksum,” so no need for repeated checks)
3. Slave Receives and Responds
- TCP Layer Verification: The slave receives data through TCP port 502, first verifying the TCP checksum (confirming data is error-free), then parsing the MBAP header;
- Target Matching: Checks the “unit identifier” (0x01)—only the matching slave (PLC) processes it, while other devices ignore it;
- PDU Execution: The slave parses the PDU (function code 03 + address 0000 + count 0002), reading registers 40001 (0x1234) and 40002 (0x5678);
- Slave Sends Response Frame: Encapsulates the data according to the Modbus TCP response frame structure and sends it back to the master through the TCP connection:
Modbus TCP Response Frame Structure (Total 15 Bytes):
| Field | Byte Count | Value in This Example (Hex) | Description |
|---|---|---|---|
| MBAP Header | 7 | —— | Transaction identifier matches the request (0001), ensuring a match |
| Transaction Identifier | 2 | 0x0001 | Same as the request transaction ID, linking request and response |
| Protocol Identifier | 2 | 0x0000 | Fixed 0000 |
| Length | 2 | 0x0008 | Number of subsequent bytes (unit identifier 1 byte + PDU 7 bytes = 8 bytes) |
| Unit Identifier | 1 | 0x01 | Matches the request |
| Modbus PDU | 7 | —— | Function code + data length + register values |
| Function Code | 1 | 0x03 | No error, matches the request |
| Data Length | 1 | 0x04 | Number of subsequent data bytes (2 registers × 2 bytes = 4 bytes) |
| Register 40001 Value | 2 | 0x1234 | Register value |
| Register 40002 Value | 2 | 0x5678 | Register value |
Actual Sent Binary Stream (Hex):<span>00 01 00 00 00 08 01 03 04 12 34 56 78</span>
4. Master Receives and Parses
- TCP Connection Maintenance: After the master receives the response, it matches the corresponding request through the “transaction identifier” (0001) (to avoid confusion during multiple requests);
- PDU Parsing: Extracts the register values from the PDU (0x1234, 0x5678) for monitoring or control (e.g., SCADA interface displaying PLC register data);
- Connection Reuse: If further communication is needed, the TCP connection can be maintained (long connection), avoiding repeated “three-way handshakes” (RTU requires re-broadcasting for each communication); if there is no data for a long time, the connection will time out and close.
3. Summary of Core Differences in Communication Processes
| Comparison Dimension | Modbus RTU | Modbus TCP |
|---|---|---|
| Connection Method | Connectionless (RS485 bus broadcast) | Connection-oriented (TCP three-way handshake establishes stable link) |
| Key Frame Structure Differences | Includes slave address + CRC check, no message header | Includes MBAP message header (transaction identifier), no CRC check |
| Data Location Method | Relies on “slave address” to filter target devices | Relies on “IP + port + unit identifier” to locate devices |
| Re-transmission Mechanism | No built-in re-transmission (requires upper-layer logic to handle timeouts) | TCP layer has built-in re-transmission (automatically retransmits after packet loss) |
| Communication Efficiency (Small Data) | Fast (no protocol stack overhead) | Slower (TCP connection/message header has slight overhead) |
| Scalability | Up to 32 slaves (bus load limit) | Theoretically unlimited (Ethernet switch expansion) |
From the specific communication processes, it can be seen that Modbus RTU is a “lightweight serial protocol” suitable for simple interactions in small ranges and low costs; Modbus TCP is a “reliable Ethernet protocol” suitable for large-scale, long-distance, and high-frequency data interactions in industrial scenarios (such as factory-level SCADA monitoring and interconnection of devices across regions).