SWTB_logo_rgb_color_mode-wPadding-500x240
Home›Resources›What is Modbus?
Device Protocols

What is Modbus?

Modbus is the most widely deployed industrial communication protocol in the world. Introduced in 1979, it still runs in the majority of PLCs, drives, meters, and sensors on plant floors today — and it is almost certainly the first protocol any OPC server or edge gateway will need to speak.

Last reviewed: 2026Reading time: ~10 minTopics: Modbus RTU, Modbus TCP, function codes, register map, OPC, TOP Server

What is Modbus?

Modbus is a serial communication protocol developed by Modicon in 1979 for use with its programmable logic controllers. Modicon released it publicly, and it became the de-facto standard for industrial device communication — not because it was the most sophisticated protocol, but because it was simple, free, and worked reliably over cheap serial hardware. Forty-five years later, it is still the first protocol listed in the documentation of most industrial devices.

Modbus is a request-response protocol built on a master-slave architecture. One device — the master — initiates every transaction. It sends a request to a slave device specifying what data it wants to read or write. The slave responds with either the requested data or an error code. Only the master can initiate communication; slaves never send data spontaneously. This simple model maps cleanly onto the way PLCs and field instruments were wired and operated when Modbus was designed.

Why Modbus is still everywhere. Modbus devices from the 1990s still run in production facilities today. The protocol has no licensing fees, no governing body that can change the specification without backward compatibility, and trivially simple implementation requirements — a Modbus RTU device can be implemented in a microcontroller with a few kilobytes of flash. When you ask why a new sensor released in 2025 supports Modbus: this is why. Every OPC server, SCADA system, and HMI already speaks it.

Modbus RTU, TCP, and ASCII

Modbus exists in three variants that use the same application-layer protocol but differ in their physical transport and framing:

Modbus RTU
Most common

The original and still dominant variant. Transmits data as compact binary over RS-232 or RS-485 serial connections. The "RTU" stands for Remote Terminal Unit — a legacy term from SCADA. Framing uses a CRC-16 checksum for error detection. Up to 247 devices can share a single RS-485 bus (one master, 246 slaves). The timing between bytes matters: a gap of more than 3.5 character times signals the end of a message frame.

Typical use: Field instruments, VFDs, flow meters, older PLCs, any device with a serial port.

Modbus TCP
Modern standard

Modbus RTU encapsulated inside TCP/IP packets, removing the serial bus constraint. Adds a 6-byte MBAP header (transaction ID, protocol ID, length, unit ID) that wraps the standard Modbus PDU. Runs on TCP port 502. Eliminates the 247-device limit and the RS-485 wiring constraints — any device with an Ethernet port can participate. Error detection is handled by TCP itself, so the CRC from RTU is dropped.

Typical use: Any Modbus-capable device with an Ethernet port; most modern PLCs, meters, and gateways.

Modbus ASCII
Legacy / diagnostic

The same register model and function codes as RTU, but data is encoded as human-readable ASCII hex characters rather than binary. Each byte becomes two ASCII characters, making messages twice as large. Uses LRC (Longitudinal Redundancy Check) instead of CRC. Slower and larger than RTU with no functional advantage, but easier to debug with a basic serial terminal. Rarely specified for new deployments.

Typical use: Legacy equipment from the 1980s–1990s; occasional diagnostic scenarios.

RTU vs TCP in practice: Most modern Modbus devices support both RTU (via a DB9 or terminal block serial port) and TCP (via Ethernet). When you have the choice, prefer TCP: it is easier to wire, supports longer distances via standard network infrastructure, allows multiple masters to poll simultaneously, and eliminates the bus timing issues that cause intermittent RTU communication failures. When you are connecting to legacy equipment with only a serial port, RTU is your only option — and a serial-to-Ethernet converter or an OPC server with a serial port handles it transparently.

The Modbus register map

Modbus organizes device data into four tables, each addressed separately. Understanding this model is essential for configuring any OPC server, SCADA system, or edge gateway to read Modbus data correctly.

Table / address rangeData typeAccessFunction codesTypical use
Coils (0x)
00001–09999
1-bit booleanRead / Write
FC01 read · FC05 write single · FC15 write multiple
Discrete outputs: relay states, actuator commands, valve open/close
Discrete Inputs (1x)
10001–19999
1-bit booleanRead only
FC02 read
Discrete inputs: limit switches, pushbuttons, digital sensor states
Input Registers (3x)
30001–39999
16-bit wordRead only
FC04 read
Analog inputs: sensor measurements, process values (temperature, pressure, flow)
Holding Registers (4x)
40001–49999
16-bit wordRead / Write
FC03 read · FC06 write single · FC16 write multiple
Configuration parameters, setpoints, calculated values, multi-register floats

The address offset problem. Modbus documentation uses two different addressing conventions that trip up almost every engineer at least once. The "data model" address (as shown above) uses 1-based numbering — Holding Register 1 is 40001. The "PDU address" actually transmitted on the wire is 0-based — the wire address for Holding Register 40001 is 0x0000. Some device manuals document the data model address; some document the PDU address. If your reads are consistently returning the wrong values or an "illegal data address" error, an off-by-one error in addressing is the first thing to check. TOP Server handles this transparently but knowing which convention a device's documentation uses prevents initial configuration errors.

How a Modbus transaction works

Every Modbus communication follows the same request-response pattern. The master sends a request frame to a slave, and the slave either responds with the requested data or an exception response explaining why it could not fulfill the request. Here is a complete Modbus TCP read transaction for 10 holding registers starting at address 0:

Modbus TCP transaction — read 10 holding registers (FC03)
Master →00 01 00 00 00 06 01 03 00 00 00 0AMBAP header (TxID, proto, length, unit) + FC03 + start addr + count
Slave →00 01 00 00 00 17 01 03 14 01 2C 00 87 02 8F ...Echo TxID + FC03 + byte count + 10 × 16-bit register values
Exception response (if error):
Slave →00 01 00 00 00 03 01 83 02FC 0x83 = FC03 | 0x80 (error flag) + exception code 02 = illegal address

A few important behaviors that affect how OPC servers and edge platforms interact with Modbus devices:

  • One transaction at a time. A Modbus RTU master must wait for the slave to respond (or time out) before sending the next request. This serializes communication and is why large register reads are more efficient than many small ones — fewer round trips.
  • Exception codes, not connection errors. Most Modbus errors are returned as exception responses — a valid frame with an error flag and a numeric exception code. The six standard codes (01 = illegal function, 02 = illegal address, 03 = illegal value, 04 = device failure, 05 = acknowledge, 06 = busy) are the first diagnostic step when data is not reading correctly.
  • No unsolicited data. Slaves never send data without being asked. Every value update requires a new request from the master. This is fundamentally different from OPC UA subscriptions or MQTT, which are event-driven. High-frequency polling of many Modbus devices can saturate the communication channel.

Modbus limitations in modern architectures

Modbus's simplicity is also its ceiling. The protocol was designed to solve a 1979 problem — getting data from a PLC over a serial cable — and it solved that problem well. It was never designed for the multi-site, AI-ready data architectures that modern industrial operations require.

⚠️
No data semantics
Register 40001 is just a 16-bit number. There is no way to encode a tag name, engineering unit, or quality status in the protocol. Every consumer needs an out-of-band mapping to understand what each register represents.
⚠️
No security
Modbus has no authentication, no encryption, and no access control. Any master on the network can read or write any register on any slave. Exposure of Modbus devices to untrusted networks is a significant OT security risk.
⚠️
Polling only
Data is only available when the master asks for it. There is no subscription or event-driven notification mechanism. High-frequency polling of large register sets consumes significant bandwidth and CPU on constrained field devices.
⚠️
Limited data types
The native data model supports only 16-bit integers and single-bit booleans. 32-bit floats, 32-bit integers, and 64-bit values require spanning two or four registers — and there is no standard for byte order (endianness), so every vendor implements it differently.
✅
OPC Server bridges the semantics gap
An OPC server like TOP Server reads raw Modbus registers and exposes them as named, typed OPC tags. The register-to-tag mapping, data type conversion, and byte order handling are configured once in the server — all downstream clients see structured data, not register addresses.
✅
Edge platform adds context and security
Platforms like N3uron subscribe to OPC tag data, apply ISA-95 contextualization, and publish structured data over encrypted MQTT. Modbus devices that have never heard of security publish their data into a modern, secure architecture without any changes to the device itself.

Modbus vs. other industrial protocols

FeatureModbus TCP/RTUEtherNet/IPOPC UAMQTT
Year introduced1979 (RTU) / 1999 (TCP)200120081999 (pub. 2013)
ArchitectureMaster-slave, pollingProducer-consumerClient-server + pub/subPub/sub via broker
Data semanticsNone — register numbers onlyCIP object modelRich — information model with types, units, metadataNone — payload is opaque
Built-in securityNoneNoneYes — X.509 + TLS + RBACTLS optional
Typical device baseAny PLC, sensor, meter, driveAllen-Bradley, OmronModern PLCs, OPC UA serversIIoT gateways, cloud platforms

Connecting Modbus devices with Software Toolbox

Device connectivity
TOP Server — Modbus Suite
TOP Server's Modbus Suite covers Modbus RTU, ASCII, and TCP in a single driver package. It handles all four register tables, all standard function codes, configurable byte and word order for 32-bit and 64-bit data spanning, automatic retry logic, connection failover, and simultaneous multi-master polling. One TOP Server installation can poll hundreds of Modbus devices simultaneously while exposing the complete tag address space to any number of OPC DA, OPC UA, or MQTT clients.
Edge platform
N3uron
N3uron connects to Modbus TCP and RTU devices directly (without requiring TOP Server as an intermediary), subscribes to register values via its built-in Modbus driver, and contextualizes raw register addresses into ISA-95-structured tag names with engineering units and quality metadata. N3uron then publishes the result as a Sparkplug B MQTT stream. It runs on ARM-based edge hardware alongside the field devices, making it the right choice for Linux-based edge gateway deployments where Windows is not available.
Serial-to-Ethernet
Serial device servers (third-party)
When Modbus RTU devices have only a serial port and the OPC server is on a different network segment, a serial device server (also called a terminal server or serial-to-Ethernet converter) creates a virtual COM port or accepts raw TCP connections. TOP Server supports both modes: it can communicate with virtual COM ports created by the serial device server's driver, or connect directly over TCP to the raw socket the device server exposes.

Frequently asked questions

What is the difference between Modbus RTU and Modbus TCP address 40001?+−

The address 40001 refers to the same Modbus data — Holding Register 1 — in both variants. The difference is purely in how the request is transported. Modbus RTU sends a binary frame over RS-232 or RS-485 serial with a CRC checksum. Modbus TCP wraps the same request payload (minus the CRC, which TCP handles) inside a TCP packet with an MBAP header, sent over port 502.

The register map, function codes, and data model are identical. If you know how to read Modbus RTU registers, you already know how to read Modbus TCP registers — you are just talking to the device over Ethernet instead of a serial cable.

Why does my Modbus read return the wrong value even though I have the right address?+−

The most common causes, in order of frequency:

  • Address offset by one. The device manual documents the "data model" address (40001, 40002…) but your OPC server or client wants the "PDU address" (0, 1, 2…). Or vice versa. Try subtracting 1 from the address you configured.
  • Wrong register table. Input Registers (3x, FC04) and Holding Registers (4x, FC03) are different tables. A value documented as "register 1" might be in the 3x table, not the 4x table. Check which function code the manual specifies.
  • Byte/word order mismatch. 32-bit floats and 32-bit integers span two Modbus registers. The order of the bytes within a word and the order of the two words can each be swapped. TOP Server provides separate byte-swap and word-swap settings per tag to handle any combination.
  • Scaling. Some devices store analog values as raw integer counts that require a scaling factor to convert to engineering units. A temperature that reads as 874 is probably 87.4°C with a 0.1 scale factor applied in the device documentation.
How many Modbus devices can one OPC server poll?+−

For Modbus TCP there is no hard protocol limit — each device connection is a separate TCP socket. In practice, TOP Server can poll hundreds of Modbus TCP devices simultaneously, with the actual limit determined by the server machine's CPU and network capacity, the polling rate configured, and the number of registers being read per device.

For Modbus RTU over RS-485, the protocol supports up to 247 slave addresses on a single bus (addresses 1–247). Multiple RS-485 buses can be added by adding serial ports or serial device servers, each supporting their own 247 devices. TOP Server supports multiple serial channels simultaneously, so a single TOP Server installation can cover many RS-485 buses at once.

Is Modbus secure enough for IIoT use?+−

Modbus itself has no security features — no authentication, no encryption, no access control. This is well understood and well documented. The standard guidance is to never expose Modbus devices directly to untrusted networks. In a properly segmented OT network architecture, Modbus traffic stays within the OT network, and an OPC server or edge gateway handles the boundary crossing into the DMZ or IT network using a secure protocol (OPC UA with TLS, MQTT over TLS, HTTPS).

Modbus Security (an extension defined in Modbus.org publication MB-TCP-Security) adds TLS to Modbus TCP using a new port (802) and certificate-based client authentication. It is available in recent devices from some vendors but has not seen widespread adoption. In most industrial deployments, network segmentation and the OPC/MQTT boundary layer provide the security for Modbus devices rather than the protocol itself.

Can multiple masters poll the same Modbus slave simultaneously?+−

For Modbus RTU over RS-485, no. The RS-485 bus is a shared medium; only one master can transmit at a time, and the protocol has no arbitration mechanism. Two masters attempting to poll the same RS-485 bus simultaneously will collide and corrupt each other's frames. A single master must manage all polling on each RS-485 bus.

For Modbus TCP, multiple masters can connect to the same slave device simultaneously, because each connection is a separate TCP socket. Whether the slave device actually handles concurrent requests depends on its firmware implementation. In practice, having an OPC server act as the single master that polls all devices, with multiple OPC clients reading from the server's cache, is the recommended architecture.

What is the "Modbus Suite" in TOP Server?+−

The Modbus Suite is a TOP Server driver package that covers the three main Modbus transport variants — Modbus RTU (serial), Modbus ASCII (serial), and Modbus TCP/IP (Ethernet) — in a single licensed unit. It handles all four register tables, all standard function codes, configurable byte/word swap for 32-bit and 64-bit data, automatic CRC and error handling, configurable polling rates and timeouts, and Ethernet redundancy (primary/secondary IP failover) for Modbus TCP.

The Suite also includes support for Modbus RTU over TCP — a hybrid mode where RTU-framed messages (including the CRC) are carried inside TCP packets rather than native MBAP-framed Modbus TCP. This is common with serial device servers that create a raw TCP socket for the serial port without converting to the Modbus TCP framing convention.

Connecting Modbus devices to your OPC or IIoT infrastructure?

Software Toolbox's engineers have configured Modbus connectivity across every variant and edge case the protocol produces. TOP Server's Modbus Suite covers RTU, TCP, ASCII, and every byte-order combination — in production since 1996.

Talk to an engineer

Connecting Modbus devices to your OPC or IIoT infrastructure?

Software Toolbox's engineers have configured Modbus connectivity across every variant and edge case the protocol produces. TOP Server's Modbus Suite covers RTU, TCP, ASCII, and every byte-order combination — in production since 1996.

Talk to an engineer