Modbus is a simple, open industrial protocol that lets one device read and write data on another. It defines four data types, coils, discrete inputs, input registers, and holding registers, and a set of function codes to access them, carried either over serial wiring (Modbus RTU) or Ethernet (Modbus TCP). It has run factory equipment since 1979 and still does.
If you connect old machines to modern systems, you will meet Modbus. It is plain, it is everywhere, and it refuses to die, which is exactly why understanding it pays off. This is a field-level explanation of how Modbus works, why it persists on legacy gear, and how to get its data into a modern IIoT stack without ripping out the controls that already run your lines.
What is the Modbus protocol?
Modbus is a request-and-response messaging protocol for industrial devices. One device, historically called the master, now often the client, asks a question; another device, the slave, or server, answers. There is no chatter and no discovery: the client asks for specific data at a specific address, and the server returns exactly that. This bluntness is the whole point. Modbus was designed in 1979 by Modicon for programmable controllers, and its simplicity is why a protocol older than most plant managers still ships in new equipment today.
The protocol is openly published and royalty-free, which is the other half of its survival story. Any vendor can implement it without a license, so it became the lingua franca that a PLC a power meter, a variable-frequency drive, and a temperature controller can all speak, even when nothing else about them matches.
What are coils, registers, and function codes?
Modbus organizes everything a device exposes into four data tables. Two are single bits (on/off), and two are 16-bit numbers. Whether you can read, write, or both depends on the table.
| Data type | Size | Access | Typical use |
|---|---|---|---|
| Coil | 1 bit | Read / write | A digital output, a valve, a motor, a lamp |
| Discrete input | 1 bit | Read only | A digital input, a switch or sensor state |
| Input register | 16 bits | Read only | An analog input, a temperature or pressure reading |
| Holding register | 16 bits | Read / write | The all-purpose register, setpoints, counters, config |
You access these tables with function codes, small numbers that say what operation you want. The common ones are 01 (read coils), 02 (read discrete inputs), 03 (read holding registers), 04 (read input registers), 05 (write single coil), 06 (write single register), 15 (write multiple coils), and 16 (write multiple registers). Function code 03, read holding registers, is the workhorse; a great deal of real-world Modbus traffic is just a client polling holding registers over and over to see what a machine is doing.
What is the difference between Modbus RTU and Modbus TCP?
The difference is only the wrapper, not the contents. Modbus RTU and Modbus TCP carry the exact same data model and the exact same function codes, a read-holding-registers request is function code 03 in both. What changes is how the message is framed and what wire it travels on.
Modbus RTU is the serial version. It runs over an RS-485 bus, wraps each message with a slave ID and a CRC checksum for error detection, and is what you find on older equipment and long cable runs. Modbus TCP carries the same message inside a TCP/IP packet over Ethernet. Because TCP already handles error checking, the CRC is dropped and replaced by a short MBAP header, and every Modbus TCP server listens on port 502. In practice, RTU is the language of the legacy floor and TCP is how that language gets onto the plant network.
How does a Modbus conversation actually work?
A Modbus exchange is always one question and one answer, initiated by the client. The client sends a request that names three things: which device (the address), what to do (the function code), and where (the register address and how many). The server does exactly that and sends back the values, or an exception code if it cannot. Nothing happens unless the client asks, servers never speak first.
Because of that, real Modbus systems run on polling: the client asks the same questions on a loop, many times a second, to keep a fresh picture of the machine. This is simple and predictable, but it has a cost, every value you want, you must ask for, over and over, and a bus with many devices spends real time just cycling through them. That polling overhead is one of the practical reasons plants pair Modbus with report-by-exception protocols higher up the stack, where a value is published only when it changes.
Why does Modbus still run so much legacy equipment?
Modbus persists for the same reasons it spread: it is open, it is simple, and it already works. A protocol that costs nothing to implement, that a junior technician can troubleshoot with a $30 adapter, and that has run a machine reliably for fifteen years gives a plant no reason to change. Newer protocols are richer, but richness is not what a working press or a thirty-year-old oven needs. In a plant, "boring and proven" beats "modern and unfamiliar" almost every time, and Modbus is as boring and proven as industrial networking gets.
There is also inertia in the best sense. The control logic on legacy gear is validated, safety-checked, and trusted; nobody wants to touch it to chase a fancier network. So Modbus becomes the stable seam you read from rather than the thing you replace. That is a feature for anyone doing machine monitoring or a retrofit: you can tap the data a machine already publishes over Modbus without altering how the machine runs.
The one honest caveat is age showing its edges. Modbus predates plant networking as we know it, so it carries no authentication, no encryption, and no concept of who is asking. On a segmented, air-gapped serial bus that never mattered. On a modern flat Ethernet network it very much does, which is why "get the data off Modbus" and "keep Modbus off the open network" are two halves of the same retrofit. Treat the protocol as a trusted local source, not something to expose broadly.
How do you get Modbus data into modern systems?
The goal is to lift Modbus data up into a network and software stack that can contextualize and act on it, usually alongside protocols like MQTT without disturbing the control layer. Doing this is often the first real step in collapsing a plant's data silos because the machine data locked behind Modbus finally reaches the systems that need it. The path is well-worn.
- Map the registers. Get or build the register map for each device: which address holds speed, which holds a fault bit, which holds the count. Without the map, the numbers are meaningless.
- Add a read-only tap. Poll the device with function codes 01-04 for the data you need. Reading never changes machine behavior, which keeps the retrofit safe.
- Bridge RTU to the network. Use a serial-to-Ethernet gateway to bring RS-485 devices onto the plant LAN as Modbus TCP, or into an edge device.
- Normalize and scale. Convert raw 16-bit registers into real engineering units and apply the plant's naming, so a register becomes "Line 3 filler speed" instead of "40001."
- Publish upward. Hand the contextualized data to your operational layer or broker so dashboards, analytics, and AI can use it, this is where Modbus meets the modern stack.
- Segment the network. Keep Modbus traffic on a controlled network segment; the protocol has no built-in authentication, so isolation is your security.
By the numbers
Modbus was introduced by Modicon in 1979 and remains an openly published, royalty-free specification maintained by the Modbus Organization; its registers are 16 bits, its RTU frames cap at 256 bytes, and every Modbus TCP server listens on the IANA-registered port 502 (Modbus Organization specifications). Because the protocol has no authentication or encryption of its own, guidance for industrial control systems stresses network segmentation and monitoring around legacy protocols like it (CISA: Industrial Control Systems). Where Harmony fits: Harmony is an AI-native operating system for manufacturing that connects machines, including legacy Modbus gear, plus ERP, MES, and paperwork into one real-time layer, so decades-old equipment contributes to the same live picture as new lines. See the wider plumbing in IIoT the control-side context in SCADA or how CLS unified its floor.