Modbus TCP vs. Modbus RTU: Which Protocol Should You Choose for Your Industrial Installation?
Modbus remains the standard protocol in industrial automation. However, depending on whether your equipment communicates via RS-485 or Ethernet, you will use Modbus RTU or Modbus TCP—two variants, each with its own limitations and advantages.
The Same Mechanics, Two Physical Formats
Modbus is a master/slave protocol released in 1979 by Modicon. It defines how a controller (the master) communicates with devices (the slaves) to read or write registers.
- Modbus RTU — operates over an RS-485 or RS-232 serial connection. Data is transmitted in compact binary format, addressed by a slave ID (1–247). Typical baud rate: 9,600 to 115,200 bps.
- Modbus TCP — encapsulates Modbus frames in TCP/IP packets over Ethernet. Standard port: 502. Data rate limited only by the Ethernet network.
Both protocols share the same data structure (coils, input registers, hold registers). A Modbus RTU ↔ TCP gateway is all you need to connect your legacy RS485 sensors to an Ethernet SCADA system.
Modbus RTU: The Robustness of Serial Communication
Benefits
- Minimal wiring: A daisy-chained RS485 bus can connect up to 32 devices over a distance of 1,200 m using a single-pair shielded cable.
- Predictable latency: no TCP stack, no fragmentation. Timing is deterministic.
- Wide range of devices: PLCs, drives, energy meters, pressure transmitters—virtually all legacy OT systems use RTU.
Disadvantages
- Linear topology required (bus). No star network without a repeater.
- Limited data rate: at 19,200 bps, a register transaction takes ~5 ms. With 20 slaves and continuous polling, latency can exceed 200 ms.
- Physical cabling is vulnerable in noisy environments without properly placed termination resistors.
Modbus TCP: IP Flexibility
Benefits
- High throughput: 100 Mbps or 1 Gbps—bulk reads are nearly instantaneous.
- Flexible architecture: Ethernet switches support star, ring, or tree topologies.
- Multi-master: Multiple clients can query the same TCP slaves simultaneously.
- Traceability: IP frames can be easily captured with Wireshark for debugging.
Disadvantages
- Network infrastructure required: an industrial switch, one IP address per device.
- Variable latency: TCP retransmissions in the event of an error introduce non-deterministic latency—which is problematic for real-time control loops.
- Security: Port 502 is often exposed on OT VLANs without authentication. It must be isolated.
Comparison Chart
| Criterion | Modbus RTU | Modbus TCP |
|---|---|---|
| Physical medium | RS485 / RS232 | Ethernet |
| Topology | Linear bus | Star, ring, tree |
| Typical baud rate | 9,600–115,200 bps | 100 Mbps – 1 Gbps |
| Number of slaves | Up to 247 | Unlimited (IP network) |
| Latency | Deterministic | Variable (TCP/IP) |
| Infrastructure | RS485 cable | Switch + Ethernet cabling |
| Typical use | Sensors, legacy PLCs | SCADA, modern equipment |
How Eziwan Handles Both
The Eziwan Gateway router features a native RS485 port that supports both Modbus RTU slave and master modes. The Eziwan platform includes a Modbus RTU → MQTT gateway and a cloud-based Modbus TCP bridge, enabling you to:
- Collect RS485/Modbus RTU data from your field sensors every N seconds.
- Transmit the values via MQTT or HTTP to your SCADA system, InfluxDB, or Grafana.
- Remotely access your serial devices via Modbus TCP through the VPN tunnel—your SCADA system sees a TCP device, and the gateway translates it to RTU.
# Example of a Modbus Configuration in Eziwan
modbus:
interface: RS485_1
baudrate: 19200
parity: even
polling_interval: 10s
registers:
- id: 0x0001
name: temperature_process
unit: 3
type: holding
scale: 0.1
- id: 0x0002
name: pression_bar
unit: 3
type: holding
scale: 0.01
RS485 Wiring for Modbus RTU: The Most Common Mistakes
RS-485 is robust, but improper implementation can cause intermittent communication errors that are difficult to diagnose. Common pitfalls include:
1. Missing termination resistors. The RS485 bus must be terminated at both ends with 120 Ω resistors. Without termination, signal reflections cause corrupted frames—especially at high baud rates (> 9600 bps).
2. Incorrect bias. An empty RS485 bus (all slaves silent) must have a defined voltage level (A+ > A-). Add bias resistors of 560 Ω–1 kΩ if your master does not include them.
3. Incorrect topology. Modbus RTU requires a bus topology (daisy chain). Stubs cause signal reflections. Each slave must be connected to the main line with the shortest possible stub (< 1 m).
4. Ground Loops. In RS485, shield grounding and the signal return (common ground) must be carefully managed. A shield connected at both ends creates a ground loop and parasitic currents—connect it only on the PLC side.
5. Inconsistent baud rate/parity. All slaves on an RTU bus must share exactly the same baud rate, parity, and number of stop bits. 19200-8-E-1 is the most common configuration in the French industry.
Modbus TCP Security: The Blind Spot
Modbus TCP has no native authentication mechanism. Any network client that reaches port 502 can read and write registers. In an isolated OT network, this is acceptable. However, as soon as a cloud connection is involved, security measures are required.
The Modbus TCP port 502 must be inaccessible from the Internet. All external access must go through a VPN tunnel. Thousands of Modbus devices are scanned and attacked every day (Shodan.io lists more than 200,000 publicly accessible port 502s worldwide).
Recommended Security Measures:
- OT firewall: Allow port 502 only for explicitly listed IP addresses (whitelist)
- VPN tunnel: All remote access to the Modbus bus must be via VPN (OpenVPN or IPSec)
- Dedicated VLAN: Isolate the Modbus TCP subnet from the rest of the LAN
- Logging: Log TCP connections and disconnections on port 502
When should you choose one over the other?
Choose Modbus RTU if:
- Your devices have only an RS485 or RS232 port
- Your system is already in place and you want to integrate it without rewiring
- You have fewer than 32 devices on the same segment
- Ethernet cabling is not feasible in the cabinet (space constraints, cost)
Choose Modbus TCP if:
- You are designing a new installation with an Ethernet infrastructure
- You have more than 32 devices or distances greater than 1,200 m
- You need multi-master capability (multiple simultaneous SCADA clients)
- Cloud integration is planned from the design phase
In practice, most existing industrial systems use RTU over RS485. Eziwan lets you connect them to the cloud without touching the existing wiring—the gateway transparently translates Modbus RTU to MQTT/HTTPS.
Architecture Example: From the RS485 Bus to the Cloud Dashboard
Here is the complete chain for a typical Modbus monitoring system, as deployed in electrical substations, pumping stations, or workshops:
Modbus RTU sensors and devices → RS485 bus (2-wire, up to 1,200 m) → Eziwan gateway (RTU↔TCP bridge + MQTT conversion) → 4G connectivity with M2M SIM → outbound VPN tunnel → Eziwan cloud → dashboards, threshold alerts, and remote access.
The key point: Modbus never leaves the local network. The gateway confines it to the site and transmits the converted values through an encrypted tunnel—which simultaneously resolves both the protocol’s security issue (no native authentication) and the distance issue.
Sizing the Polling: Frequency, Volumes, and 4G Data
The polling frequency determines both the responsiveness of the monitoring system and data consumption. Order-of-magnitude guidelines for sizing the system:
| Use Case | Polling Frequency | Estimated Monthly Data Volume |
|---|---|---|
| Remote meter reading (meter readings) | 1 to 4 readings per day | < 5 MB |
| Energy monitoring (voltage, current, power) | Every 10 to 60 seconds | 5 to 30 MB |
| Near-real-time machine monitoring | Every 1 to 5 seconds | 30 to 150 MB |
Two common pitfalls: overly aggressive polling on a slow RTU bus (9,600 baud) causes a cascade of timeouts—space out the requests or increase the bus speed; and on 4G, set Modbus TCP timeouts to at least 3,000 ms to account for the variable latency of the cellular network.
Migrating from RTU to TCP: Is It Necessary?
Not in most cases. The tendency to think that “modernization = switching everything to Ethernet” leads to costly rewiring for only marginal gains: a healthy RS485 bus transmits the same Modbus data perfectly reliably. The right strategy is to keep the field devices as RTUs and perform the conversion at the gateway—which exposes the serial slaves via Modbus TCP to the SCADA system and publishes data to the cloud via MQTT. Physical migration to TCP should only occur during a pre-planned control cabinet overhaul or when the number of devices exceeds the bus’s capacity limits.
FAQ
What is the role of a Modbus gateway? It connects the serial world to the IP world: on the field side, it queries Modbus RTU slaves over RS-485; on the network side, it exposes them via Modbus TCP and publishes measurements to the cloud via MQTT. It also provides local buffering during network outages and transport encryption—two features that the Modbus protocol does not offer.
Can Modbus RTU registers be read from a SCADA system that only supports TCP? Yes—that is precisely the role of a Modbus RTU↔TCP gateway. The SCADA system connects via Modbus TCP (port 502) to the gateway, which translates the requests into Modbus RTU on the RS485 bus. The Eziwan Gateway includes this functionality natively: from your cloud-based SCADA system, RTU slaves are seen as TCP slaves.
What is the maximum RS485 bus length for Modbus RTU? The RS485 specification allows for up to 1,200 m at 9,600 bps using appropriate cable (Belden 9842 or equivalent, 120 Ω impedance). At 115,200 bps, the maximum length is reduced to approximately 200–300 m. Beyond that, RS485 repeaters can be used to extend the bus.
How many slaves can be addressed on a Modbus RTU bus? The Modbus RTU protocol can address up to 247 slaves (addresses 1 through 247; address 0 is reserved for broadcasts). In practice, the physical limitations of RS-485 (32 “unit loads” per segment) require the use of repeaters when there are more than 32 devices on a single physical segment.
What is the difference between Modbus RTU and Modbus ASCII? Modbus ASCII is an older variant that encodes frames using hexadecimal ASCII characters (readable by a serial terminal). Modbus RTU uses a compact, more efficient binary encoding. Modbus ASCII is virtually obsolete—if your equipment supports both, choose RTU.
Does Modbus TCP work over Wi-Fi or 4G? Yes. Modbus TCP is standard TCP/IP and can be used on any IP network—Ethernet, Wi-Fi, or 4G LTE. On 4G, variable latency (20–100 ms) can cause timeouts with conservative configurations. Increase the Modbus TCP timeout to at least 3000 ms (vs. 500 ms on a LAN) for 4G connections.
Further Reading
- Blog: MQTT, RS485, Modbus — Industrial IoT Protocols Explained
- Blog: IIoT Predictive Maintenance — From Sensor Data to Alerts
- Blog: Modbus, MQTT, OPC-UA — A Comprehensive Comparison of Industrial Protocols
- Docs: RS485 / Modbus RTU Configuration on the Eziwan Gateway
- Blog: Secure Remote Access to PLCs and SCADA
Need advice on the Modbus architecture of your system? Contact our engineers — free diagnostic.
Additional Resources
- Modbus RTU to the Cloud — Connect your RS-485 Modbus RTU devices to a cloud platform
- Modbus TCP to the Cloud — Monitor your Modbus TCP controllers from the cloud
- Modbus RTU to MQTT — convert your Modbus RTU frames into MQTT messages
- Industrial Protocols — comprehensive comparison of field and cloud protocols
- RS-485 Modbus 4G — connect an RS-485 Modbus bus via a 4G LTE network
- Guide: Modbus to the Cloud — a step-by-step guide to uploading your Modbus data