A Modbus gateway converts requests from one transport method to another and manages the correspondence between requests and responses. Common Modbus TCP to RTU gateways not only move bytes but also handle TCP message headers, serial addresses, and checksums. They also do not automatically understand units of engineering quantities such as temperature or pressure; the interpretation of registers is still determined by device documentation and the application.
First distinguish between protocol and physical interface
RS485 specifies electrical transmission conditions, while Modbus specifies application requests and responses; the same RS485 port does not necessarily use Modbus. Modbus RTU is commonly found on serial buses, while Modbus TCP uses TCP connections. A transparent serial server can move RTU bytes, but that does not mean it supports a standard Modbus TCP client. When purchasing, clarify the gateway’s protocol direction, role, concurrency capability, and supported functions, not just that it has a serial port and a network port.
What is converted is the outer wrapper and the transaction relationship
An RTU frame contains the device address, function, and data, and uses serial frame checksums; the TCP method uses an MBAP header to carry information such as transaction identifier, length, and unit identifier. The gateway parses the request, forms the target serial frame, and after receiving the response returns the corresponding network transaction. It does not simply append the RTU checksum bytes to the end of the TCP message. Function codes and register semantics are application content; whether mapping or conversion is needed depends on device capabilities and configuration.
Even if the address is correct, you still need to check the register convention
Serial device addresses must not conflict, and how the network unit identifier corresponds to the serial address must be set according to the gateway. The register display numbers in documentation and the message offsets may use different notations; use device examples or actual measurements to confirm, and do not mechanically copy a single number. When 32-bit data spans two registers, word order, scaling, and signed/unsigned interpretation may also be involved. If you can receive a response but the value is absurd, it is often these interpretations that are inconsistent, not that the fiber or network cable is broken.
Network concurrency is limited by serial processing capacity
When multiple network clients access simultaneously, the gateway must queue and match transactions; the same half-duplex serial port cannot unconditionally send multiple requests at the same time. The polling cycle should cover serial transmission, device processing, return, and queuing time. Too short a timeout leads to a retry storm, while too long a timeout delays fault discovery. Broadcasts, exception responses, and unsupported functions should also be handled explicitly; do not treat all responses without normal values as disconnections.
Build an acceptance script using known values
First read a known value from a single device, verify the raw bytes, engineering quantity, and units, then test multiple addresses and concurrent access. After verifying read operations, write operations must be performed under safe, approved device conditions. Save serial parameters, mapping tables, exception codes, and timeout records; test disconnection recovery, address conflicts, and slow devices to confirm that one device’s response is not mistakenly given to another request. The gateway itself does not provide a full set of network security; access entry points should be restricted.
Example: connection is normal but the temperature read is wrong
First find the official description of the temperature register, and confirm the function code, offset, number of registers, byte or word order, and scaling. The software display number may differ from the message offset, and the gateway address mapping may also cause the request to land on another device. Check the actual request and returned raw value in the gateway log, verify the address and data interpretation separately, and then adjust the configuration. Do not skip protocol analysis just because the network is online, and do not attribute all incorrect values to serial interference. For RTU/ASCII and different master/slave roles, check the modes explicitly supported by the product, and do not assume that one conversion direction is arbitrary bidirectional conversion.
Principle reference:Official technical documentation. The structural diagrams in this article do not represent specific product specifications; for selection, check the model manual.
Translated from the Chinese technical article. Source first published: 2021-12-15. Source last revised: 2026-10-13T20:58:17+08:00. Read the Chinese source
