What Is Modbus? The Protocol That Runs Industrial Automation
Modbus is an open request/response communication protocol: one master (client) asks a device (slave or server) to read or write its registers and coils, and the device replies. Modicon (now Schneider Electric) published it in 1979 for connecting programmable logic controllers, and it now runs over serial lines (Modbus RTU and ASCII) and over Ethernet (Modbus TCP). Walk into a factory, water treatment plant or substation and you will usually find it running somewhere. It is not the fastest, most secure or most feature-rich protocol, but after nearly fifty years it remains the default language many industrial devices speak.
Next steps: RTU vs TCP, the four register types, function codes, BACnet vs Modbus, and Modbus Poll to try it on a real device.
If you are a system integrator, a plant engineer, or a developer building SCADA software, you will run into Modbus. Not because it is exciting. Because so many devices, SCADA platforms and HMIs support it. It is a common denominator of industrial automation.
Why Is Modbus Still Everywhere After 50 Years?
Protocols come and go. Profibus, DeviceNet, EtherCAT, PROFINET, OPC-UA, MQTT: many newer protocols were meant to replace what came before them, yet Modbus is still widely deployed next to them. Four reasons stand out:
- It is simple. The serial line specification is 44 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 and single-bit coils. No object models, no discovery hierarchies, no certificate exchanges. You send a request, you get a response.
- It is open and royalty-free. The specification is published openly. Any manufacturer can add Modbus support to a device without paying a licence fee, which is why Modbus shows up in so many VFDs, temperature controllers, power meters and PLCs.
- It is well-understood. The knowledge base is large. If something goes wrong with a Modbus connection, there are forum threads, manuals, and videos that explain how to fix it.
- The network effect. Because so many devices support Modbus, a system integrator can mix hardware from many vendors, and that in turn keeps manufacturers adding it. The cycle reinforces itself.
Modbus is not the best protocol for any single application, but it works for a very wide range of them.
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 the function code with the high bit set plus an exception code if something went wrong). The common function codes read and write coils and registers; others handle diagnostics and device identification.
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.
0x1x3x4xCoils (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. Slave addresses run from 1 to 247, but the Modbus serial line specification only guarantees 32 devices on an RS-485 segment without a repeater, 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 and 8 data bits. The Modbus serial line specification makes even parity with 1 stop bit (8-E-1) the default, and says that no parity requires 2 stop bits; many devices are nevertheless set up as 8-N-1, so check the manual. 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 with 11 bits per character (start, 8 data, parity, stop), about 870 characters per second go over the wire. A read of 10 holding registers is an 8-byte request plus a 25-byte response (slave, function, byte count, 20 data bytes, 2 CRC), 33 characters in total, about 38 ms. Add two inter-frame silences of 3.5 characters (about 8 ms) and a single read takes about 46 ms before the slave's own processing time, so one device can be polled about 20 times per second at best. With 30 devices on the bus and a 1 second poll cycle, 30 reads of about 46 ms each already add up to roughly 1.4 seconds, so RTU cannot keep up. This is one reason 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. A 7-byte MBAP header (transaction ID, protocol ID 0, length, unit ID) replaces the RTU address and CRC: the IP address identifies the host to connect to, and the unit ID stays in the header, which matters when the host is an RTU gateway that forwards the request to a serial slave. Function codes, register tables, and the data model stay the same.
Modbus TCP is much faster than Modbus RTU at 9600 or 19200 baud. You are no longer limited by serial baud rates or bus contention, and you can keep a separate connection to each device. The per-request limit does not change: a read of holding registers is still capped at 125 registers per request.
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.
Modbus TCP is the usual choice for new installations with Ethernet available. RTU remains common 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, a handful cover most work: the table lists the seven you will meet most often.
0102030405061516Function 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 decades 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. Modbus was designed in 1979 for isolated serial networks, and plants are now increasingly connected to IT networks. If your Modbus TCP devices are reachable from a network that touches the internet without a firewall, that is a security vulnerability.
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, but the serial line specification only guarantees 32 devices per RS-485 segment without a repeater. In practice, polling time sets a lower limit still: see the calculation above, where 30 devices at 9600 baud already need about 1.4 seconds per cycle. 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 (typically RS-485) with binary framing; 9600 and 19200 baud are the common speeds and some devices go up to 115.2 kbps. The serial line specification allows slave addresses 1 to 247, and 32 devices are always allowed on an RS-485 segment without a repeater. Modbus TCP wraps the same Modbus protocol inside TCP/IP packets over Ethernet at 10 Mbps to 1 Gbps. RTU uses a slave address on a shared serial bus; TCP uses an IP address to reach the device and keeps a unit ID in the MBAP header. Both use the same function codes and register tables.
Why is Modbus still used in industrial automation?
Modbus remains widely used because it is open and royalty-free, simple to implement (the serial line specification is 44 pages), well understood by automation engineers, and supported by a very large number of PLCs, meters, drives and sensors. That wide support reinforces itself, which 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.
Start Monitoring Your Modbus Devices
Voltrus connects to Modbus TCP devices out of the box. Auto-discovery, visual register mapping, dashboards, trend charts, and alerts. No protocol configuration headaches. Free open source core.
Explore Voltrus