Modbus Protocol: History, Origin, and Why It Still Runs

The Modbus protocol is the common language an energy meter, heat pump, or inverter uses to hand over its values, and it is older than almost everything you connect it to. Modicon published it in 1979 for its own programmable controllers, and nearly half a century later you still speak it every working day. That is no accident. Once you understand where Modbus came from and why it stayed so simple, you immediately see why certain quirks bite you on the bus and others never do.

This guide explains the history of the Modbus protocol for installers, not for protocol historians. You will learn who created it, why it became open and royalty-free in 2004, how the 1979 design still works today, and what those choices mean for your daily work. For a broader explanation of the protocol itself, see our complete Modbus guide.

Key takeaways

• Modbus was created in 1979 by Modicon, the maker that also built the first PLC, and became an open, royalty-free standard under the Modbus Organization in 2004.
• The master-slave, request-response model has not changed in substance since 1979, and that simplicity is exactly what explains the huge installed base.
• The same simplicity means the standard fixes no meaning per register address, so every device still needs its own register map.

What is the Modbus protocol?

The Modbus protocol is an open communication protocol that lets a polling device (the master or client) exchange simple read and write messages with field devices (the slaves or servers) over a serial line or over Ethernet. It defines only what those messages look like and how they travel, not what the data means.

That is where the strength and the trap both live. Modbus fixes four data blocks and a handful of function codes, and nothing more. There is no device description, no automatic discovery, no built-in security. That plainness made it trivial to implement in 1979, which is why nearly every manufacturer adopted it. You feel the flip side today when you commission a new device and have to pull the meaning of each address out of the datasheet by hand.

Where Modbus came from: Modicon and 1979

To understand why Modbus is the way it is, you have to go back to the industry it grew out of: the programmable controller.

From the first PLC to the 1979 protocol

Modicon (a contraction of MOdular DIgital CONtroller) was founded in 1968 by a group of engineers around Dick Morley. That same team built the Modicon 084, widely recognized as the first programmable logic controller (PLC), for General Motors. According to the Modbus Organization, Modicon published the Modbus protocol in 1979 so its controllers could exchange data with peripheral equipment.

2004: the year Modbus became open

Schneider Electric acquired Modicon in 1997 and with it ownership of the protocol. The real turning point came in 2004: Schneider transferred the rights to Modbus to the Modbus Organization, an independent user group, and the specification became available free of charge and royalty-free. That same year the IEC accepted Modbus as a Publicly Available Specification. The fact that you can build or read a Modbus device today without paying a license fee is a direct result of that decision.

How the 1979 design still works

The communication model Modicon chose in 1979 has stayed remarkably simple. There is always a master that takes the initiative and slaves that only answer when addressed. The master sends a request with an address, a function code, and a register range; the addressed slave returns the requested values or reports an error. On a serial bus, up to 247 slaves can hold a unique address (1 to 247; 248 to 255 are reserved).

This explains a behavior that sometimes surprises installers. A slave never speaks on its own, so if you want a value you have to ask for it (poll it). Two devices sharing an address on a bus collide, because the master cannot tell who answered. And because all traffic runs through the single master, the poll rate decides how fresh your data is. The modern term is client-server rather than master-slave, but the mechanism is identical to 1979. To see which function code reads which register type, see our Modbus function codes reference.

Why the same address means different things per brand

The biggest design choice of 1979 was what Modbus deliberately does not settle. The standard fixes the transport and four data blocks, but never what a given address means. Register 40001 is a voltage on one meter, a setpoint on the next, and a firmware version on a third. There is no universal map and no gateway that automatically guesses what a register represents.

This is what surprises installers coming from BACnet, where objects carry self-describing names. With Modbus you always request the device's register map first. A second legacy of the plainness: the specification mandates big-endian for addresses and data fields, but does not fix the word order of a 32-bit value spread across two registers. Read them in the wrong order and you get a believable but wrong number. For the contrast between Modbus and the self-describing alternative, see BACnet versus Modbus.

From serial to Ethernet: RTU, ASCII, and TCP

Modbus began as a serial protocol over RS232 and later RS485, in two transmission modes: RTU (binary, compact, by far the most common) and ASCII (readable, but slower and heavier). When Ethernet reached the factory and the building, Modbus gained a TCP/IP variant in the late 1990s. Modbus TCP wraps the exact same message in a TCP packet and listens on port 502, a reserved port of its own in the internet world.

The core stayed the same message with the same function codes throughout; only the packaging changed. That is why you can put an RTU device and a TCP device into the same monitoring chain through a gateway. To choose the variant that fits a job, read Modbus RTU versus TCP, or the standalone explainers for Modbus RTU and Modbus TCP.

Why Modbus is still dominant

A protocol from 1979 that still runs raises the question of why nothing replaced it. The answer is a combination of three things: it has been open and royalty-free since 2004, it is dead simple to implement, and a vast installed base sits in the field. Modbus remains, alongside BACnet, one of the two most deployed protocols in HVAC, energy management, and building automation.

The numbers behind the installed base

The numbers confirm that this base is growing rather than shrinking. Within the Modbus world, the TCP variant now carries roughly 45 percent of installations and RTU about 35 percent, with TCP growing fastest on the back of the existing serial base. According to HMS Networks' 2025 industrial network survey, 76 percent of all new industrial network nodes are Ethernet-based, while serial RTU simply persists across the legacy base. For you as an installer, that means you will keep meeting Modbus on every job for the foreseeable future, old and new side by side.

What the history means for your installation

The practical lesson from forty-five years of Modbus is that the protocol deliberately does little for you. It transports plain numbers reliably, but meaning, address translation, and word order are yours to supply per device. That was a feature in 1979, because it kept the implementation small, and today it is the work that lands on your plate at every new installation.

That is exactly the work the ModbusCloud Gateway takes off your hands. The Gateway reads your Modbus RTU and TCP devices into a cloud dashboard through ready-made register templates, so you pick the device instead of decoding the map by hand. It handles the address translation and the word order for you, so the simplicity of 1979 works in your favor instead of against you.

Ready to leave manual address translation behind? The ModbusCloud Gateway reads your Modbus devices into a cloud dashboard through ready-made templates and handles the legacy of 1979 automatically for you.