RS-485 meters behind a serial-to-Ethernet converter: Modbus TCP or RTU over TCP?

[ShiftAnalyst]

We have eight RS-485 devices (flow meters and two temperature controllers) on one serial line. The SCADA PC is 150 m away, so we installed a serial-to-Ethernet converter in the field panel instead of pulling a long RS-485 cable.
In the Tag Editor I added a Modbus TCP channel with the converter's IP and port 502, but every frame times out. The converter's web page shows TX activity, so something is being sent. The devices work fine when I connect them directly to a laptop with a USB-RS485 adapter. Which channel type should I use here?

[Technical Support]

The key question is what mode your converter is in. Most serial-to-Ethernet converters can work in one of two ways:

• Transparent (raw TCP) mode: the converter passes the bytes through unchanged. The devices still expect Modbus RTU frames, just carried over TCP. In Omnivex SCADA, use a Modbus RTU OVER TCP channel.
• Modbus gateway mode: the converter translates Modbus TCP to Modbus RTU. Here you use a normal Modbus TCP channel.

Your symptoms (TX activity but no answers) are typical of sending Modbus TCP frames to a converter in transparent mode. The devices receive a frame they don't understand and stay silent.
Steps
1. Check the converter's configuration and note the mode and the TCP port (often not 502 in transparent mode).
2. In the Tag Editor, right-click Created Channels > Add Channel and choose Modbus RTU OVER TCP. Enter IP, Port and Request Time.
3. Make sure the converter's serial settings (baud rate, parity, stop bits) match the devices. In this setup the serial parameters live in the converter, not in SCADA.
4. Create one frame per device and set the correct Slave ID on each frame.
5. Start with one device and a small frame (low Quantity) until you see data, then add the rest.
Request Time on a shared line
All eight devices share one serial line, and requests are answered one after another. A very short Request Time can cause timeouts even when everything is wired correctly. Start with a conservative value and lower it once the line is stable.
Documentation: https://greensoft.ai/documentation/o...ion-protocols/