After a true Modbus protocol gateway replaces the transparent serial/Ethernet path, a Modbus TCP client can exchange requests with Modbus RTU slaves without generating RTU frames itself. The reported mismatch occurs because a serial device server carries RTU bytes through Ethernet, while a gateway converts between two different Modbus application data unit formats.
Where does the request travel?
Follow the packet from the client to the serial slave. A SCADA system or other Ethernet client initiates the request. Ethernet and TCP carry it to the serial/Ethernet device. That device either forwards the payload unchanged or interprets and converts it before transmitting on the serial link.
| Path element | Expected function | Reading to take | Decision |
|---|---|---|---|
| Ethernet client | Generate either Modbus TCP or RTU-formatted data inside TCP | Selected driver or protocol mode | If the driver says Modbus TCP, the next device must perform protocol conversion. If it says Modbus RTU over TCP/IP, transparent forwarding may work. |
| Ethernet network | Carry the TCP connection | Link state, client and device addresses, configured TCP port | If the connection cannot open, remain at the physical and TCP layers. If it opens, inspect the application payload. |
| Serial/Ethernet device | Forward bytes or translate protocols | Operating mode and product function | A transparent converter does not make a Modbus TCP request into an RTU request. A Modbus gateway does. |
| Serial bus | Carry an RTU frame to the addressed slave | Transmit activity, receive activity, serial settings, slave address | Transmit without a reply points to serial configuration, addressing, wiring, or slave availability. |
The ATC-1200 is cited as an example of the Ethernet/serial converter class. The ATC-3002 is cited as the requested Modbus gateway class. Confirm the selected operating mode in the actual device configuration; product category, not the Ethernet connector alone, determines the behavior.
Does layer one pass traffic?
Layer one first. Confirm that the Ethernet link is active and that the client can establish a TCP connection to the configured device address and listening port. Record the configured address and port from both ends instead of relying on a successful ping: ping tests IP reachability but does not prove that the required TCP service is listening.
Then inspect the serial side. Match the gateway and RTU slave settings for baud rate, data bits, parity, and stop bits. Check the physical interface, conductor assignment, polarity where applicable, common reference requirements, termination, and biasing against the equipment documentation. A protocol gateway cannot compensate for an electrically invalid serial bus.
| Observation | Meaning | Next check |
|---|---|---|
| No Ethernet link | The request never reaches TCP | Cabling, switch port, interface state, and address configuration |
| Link present, TCP connection refused or timed out | The path reaches the network interface but not the service | Configured listening port, service mode, routing, and filtering |
| TCP request received, no serial transmission | The device rejected the payload or is not operating as a gateway | Protocol mode and request format |
| Serial transmission present, no reply | The failure is now on the RTU segment | Serial format, wiring, slave address, and requested function |
| Serial reply present, no client response | The return path or response conversion failed | Gateway diagnostics, transaction matching, timeout, and TCP connection state |
Which Modbus frame reaches the converter?
The term “Modbus over IP” is ambiguous. It may mean Modbus TCP, which uses a Modbus TCP application data unit, or it may mean a complete Modbus RTU frame transported as opaque bytes inside a TCP stream. Those payloads are not interchangeable.
| Mode | Ethernet payload | Serial-side behavior | Required intermediary |
|---|---|---|---|
Modbus RTU over TCP/IP |
RTU-formatted request, including the RTU addressing and error-checking fields | Forward the received byte sequence to the serial interface | Transparent Ethernet/serial converter |
Modbus TCP |
Modbus TCP header followed by the protocol data unit | Build a valid RTU request and later convert the RTU response back to Modbus TCP | Modbus TCP-to-RTU gateway |
A transparent converter treats the TCP payload primarily as a byte stream. It does not inherently remove the Modbus TCP header, map the unit identifier to an RTU slave address, calculate the RTU CRC, or reverse those operations on the reply. Some SCADA packages can deliberately send RTU-formatted frames over an Ethernet connection, which explains why the same converter works with one client and fails with another.
Capture one client request at the gateway-facing Ethernet interface. If it contains a Modbus TCP application data unit, select a protocol gateway. If it contains a complete RTU frame inside TCP, verify that the transparent converter’s packetization and serial timing behavior match the client and slave.
Where does a valid request stop?
Use activity counters, diagnostic logs, or packet captures to locate the last valid representation of the request. Do not change several layers at once.
- Verify the Ethernet link and record the client and converter IP settings.
- Open the configured TCP connection. If it fails, correct addressing, routing, filtering, service state, or the port selection before testing Modbus.
- Confirm the client driver mode. Separate
Modbus TCPfromModbus RTU over TCP/IP; a generic “Ethernet” label does not identify the payload. - Observe the received TCP payload or device diagnostics. If a Modbus TCP request reaches a transparent converter but no valid RTU exchange follows, the architecture is wrong.
- Observe serial transmit and receive activity. If a request is transmitted but the slave remains silent, check the serial settings and physical bus, then confirm the slave address and requested data location.
- If the RTU slave replies, verify that the response returns through the same gateway session and that the client timeout does not expire before conversion completes.
A TCP connection can deliver data in chunks that do not correspond to RTU frame boundaries. Transparent devices therefore depend on their configured packetization rules or idle-gap handling. A protocol-aware gateway identifies Modbus requests at the application layer and manages the conversion explicitly.
Which device and settings resolve the mismatch?
Select a Modbus TCP-to-Modbus RTU gateway when the Ethernet client supports Modbus TCP but cannot generate RTU over TCP/IP. The ATC-3002 is identified for this gateway role. A device such as the ATC-1200 belongs to the transparent Ethernet/serial converter case described above.
| Configuration item | Gateway-side value source | What it controls |
|---|---|---|
| Ethernet address | Network design | Where the client sends the TCP connection |
| TCP listening port | Client and gateway configuration | Which service accepts requests |
| Gateway protocol mode | Gateway configuration | Whether the device converts Modbus TCP or forwards raw serial data |
| Unit identifier mapping | Client request and gateway mapping table | Which RTU slave receives the request |
| Serial format | RTU slave configuration | Baud rate, data bits, parity, and stop bits |
| Response timeout | Measured slave response and gateway/client configuration | How long each layer waits before declaring failure |
Read the gateway documentation for unit-identifier routing and timeout behavior. When one serial bus contains multiple slaves, verify every mapping independently; a successful exchange with one address proves the link but not the remaining address entries.
How is the corrected path commissioned and verified?
- Configure the Ethernet client for
Modbus TCPand enter the gateway’s configured address and listening port. - Set the gateway to its Modbus TCP-to-RTU conversion mode rather than transparent serial tunneling.
- Configure the serial interface to match the RTU slave and connect the bus using the interface-specific wiring requirements.
- Map the client’s unit identifier to the intended RTU slave address using the gateway’s documented method.
- Send one known read request. Confirm the TCP request reaches the gateway, the gateway transmits an RTU request, the addressed slave replies, and the gateway returns a Modbus TCP response with the matching transaction context.
- Repeat the request while watching error counters and response time. Then test each required slave address and function through the production client.
FAQ
Why does Modbus RTU over IP work with one SCADA but not another?
Some SCADA drivers can place a complete RTU frame inside a TCP connection, while others generate only Modbus TCP. A transparent serial/Ethernet converter works only when the client supplies the frame format expected on the serial side.
Why does the TCP connection open but the RTU slave never reply?
The TCP session proves transport connectivity, not protocol compatibility. Check whether the payload is Modbus TCP or RTU over TCP/IP, then verify gateway mode, unit-identifier mapping, serial settings, wiring, and the RTU slave address.
How do I verify a Modbus TCP-to-RTU gateway conversion?
Trace one transaction end to end: observe the TCP request, the corresponding RTU transmission, the slave reply, and the converted TCP response. The final verification is a repeatable production-client read with stable response time and no incrementing gateway or serial error counters.