Modbus RTU and Modbus TCP share function codes and a data model, but their transport framing is different. RTU is often used on serial lines, and its message contains an address and a CRC; TCP transmits over TCP/IP and uses an MBAP header without adding RTU’s CRC field. Connecting the two usually requires a gateway that can handle Modbus conversion; an ordinary interface adapter is not enough to do the job.
What is the same is “what is being asked”; what is different is “how it is delivered”
Modbus function codes represent operations such as reading coils, reading registers, or writing, and the data part explains the address, quantity, or content. The function code and data make up the protocol data unit, or PDU. When the same request is sent onto a serial line or a TCP connection, different transport-related fields are added.
RS485 mainly defines the electrical interface and is not the same as Modbus RTU; Ethernet mainly solves link transmission and is also not the same as Modbus TCP. A device having an RS485 or RJ45 port only shows part of the interface conditions; you must continue to check which application protocol it supports.
How differences in message structure affect connection
An RTU message can be summarized as device address, function code, data, and CRC check. The serial line also relies on timing rules to identify message boundaries. A TCP message is organized as an MBAP header plus PDU. The MBAP contains information such as transaction identifier, protocol identifier, length, and unit identifier, and is used to identify and match requests and responses.
The fact that Modbus TCP has no RTU CRC field does not mean the entire network has no error detection; TCP/IP and the underlying link have their own mechanisms. Conversely, RTU’s CRC mainly checks message errors; it is not identity authentication or encryption. No basic mode should be regarded by default as having network security protection.
Serial bus and TCP concurrency cannot be converted simply
Common serial Modbus uses a method in which one client initiates a request and the server responds, coordinating access on the same bus; multiple masters cannot send at the same time without coordination. A TCP server may accept multiple connections, but the allowed number of connections, concurrent requests, and processing speed are determined by the device implementation.
If the other end of the TCP gateway is still a shared serial bus, multiple TCP requests usually need to queue. Increasing the network port speed does not mean the instrument responds immediately faster; the serial baud rate, message length, slave processing, and timeout all affect the total polling cycle. Access pacing must also be designed for high-priority operations.
An example of reading registers
If host software wants to read two holding registers from an instrument, it needs to specify the target device, function code, starting address, and quantity. The instrument documentation may use a conventional number like 40001, while the message address uses an offset representation, and the way the software fills it in may not be the same. You should check it against the manual and the software convention to avoid being off by one.
Even if two 16-bit registers are received, you cannot immediately determine that they are one correct floating-point number. Byte order, register word order, signed numbers, scaling factors, and units may be defined by the manufacturer. Successful communication and correct data interpretation are two separate checks; it is best to verify with a known measured value.
Why an ordinary serial server may not be enough
A transparent serial server may only put serial bytes into a TCP data stream; it does not necessarily parse the MBAP, generate the RTU address and CRC, or match transactions. This type of product can be used in a clearly defined transparent transmission scheme, but it cannot be assumed by default to be a Modbus protocol gateway. When purchasing, you should clearly state that TCP-to-RTU conversion is needed, rather than only writing “serial to network port.”
A gateway also needs to be checked for its working role, unit identifier mapping, serial format, timeout, and polling strategy. How the unit identifier on the TCP side locates serial devices must be configured according to the gateway implementation; the usage habits of direct TCP devices may be different, and not all devices can be filled in according to one rule.
Faults fall into three layers: connection, message, and business
When TCP cannot connect, check the address, port, route, and access rules; when the connection is established but times out, check the gateway mapping, serial parameters, terminal status, and queuing; when an exception response is received, check the function code and address range. An exception response means the device clearly reports a certain type of problem, which is different from no response at all.
On the RTU side, you also need to check wiring, termination matching, address conflicts, and electrical conditions. Do not directly equate A/B names with positive and negative definitions; match them according to the device documentation. Testing should preferably start with a single device and low-frequency read-only requests, then gradually expand the load; do not try writing registers on production devices without authorization.
A basic Modbus deployment should restrict access sources, partition, and set up firewalls as needed, and should not directly expose port 502 to the public network. If Modbus security extensions or security gateways are used, compatibility and certificate management still need to be checked. Whether to choose RTU or TCP depends on existing terminals, data scale, and maintenance conditions, not simply on ranking “new versus old” or “high versus low.”
References:Modbus Application Protocol Specification;Modbus over Serial Line Implementation Guide.
Translated from the Chinese technical article. Source first published: 2026-04-23. Source last revised: 2026-10-13T23:07:12+08:00. Read the Chinese source
