Modbus is a communication protocol that lets industrial devices exchange data with each other. Originally published in 1979 by Modicon (now part of Schneider Electric), it was designed so programmable logic controllers (PLCs) could talk to sensors, motors, and other equipment on a factory floor. Over four decades later, it remains one of the most widely used protocols in industrial automation, building management, and energy systems, largely because it’s simple, open, and free to implement.
If you’re encountering Modbus for the first time, whether you’re setting up a sensor network, troubleshooting an HVAC system, or just trying to understand how industrial equipment communicates, here’s what you need to know.
How Modbus Communication Works
Modbus uses a client/server model (historically called master/slave). One device, the client, sends a request. Another device, the server, responds. The client might ask a temperature sensor for its current reading, or tell a motor controller to change speed. The server processes the request and sends back the data or confirms the action.
Every message follows a predictable structure: the server’s address, a function code that specifies what operation to perform, the data itself, and an error-checking value. This simplicity is a big part of why Modbus caught on. There’s no complex handshaking or negotiation. The client asks, the server answers, and the transaction is done.
Each server device on a Modbus network has a unique address (1 through 247 for serial networks). The client uses this address to direct its request to a specific device. Address 0 is reserved for broadcast messages that go to every device at once.
The Four Data Types
Modbus organizes data into four categories, each stored in its own address space on the server device:
- Coils: Single-bit values (on/off) that can be read and written. Think of a relay that you can turn on or off remotely.
- Discrete inputs: Single-bit values that are read-only. These represent the state of physical inputs like a switch or a limit sensor.
- Holding registers: 16-bit values (numbers) that can be read and written. These store things like setpoints, configuration values, or commands.
- Input registers: 16-bit values that are read-only. These typically hold measurement data like temperature, pressure, or flow rate.
The distinction between “read-only” and “read/write” is built into the protocol itself. You physically cannot write to a discrete input or input register through Modbus. This separation provides a basic layer of protection for sensor data that shouldn’t be overwritten by a controller.
Function Codes: The Language of Requests
Every Modbus message includes a function code, a number that tells the server what to do. The most commonly used codes cover reading and writing across those four data types:
- 01: Read coils (up to 2,000 at once)
- 02: Read discrete inputs (up to 2,000 at once)
- 03: Read holding registers
- 04: Read input registers (up to 125 at once)
- 05: Write a single coil
- 06: Write a single holding register
- 15: Write multiple coils
- 16: Write multiple holding registers (up to 123 at once)
Function code 23 combines a read and write into one transaction, with the write executing before the read. In practice, most Modbus setups rely heavily on codes 03 and 06 for reading and writing holding registers, since that’s where the most useful operational data lives.
If something goes wrong (say you request a register address that doesn’t exist), the server returns an error response with a specific exception code. This tells the client whether the problem is an illegal function, an illegal address, or a device failure, making troubleshooting more straightforward.
Modbus RTU vs. Modbus TCP
Modbus comes in several variants, but two dominate: Modbus RTU for serial connections and Modbus TCP for Ethernet networks.
Modbus RTU
RTU (Remote Terminal Unit) transmits data in compact binary form over serial connections, typically RS-485 wiring. It’s efficient and low-overhead, which made it the standard for decades in factories and remote installations. Each message ends with a CRC (cyclic redundancy check) value that the receiver recalculates to verify the data arrived intact.
An RS-485 Modbus network can stretch up to 1,000 meters without repeaters, as long as there’s no branching. With branching (stub connections off the main line), the maximum drops to about 15 meters per branch. A single RS-485 segment supports up to 32 devices, though repeaters can extend this. There’s also Modbus ASCII, a less common variant that sends data as readable text characters instead of binary. It’s slower but easier to debug with basic tools.
Modbus TCP
Modbus TCP wraps the same Modbus messages inside standard TCP/IP packets for transmission over Ethernet networks. It uses port 502, officially registered with IANA. The core data structure is nearly identical to RTU, with one key difference: RTU’s CRC error checking is stripped out and replaced by an MBAP (Modbus Application Protocol) header. Since TCP already guarantees reliable delivery at the transport layer, a separate CRC would be redundant.
A useful way to think about it: Modbus TCP is Modbus RTU with the CRC removed and a network header added to the front. The actual data inside, the function codes, register addresses, and values, stays the same. This means the same logic works regardless of whether you’re communicating over a serial cable or an Ethernet network.
Modbus TCP also removes the 247-device address limit. Since each device has its own IP address, you can have far more devices on a network. It also supports faster data rates and works over existing Ethernet infrastructure, which is why it has become the preferred choice for new installations.
Where Modbus Is Used
Modbus shows up in nearly every corner of industrial automation. Manufacturing plants use it to connect PLCs with sensors, actuators, and human-machine interfaces. Building management systems rely on it for HVAC controllers, power meters, and lighting systems. Solar inverters, battery management systems, and smart grid equipment frequently speak Modbus. Water treatment facilities, oil and gas pipelines, and agricultural irrigation systems all use it to monitor and control remote equipment.
Its popularity comes down to a few things: it’s royalty-free, easy to implement on low-cost hardware, well-documented, and supported by virtually every industrial device manufacturer. A sensor from one company and a controller from another will almost certainly both support Modbus, making interoperability far less painful than with proprietary protocols.
Security Limitations and Modbus/TCP Security
Modbus was designed in 1979 for isolated factory networks. It has no built-in authentication, encryption, or access control. Any device that can reach a Modbus server can read or write data. For decades, this didn’t matter much because industrial networks were physically separate from the internet. As those networks have become more connected, the lack of security has become a serious concern.
The Modbus organization addressed this by publishing the Modbus/TCP Security specification, which runs on port 802. It layers TLS (the same encryption technology that protects websites) on top of standard Modbus TCP. This provides encrypted communication channels and device authentication through X.509 certificates, the same type of digital certificates used in web browsers. The specification also supports role-based access control, where a device’s certificate defines what operations it’s allowed to perform. A monitoring station, for example, could be limited to read-only access while a control system gets full read/write permissions.
Adoption of the secure variant has been slow, partly because many Modbus devices run on minimal hardware that can’t handle the processing overhead of TLS, and partly because upgrading thousands of existing devices in a working industrial plant is expensive and risky. Many facilities still rely on network segmentation and firewalls to protect their Modbus traffic instead.