Modbus.

Modbus is a simple master-slave communications protocol originally developed by Modicon in 1979. Its longevity is remarkable. Modbus RTU, over RS-485 serial and Modbus TCP, over Ethernet are still ubiquitous in industrial automation as the lingua franca for connecting third-party devices, packaged skids, and legacy equipment to modern control systems.

Upload a drawing Pricing

Three drawings included on a new account.

Part ofGlossary

What Modbus means.

Modbus was published by Modicon in 1979 to allow its PLCs to communicate with operator terminals. There was no standards body, no license, and no patent. The spec was a simple document that anyone could implement. That openness made it the protocol every microcontroller-based device maker reached for when they needed to expose data to an external host. By the time industrial Ethernet arrived in the 1990s, Modbus had accumulated an installed base of hundreds of millions of devices worldwide. Modbus TCP, 1999 moved the same register model to Ethernet, removing the RS-485 distance and node-count limits. Modbus now runs on serial, Ethernet, radio, cellular, and fiber. Any combination of physical layer and Modbus framing works as long as master and slave agree on the register map. The data model is extremely simple. Registers, 16-bit unsigned integers, addressed 0-65535, input registers, read-only analogs, coils, single-bit outputs, and discrete inputs, single-bit read-only status. That simplicity is the protocol's enduring strength. Every device that supports Modbus describes its data in the same few register types. The weakness is that simplicity. No data types beyond 16-bit integer, floating-point requires two registers with an agreed byte order, no device description, no diagnostic layer, no security, and no timestamping. Modern protocols like MQTT Sparkplug B or OPC UA address these gaps. They run alongside Modbus rather than replacing it in the installed base.

Why Modbus refuses to die

It is open, royalty-free, trivial to implement, and supported by every PLC, DCS, RTU, and packaged-skid controller on the market. When a chiller manufacturer ships a skid with its own controller and the customer asks 'how do we read the alarm summary,' the answer is almost always Modbus. The protocol is unsophisticated, no security, no native diagnostics, no device discovery but the simplicity is the feature. It interoperates.

Modbus RTU vs Modbus TCP

Modbus RTU runs on RS-485 serial at typical baud rates of 9600-115200, up to 32 nodes per segment, with a master polling slaves in turn. Modbus TCP runs the same register-and-coil model over standard Ethernet without the master-slave timing constraints, supporting many simultaneous client connections. Modbus over TCP is the modern default for new packaged equipment. Modbus RTU survives in retrofit and very-low-cost-device scenarios.

Modbus function codes and data types

Modbus requests and responses are structured around function codes. FC 01 reads coils, single-bit outputs. FC 02 reads discrete inputs, single-bit read-only. FC 03 reads holding registers, 16-bit read-write. FC 04 reads input registers, 16-bit read-only. FC 05 and 06 write single coil and register. FC 15 and 16 write multiple coils and registers. Floating-point values require two consecutive holding registers, FC 03 with a byte-order convention, big-endian or little-endian agreed between master and slave. The skid vendor's Modbus register map document specifies the register addresses, data types, scaling factors, and byte order for every variable. Without it the master cannot interpret the raw register values correctly.

Modbus in the I/O list and controls architecture

Instruments connected via Modbus, package-skid controllers, compressor units, analyser shelves, variable-frequency drives, power meters typically appear in the I/O list as a block rather than as individual AI, AO, DI, DO rows. The block entry references the Modbus register map document and specifies the physical connection, serial COM port or Ethernet IP address and port. Some projects expand the block into individual rows, one per register, to give the commissioning team a loop-by-loop sign-off format. Either approach is acceptable. The important thing is that the I/O list is the complete record of what the control system reads and from where, including Modbus sources alongside hardwired signals.

What goes wrong with Modbus integrations

The register map is the only documentation between master and slave. If the skid vendor provides the wrong revision, the master reads wrong values. Byte-order confusion, big-endian vs little-endian float packing produces plausible but wrong engineering values that pass a superficial check. Modbus RTU bus collisions cause CRC errors that most masters silently retry without raising an alarm to the operator. Modbus TCP connections dropped by a network switch go undetected if the master has no connection-health check configured. All of these produce intermittent bad data rather than a clean instrument fault, making them harder to diagnose than a simple 4-20 mA open circuit.

Worked example, the address offset that breaks most integrations.

A vendor document says a flow rate is at register 40108. That number is a documentation convention, not what goes on the wire. The leading 4 identifies the data block as holding registers, which are read with function code 03. The remaining digits, 0108, are a one based reference within that block, so the zero based protocol address that actually travels is 107. A master configured for address 108 will read the neighbouring register and return a plausible but wrong number, which is the classic symptom: everything communicates, nothing errors, and one value is consistently one register out. If the device rejects the request instead, the exception code says which end is wrong. Exception 02, illegal data address, means that register does not exist on the device, which usually means the base is wrong by one or the block is wrong. Exception 03, illegal data value, usually means more registers were requested in one read than the limit of 125 allows. Two further things a point list has to state, because the protocol does not: whether a 32 bit value is stored high word first or low word first, and whether it is scaled, since a 16 bit register has no units of its own.

Modbus function codes

The function code is the first byte of the request after the address. Codes marked serial only are defined for Modbus RTU and ASCII and are not used over Modbus TCP.

Decimal	Hex	Name	What it does	Data block
01	0x01	Read Coils	Reads 1 to 2000 discrete outputs	Coils
02	0x02	Read Discrete Inputs	Reads 1 to 2000 discrete inputs	Discrete inputs
03	0x03	Read Holding Registers	Reads 1 to 125 registers	Holding registers
04	0x04	Read Input Registers	Reads 1 to 125 registers	Input registers
05	0x05	Write Single Coil	Writes one discrete output	Coils
06	0x06	Write Single Register	Writes one holding register	Holding registers
07	0x07	Read Exception Status	Reads eight exception bits, serial only	Device specific
08	0x08	Diagnostics	Serial line diagnostics and counters, serial only	Device specific
11	0x0B	Get Comm Event Counter	Reads the event counter, serial only	Device specific
12	0x0C	Get Comm Event Log	Reads the event log, serial only	Device specific
15	0x0F	Write Multiple Coils	Writes 1 to 1968 discrete outputs	Coils
16	0x10	Write Multiple Registers	Writes 1 to 123 registers	Holding registers
17	0x11	Report Server ID	Returns a device description, serial only	Device specific
20	0x14	Read File Record	Reads from a file record	File records
21	0x15	Write File Record	Writes to a file record	File records
22	0x16	Mask Write Register	Applies an AND mask and an OR mask to one register	Holding registers
23	0x17	Read/Write Multiple Registers	Writes and then reads in a single transaction	Holding registers
24	0x18	Read FIFO Queue	Reads a first in, first out queue of registers	Holding registers
43	0x2B	Read Device Identification	Returns vendor name, product code and revision	Device identification

The four Modbus data blocks and the address conventions

The conventional five digit numbers are a documentation habit, not part of the protocol. What goes on the wire is the zero based protocol address, and the gap between the two is the most common integration fault.

Data block	Access	Size	Conventional reference	Function codes
Discrete input	Read only	One bit	10001 to 19999	02
Coil	Read and write	One bit	00001 to 09999	01, 05, 15
Input register	Read only	16 bit	30001 to 39999	04
Holding register	Read and write	16 bit	40001 to 49999	03, 06, 16, 22, 23

Modbus exception codes

An exception response returns the function code with the high bit set, followed by one of these codes. Reading it saves the usual hours spent suspecting the cable.

Code	Name	What it usually means in practice
01	Illegal function	The device does not implement that function code
02	Illegal data address	The register does not exist on that device, most often an off by one on the address base
03	Illegal data value	The quantity requested is out of range, for example more than 125 registers in one read
04	Server device failure	An unrecoverable error inside the device
05	Acknowledge	The request was accepted and will take a long time; poll again
06	Server device busy	The device is processing a long command; retry later
08	Memory parity error	A file record read failed a parity check
0A	Gateway path unavailable	A gateway could not allocate a path to the target device
0B	Gateway target device failed to respond	The gateway reached the network but the device did not answer

Common questions

Is Modbus secure.

No. Modbus has no authentication, no encryption, and no integrity protection at the protocol level. Modbus over TCP exposed to a network is a security gap. Hardening relies on network segmentation, firewalls, VLANs, OT DMZs rather than protocol-level controls. Modbus Secure, the evolving secure variant is gaining traction but penetration is low.

What's the difference between Modbus and Modbus Plus.

Modbus Plus is a separate proprietary token-passing network from Modicon, distinct from Modbus RTU, TCP. It survives in legacy Modicon installations but is not a current product. When people say Modbus today, they mean RTU or TCP.

How does a package-skid vendor typically hand Modbus data to the main PLC.

The skid controller acts as a Modbus slave, server. The main PLC acts as master, client. The skid vendor supplies a Modbus register map listing every analog input, setpoint, status bit, and alarm at its register address. The main PLC polls the map on a configurable scan rate, typically one to five seconds, and maps the registers into its own tag database for HMI display and interlock logic.

How does Modbus differ from OPC UA.

Modbus exposes raw registers. The meaning of each register is documented only in the vendor's register map, outside the protocol. OPC UA exposes a self-describing namespace where every node has a name, data type, engineering unit, and description that a generic client can read. Modbus is point-to-point polling. OPC UA is subscription-based with configurable deadband. Modbus survives as the field-device layer. OPC UA aggregates and normalizes the data northbound. Many modern systems run both. Modbus at the device, OPC UA gateway at the controller.

What is the Modbus register map and who provides it.

The register map is a document, often an Excel table that the device or skid vendor provides with their product. It lists every Modbus holding register or input register by address, with the parameter name, engineering unit, scaling factor, data type, and read, write access. Without the register map the master PLC has a set of numbered 16-bit integers with no way to know which is pressure, which is temperature, and which is a status byte. The register map is a critical project document. It must be obtained before the controls-configuration phase and reconciled with the I/O list.

Written byTagsight Controls DeskUpdated 20 September 2026

Get the I/O list template.

Fourteen columns with the signal class as a dropdown, auto-filter on every column, frozen header. Plain .xlsx.

Download the I/O list template Upload a drawing