Modbus RTU and Modbus TCP carry the same application data (the same function codes, the same register map, the same data model) but they move it over completely different physical layers. RTU is a serial protocol that runs over RS-485 or RS-232, while TCP wraps the Modbus payload inside an Ethernet/IP packet. Choosing between them, or bridging one to the other with a gateway, comes down to distance, device count, determinism, error handling, and how the data needs to reach your SCADA or cloud platform.
Same Application Layer, Different Transport
Both variants are defined by the same Modbus Application Protocol Specification maintained by Modbus Organization. A read or write is built from a function code (for example 0x03 Read Holding Registers, 0x06 Write Single Register) plus the relevant register addresses and data. That part is identical. What differs is the framing that surrounds it.
In Modbus RTU, each message is a compact binary frame: a 1-byte slave address, the function code, the data field, and a 2-byte CRC-16 checksum. Frame boundaries are detected by silence on the wire, specifically a gap of at least 3.5 character times. There is no slave address larger than 247, and one master polls many slaves in strict request/response sequence.
In Modbus TCP, the CRC and the silence-based framing are dropped because the underlying TCP/IP stack already guarantees ordered, error-checked delivery. Instead, a 7-byte MBAP header (Modbus Application Protocol header) is prepended: a 2-byte transaction identifier, a 2-byte protocol identifier (always 0 for Modbus), a 2-byte length field, and a 1-byte unit identifier. The unit identifier is what lets a single TCP/IP endpoint, such as a gateway, address multiple serial slaves behind it.
Side-by-Side Comparison
| Characteristic | Modbus RTU | Modbus TCP |
|---|---|---|
| Physical layer | RS-485 (2 or 4 wire) or RS-232 | Ethernet (10/100/1000), TCP/IP |
| Default port | Not applicable (serial) | TCP 502 |
| Frame overhead | Address + CRC-16 (3 extra bytes) | 7-byte MBAP header, no CRC |
| Error checking | CRC-16 in the frame | Delegated to TCP checksum + retransmission |
| Frame delimiting | 3.5 character idle time | Length field in MBAP header |
| Addressing | 1-247 slave address on shared bus | IP address + unit ID |
| Topology | Multidrop bus, daisy chain, 1 master | Star via switch, multiple masters possible |
| Max nodes per segment | 32 unit loads (up to 256 with 1/8-load transceivers) | Limited by IP subnet and switch ports |
| Max distance | Up to 1200 m at low baud (per EIA/TIA-485-A) | 100 m per copper run, unlimited via switches/fiber |
| Typical speed | 9600 to 115200 baud | 10/100 Mbit/s or higher |
| Concurrent transactions | One outstanding poll at a time | Multiple via transaction ID pipelining |
| Determinism | High (predictable poll cycle on dedicated bus) | Depends on network load and switching |
| Cabling cost | Low (single twisted pair, daisy-chained) | Higher (structured cabling, switches) |
Distance, Topology, and Node Count
RS-485 is built for the plant floor. A single twisted pair, properly terminated with 120-ohm resistors at both ends, can run up to 1200 m at lower baud rates, and a standard transceiver presents one unit load so the bus supports 32 nodes (more with fractional-unit-load transceivers). The trade-off is the classic speed-versus-distance relationship: the longer the cable, the lower the baud rate you can reliably sustain. Wiring faults, missing termination, and ground potential differences are the usual culprits behind intermittent RTU errors, which is why bus design and protection matter. For the wiring and termination details, see our guide on RS-485 wiring, termination, and common faults.
Modbus TCP rides on standard Ethernet, so individual copper runs are limited to roughly 100 m, but switches and fiber let you extend the network across an entire facility with a star topology. You get higher throughput and can have multiple SCADA clients polling the same device concurrently, something a single-master RTU bus cannot do natively.
Error Checking and Determinism
RTU embeds a CRC-16 in every frame, so the receiving device validates integrity at the application layer and discards corrupt frames. TCP removes that CRC because the transport layer already provides a checksum plus automatic retransmission of lost segments. Both approaches are robust, but they fail differently: a noisy RS-485 segment shows up as CRC errors and timeouts, while a congested Ethernet link shows up as latency and TCP retransmissions.
For determinism, a dedicated RTU bus is highly predictable because the master controls the entire poll cycle and nothing else competes for the wire. On a shared Ethernet network, jitter depends on traffic and switch behavior, so for hard real-time control engineers often keep RTU close to the equipment and use TCP for supervisory data. When timeouts or exception codes appear, the systematic approach in our article on troubleshooting Modbus communication errors helps isolate physical-layer faults from protocol-level ones.
When to Convert RTU to TCP with a Gateway
Most real installations are mixed. Field devices such as power meters, temperature sensors, and drives speak RTU over RS-485, but the monitoring system, historian, or cloud platform expects TCP or MQTT. A protocol gateway bridges the gap by polling the serial slaves as an RTU master and re-presenting them as TCP servers (or publishing to a broker), mapping each serial slave to a unit identifier.
Convert RTU to TCP or MQTT when you need to:
- Reach devices that are physically distant from the control room over existing Ethernet rather than running new serial cable.
- Let multiple clients (SCADA, dashboard, analytics) read the same field devices concurrently.
- Decouple the slow, deterministic serial poll cycle from a faster supervisory layer.
- Push field data to a cloud or edge platform using MQTT instead of point-to-point polling.
SURIOTA’s SRT-MGATE-1210 Modbus gateway performs exactly this role: it acts as an RTU master on the RS-485 side, aggregates the connected slaves, and bridges them to Modbus TCP and MQTT. That makes it the integration point between legacy serial instrumentation and a modern industrial IoT and system integration stack. If you are weighing where polling logic should live, our comparison of an edge gateway versus a PLC versus an RTU covers the architectural trade-offs.
Frequently Asked Questions
Is Modbus TCP just Modbus RTU over Ethernet?
Not exactly. The application data and function codes are identical, but Modbus TCP replaces the RTU address byte and CRC-16 with a 7-byte MBAP header and relies on TCP for error checking. A distinct variant called Modbus RTU over TCP does encapsulate the full RTU frame (including CRC) inside a TCP stream, which is different from native Modbus TCP and must be matched on both ends.
Can one gateway expose many RTU slaves over a single TCP connection?
Yes. The unit identifier in the MBAP header lets a single IP endpoint route requests to different serial slaves behind the gateway, so a TCP client addresses each field device by its original slave ID.
Which is faster, Modbus RTU or Modbus TCP?
Modbus TCP usually offers higher raw throughput and supports concurrent transactions, while a dedicated RTU bus offers more predictable timing. For supervisory data and many devices, TCP wins; for tight, deterministic local control loops, RTU is often preferred.
Do I lose CRC protection when bridging RTU to TCP?
The CRC-16 is stripped at the gateway because TCP provides its own integrity and retransmission. End-to-end integrity is preserved, but the protection mechanism shifts from the application frame to the transport layer.