Modbus TCP vs Modbus RTU: The Old Protocol Still Running Half Your Machines

Modbus is a simple, open serial and Ethernet protocol that lets a controller read and write numbered data locations (registers) inside industrial devices, and its two dominant variants are Modbus RTU (serial, over RS-485) and Modbus TCP (the same data model wrapped in Ethernet/IP packets). Released by Modicon in 1979, it predates most of the equipment on your floor and yet it is still, quietly, how a huge share of PLCs, drives, meters, and sensors talk. It is not glamorous. It has no built-in security, no self-description, and a data model that feels antique. But it is free to implement, trivial to debug, and supported by almost everything, which is exactly why it remains the default first choice for cheap, reliable machine data capture.

The two variants at a glance

Both variants share an identical application layer. The same function codes and the same register map work whether the bytes travel over a copper twisted pair or an Ethernet switch. What differs is the transport underneath.

• Modbus RTU runs over serial RS-485 (occasionally RS-232). It is a master/slave bus: one master polls, up to 247 slave devices answer, and only one device talks at a time. Framing is compact binary with a 16-bit CRC for error checking. Typical baud rates are 9600 or 19200 bits per second, though the wiring supports faster.
• Modbus TCP runs over standard Ethernet on TCP port 502. The CRC is dropped (TCP already guarantees delivery) and replaced by a short MBAP header. Multiple clients can query the same server at once, and you get the whole networking toolbox: switches, routers, VLANs, and long cable runs.

In short: RTU is cheap, rugged, and slow across a shared wire; TCP is faster, concurrent, and rides your existing plant network but needs an Ethernet-capable device or a gateway.

Registers: the data model you must understand

Modbus does not send named tags. It sends the contents of numbered locations, and there are exactly four tables:

• Coils (read/write single bits) for outputs like a relay or a run command.
• Discrete inputs (read-only bits) for things like a limit switch or a fault flag.
• Input registers (read-only 16-bit words) for measured values like a temperature or a counter.
• Holding registers (read/write 16-bit words) for setpoints, configuration, and most of what you will actually poll.

Because a register is only 16 bits, a value larger than 65535 (a 32-bit production counter, a floating point speed) is split across two consecutive registers. Here is the classic trap: byte and word order are not standardized. A 32-bit part count of 1,000,000 might arrive as word pair (15, 16960) in one device and (16960, 15) in another. If your counter reads garbage, swap the word order before you blame the wiring. Always confirm the register map and endianness from the device manual, not from a guess.

A worked example: reading a part counter for OEE

Say you want the good-count from a press to feed an availability and performance calculation. The manual says the running total sits in holding registers 40001 and 40002 as a 32-bit unsigned integer, high word first.

1. You issue function code 03 (read holding registers), start address 0, quantity 2. (Address 40001 maps to protocol offset 0; the 4xxxx numbering is a human convention, the wire uses zero-based offsets.)
2. The device returns two words: 0x000F and 0x4240.
3. Combine them: 0x000F4240 = 1,000,000 parts.
4. Poll again 60 seconds later and you read 1,000,450. The delta is 450 parts per minute.

Feed that rate against the machine's ideal cycle time and you have live performance; add planned time and stops and you have overall equipment effectiveness. That is the entire magic. A two-register read, once a second, turns a silent press into a data source, and it costs nothing but a poll. Pair the same feed with throughput and scrap rate tracking and you can see losses the shift report never captured.

RTU vs TCP: how to choose

The decision usually comes down to what the device already supports and how far the data has to travel.

• Pick RTU when the device only has a serial port, when runs are within a machine or cell, and when you are chaining several cheap meters on one bus. RS-485 tolerates electrical noise well and needs no switch.
• Pick TCP when the device has an Ethernet port, when you need multiple systems reading the same data, or when distance and cable management on a serial bus become painful. Concurrency alone is often the deciding factor.
• Use a gateway when you have legacy RTU devices but want them on the network. A Modbus RTU-to-TCP gateway is a small, inexpensive box that bridges the two, and it lets you modernize data collection without touching the machine.

Neither variant is a control system. Modbus is a data-exchange protocol, not SCADA and not a safety layer, so keep it off any path that requires guaranteed timing or security.

The catch: polling budgets and no security

RTU is half-duplex on a shared wire, so poll timing matters. If one master polls 20 slaves at 9600 baud and each transaction (query plus response plus turnaround) takes roughly 30 to 50 milliseconds, a full sweep of all 20 devices takes about one second. Add more devices or slower baud and your data ages. When sub-second resolution matters, split the load across multiple serial ports or move the busy devices to TCP.

Security is the other honest caveat. Classic Modbus has no authentication and no encryption; anyone on the wire can read or write any register. Keep it on isolated OT networks or VLANs, never expose port 502 to the internet, and treat write access as privileged. This same data foundation feeds reliability metrics like MTBF and MTTR and supports a move toward condition-based maintenance, but only if the pipe carrying it is designed with those limits in mind.

Where Fabrico fits

Fabrico is the real-time data foundation that turns those raw Modbus reads into decisions. It captures live production and OEE from the machine data you already have, whether the values arrive over RTU, TCP, or a gateway in between. When a machine has no PLC or exposes nothing useful over the wire, Fabrico can read the state visually with computer vision instead, so you are not blocked by an old line. On top of the monitoring sits a field-ready CMMS for work orders, assets, preventive scheduling, and spare parts, which means the same signal that measures a stop can trigger the response to it. Fabrico is EU-built with EU data residency, a real consideration when your production data leaves the plant floor. For the maintenance side of that loop, see how it supports a shift from reactive to proactive maintenance.

Frequently Asked Questions

Is Modbus obsolete?

No. It is old (1979) and technically limited, but it is open, free to implement, and supported by an enormous installed base of PLCs, drives, and meters. For straightforward register reads, which is most machine-monitoring work, newer protocols add complexity without a payoff. Modbus stays the pragmatic default precisely because it is everywhere and easy to debug.

Can Modbus RTU and Modbus TCP talk to each other?

Not directly, because they use different physical transports, but they share the same application layer, so a Modbus gateway translates between them cleanly. The register maps and function codes are identical on both sides, which is why bridging is a simple, inexpensive box rather than a full re-engineering job.

Why does my 32-bit value read wrong over Modbus?

Almost always word or byte order. A 32-bit number spans two 16-bit registers, and Modbus never standardized which word comes first, so a value can arrive high-word-first or low-word-first depending on the vendor. Check the device manual for the byte and word order, then swap in your parsing code. The wiring is rarely the culprit.

Old protocol, modern insight: if your machines already speak Modbus, you are one poll away from live OEE. Book a Fabrico demo to see your real machine data turned into decisions.