How Modbus Works:
A Plain English Guide

▶ Modbus Explained - The 1979 Protocol Still Running the Oilfield - from the Merobix channel. Subscribe for weekly SCADA explainers.

What Is Modbus and Why Is It Everywhere?

In 1979, a company called Modicon needed a way for their programmable logic controllers to talk to each other and to operator terminals on the factory floor. The protocol they created was called Modbus. It was designed to be simple, deterministic, and easy to implement on the microcontrollers of the era. What they almost certainly did not anticipate was that their internal communication protocol would still be running the world's industrial infrastructure nearly five decades later.

Modbus became ubiquitous for three interconnected reasons: it was open, it was simple, and it was royalty-free. Any manufacturer could implement Modbus without licensing fees or approval from Modicon. The specification was short enough to understand in an afternoon. Field devices from dozens of competing manufacturers could all speak the same protocol. That combination proved impossible to dislodge even as better-designed alternatives emerged.

Today, a very large share of industrial field devices support Modbus in some form. You will find it in flow meters, pressure transmitters, variable-frequency drives, power meters, temperature controllers, RTUs, PLCs, and gas analyzers from virtually every major manufacturer. If a field device has a digital communication port, there is a high probability it speaks Modbus.

The protocol operates on a simple principle: one device (the master, or in modern terminology, the client) sends a request, and one or more other devices (slaves, or servers) respond. The master controls when communication happens. Slaves never transmit unless explicitly asked. This determinism was critical for factory automation in 1979, and it remains a practical feature in noisy industrial environments today.

Understanding Modbus's limitations is just as important as understanding how it works. The protocol was designed for point-to-point or small multi-drop serial networks in a single facility. It has no concept of IP addresses, no security model, no built-in data types beyond 16-bit integers, and no mechanism for a device to push data to the master without being asked first. These constraints drive many of the engineering decisions made in modern SCADA system design.

Modbus RTU vs Modbus TCP: Key Differences

The Modbus name covers three distinct variants that share the same application-layer data model but differ substantially in how they transmit data. Understanding which variant you are dealing with is the first step in troubleshooting any Modbus issue.

Modbus RTU

RTU stands for Remote Terminal Unit - a nod to the original SCADA roots of the protocol. Modbus RTU transmits data in a compact binary format over RS-485 or RS-232 serial links. Each message is a raw byte stream with no framing characters; message boundaries are instead determined by timing gaps (a silence of at least 3.5 character times signals the start of a new frame). A CRC-16 checksum at the end of every frame allows the receiver to detect transmission errors.

Modbus TCP

Modbus TCP takes the identical application-layer data and wraps it inside a standard TCP/IP packet sent over Ethernet on port 502. A small six-byte header called the MBAP (Modbus Application Protocol) header is prepended to each message. The MBAP carries a Transaction ID (for matching requests to responses when multiple requests are in flight), a Protocol ID (always 0x0000 for Modbus), a Length field, and a Unit ID (equivalent to the RTU slave address, used when a TCP gateway fronts multiple serial devices). Because TCP already provides reliable delivery and error detection via its own checksum and acknowledgment mechanism, the CRC of Modbus RTU is not needed and is not included.

Modbus ASCII

Modbus ASCII is an older variant that encodes each byte as two ASCII hexadecimal characters. A colon character (":") starts each frame and a CRLF ends it, making it human-readable on a terminal. It uses a simpler LRC (Longitudinal Redundancy Check) instead of CRC-16. Modbus ASCII is rarely encountered in new installations - it uses twice the bandwidth of RTU for the same data and offers no practical advantages over RTU in modern hardware. You may still encounter it on legacy laboratory instruments or older weight scales.

The practical decision between RTU and TCP usually comes down to the physical infrastructure. If you have existing RS-485 wiring to field devices - flow meters on a pipeline, sensors in a tank farm, drives in a motor control center - Modbus RTU is the correct choice. If you are connecting to devices inside an Ethernet-connected panel or integrating with a SCADA system over a LAN, Modbus TCP eliminates the need for serial converters and supports multiple simultaneous connections from different clients.

The Modbus Data Model: Coils, Registers, and Addresses

Before any request can be made, you need to understand what Modbus actually stores. The protocol defines four distinct data tables, each with its own addressing range, data type, and read/write permissions.

The Four Data Types

• Coils (0x / 0xxxx): Single-bit, read/write. Used for binary outputs - relay states, valve open/close commands, pump on/off signals. Addresses 1 through 9999 in documentation notation (zero-based 0x0000–0x270E in the protocol).
• Discrete Inputs (1x / 1xxxx): Single-bit, read-only. Used for binary inputs that the field device itself sets - limit switch states, digital input status. Addresses 10001 through 19999.
• Input Registers (3x / 3xxxx): 16-bit unsigned integer, read-only. Used for measured process values that the device populates from hardware - ADC readings, raw sensor counts. Addresses 30001 through 39999.
• Holding Registers (4x / 4xxxx): 16-bit unsigned integer, read/write. The workhorse of Modbus. Used for configuration parameters, setpoints, engineering-unit scaled values, and most process variables you will actually care about. Addresses 40001 through 49999.

The Off-by-One Problem

One of the most common sources of confusion in Modbus is the discrepancy between documentation addresses and protocol addresses. Device manuals typically use one-based notation: "Flow rate is at register 40001." But the Modbus protocol itself uses zero-based addressing. To read register 40001, your request must specify address 0x0000 (zero). To read 40003, specify 0x0002. The master subtracts 40001 and converts to hex. Most Modbus masters and SCADA platforms handle this automatically, but when you are reading raw packets in a protocol analyzer, keep this offset in mind.

Register Map Example

Every Modbus device ships with a register map - a table in the device manual listing what lives at each address. A simple flow meter installation might look like this:

Notice that the 32-bit totalizer value requires two 16-bit registers. This two-register float/double pattern is extremely common in Modbus devices and is discussed further in the limitations section. SCADA systems and Modbus masters must be configured to read both registers and combine them correctly - either as a 32-bit integer or as an IEEE 754 float, depending on what the device manual specifies.

Modbus Function Codes Explained

A function code (FC) tells the slave device what operation the master wants to perform. The FC is a single byte in the request frame. There are 127 possible function codes; fewer than 15 are in common use in industrial automation.

The Core Function Codes

• FC01 - Read Coils: Reads one or more coil values (bits). Response packs bits eight per byte.
• FC02 - Read Discrete Inputs: Reads one or more discrete input values (bits). Same format as FC01 but targets the read-only input bit table.
• FC03 - Read Holding Registers: The most commonly used function code. Reads one or more 16-bit holding registers. Each register occupies two bytes in the response, big-endian.
• FC04 - Read Input Registers: Same as FC03 but reads from the read-only input register table. Used for raw sensor values on devices that distinguish between measured inputs and configurable holding registers.
• FC05 - Write Single Coil: Forces a single coil to ON (0xFF00) or OFF (0x0000). Note the non-obvious ON value - 0xFF00 is the spec-defined constant, not 0x0001.
• FC06 - Write Single Register: Writes a single 16-bit value to one holding register. Simple and widely supported, but inefficient for writing multiple registers.
• FC15 - Write Multiple Coils: Writes multiple coils in a single request. Useful for setting several output bits simultaneously.
• FC16 - Write Multiple Registers: Writes multiple holding registers in one request. This is how you update a device configuration in one network round trip rather than many FC06 calls.

Exception Codes

When a slave cannot fulfill a request, it returns an exception response. The exception response sets the high bit of the function code byte (function code | 0x80) to signal an error, followed by an exception code byte. The four standard exception codes are:

• 0x01 - Illegal Function: The slave does not support this function code at all.
• 0x02 - Illegal Data Address: The requested register address does not exist in this device. Most commonly seen when a register map is misread and an address is off by one or the wrong table is targeted.
• 0x03 - Illegal Data Value: The value written to a register is outside the allowed range for that parameter (e.g., writing 500 to a baud rate register that only accepts 0–3).
• 0x04 - Slave Device Failure: The slave attempted to perform the operation and encountered an internal error. This indicates a device-level problem, not a communication issue.

Raw FC03 Request and Response Bytes

Understanding what the actual bytes look like demystifies everything. Here is an FC03 request to slave address 1, asking for 4 registers starting at address 0x0000 (documentation register 40001 through 40004):

The scaling (dividing by 10 or 100 to get engineering units) is purely a SCADA-side configuration. Modbus registers are always raw 16-bit unsigned integers. The device manual specifies the scaling factor, and the SCADA master applies it. This separation is both Modbus's greatest flexibility and one of its core limitations.

Modbus RTU Deep Dive: RS-485 and Serial Networks

Modbus RTU is inseparable from RS-485. Understanding the physical layer is essential for wiring, troubleshooting, and understanding why certain problems occur exclusively in serial environments.

RS-485 Fundamentals

RS-485 uses a differential pair - two wires, typically labeled A/B or D+/D-, that carry the same signal at opposite polarities. A receiver detects the difference between the two lines, not the voltage relative to ground. This differential approach gives RS-485 excellent noise immunity: any common-mode interference (induced from nearby power cables, motor drives, or VFDs) appears on both lines equally and is rejected. This is why RS-485 can run cables hundreds of meters through electrically noisy industrial environments where RS-232 would be completely unusable.

Key RS-485 specifications relevant to Modbus deployments:

• Maximum cable length: 1,200 meters (4,000 feet) at lower baud rates. This reduces with baud rate - at 115,200 baud, you should keep cable runs under 200 meters.
• Maximum devices per segment: 32 unit loads with standard transceivers. RS-485 repeaters allow extending to additional segments. Modbus addressing supports up to 247 slave addresses (1–247). Address 0 is reserved for broadcast messages (no response expected from any slave).
• Topology: Daisy-chain (multi-drop bus), not star. T-connections should be kept as short as possible. Star topologies cause reflections that corrupt data at higher baud rates.

Inter-Frame Timing

Because Modbus RTU has no start/stop characters to delimit frames, it relies entirely on timing. A gap of 3.5 character times of silence on the bus signals the end of one frame and the potential start of another. At 9,600 baud (the most common default), one character time is about 1.04 milliseconds, so the inter-frame gap is approximately 3.6 ms. At higher baud rates, this gap shrinks proportionally. Most modern Modbus master implementations use a minimum gap of 1.75 ms regardless of baud rate to accommodate slower slave devices.

Common Wiring Mistakes

• Missing termination resistors: A 120-ohm termination resistor must be placed at each end of the RS-485 bus - not at every device, only at the two physical ends of the cable run. Missing or incorrect termination causes signal reflections that appear as CRC errors at higher baud rates.
• Ground loops: RS-485 uses differential signaling, but the ground reference (the third wire in proper RS-485 wiring) must still be connected between devices. When devices are powered from different sources without a common ground reference, the common-mode voltage can exceed the RS-485 receiver's input range, causing erratic communication. Run a ground wire alongside the A/B pair.
• Incorrect bias resistors: When the bus is idle (all devices in receive mode), the A and B lines float. Without bias resistors pulling A high and B low, the differential voltage can be ambiguous and cause false start-of-frame detections. Many RS-485 converters have built-in bias; dedicated RS-485 networks may need external resistors (typically 560 ohms to Vcc and GND).
• Baud rate or parity mismatch: All devices on a Modbus RTU network must use identical settings: baud rate, data bits (always 8 for RTU), parity (none, even, or odd - and the parity must match), and stop bits. A single device with a different baud rate will occasionally corrupt frames for all other devices on the bus.

Modbus TCP Deep Dive: Ethernet and IP

Modbus TCP was standardized in 1999 and extended the reach of Modbus to Ethernet networks. The Modbus application data model is identical - the same function codes, the same register types, the same addressing. The key change is the transport.

The MBAP Header

Every Modbus TCP frame begins with a six-byte MBAP header that provides information otherwise carried implicitly by the serial framing:

• Transaction ID (2 bytes): Assigned by the client. The server copies it into the response. Allows a client to match responses to requests when multiple requests are outstanding simultaneously - something impossible in Modbus RTU where the master must wait for each response before sending the next request.
• Protocol ID (2 bytes): Always 0x0000 for Modbus. Reserved for future protocol extensions.
• Length (2 bytes): Number of bytes remaining in the packet (Unit ID + PDU). Replaces the timing-based frame detection of RTU.
• Unit ID (1 byte): Equivalent to the RTU slave address. Critical when a Modbus TCP gateway sits in front of a serial RS-485 network - the Unit ID tells the gateway which RS-485 device to forward the request to.

Port 502 and Firewalls

Modbus TCP listens on TCP port 502. This is an IANA-assigned well-known port. In practice, firewall rules for industrial networks must explicitly allow port 502 between the SCADA server and any Modbus TCP devices. If a Modbus TCP connection cannot be established, the firewall is the first place to check after verifying IP addressing. Because port 502 carries a protocol with no authentication, it should never be accessible from the internet or from untrusted network segments.

Concurrency Advantage

Modbus RTU is strictly half-duplex and single-threaded. The master sends a request, waits for the response (or a configurable timeout), then sends the next request. Modbus TCP over Ethernet supports multiple simultaneous TCP connections, and within a single connection, a client can send multiple requests with different Transaction IDs before receiving any responses (pipelining). This dramatically improves throughput when polling large numbers of registers from multiple devices.

RTU-to-TCP Gateways

The most common Modbus TCP deployment in legacy environments is a serial-to-Ethernet gateway that connects to the RS-485 bus on one side and presents a Modbus TCP server on the Ethernet side. The SCADA master communicates with the gateway over TCP; the gateway serializes requests and polls the RTU devices on the serial bus, returning responses via TCP. This is the architecture that makes it possible to connect 1990s-era field devices to modern cloud SCADA platforms without replacing any field hardware.

Common Modbus Errors and How to Fix Them

Modbus troubleshooting follows a consistent diagnostic pattern. The first step is always to determine whether the problem is at the physical layer (no communication at all), the link layer (CRC errors, garbled frames), or the application layer (exception codes, wrong values).

No Response

No response means the master sent a request and received nothing within the timeout period. For RTU networks, check: slave address (does the device actually have the address you are polling?), baud rate and parity settings (must match exactly), physical wiring (continuity on both A and B lines), and termination resistors. For TCP, verify IP address, subnet, port 502, and any firewall rules between master and device.

CRC Errors

CRC errors indicate that data was received but the checksum did not match - the data was corrupted in transit. Common causes in RTU networks: cable too long for the baud rate, missing or incorrect termination resistors, induced noise from nearby VFDs or motor cables (run Modbus cables in separate conduit from power wiring), ground potential differences between devices, or a failed or intermittent connection at a terminal block. CRC errors that occur only under certain load conditions suggest noise from motor starts or switching events.

Exception Code 01 - Illegal Function

The slave received the request but does not support the function code. Check the device manual to confirm which FCs are supported. Some lower-cost sensors only support FC03 (read holding registers) and FC04 (read input registers). Trying to use FC01 or FC05 on such a device will always return exception 01.

Exception Code 02 - Illegal Data Address

The most common exception in Modbus. The register address requested does not exist in the device. The most likely cause is the off-by-one addressing confusion: the master is requesting protocol address 40001 (which would be documentation address 80002) instead of protocol address 0 (documentation address 40001). Double-check the device's register map and the addressing mode configured in your Modbus master.

Exception Code 03 - Illegal Data Value

A write request contained a value outside the valid range for that register. For example, writing 0x0002 to a coil (only 0xFF00 and 0x0000 are valid) or writing a baud rate code of 99 when the device only accepts 0–3. Refer to the register map for valid value ranges.

Exception Code 04 - Slave Device Failure

The slave attempted to execute the function and failed internally. This usually indicates a hardware fault, a corrupted configuration in the device, or a firmware bug. The register map operation was valid; the device simply could not execute it. Cycle power to the device and check its diagnostic registers if it has them.

Modbus in SCADA Systems

Modbus and SCADA have been partners since SCADA systems first emerged. Understanding how a SCADA system interacts with Modbus devices clarifies both the protocol's role and its constraints. For a broader introduction to SCADA architecture, see our What Is SCADA? A Beginner's Guide.

Polling Architecture

A SCADA system communicates with Modbus devices by continuously polling them on a schedule. The SCADA master has a scan list - a configured set of devices, register addresses, and polling intervals. Every scan cycle, the master works through the list, sends FC03 (or whichever FC is appropriate) requests to each device, and stores the returned values in its internal database. Typical scan intervals range from one second for fast process variables like flow rate and pressure to 15–60 seconds for slower parameters like daily totalizers.

For large RTU networks with dozens of devices on a single RS-485 bus, polling every device quickly enough can be a challenge. At 9,600 baud, reading 10 registers from one device takes approximately 30 milliseconds including the response turnaround time. Polling 20 devices consecutively takes 600 milliseconds minimum. This is why baud rate selection and the number of registers read per request matter - reading 10 consecutive registers in one FC03 request is far more efficient than 10 individual single-register requests.

What Modbus Does Not Carry

Modbus is often described as a "dumb" protocol because it conveys raw data with no context. A Modbus register contains a 16-bit integer - nothing more. It carries no timestamp, no engineering units, no alarm state, no quality flag indicating whether the value is valid or stale. All of that context is added by the SCADA system based on configuration: the SCADA database knows that register 40001 is "Flow Rate" in gallons per minute, scaled by 0.1, with alarm thresholds at 10 gal/min and 500 gal/min.

This architecture means the SCADA configuration must be kept synchronized with the device register map. When a device's firmware is updated and a register address changes, the SCADA configuration must be updated to match - the protocol provides no mechanism for the device to self-describe its data.

Cloud SCADA and Modbus TCP Gateways

Modern cloud SCADA architectures bridge the gap between Modbus field devices and cloud platforms using edge gateways. The gateway polls Modbus RTU or TCP devices locally, applies engineering unit scaling, timestamps the values, and publishes them to the cloud via MQTT or HTTPS over a cellular or broadband connection. This approach keeps Modbus isolated on the local network while exposing data securely to cloud applications. See our comparison of MQTT vs OPC-UA for Industrial Monitoring for details on how that data transport works.

Modbus Limitations and Modern Alternatives

Modbus's longevity is a testament to its simplicity, but that simplicity comes with real limitations that every engineer working with it should understand clearly.

No Security

Modbus was designed when industrial networks were physically isolated. There is no authentication - any device on the network can send commands to any slave. There is no encryption - all data is transmitted in plaintext. There is no authorization - there is no concept of read-only versus read-write access at the protocol level. Connecting a Modbus TCP device to a network with internet access or multi-tenant users is a critical security vulnerability. This limitation has driven the development of security-aware replacements and the use of encrypted tunnels for any remote Modbus access.

Limited Data Types

Modbus registers are 16-bit unsigned integers. That's it. There is no native support for 32-bit integers, floating-point values, strings, timestamps, or arrays. Devices work around this with vendor-specific conventions: a 32-bit integer is stored in two consecutive holding registers, with the high word first (big-endian) or low word first (little-endian) depending on the manufacturer's choice. IEEE 754 single-precision floats are similarly split across two registers. This means the SCADA master must be configured to know not just the register address but the data type, word order, and byte order for every value - information that comes only from the device manual.

Polling-Only Architecture

In Modbus RTU, a slave can never initiate communication. It can only respond when asked. If an alarm condition occurs at a field device at 2:47 AM, the SCADA system will not know until it next polls that device - which could be seconds or minutes later depending on the scan cycle. There is no push mechanism, no interrupt, no event notification. Modbus TCP gateways with multiple simultaneous connections allow faster scan rates, but the fundamental polling paradigm remains.

Modern Alternatives

• OPC-UA: A rich, secure, self-describing protocol with a hierarchical data model, built-in authentication and encryption, support for complex data types, and both subscription (push) and read (poll) models. The preferred protocol for integration between SCADA systems and modern PLCs from major manufacturers.
• MQTT: A lightweight publish-subscribe protocol designed for constrained devices and unreliable networks. Clients publish data when it changes; subscribers receive it immediately. Excellent for IIoT and cloud SCADA. No native industrial data model - typically combined with a payload format like Sparkplug B for structured industrial data.
• DNP3: Dominant in electric utilities and water systems. Provides unsolicited responses, data quality flags, precise timestamps, and integrity polls. Designed for wide-area networks with unreliable links.
• EtherNet/IP: The Ethernet protocol used natively by Rockwell Automation (Allen-Bradley) PLCs. Uses the Common Industrial Protocol (CIP) over Ethernet, with implicit (cyclic) and explicit (on-demand) messaging.

Why Modbus Persists

Despite all of these limitations, Modbus remains a common choice for new device deployments for a straightforward reason: the alternatives all require more implementation complexity and cost. A $200 pressure transmitter that speaks Modbus RTU can be built with minimal firmware and hardware. The same transmitter with OPC-UA requires a more capable processor, more flash memory, a network stack, a certificate infrastructure for TLS, and engineering time to implement the OPC-UA specification correctly. For the vast majority of simple sensor and actuator applications, Modbus is good enough at low cost.

How Merobix Handles Modbus in Cloud SCADA

At Merobix, our cloud SCADA platform is built around the reality that the majority of industrial field hardware speaks Modbus - and will continue to do so for the foreseeable future. Our approach is to handle all Modbus complexity at the edge gateway level so that operators interact only with clean, engineering-unit data in the cloud dashboard.

Edge Gateway Polling

The Merobix gateway connects to field devices over both Modbus RTU (RS-485) and Modbus TCP (Ethernet), configurable per device. Polling intervals are set per register group - a high-frequency group for process variables like flow and pressure might poll every five seconds, while a low-frequency group for totalizers and configuration parameters polls every five minutes. This tiered approach minimizes bus loading on congested RS-485 networks while ensuring critical process values are current.

The gateway handles exception scanning automatically. If a device returns an exception code, the gateway logs it, flags the associated tags as bad quality, and triggers an alert in the cloud dashboard. Operators see a "Device Fault" alarm rather than a raw exception code 04. For details on how this works in oil and gas applications, see our guide to SCADA Monitoring for Oil & Gas in the Permian Basin.

Engineering Unit Scaling

The gateway applies register-level scaling configuration - multiplier, offset, data type (16-bit int, 32-bit int, IEEE 754 float, word order) - before data ever leaves the edge. The cloud platform receives engineering-unit values with timestamps. Operators never see raw register counts; they see gallons per minute, PSI, degrees Fahrenheit, and percentage open.

Efficient Cloud Publishing

Rather than forwarding every polled value to the cloud on every scan cycle, the Merobix gateway implements change-of-value (COV) publishing. A value is published only when it changes by more than a configured deadband, or when a configurable heartbeat interval expires to confirm the tag is still alive. This approach substantially reduces cellular data usage compared to naive time-based publishing, which is critical for sites on metered LTE connections. Data is published to the cloud via MQTT over TLS - the Modbus network at the field site remains completely isolated from the internet.

The Merobix platform supports Modbus RTU, Modbus TCP, and Modbus ASCII out of the box, alongside OPC-UA, DNP3, and MQTT Sparkplug B, so operators can consolidate data from mixed-protocol sites into a single dashboard. To see what this looks like in practice, visit our features page.

Frequently Asked Questions