Modbus RTU vs Modbus TCP: When to Use Each in Industrial Networks

Modbus has outlived almost every protocol that was supposed to replace it. It’s simple, it’s open, and almost every PLC, VFD, power meter, and HMI on the planet speaks at least one flavor of it. The two flavors you’ll actually encounter are Modbus RTU (serial, usually over RS-485) and Modbus TCP (Ethernet). They share a register model and a function code set, but everything below the application layer is different — and the differences matter when you’re picking how to wire a new line or extend an old one.

Here’s how they actually differ on the floor, and how to choose.

Same Data Model, Different Transport

Both flavors expose the same things to a master/client:

Coils (1-bit, read/write) at addresses 00001–09999
Discrete inputs (1-bit, read-only) at 10001–19999
Input registers (16-bit, read-only) at 30001–39999
Holding registers (16-bit, read/write) at 40001–49999

A “read holding registers” call (function code 03) requesting registers 40001–40010 looks identical at the application layer in both versions. What changes is the wrapper:

Modbus RTU wraps the request in a frame with a slave address byte and a CRC-16 checksum, transmitted serially.
Modbus TCP wraps it in an MBAP header (transaction ID, protocol ID, length, unit ID), transmitted over a TCP socket on port 502. No CRC — TCP handles integrity.

The same PLC code reading register 40050 from a flow meter doesn’t care which transport carried the bytes. That’s why bridging RTU to TCP is so easy and why so many gateway products exist.

The Wiring Reality

This is where the practical decision usually starts.

Modbus RTU (RS-485)

A two-wire (or three-wire with reference) twisted pair runs from device to device in a daisy chain. You can stack up to 32 devices on a standard segment without a repeater (more with low-load transceivers — up to 256 in theory, rarely in practice). Maximum cable length is roughly 1200 m at 9600 baud, less at higher speeds. You terminate both ends of the bus with 120 Ω resistors and bias the line so it doesn’t float.

Wiring cost is low — a single roll of shielded twisted pair handles dozens of nodes. Failure modes are noisy: one device with reversed polarity or a missing terminator will degrade or kill the whole bus. T-tap stubs longer than ~30 cm cause reflections that wreck signal integrity, and people add them anyway because the bus runs past a panel and “it’s just a short stub.” It isn’t.

Modbus TCP (Ethernet)

Each device gets a Cat5e/Cat6 drop back to a switch. Star topology, point-to-point links. Maximum segment length is 100 m between switch and device. Number of devices is limited by the number of switch ports and your IP addressing, not by the protocol.

Wiring cost is higher — every device is its own home run. But a fault on one cable affects only one device, not the whole network. Diagnostic tools (link lights, ping, Wireshark) are dramatically better than anything you have for RS-485.

Addressing

RTU

Each slave gets a unique address from 1 to 247 (0 is broadcast). You set it via DIP switches, a keypad, or a config tool. A common rookie mistake: two devices with the same address. The bus will look like it works for the device that responds slightly faster, and the other one will be invisible — no clean error message, just garbage.

TCP

Each device gets an IP address. The Modbus “unit ID” still exists in the MBAP header but is usually meaningless on a TCP-native device (set it to 1 or 255). It becomes meaningful again when a TCP-to-RTU gateway is in the path: the unit ID then identifies which RTU slave behind the gateway you’re talking to.

Static IPs are mandatory in production. DHCP on a control network is a fast way to lose your mind when a meter’s IP changes after a power cycle and the SCADA system can’t find it.

Throughput and Timing

RTU

At 9600 baud — still the most common default — a single read of 10 registers takes roughly 30–40 ms including the silent intervals between frames. Bump to 115200 baud and you can crunch through dozens of devices per second, but cable runs over a few hundred meters get unreliable above 38400 baud unless your wiring is excellent.

The bigger constraint is that RTU is half-duplex. Only one device transmits at a time, and the master must wait at least 3.5 character times of silence between frames. Polling 30 devices each for 20 registers at 9600 baud is a minimum of about a second of bus time, in practice closer to 1.5–2 seconds. If you need 100 ms updates from a fast process, RTU at 9600 won’t get there.

TCP

A round-trip on a quiet 100 Mbit Ethernet network is sub-millisecond at the wire level. A single Modbus TCP transaction completes in 2–10 ms typically — most of which is the slave’s processing time, not the network. You can also have multiple simultaneous TCP connections to a single device, polling different register ranges in parallel.

For high-poll-rate applications (motion control, fast process loops), TCP wins decisively. For slow polling of dozens of meters every few seconds, both work fine.

When to Use RTU

Existing RS-485 infrastructure. If the cable is already pulled and the devices already addressed, don’t rewire to TCP for the sake of it.
Long runs, few devices. A single twisted pair to four meters 800 m away is cheap and reliable.
Cheap field devices. A $40 power meter is RTU-only; a TCP version is $120. Times forty meters, the math chooses for you.
Hazardous areas. Intrinsically safe RS-485 is well-understood; Ethernet in Class I Div 1 areas is more involved.
Air-gapped requirement. RS-485 has no IP stack to attack. Some safety-critical loops are easier to certify when there’s literally no Ethernet.

When to Use TCP

Greenfield installations. Cable is going in anyway — pulling Cat6 to each device is barely more expensive than running an RS-485 daisy chain and gives you a far better network.
High poll rates or many registers. Anything faster than ~250 ms updates is painful on RTU.
Distributed monitoring. Devices in multiple buildings, plant-wide SCADA, or anything that needs to cross a router.
Multiple masters. RTU is master-slave with a single master per bus. TCP cheerfully supports several SCADA clients hitting the same device at once.
Diagnostic visibility. Wireshark on a mirror port will show you every transaction. The RS-485 equivalent is a serial sniffer that costs more and tells you less.

The Hybrid That Most Plants Actually Run

Almost no real facility is pure one or the other. A typical layout looks like:

Backbone: Modbus TCP on a managed switch fabric, with the SCADA server and the main PLCs.
Field devices: Modbus RTU on RS-485 segments running off gateway devices (e.g., HMS Anybus, Moxa MGate) that present each RTU slave as a unit ID behind a single TCP IP address.
Modern field devices: Bought new with TCP and connected directly to the switch fabric.

This is the right answer because it lets you keep working RTU loops in place while new gear comes in over Ethernet. Don’t rip out a working RS-485 line; bridge it.

Things That Bite You No Matter Which You Pick

Endianness. A 32-bit float spans two consecutive Modbus registers, and devices disagree on byte order (ABCD, CDAB, BADC, DCBA). Always check both byte and word order against the device datasheet. “It almost works” usually means you have one of the two swapped.
Off-by-one register addressing. Some clients use 0-based offsets, some use 1-based register numbers. The “first holding register” can be 0, 1, 40000, or 40001 depending on the documentation. Always verify with a known register before assuming.
Slave timeouts. A slow device that takes 800 ms to respond will time out a master configured for 500 ms. Set timeouts to 2–3× the slowest device on the bus, not the average.

Quick Decision Cheat Sheet

Situation	Pick
New plant, building from scratch	TCP
Adding 3 meters to an existing RS-485 loop	RTU
Need <100 ms polling	TCP
40 cheap meters spread across a long building	RTU
Multiple SCADA systems reading same device	TCP
One PLC, ten devices, 1-second update is fine	Either — pick by device cost

Modbus is a 1979 protocol that has somehow won. Treat both flavors as transports for the same idea, choose them by your wiring and timing constraints, and you’ll avoid most of the trouble new integrators run into.