Modbus RTU vs Modbus TCP: how to decide without falling for myths

The automation engineer closing the specification of a new panel usually reaches this point with two voices in their head. On one side, the field veteran says "Ethernet in an industrial panel does not work, it keeps dropping, it picks up noise, latency is unpredictable". On the other, the modern integrator says "RS-485 belongs to the 80s, nobody uses it anymore, every new SCADA is TCP". Both exaggerate. Modbus RTU and Modbus TCP coexist in millions of plants in 2026, each solving different problems, and the wrong choice costs cable, switches and commissioning hours. This post compares both protocols in what matters for the decision: physical layer, frame, latency, security, cost, application scenarios and how to live with both through a gateway. At the end, the honest role of the AEM-60DC8 in this decision.

Quick history — where each came from

Modbus RTU was born in 1979 at Modicon, part of the then newly created Modicon 084 and 184 PLC family. The scene was a factory floor with expensive PLCs and simple field instruments; the protocol had to run over cheap serial (initially RS-232, then RS-485 once Modicon published the physical specification) and had to be simple enough for an 8-bit microcontroller of the time to process in an interrupt. The result was a master-slave, binary protocol with CRC-16 and a compact function table. Modicon released the specification as open in 2004; it is now maintained by the Modbus Organization.

Modbus TCP appeared twenty years later, in 1999, specified by Schneider Electric (which had acquired Modicon in 1996) as an adaptation of the same application protocol running over TCP/IP, port 502. The motivation was clear: plants were connecting to corporate Ethernet networks and SCADA systems were migrating to networked PCs. Rather than designing a new protocol, Schneider preserved the RTU semantics (same functions, same codes, same register structure) and only swapped the transport. That is why the learning curve between RTU and TCP is small once you know either one.

There is also a third variant, Modbus ASCII, the same application protocol over serial in text form. It is rare in the field today, used mostly for diagnostics or in legacy systems with slow analog modems. This comparison focuses on RTU and TCP, the two that matter in greenfield projects.

Physical layer — RS-485 vs Ethernet

This is where myths come out the most. RS-485 is differential, two wires (plus reference ground), up to 32 unit loads per segment (1200 m at low speed), good common-mode noise rejection and transceiver cost in cents. Industrial Ethernet is twisted pair category 5e or 6, also differential, 100 m per run between node and switch, requires managed switches for any serious network and has a per-port cost in single-digit US dollars.

Aspect	RS-485 (RTU)	Ethernet (TCP)
Topology	Bus (daisy-chain)	Star through a switch
Distance	Up to 1200 m per segment at 9600 bps	100 m per run, repeated by switch
Nodes per segment	32 unit loads (up to 256 with repeater)	Limited only by switch
Typical cable	Shielded twisted pair 24 AWG	Cat 5e / Cat 6
EMC immunity	High (differential, low impedance)	High with shielded cable and proper grounding
Per-node cost	US$ 0.50 transceiver, US$ 1 connector	Industrial switch port US$ 30 to US$ 80
Configuration complexity	Address, baud, parity	IP, mask, gateway, VLAN, switch

In practice, RS-485 still wins in small panels and point-to-point links in EMC-heavy environments (medium-voltage substations, machine rooms with VFDs). Ethernet wins in large plants with many distributed devices and when network infrastructure already exists for other purposes (video, IT, management).

Frame and overhead — how many bytes per read

Here RTU is leaner, and that matters on slow links. A typical Modbus RTU frame reading 10 holding registers is:

Field	Bytes
Slave address	1
Function code (0x03)	1
Starting address	2
Quantity of registers	2
CRC-16	2
Request total	8 bytes
Response: addr+func+bytecount+data (20)+CRC	25 bytes
Total round-trip	33 bytes

At 9600 bps with 8N1 that is about 34 ms of transmission time alone, plus the slave processing time (typically 2 to 10 ms) and the mandatory inter-frame silence of 3.5 characters (3.6 ms at 9600).

The same request in Modbus TCP carries an extra header called MBAP (Modbus Application Protocol) of 7 bytes: transaction ID (2), protocol ID (2), length (2), unit ID (1). There is no CRC because TCP already provides integrity at the transport layer.

Field	Bytes
MBAP header	7
Function + address + quantity	5
Request total	12 bytes
Response: MBAP (7) + func (1) + bytecount (1) + data (20)	29 bytes
Total round-trip at Modbus layer	41 bytes

On top of that comes the TCP/IP overhead: IP header (20), TCP header (20), Ethernet (18), adding ~58 bytes per packet. At 100 Mbps that is still microseconds, but in massive polling (1000 nodes, 10 Hz) it starts to matter for the switch.

Polling efficiency: in RTU at 19200 bps, a cyclic poll of 8 slaves reading 32 registers each completes in around 250 ms (4 Hz). In TCP over a 100 Mbps LAN, the same 8 nodes can be read in parallel (multiple simultaneous connections) in under 50 ms. RTU is denser in bytes; TCP is more parallel in transactions.

Latency and determinism

RTU is deterministic by construction: master speaks, slave answers, nobody else talks. Polling time is predictable within a small tolerance (jitter variation around 1 ms). For short-cycle control loops (50 to 200 ms) in an isolated panel, RTU delivers consistent latency.

TCP is probabilistic. Typical latency in a dedicated industrial LAN sits at 1–5 ms, but in a network shared with video, backup or misconfigured routing, it can jump to tens or hundreds of milliseconds without warning. Where TCP wins is in large networks with multiple masters reading the same device (impossible in RTU without token-passing, which nobody implemented in Modbus in practice), or when devices are physically distributed across buildings and Ethernet is the natural path.

Rule of thumb: for control (PID, interlock, protection), RTU in an isolated panel tends to deliver more predictable latency. For supervision and historization (SCADA, MES, BI), TCP delivers more flexibility. Most projects use both.

Security — both were born naked

There is no default winner here: neither Modbus RTU nor Modbus TCP carries authentication, encryption or integrity control at the application layer. Anyone with physical access to the bus (RTU) or the network (TCP) can read every register and write to any one that is exposed.

There is an extension called Modbus/TCP Security (published in 2018) that wraps traffic in TLS 1.2 or newer on port 802, with mutual X.509 authentication. It is rare in the field — conservative estimates put fewer than 1% of Modbus/TCP installations running TLS in 2026. The reason is practical: most field devices still lack TLS firmware, and legacy SCADA platforms do not speak Modbus/TCP Security.

The real defense today is layered:

• RTU: physical isolation. Closed panel, cabling inside the enclosure, RS-485 not exposed outside the controlled zone. If the attacker is already inside the cabinet, the problem is bigger than Modbus.
• TCP: network segmentation. Dedicated VLAN for OT, firewall between OT and IT, conduits in the ISA/IEC 62443 model, whitelist of IPs per device, anomaly monitoring. Ideally Modbus/TCP Security when the device supports it.

The AEM-60DC8 only speaks Modbus RTU. The defense, therefore, comes from topology: the device sits in the cabinet next to the DC bus it monitors, and the gateway that exposes data to the corporate network is what implements authentication and isolation.

Total cost — it is not just the device price

The honest tally includes cable, connectors, switches, training and commissioning time. Simplified example of a panel with 6 devices:

Item	Modbus RTU	Modbus TCP
Cable (twisted pair vs Cat 5e)	80 m × US$ 0.80 = US$ 64	6 runs × 15 m × US$ 1.20 = US$ 108
Connectors	12 × US$ 1 = US$ 12	12 × US$ 2 = US$ 24
Switch / converter	1 USB-RS485 converter US$ 40	8-port industrial switch US$ 360
Training (engineer-hours)	4 h (address, baud)	12 h (IP, VLAN, switch)
Typical commissioning time	2 to 4 h	4 to 8 h
Estimated hardware total	~US$ 116	~US$ 492

This example is simplified and excludes cable-pulling labor, which is similar in both cases. The gap is clear: in a small isolated panel, RTU is dramatically cheaper. In a large plant already wired with Ethernet for other purposes, the marginal cost of TCP is lower because infrastructure already exists.

When to use each — decision matrix

The decision is rarely binary. The matrix below is what we apply in real projects:

Scenario	RTU	TCP	Why
Isolated solar panel, 4 to 8 devices in same cabinet	Recommended	Overkill	Cost, simplicity, EMC
Telecom site in a tower, single cabinet	Recommended	Overkill	Same reasons, plus harsh environment
138 kV substation, several cabinets 50 m apart	Hybrid	Recommended for SCADA	EMC favors local RTU + gateway outward
Connected factory (Industry 4.0) with MES/historian	In local islands	Recommended on backbone	TCP is the natural path to SCADA
Commercial building with BAS	Possible	Recommended	Reuses existing Ethernet
Machine room with VFDs	Recommended	Careful with noise	Severe EMC, shielded differential pair
Data center monitoring DC bus	Recommended in rack	TCP to aggregate racks	RTU inside the rack, TCP between racks

Practical rule: inside the cabinet and in isolated panels, RTU. Between panels and up to the SCADA, TCP. The junction is the gateway, described next.

Coexistence — gateway as junction point

In most real projects, RTU and TCP coexist. The junction is a Modbus RTU↔TCP gateway, which behaves as RTU master on one side and TCP slave on the other (or vice versa, depending on topology). Common brands: Moxa MGate, HMS Anybus, Advantech EKI, Comtrol DeviceMaster.

Simplified example of a hybrid architecture using AEM-60DC8:

[ AEM-60DC8 #1 ]──┐
                  ├── RS-485 (Modbus RTU, 19200 8N1) ──> [ Gateway ] ── Ethernet ──> [ SCADA TCP ]
[ AEM-60DC8 #2 ]──┤
[ AEM-60DC8 #3 ]──┘

The gateway typically maps each RTU slave to a TCP unit ID. The SCADA sees three "TCP devices" on the same IP, with unit IDs 1, 2 and 3, and the gateway resolves the RS-485 polling internally. Care points when specifying a gateway:

• Polling buffer: the gateway must keep a background cache and respond to TCP from cache, rather than blocking the TCP request waiting for RTU. Without a cache, SCADA response time is tied to the slowest RTU poll.
• Independent timeouts: RTU timeout configured for the worst slave; TCP timeout configured for the SCADA. The two decoupled.
• Exception mapping: an RTU error (slave offline, CRC, timeout) must turn into a correct Modbus TCP exception, not silence.
• Simultaneous TCP connection limit: cheap gateways support 2 or 4 connections; in serious projects, specify 16 or more.

The AEM-60DC8 in this decision — RTU only, and why

To be blunt: the AEM-60DC8 only speaks Modbus RTU over RS-485. It has no Ethernet port. This design choice comes from three drivers.

When this is an advantage:

• Enclosed industrial panel, where the monitor sits next to the DC bus it watches and the RS-485 cable never leaves the cabinet. EMC, cost and simplicity favor RTU.
• Secure by Design scenario through physical isolation: no network port, no IP attack surface, no TCP/IP stack firmware to audit. The security perimeter is the panel itself.
• Long lifespan: RS-485 has been a stable technology since 1983, with no "deprecate TLS 1.2 by 2030" obsolescence cycle. The device installed today speaks the same protocol 20 years from now.

When this is a limitation:

• Project that demands direct TCP polling from the SCADA, with no extra hardware. The AEM-60DC8 does not fit without a gateway.
• Plant already 100% Ethernet, with a "no new serial" policy. Standardization arguments beat technical ones.
• When the customer wants multiple masters reading the same device simultaneously. RTU is single-master single-slave; the gateway only partially helps.

How we solve it in projects: the recommended path is the AEM-60DC8 speaking RTU inside the cabinet, connected to a commercial industrial RTU↔TCP gateway. The gateway exposes the device as Modbus/TCP to the SCADA and transparently maps the 147 holding registers of firmware v1.03. This arrangement delivers the best of both worlds: EMC and simplicity of RTU inside the panel, flexibility of TCP outside it.

In v1.03 the AEM-60DC8 supports 4800, 9600, 19200, 38400, 57600 and 115200 bps on RS-485, with Modbus address 1 to 247. Typical project speed in industrial panels is 19200 or 38400, which comfortably covers useful polling for up to 8 devices on the same bus.

FAQ

1. Can I bridge Modbus RTU to Modbus TCP with software only, without a dedicated gateway? Yes, software bridges exist (modpoll, libmodbus, NodeRED with the modbus-serial node) running on a PC or Raspberry Pi with a USB-RS485 adapter. It works in the lab and in small projects. In 24/7 production we do not recommend it: desktop PCs have low MTBF, USB has unpredictable timing and any OS reboot brings the SCADA down. In serious projects, use a dedicated industrial gateway.

2. Is Modbus TCP faster than Modbus RTU in every case? No. On a dedicated LAN with few devices, TCP delivers lower per-transaction latency (1–5 ms vs 10–30 ms). But in a small panel with 4 devices at 38400 bps, RTU already delivers 10 Hz polling without a switch or IP plan. The right question is "what latency does the application require", not "which protocol is faster".

3. Why does the AEM-60DC8 lack Ethernet if most plants are TCP? By design choice: focus on enclosed industrial panels where cost, simplicity, EMC and the absence of an IP attack surface outweigh TCP flexibility. For TCP SCADA integration, the path is a gateway. This choice does not close the roadmap; it is the position in v1.03.

4. Is Modbus/TCP Security (TLS) worth implementing today? It is worth it in specific scenarios: new devices, new SCADA, corporate policy mandating OT encryption. In the field it is still a minority — most of the installed base does not support it. For most projects, the real defense remains VLAN, firewall, ISA/IEC 62443 segmentation and physical isolation, not TLS at the Modbus application layer.

5. How do I size the RS-485 network when adding AEM-60DC8 to an existing bus? Count unit loads (each AEM-60DC8 is 1 UL on receive, 0 idle), confirm bus biasing (120 Ω termination at both ends, master bias), pick a baud rate common to every slave and assign a unique address. At 19200 bps with up to 500 m of cable, up to 16 devices coexist without issues; beyond that, drop to 9600 or split into two segments with a repeater.