Modbus RTU vs Modbus TCP: how to choose for PLCs, meters and sensors

By Synacl · 9 min read · Published 16 Sep 2026

Almost every PLC, energy meter and VFD sold in the last twenty years speaks Modbus, and a good number of them speak it two ways: Modbus RTU over an RS485 pair, and Modbus TCP over an Ethernet port. The register map is usually identical. The choice between them is not about the protocol at all — it is about wiring, distance, how many devices share a link, and what you will be able to diagnose at 2am when a reading stops arriving. This guide compares the two the way the decision actually gets made on site, and shows what changes on the cloud side once you have picked.

The same protocol, two different envelopes

Modbus is a request/response protocol with four data areas — holding registers, input registers, coils and discrete inputs — and a handful of function codes for reading and writing them. That part does not change between RTU and TCP. What changes is the envelope around the request.

Modbus RTU puts the request on a serial line, usually RS485: a differential pair (A/B) plus a common reference, with a CRC on every frame and a slave address at the front. The bus is multi-drop — many devices share one pair of wires — and only one conversation can happen at a time, so the master polls each unit in turn and waits for silence between frames.

Modbus TCP wraps the same request in a TCP packet on port 502 and drops the CRC, because TCP already guarantees delivery and ordering. Each device is a network host with its own IP address, and the master opens a socket to it. The old slave address survives as the unit ID, which matters more than people expect — see the addressing section below.

Two consequences follow from that difference and drive almost everything else:

• RTU is shared and serial. Adding a device costs two wire terminations and nothing else, but every device you add takes a slice of the same bus time.
• TCP is switched and parallel. Each device costs a switch port and a cable run, but devices do not contend with each other for a bus.

Where each one wins

That last row is not a joke. On more than one site the deciding factor has been whether putting a meter on the corporate network needs a change request and a VLAN, or whether the electrician can simply land two wires in the panel that afternoon.

RTU is the right default for meters, sensors and small equipment sitting inside one panel or along one machine line, especially when there are more than a handful of them and they are all within a few hundred metres. It is cheap, it is electrically robust in noisy environments, and it does not involve anyone outside the panel.

TCP is the right default when the device already has an Ethernet port and is already on a network, when devices are scattered across a site that is wired for Ethernet anyway, when you need higher polling rates on a few high-value devices, or when the equipment is a PLC that is also being programmed over the same port.

The decision, in the order it actually gets made

1. Does the device offer a choice at all? Most do not. A DIN-rail energy meter is RS485 and that is that; a mid-range PLC is Ethernet and that is that. This settles the majority of installs before anything else is considered.
2. Is there already an RS485 bus in this panel? If yes and the new device speaks RTU, join it. One more device on an existing, working bus is the cheapest option available and stays cheap.
3. Is there already an Ethernet drop within reach, and will IT allow a device on it? If yes and the device speaks TCP, use it — you gain proper tooling for diagnosis and you skip the wiring discipline RS485 demands.
4. How fast do you actually need readings? This question eliminates far less than people think. A tank level or a power meter is genuinely useful at one reading per ten seconds, and RTU handles that for dozens of devices comfortably. If you need sub-second data from a servo drive, that is a TCP conversation — or more likely, a job for logic running at the edge rather than a cloud poll. See sizing your publish rate for how that maps to what you send upward.
5. Everything else equal, pick the one the site's existing staff can fix. If the maintenance team owns panels and not switches, RS485 will be repaired faster.

A fourth option worth naming: if you have a working RS485 bus and someone asks for the data over Ethernet, you do not have to convert anything. A gateway on the bus reads RTU and publishes upward over the network — which is exactly the arrangement described in ESP32 Modbus RTU to a cloud dashboard in 15 minutes. Serial-to-Ethernet converters that expose an RTU bus as Modbus TCP exist too, and they are the reason unit IDs matter so much on TCP.

What changes on the Synacl side

Both protocols are first-class on a Synacl gateway, and in both cases the gateway is the Modbus master: it polls devices on its own schedule and publishes readings upward. The platform-side model — devices, tags, rules, dashboards — is identical, so a device can be moved from one transport to the other without redoing any of it.

What differs is the connection form you fill in when adding the device.

The full field-by-field walkthroughs are in Connect an RS485 / Modbus RTU device and Connect a Modbus TCP device. Three behaviours are worth knowing before you commit to one:

Reads are per tag, one register at a time. Each tag you define maps to one 16-bit register, and each poll pass issues one Modbus transaction per tag. A device with twelve tags is twelve transactions, not one block read. On RTU that is twelve slices of bus time; on TCP it is twelve round trips inside one connection. It is the single biggest driver of how long a poll pass takes, on either transport.

RTU retries more than TCP. A failed RTU read is retried three times before the gateway gives up on it; a failed TCP read gets one retry. That asymmetry is deliberate — a serial frame lost to electrical noise is often fine on the next attempt, whereas a refused TCP connection will be refused again.

Modbus TCP connects per poll pass, then disconnects. The gateway opens the socket, reads every tag on that device, and closes it again, rather than holding a connection open between passes. Devices that only accept one or two concurrent Modbus clients therefore stay reachable even when a laptop or an HMI is also talking to them — but it does mean a device that is slow to accept connections will show up as slow on every pass.

The mistakes that cost the most time

Using the wrong port on TCP. Modbus TCP is port 502. The most expensive version of this mistake is copying a port from somewhere else on the platform — the gateway's MQTT broker port 8883 is a popular wrong answer — because it fails exactly like a dead device: ping succeeds, the device looks alive, and every poll times out. A ping proves the host is powered and on the network; it says nothing about whether a Modbus server is listening. Test the port itself from a machine on that LAN with nc -vz <ip> 502 before suspecting anything else. From gateway firmware 1.5.1 the device page names the address and port it tried, so you see TCP connect failed to 192.168.1.50:8883 instead of a bare connection error.

Leaving the unit ID at 1 on TCP. People assume the IP address is the whole address on Modbus TCP. It often is not: one IP commonly fronts several units — a serial-to-Ethernet converter bridging an RS485 bus, or a multi-meter panel — distinguished only by unit ID. Leave it at 1 only if the device genuinely is unit 1. Otherwise reads either time out or, worse, silently return a different unit's registers, which looks like a scaling bug and gets debugged as one for a day.

Mismatched serial framing on RTU. Baud rate, data bits, stop bits and parity must match the device exactly. Many meters ship at 9600 8-E-1, and Even parity is the field most often left at None. The symptom is uniform silence rather than garbled data, so it reads like a wiring fault.

RS485 bus hygiene. One pair, daisy-chained — not a star. Termination at both physical ends, not at every device. A common reference between nodes. These are the faults that appear only when the bus gets long or the VFD next to it starts switching.

Confusing publish interval with read interval. They are different numbers. The read interval is how often the gateway talks to the device, and it drives gateway-side alerts and macros. The publish interval is how often readings reach the cloud, and it is what counts against your plan's rate limit — the limits per tier are on the plans page. Polling a meter every second and publishing every minute is a perfectly normal configuration, and usually the right one.

Running both on one gateway

There is no need to standardise. A single gateway can hold RTU devices on its RS485 port and Modbus TCP devices on the LAN at the same time, each with its own poll cadence, and every device lands in the same dashboards and rules regardless of how it was read. In practice most sites end up mixed anyway: the meters and sensors on a bus, the PLC on Ethernet.

If you want to try it before committing to any wiring, the fastest path is an ESP32 and a browser: flash the gateway firmware from the web flasher, provision it over USB, and add one device of each kind. Nothing needs to be compiled and no broker needs to be run.

Next, if you are working with an RS485 sensor and want the full wiring-to-dashboard walkthrough with a worked register map, read ESP32 Modbus RTU to a cloud dashboard in 15 minutes.