FoundryNet / Compare / Modbus RTU vs Modbus TCP
Protocol comparison

Modbus RTU vs Modbus TCP

Not really a protocol choice — a wiring choice. Same data model, same registers, entirely different operational life.

Get an API key All 14 adapters

Side by side

The comparison

Modbus RTUModbus TCP
SpecificationModicon Modbus, serial framing with CRCModicon Modbus, TCP encapsulation (Modbus-TCP)
First published19791979 (serial), 1999 (TCP)
TransportRS-485 / RS-232 multidrop, typically 9600–115200 baudTCP, port 502
Data modelIdentical to Modbus TCP — the same registers and coils, different framing.Flat 16-bit registers and single-bit coils. No types, no names, no metadata — a register is a number at an address.
DiscoveryNone, plus you also need the bus address, baud rate, parity and stop bits.None. You need the vendor's register map, usually a PDF.
SecurityNone. Physical access to the bus is full access.None in the base specification. Whatever the network gives you.
Polling or subscriptionPolling, strictly one master per bus, request/response with turnaround delays.Polling only. The client asks; the device answers.
Implementation complexityLow protocol complexity, real physical-layer complexity: termination, biasing, cable length, ground loops.Lowest of any protocol here. A working client is ~200 lines.
Typical industriesRetrofit and brownfield. Meters, VFDs, older instrumentation.Everything. Drives, meters, inverters, sensors, PLCs, BESS.
Forge supportAdapter shipped (same adapter as Modbus TCP).Adapter shipped. 14 OEM families mapped.

Where each one wins

Modbus RTU

Strength. Runs over two wires for a kilometre. No switch, no IP stack.

What it costs you. Bus-limited throughput. One slow device delays every other device on the loop.

Modbus RTU adapter →

Modbus TCP

Strength. Universal, trivial to implement, works on hardware from 1985.

What it costs you. Carries no semantics whatsoever. Scaling, byte order and register meaning all live outside the protocol.

Modbus TCP adapter →

The register map is identical, so anything that reads one reads the other after a framing change. What differs is everything around it: bus arbitration, cable runs, and the fact that one slow RTU device delays every other device on the loop while a slow TCP device delays only itself.


The Forge angle

Whichever one you pick, the output is the same

Forge is not an argument for a protocol. It is the layer that makes the choice stop mattering downstream: 16,908 curated mappings across 14 protocol adapters, resolving to 366 canonical fields with enforced units and physics bounds.

Two devices, two protocols, two vendors, two entirely different tag names — and one canonical field out. Both of these are real mappings from the corpus, not illustrations.

Modbus RTU — Schneider

# raw tag on the wire
{"ActivePower": 1450}
# normalized
{"active_power_kw": 1450}

Modbus TCP — Sungrow

# raw tag on the wire
{"Total active power": 1450}
# normalized
{"active_power_kw": 1450}

Same field: active_power_kw. Same unit contract, same physics bounds, same shape. Your query does not need to know which protocol the reading arrived on.

# Try it against both, with no key and no account
docker run -p 8000:8000 ghcr.io/foundrynet/forge-sandbox

Keep reading

The protocol you pick matters less than the schema underneath. The Machine Agent, weekly. Read it →
Get the thesis behind this infrastructure — The Machine Agent, weekly.