May 14, 2026 · Comparison

Modbus RTU vs TCP, and Bridging the Two with a Gateway

By Dzulfikar Ats Tsauri, founder of Voltrus / JoyoDigitama. He builds the protocol tools covered in these posts. Updated October 28, 2026.

Modbus has been the lingua franca of industrial automation since 1979. If you work with PLCs, power meters, VFDs, or any industrial device, you will encounter Modbus. For a complete overview of the protocol, see What Is Modbus? The two dominant variants (Modbus RTU (serial) and Modbus TCP (Ethernet)) use the same application protocol but differ fundamentally in how they transport data. Choosing the wrong one costs time, money, and field-truck rolls.

What Is Modbus RTU?

Modbus RTU (Remote Terminal Unit) runs over serial communication, typically RS-485. Data is transmitted as binary frames over a two-wire bus. A single master polls one or more slave devices by sending a request frame; the addressed slave responds. The bus supports up to 247 devices on a single serial line at distances up to 1,200 meters (4,000 feet) at 9600 baud. For more on the underlying serial protocols, see our guide to serial communication protocols in industrial settings.

RTU encodes data in hexadecimal, which makes it compact and efficient over slow serial links. A typical holding register read request is only 8 bytes. The trade-off is speed: at 9600 baud, you can poll roughly 30-40 registers per second. At 115200 baud, that rises to a few hundred, still far slower than Ethernet.

Key Characteristics of Modbus RTU

• Physical layer: RS-485 (2-wire, half-duplex) or RS-232 (point-to-point)
• Topology: Daisy-chain bus, up to 247 devices
• Speed: 1200 to 115200 baud (typical: 9600 or 19200)
• Distance: Up to 1,200m without repeaters
• Frame format: Binary (hex), compact
• Error checking: CRC-16
• Wiring: Two twisted pairs (A/B + shield), simple and cheap

What Is Modbus TCP?

Modbus TCP encapsulates the same Modbus application protocol inside TCP/IP packets over Ethernet. Introduced in 1999, it was designed to bring Modbus into modern networked environments. Instead of serial addresses, devices use IP addresses. Instead of a single master, multiple clients can connect to the same server simultaneously.

TCP eliminates the master-slave limitation. Any number of clients can read and write to the same Modbus TCP device at the same time. The Ethernet physical layer supports speeds from 10 Mbps to 1 Gbps, orders of magnitude faster than serial. A single read request over TCP still only queries one device, but the response time is measured in milliseconds rather than tens of milliseconds.

Key Characteristics of Modbus TCP

• Physical layer: Ethernet (Cat5/6, fiber)
• Topology: Star, tree, or ring via switches
• Speed: 10 Mbps to 1 Gbps
• Distance: 100m per Ethernet segment, unlimited with fiber/switches
• Frame format: Modbus Application Protocol (MBAP) header + PDU
• Error checking: Handled by TCP (checksums, retransmission)
• Wiring: Standard Ethernet, often already in place

Head-to-Head Comparison

When to Use Modbus RTU

• Long cable runs in industrial environments. RS-485 differential signaling handles electrical noise better than Ethernet in harsh environments. If your devices are spread across a factory floor with variable-frequency drives, motors, and welders generating EMI, RTU over shielded twisted pair is more reliable.
• Connecting legacy devices. Most industrial devices manufactured before 2010 only speak Modbus RTU. Power meters, flow computers, VFDs, and temperature controllers often have RS-485 ports and no Ethernet option. RTU is your only choice.
• Simple, low-cost sensor networks. RS-485 transceivers cost cents. Running a two-wire bus to a dozen temperature sensors across a building is significantly cheaper than installing Ethernet switches and running Cat6 to each one.
• Hazardous or classified areas. RS-485 is inherently current-limited and simpler to certify for intrinsic safety barriers than Ethernet.

When to Use Modbus TCP

• High-speed data acquisition. If you need to poll hundreds or thousands of registers per second (real-time dashboarding, high-speed trending, or rapid commissioning), TCP is the only practical choice. Ethernet bandwidth eliminates the serial bottleneck entirely.
• Multiple clients accessing the same device. RTU allows only one master. If your SCADA system, a data logger, and a commissioning laptop all need to read the same PLC, TCP supports simultaneous connections from all of them.
• Existing Ethernet infrastructure. If your plant already has an industrial Ethernet network with managed switches, VLANs, and fiber backbones, adding Modbus TCP devices is trivial. No separate serial cabling required.
• Remote access and monitoring. Modbus TCP devices can be accessed over VPNs, routed networks, and even the internet (with proper security). RTU requires physical proximity or serial-to-Ethernet converters. For guidance on setting up continuous monitoring, see how to monitor Modbus TCP devices without middleware bloat.

Can You Use Both? The RTU to TCP Gateway

Yes, and most real installations do. Legacy field devices (power meters, VFDs, temperature controllers, 2000s-era PLCs) speak RTU over RS-485, while SCADA, dashboards, and edge boxes speak TCP. The two share one application protocol but not a transport, so a Modbus RTU to TCP gateway sits between them. It terminates TCP sessions from Ethernet clients, translates each request into an RTU frame, puts it on the serial bus, and returns the slave's reply to the client that asked. You keep the noise immunity and low cost of RS-485 in the field and get multi-client Ethernet access in the control room.

The gateway also serializes access. RTU is half-duplex with one transaction on the wire at a time, while TCP clients can send in parallel. The gateway queues their requests so concurrent clients never collide on the bus.

Typical Topology

1. RS-485 bus daisy-chained through the meters and drives, terminated at both ends and biased at one point.
2. The bus lands on the gateway's serial port (A/B plus shield).
3. The gateway's Ethernet port joins the plant LAN or an edge switch.
4. The client opens a Modbus TCP connection to the gateway IP on port 502.
5. Each poll targets a unit ID that maps to a slave downstream.

Where the Latency Comes From

People blame the gateway, but the serial bus is almost always the bottleneck. At 9600 baud one RTU round trip (request, response, inter-frame gaps) takes tens of milliseconds, and only one can run at a time. Polling 30 slaves with 5 registers each takes the sum of 30 serial round trips no matter how fast the Ethernet side is. The gateway itself adds a few milliseconds: receive the TCP request, wait out the 3.5-character gap, send, wait for the reply, forward. To shorten the cycle, raise the baud rate (38400 or 115200 if every device accepts it) and read fewer registers per slave, ideally in one contiguous block.

Hardware or Software Gateway

• Hardware gateway (Moxa MGate, Anybus, USR-TCP232): a DIN-rail box that does one job, with isolated serial ports and a web UI for IP and serial settings. The right choice for permanent installs and electrically noisy panels.
• Software gateway on a host or edge box with a USB-RS485 adapter: cheaper and scriptable. You can log, filter requests, or bridge to other protocols. It fits when a host is already on site or you want more than plain RTU to TCP.

The RS-485 standard allows 32 unit loads per segment (more with repeaters or low-load transceivers), and every slave needs a unique address from 1 to 247.

Before pointing production SCADA at a gateway, prove the path: open a TCP connection to the gateway IP and read a known register from a downstream slave by unit ID. If that returns valid data, the unit-ID routing and the serial side both work. For bus-level faults see the RTU over serial guide. To bridge several protocols behind one API, Voltrus Gateway runs as a single self-hosted binary.

Traffic Monitoring and Packet Loss

One thing that catches engineers off guard with Modbus TCP: TCP handles retransmission, so a dropped packet is invisible at the application layer. Your Modbus client gets a response, but you have no idea whether the network delivered it on the first try or after three retransmissions. If your plant network is congested (competing with HTTP traffic, HMI updates, or video streams), silent retransmissions add latency you cannot see from the register values alone.

The traditional approach is Wireshark. Capture packets on port 502, filter by Modbus TCP, and dig through the capture to find retransmissions, duplicate ACKs, and delayed responses. It works, but it is a multi-step process: start capture → reproduce the issue → stop capture → apply filters → interpret TCP flags. For a quick "is my Modbus traffic healthy?" check during commissioning, Wireshark is overkill.

A built-in traffic monitor shows you the full request/response exchange in real time. Every Modbus TCP request and response (function code, register address, byte count, and payload) is logged as it happens. If a request gets no response within the timeout, it shows up as a failed transaction immediately. No packet capture, no filter setup, no TCP flag interpretation. You see the traffic, you see the gaps, you see if your request got dropped.

Testing Both Protocols

Regardless of which protocol you choose, you need a tool that can poll registers and verify communication during commissioning. MacTools Modbus Poll supports both Modbus TCP and Modbus RTU in a single native app: no Windows VM, no Parallels, no command-line tools.

For RTU, it works with USB-to-RS485 adapters that macOS exposes as a serial port. For TCP, just enter the device IP address and port. The same register table, live value monitoring, and communication logging work across both protocols.

The built-in traffic monitor shows every Modbus TCP request and response in real time: function code, register address, payload bytes, and round-trip time. If a request gets dropped or the response is delayed, you see it immediately without opening Wireshark. This is especially useful during commissioning when you are verifying that a new device responds correctly, or debugging why a register read returns unexpected values.

Further Reading

• Modbus TCP vs OPC UA: Which Industrial Protocol to Choose
• Modbus Register Types Explained: Coils, Holding Registers, Input Registers
• Best Modbus Simulator for macOS (2026)