By the end of this section, you will be able to:
Before diving into this chapter, you should be familiar with:
Modbus is 45+ years old and still the most common industrial protocol. Why?
Analogy: Modbus is like the telephone: - Everyone knows how to use it - It works everywhere - New technologies (Zoom, Teams) are better but not always necessary - When something needs to “just work,” people reach for the phone
How Modbus Works (Simple Version):
“Modbus was invented in 1979? That’s ancient!” said Sammy the Sensor.
Max the Microcontroller smiled. “And it STILL runs millions of industrial devices today! Modbus is the simplest protocol you’ll ever meet. One master asks a question, one slave answers. No subscriptions, no brokers, no exchanges. Just ‘what’s register 40001?’ and the answer comes back.”
“It uses numbered addresses instead of names,” explained Lila the LED. “Register 30001 might be a temperature sensor, register 30002 might be a pressure sensor. The master has a map that says what each number means. Simple but effective – factory workers have been using it for over 40 years.”
Bella the Battery appreciated the simplicity: “Modbus RTU uses a serial cable (RS-485) and barely any processing power. Modbus TCP runs over Ethernet. Both are so lightweight that even the tiniest microcontroller can implement them. Sometimes the oldest solution is still the most practical one!”
This sequence diagram shows Modbus polling timing: master queries each slave in turn, waits for response, handles timeouts for offline devices.
Key Characteristics:
Core Concept: Modbus uses a simple memory-mapped addressing scheme with four distinct register types—coils (1-bit R/W), discrete inputs (1-bit R), input registers (16-bit R), and holding registers (16-bit R/W)—each accessed by a numeric address from 0 to 65535.
Why It Matters: The beauty of Modbus is its simplicity: every device presents its data as a flat array of addresses. However, this simplicity comes with a catch—address assignments are vendor-specific. Address 40001 might be temperature on one device and pressure on another. Always consult the device’s register map documentation before integration.
Key Takeaway: When documenting a Modbus integration, create a register map table showing address, data type, scaling factor, and engineering units. This becomes your single source of truth for the entire project lifecycle.
| Type | Address Range | Size | Access | Typical Use |
|---|---|---|---|---|
| Coils | 0-65535 | 1 bit | R/W | Digital outputs, relay control |
| Discrete Inputs | 0-65535 | 1 bit | R | Digital inputs, switches |
| Input Registers | 0-65535 | 16 bit | R | Analog inputs, sensor readings |
| Holding Registers | 0-65535 | 16 bit | R/W | Configuration, setpoints |
16-bit Register Encoding for Common Data Types:
| Data Type | Registers | Encoding Example |
|---|---|---|
| 16-bit Integer | 1 | 0x1234 = 4660 |
| 32-bit Integer | 2 | Registers 0-1, Big-endian |
| 32-bit Float | 2 | IEEE 754, word order varies |
| String | N | 2 chars per register |
| Scaled Integer | 1 | 255 × 10 = 25.5°C |
RS-485 Specifications:
| Parameter | Value | Notes |
|---|---|---|
| Max Distance | 1200 m (4000 ft) | With proper cabling |
| Max Devices | 32 unit loads | 247 with repeaters |
| Baud Rate | 9600-115200 | 9600 most common |
| Wiring | Twisted pair | Shielded recommended |
| Termination | 120Ω | Both ends of bus |
| Address | Function | Data | CRC-16 |
| 1 byte | 1 byte | N bytes | 2 bytes|Example: Read Holding Registers (Function 03)
Request:
| 01 | 03 | 00 00 | 00 02 | C4 0B |
| ID | Fn | Start | Count | CRC |Response:
| 01 | 03 | 04 | 01 F4 | 00 64 | B8 44 |
| ID | Fn | Bytes| Reg 0 | Reg 1 | CRC || Code | Name | Description |
|---|---|---|
| 01 | Read Coils | Read 1-2000 coil statuses |
| 02 | Read Discrete Inputs | Read 1-2000 input statuses |
| 03 | Read Holding Registers | Read 1-125 registers |
| 04 | Read Input Registers | Read 1-125 registers |
| 05 | Write Single Coil | Write one coil |
| 06 | Write Single Register | Write one register |
| 15 | Write Multiple Coils | Write 1-1968 coils |
| 16 | Write Multiple Registers | Write 1-123 registers |
| Transaction ID | Protocol ID | Length | Unit ID |
| 2 bytes | 2 bytes | 2 bytes | 1 byte |
| Client-set | 0x0000 | Remaining | RTU addr|Key Differences from RTU:
from pymodbus.client import ModbusTcpClient
# Connect to Modbus TCP server
client = ModbusTcpClient('192.168.1.10', port=502)
client.connect()
# Read holding registers (address 0, count 10)
result = client.read_holding_registers(address=0, count=10, slave=1)
if not result.isError():
print(f"Registers: {result.registers}")
# [500, 100, 255, 0, 1234, ...]
# Read temperature (register 0, scaled by 10)
temp_raw = client.read_holding_registers(0, 1, slave=1).registers[0]
temperature = temp_raw / 10.0 # 500 → 50.0°C
# Write setpoint (register 100 = 60.0°C)
client.write_register(100, 600, slave=1)
# Read coils (digital outputs)
coils = client.read_coils(0, 8, slave=1)
print(f"Pump status: {'ON' if coils.bits[0] else 'OFF'}")
# Write coil (turn on pump)
client.write_coil(0, True, slave=1)
client.close()#include <ModbusMaster.h>
ModbusMaster node;
void setup() {
Serial.begin(9600);
Serial1.begin(9600); // RS-485 bus
node.begin(1, Serial1); // Slave ID 1
node.preTransmission(preTransmission); // RS-485 direction control
node.postTransmission(postTransmission);
}
void loop() {
uint8_t result = node.readHoldingRegisters(0, 2); // Read 2 registers
if (result == node.ku8MBSuccess) {
float temperature = node.getResponseBuffer(0) / 10.0;
Serial.print("Temperature: ");
Serial.println(temperature);
}
delay(1000);
}
void preTransmission() { digitalWrite(DE_PIN, HIGH); } // Enable TX
void postTransmission() { digitalWrite(DE_PIN, LOW); } // Enable RX| Symptom | Likely Cause | Solution |
|---|---|---|
| No response | Wrong address, baud rate | Verify slave ID and serial settings |
| CRC errors | Noise, termination | Add termination, use shielded cable |
| Timeout | Polling too fast | Increase delay between requests |
| Wrong data | Byte order | Check endianness (big/little) |
| Intermittent | Ground loop | Use isolated RS-485 converter |
| Vulnerability | Risk | Mitigation |
|---|---|---|
| No authentication | Anyone can send commands | Network segmentation |
| No encryption | Data visible on wire | VPN for remote access |
| No authorization | All clients equal | Firewall rules |
| Broadcast abuse | DoS via address 0 | Block broadcasts |
:
Modbus is simple by design—request/response with 4 register types
RTU uses RS-485 (serial, up to 1200m, 247 devices)
TCP uses Ethernet (port 502, unlimited devices, faster)
Register addressing varies by vendor—always check documentation
No built-in security—use network segmentation and firewalls
Still the most common industrial protocol for simple I/O
Modernize by adding gateways alongside existing SCADA rather than replacing proven installations
| Chapter | Focus | Why Read It |
|---|---|---|
| OPC-UA Fundamentals | Modern industrial information model with built-in security, pub/sub, and cloud integration | Learn how OPC-UA solves the security and scalability gaps that Modbus leaves open |
| Industrial Protocols Overview | Side-by-side comparison of Modbus, PROFINET, EtherNet/IP, EtherCAT, and OPC-UA | Develop the decision framework to select the right protocol for any industrial deployment |
| Industrial Ethernet — PROFINET & EtherNet/IP | Deterministic Ethernet protocols for real-time motion control and high-speed I/O | Understand when Modbus RTU bandwidth limits make a migration to industrial Ethernet worthwhile |
| Application Protocols Overview | MQTT, AMQP, CoAP, and REST for IoT messaging above the transport layer | Connect Modbus gateway data to cloud platforms using the messaging protocols that cloud services speak natively |
| Networking Basics | TCP/IP stack, subnetting, and Ethernet fundamentals | Strengthen the network-layer knowledge required to design and troubleshoot Modbus TCP deployments |
| Gateway Architectures | Edge gateway design patterns for bridging OT field buses to IT cloud systems | Apply the Modbus-to-MQTT gateway pattern at scale within a reference IoT system architecture |