What is Modbus Protocol? A Complete Guide

Modbus is a serial communication protocol originally developed by Modicon (now Schneider Electric) in 1979. It was designed to enable communication between programmable logic controllers (PLCs) and has since become the de facto standard for industrial electronic communication. Decades later, Modbus remains one of the most widely deployed protocols in industrial automation, building management, and energy systems.

Whether you're an automation engineer commissioning a new system or a developer integrating industrial devices, understanding Modbus is essential. This guide covers the protocol's architecture, how data is exchanged, and why it continues to thrive despite being over 40 years old.

A Brief History of Modbus

Modbus was published by Modicon in 1979 as a way for their PLCs to communicate over serial lines. The protocol was open and royalty-free from the start, which encouraged widespread adoption. In 1996, Modbus TCP was introduced to support Ethernet networks. The Modbus Organization (now part of the OPC Foundation) maintains the specification and ensures interoperability.

Key milestones:

• 1979 — Original Modbus specification published by Modicon for serial communication (RS-232)
• 1980s — RS-485 support added, enabling multi-drop networks with up to 247 devices
• 1996 — Modbus TCP/IP introduced for Ethernet-based communication
• 2004 — Modbus Organization takes over specification maintenance
• Today — Millions of devices worldwide use Modbus across manufacturing, energy, HVAC, and water treatment

How Modbus Works: The Master-Slave Architecture

Modbus uses a master-slave (also called client-server) architecture. One device acts as the master (client) and initiates all communication. One or more slave (server) devices respond to requests. Slaves never transmit data without being asked by the master.

The communication flow is straightforward:

1. The master sends a request to a specific slave, identified by its slave ID (1–247)
2. The request specifies a function code (what to do) and a data payload (which registers or coils to read/write)
3. The slave processes the request and sends a response back with the requested data or a confirmation
4. If something goes wrong, the slave returns an exception response with an error code

This request-response model is simple, predictable, and easy to debug — which is one reason Modbus has lasted so long.

Modbus Data Model

Modbus defines four types of data that a slave device can expose:

Data Type	Access	Size	Address Range	Common Use
Coils	Read/Write	1 bit	00001–09999	Digital outputs (relays, switches)
Discrete Inputs	Read Only	1 bit	10001–19999	Digital inputs (sensors, status)
Input Registers	Read Only	16 bits	30001–39999	Analog inputs (temperature, pressure)
Holding Registers	Read/Write	16 bits	40001–49999	Configuration, setpoints, control values

For a deeper dive into these register types and how they're used in practice, see our guide on Modbus register types.

Modbus Function Codes

Function codes tell the slave what operation to perform. The most common function codes are:

• FC01 — Read Coils
• FC02 — Read Discrete Inputs
• FC03 — Read Holding Registers
• FC04 — Read Input Registers
• FC05 — Write Single Coil
• FC06 — Write Single Holding Register
• FC15 — Write Multiple Coils
• FC16 — Write Multiple Holding Registers

Advanced function codes include FC08 (Diagnostics), FC22 (Mask Write Register), FC23 (Read/Write Multiple Registers), and FC43 (Read Device Identification). A professional Modbus tool like Modbus Simulator supports all 14 standard function codes.

Modbus Protocol Variants

Modbus comes in three main variants, each designed for different physical layers:

• Modbus RTU — Binary encoding over serial lines (RS-232/RS-485). Compact and efficient. Uses CRC-16 for error detection.
• Modbus ASCII — ASCII-encoded data over serial lines. Human-readable but slower. Uses LRC for error checking.
• Modbus TCP/IP — Modbus over Ethernet using TCP sockets on port 502. No slave ID limitation — uses IP addressing.

There are also hybrid variants such as RTU-over-TCP and ASCII-over-TCP for tunneling serial protocols over Ethernet. For a detailed comparison, see our article on Modbus TCP vs RTU vs ASCII.

Modbus Frame Structure

A Modbus RTU frame consists of:

Field	Size	Description
Slave Address	1 byte	Target device ID (1–247, or 0 for broadcast)
Function Code	1 byte	Operation to perform (1–127)
Data	N bytes	Register addresses, values, or counts
CRC	2 bytes	Error-checking value (CRC-16)

Modbus TCP wraps a similar payload inside a MBAP (Modbus Application Protocol) header that includes a transaction ID, protocol ID, and length field. The CRC is omitted since TCP provides its own error checking.

Why Modbus is Still Relevant

Despite being over four decades old, Modbus continues to dominate industrial communication for several reasons:

• Simplicity — The protocol is straightforward to implement, debug, and understand. New engineers can learn it in hours, not weeks.
• Open standard — No licensing fees or proprietary requirements. Anyone can implement Modbus freely.
• Universal support — Virtually every PLC, HMI, SCADA system, and industrial sensor supports Modbus out of the box.
• Proven reliability — Decades of field deployment have proven Modbus reliable in harsh industrial environments.
• Low overhead — Minimal protocol overhead means it works well even on constrained devices and slow serial links.

Getting Started with Modbus

If you're new to Modbus, the best way to learn is hands-on. Using a Modbus simulator tool, you can create virtual slave devices and practice reading and writing registers without needing physical hardware.

For step-by-step instructions on setting up your first Modbus connection, check out our guide on how to test Modbus devices.