What Is Modbus? The Protocol That Runs Industrial Automation

Modbus is a serial communication protocol published by Modicon (now Schneider Electric) in 1979 for connecting programmable logic controllers in industrial environments. It is the oldest and most widely deployed industrial protocol in the world. Walk into any factory, water treatment plant, or power substation on the planet and you will find Modbus running somewhere in the system. It is not the fastest protocol, not the most secure, and not the most feature-rich. But after nearly fifty years, it remains the default language that industrial devices speak when they need to talk to each other.

If you are a system integrator, a plant engineer, or a developer building SCADA software, you need to understand Modbus. Not because it is exciting. Because it is unavoidable. Every industrial device manufacturer supports it. Every SCADA platform reads it. Every HMI connects to it. Modbus is the lingua franca of automation, and it is not going anywhere.

Why Is Modbus Still Everywhere After 50 Years?

Protocols come and go. Profibus, DeviceNet, EtherCAT, PROFINET, OPC-UA, MQTT. The industrial networking landscape is littered with protocols that were supposed to replace everything before them. Modbus outlasted all of them for four reasons:

• It is simple. The Modbus specification is roughly 50 pages. You can implement a basic Modbus client in a weekend. The protocol does one thing and does it predictably: it reads and writes 16-bit registers. No object models, no discovery hierarchies, no certificate exchanges. You send a request, you get a response.
• It is royalty-free. Modicon published the specification openly and never charged licensing fees. Any manufacturer can add Modbus support to their device without paying anyone. This is why every VFD, every temperature controller, every power meter, every gas detector, and every PLC on the market supports Modbus. It costs nothing to implement.
• It is well-understood. Every automation engineer alive knows how Modbus works. The knowledge base is enormous. If something goes wrong with a Modbus connection, there are thousands of forum threads, manuals, and YouTube videos that explain how to fix it. No other industrial protocol has this depth of community support.
• Every device manufacturer supports it. This is the network effect. Because Modbus is universal, no device manufacturer would ship a product without Modbus support. Because every device supports it, no system integrator would choose a protocol that limits their hardware options. The cycle reinforces itself.

Modbus is not the best protocol for any single application. But it is the protocol that works for every application. In industrial automation, reliability beats innovation.

How Modbus Works: Master, Slave, Registers, and Function Codes

Modbus uses a client-server architecture (originally called master-slave). One device, the client or master, sends requests. One or more devices, the servers or slaves, respond. The client asks: "Give me the value of register 40001." The server replies: "The value is 2375." That transaction is the entire protocol in its simplest form.

Every server on a Modbus network has a unique address, typically between 1 and 247. Address 0 is reserved for broadcast (all devices listen, none respond). When the client sends a request, it includes the target server address. Only that device responds.

Function Codes

Function codes tell the server what operation to perform. The client sends a function code in the request. The server executes it and returns the same function code in the response (or an error code if something went wrong). The most common function codes cover four operations: read, write, read diagnostics, and write diagnostics.

Registers

Data in a Modbus device lives in registers. A register is a 16-bit word. That is it. Modbus does not define data types, structures, or objects. Everything is a 16-bit unsigned integer. If you want to read a temperature of 72.5 degrees, you store 725 in a register and the client application divides by 10. If you need a 32-bit floating point value, you use two consecutive registers and the client application interprets the pair as an IEEE 754 float. The protocol does not care. It just moves bits. For a deeper dive into each register type and how addresses work, see our Modbus register types guide.

The Modbus Data Model: Four Tables You Need to Know

Modbus organizes data into four tables, each with a different access type and a different reference number prefix. Understanding these four tables is the single most important thing you need to work with Modbus devices.

Coils (0x) are single-bit read/write values. They represent binary outputs: a relay that is on or off, a valve that is open or closed, a motor that is running or stopped. Function code 01 reads coils. Function code 05 writes a single coil. Function code 15 writes multiple coils.

Discrete Inputs (1x) are single-bit read-only values. They represent binary inputs: a limit switch state, an alarm flag, a digital sensor reading. You can read them with function code 02, but you cannot write to them.

Input Registers (3x) are 16-bit read-only values. This is where most sensor data lives: temperature readings, pressure values, flow rates, voltage measurements. Function code 04 reads input registers.

Holding Registers (4x) are 16-bit read/write values. This is the most commonly used table. Holding registers store configuration parameters, setpoints, control commands, and any data that the client needs to both read and modify. Function code 03 reads holding registers. Function code 06 writes a single holding register. Function code 16 writes multiple holding registers.

Modbus RTU: The Serial Workhorse

Modbus RTU (Remote Terminal Unit) is the original Modbus. It runs over serial communication, typically RS-485, which is a differential signaling standard that allows multiple devices on a single bus cable. Up to 247 devices can share one RS-485 bus, daisy-chained with twisted-pair cable.

RTU uses binary framing. Data is transmitted as raw bytes, not human-readable characters. An RTU frame includes the device address, the function code, the data, and a CRC (cyclic redundancy check) for error detection. The silence between frames is what separates one message from the next. This makes RTU efficient and compact, but it also means you need a protocol analyzer or a Modbus debugging tool to see what is happening on the wire.

Typical RTU parameters: 9600 or 19200 baud, 8 data bits, no parity, 1 stop bit. These are the settings you will find in 90% of Modbus RTU device manuals. RTU has been the default for decades in legacy systems, motor drives, PLCs, and instruments where Ethernet infrastructure does not exist or is not needed.

The limitation of Modbus RTU is speed. At 9600 baud, you can read roughly 40 registers per second from a single device. If you have 30 devices on the bus and you need to poll each one every second, RTU cannot keep up. This is why Modbus TCP exists. For a full breakdown of when to use each variant, see our Modbus RTU vs TCP comparison.

Modbus TCP: The Modern Standard

Modbus TCP wraps the same Modbus protocol inside a standard TCP/IP packet and transmits it over Ethernet. The default port is 502. The device address in the RTU frame becomes the IP address in the TCP connection. Everything else stays the same: function codes, register tables, the data model.

Modbus TCP is dramatically faster than Modbus RTU. A single TCP connection can read hundreds of registers per transaction at Ethernet speeds. You are no longer limited by serial baud rates or bus contention. You can poll dozens of devices simultaneously without breaking a sweat.

The trade-off is infrastructure. RTU runs on a two-wire cable. TCP requires Ethernet switches, IP address management, and network configuration. In a greenfield installation with modern hardware, this is trivial. In a brownfield plant with 20-year-old PLCs connected by serial cables, migrating from RTU to TCP means running new cables or installing serial-to-Ethernet gateways.

Most new industrial deployments use Modbus TCP as the primary protocol. RTU remains dominant in retrofit projects, legacy systems, and applications where running Ethernet cable is impractical.

Modbus ASCII: The One You Will Rarely Use

Modbus ASCII is the third variant. Like RTU, it runs over serial (RS-485 or RS-232). Unlike RTU, it encodes data as human-readable ASCII characters instead of raw binary bytes. Each byte of data is sent as two ASCII characters representing the hexadecimal value. A byte value of 0x1A is transmitted as the characters "1" and "A".

The advantage is debuggability. You can watch Modbus ASCII traffic on a terminal program and read the values directly. The disadvantage is that it is roughly twice as slow as RTU for the same data payload, because every byte requires two characters on the wire.

In practice, Modbus ASCII is rarely used in new installations. RTU is more efficient for serial communication, and TCP is the standard for Ethernet. You will encounter Modbus ASCII in older systems and in some specialized devices, but it is not something you will deploy by choice.

Modbus RTU vs TCP vs ASCII: Comparison

Here is the side-by-side breakdown of the three Modbus variants.

And where Modbus ASCII fits: same physical medium as RTU (serial), ASCII-encoded frames instead of binary, roughly half the throughput of RTU, used in legacy systems where human-readable debugging was prioritized over performance.

Common Modbus Function Codes You Will Actually Use

The Modbus specification defines dozens of function codes. In practice, you will use four of them for 95% of your work. Memorize these and you can configure any Modbus device on the market.

Function code 03 (Read Holding Registers) is the workhorse. When a SCADA system polls a device, this is the function code it sends most of the time. You specify the starting register address and the number of registers to read. The device responds with the values.

Function code 06 (Write Single Register) is how you send setpoints and commands. Want to change a temperature setpoint from 50 to 75 degrees? Write the value 750 to the appropriate holding register (assuming the device uses tenths of a degree) with function code 06.

Function code 16 (Write Multiple Registers) does the same thing as 06 but for a block of consecutive registers. Useful when you need to update several parameters in one transaction.

Modbus Limitations: The Honest Assessment

Modbus has survived for 50 years not because it is perfect, but because its limitations are well-known and well-managed. Here are the real problems you will encounter:

No Security

Modbus has no encryption, no authentication, and no access control. Any device that can reach a Modbus TCP server on port 502 can read and write any register. In 1979, when Modbus was designed, industrial networks were air-gapped. In 2026, they are not. If your Modbus TCP devices are on a network that touches the internet without a firewall, that is a security vulnerability. Period.

No Built-in Discovery

Modbus has no mechanism for a client to discover what devices exist on a network or what registers they contain. You have to know the device address and the register map in advance, usually by reading the device manual. This is why SCADA software like Voltrus provides auto-discovery features that probe address ranges and identify responding devices.

Limited Data Types

Everything in Modbus is a 16-bit unsigned integer. There is no standard way to represent floating point numbers, strings, timestamps, or complex data structures. The convention is to use two consecutive 16-bit registers for a 32-bit float (IEEE 754), but byte order (big-endian vs little-endian) varies between manufacturers. This is the source of more debugging headaches than any other Modbus issue.

247 Device Limit per Bus

On a single Modbus RTU serial bus, you can address devices 1 through 247. In practice, the real limit is much lower. At typical baud rates, polling 30 devices on one bus already pushes the limits of acceptable response times. Modbus TCP removes this bottleneck because each TCP connection is independent.

No Timestamps

Modbus data has no timestamp. When you read register 40001, you get the current value. You do not get when that value was measured or when it last changed. If you need time-series data, the SCADA software must attach timestamps at the moment it reads the register.

How Voltrus Uses Modbus

Voltrus is a SCADA platform that speaks Modbus natively. If you have Modbus TCP devices on your network, Voltrus connects to them, reads their registers, and displays the data on dashboards. No middleware. No protocol conversion. No OPC-UA server in between.

Built-in Modbus TCP Client

Voltrus includes a full Modbus TCP client. You configure the device IP address, port (default 502), and the register addresses you want to monitor. Voltrus polls the devices on a configurable interval, stores the values, and makes them available for dashboards, trend charts, and alert rules. If you need a standalone tool for quick register reads during commissioning, MacTools Modbus Poll provides native macOS polling for both TCP and RTU.

Auto-Discovery

You do not have to manually enter every device. Voltrus can scan a range of IP addresses and identify Modbus TCP devices that respond. This saves hours of configuration time when you are setting up a new plant with dozens of devices.

Visual Register Mapping

Instead of looking up register addresses in a PDF manual and typing them into a configuration file, Voltrus provides a visual register mapping interface. You select the data type (Int16, UInt16, Float32, Boolean), enter the register address, and assign a label. Voltrus handles the byte order interpretation internally.

Modbus RTU Support

If your devices use Modbus RTU over serial, Voltrus works with standard RTU-to-TCP gateways. The gateway handles the serial side. Voltrus connects to the gateway over Ethernet using Modbus TCP. This is the standard architecture for plants with mixed RTU and TCP environments.

Frequently Asked Questions

What is the difference between Modbus RTU and Modbus TCP?

Modbus RTU runs over serial communication (RS-485) with binary framing at speeds up to 115.2 kbps, supporting up to 247 devices on a single bus. Modbus TCP wraps the same Modbus protocol inside TCP/IP packets over Ethernet at speeds from 10 Mbps to 1 Gbps. RTU uses device addresses on a shared serial bus; TCP uses IP addresses with independent connections. Both use the same function codes and register tables.

Why is Modbus still used in industrial automation?

Modbus remains dominant because it is royalty-free, simple to implement (the specification is roughly 50 pages), well-understood by every automation engineer, and supported by every industrial device manufacturer. No licensing cost means every VFD, power meter, PLC, and sensor ships with Modbus support, creating a self-reinforcing network effect that has kept Modbus relevant for nearly 50 years.

What are the four Modbus data tables?

Modbus organizes data into four tables: Coils (0x prefix, read/write, 1-bit booleans for outputs like relays), Discrete Inputs (1x prefix, read-only, 1-bit booleans for inputs like limit switches), Input Registers (3x prefix, read-only, 16-bit integers for sensor data like voltage), and Holding Registers (4x prefix, read/write, 16-bit integers for configuration and setpoints). Each table uses specific function codes for read and write operations.

What is a Modbus register?

A Modbus register is a 16-bit word that stores data in a Modbus device. Registers do not have built-in data types — everything is a 16-bit unsigned integer. For larger values like 32-bit floats, two consecutive registers are used and interpreted as an IEEE 754 float by the client application. The register address combined with the table prefix (e.g., 40001 for holding register 1) tells you which function code to use for reading or writing.

Is Modbus secure?

No. Modbus has no built-in encryption, authentication, or access control. Any device that can reach a Modbus TCP server on port 502 can read and write any register. To secure Modbus deployments, use VLAN segmentation for OT networks, VPN tunnels for remote access, firewall rules restricting port 502 to known IPs, and never expose Modbus devices directly to the internet.

Further Reading

• Modbus RTU vs TCP: Which One Should You Use?
• Modbus Register Types Explained: Coils, Inputs, and Holding Registers
• How to Monitor Modbus TCP Devices Without Writing Code