Modbus RTU & TCP: The Universal Language of Industry

Published by LogicHobbyist Automation Lab — A comprehensive, hands-on guide for engineers, system integrators, and enthusiasts. From basic theory to implementation and troubleshooting.

1. Introduction & Core Concepts

Modbus, developed by Modicon (now Schneider Electric) in 1979, is the most widely used industrial communication protocol. Its primary strength is its simplicity: it is an open, royalty-free standard that is easy to understand and implement. At its heart, Modbus allows a single “master” device to read data from and write data to multiple “slave” devices over various types of physical links, most commonly serial (RS-485) and Ethernet.

The Network Models

It’s important to distinguish the two main variants:

• Modbus RTU (Serial): Uses a strict Master/Slave model. The master initiates all communication, and slaves only respond when addressed. Only one master can exist on a single RS-485 network.
• Modbus TCP (Ethernet): Uses a more flexible Client/Server model. Multiple clients can connect to a single server, and the server can handle requests from multiple clients simultaneously.

The Four Data Tables

Every Modbus device organizes its data into four standard tables. Before you can read or write data, you must know which table the information resides in.

Table Name	Address Range (PLC)	Data Size	Access	Description
Coils	00001 – 09999	1-bit (Boolean)	Read/Write	Digital outputs, relays, flags.
Discrete Inputs	10001 – 19999	1-bit (Boolean)	Read-Only	Physical switches, sensor states.
Input Registers	30001 – 39999	16-bit (Word)	Read-Only	Analog data: temperature, pressure, speed.
Holding Registers	40001 – 49999	16-bit (Word)	Read/Write	Configuration, setpoints, accumulated values.

2. Modbus RTU vs. TCP: A Detailed Comparison

While both protocols serve the same purpose, their underlying physics dictate their use cases. The Modbus Application Protocol (PDU) is identical; only the encapsulation method changes.

The Critical RTU Timing: T3.5 and T1.5

Unlike TCP, which uses a packet header for framing, Modbus RTU relies on silent intervals on the serial line to know when a message starts and ends. This is a common source of errors for beginners.

• T3.5 (Inter-Frame Delay): A pause of at least 3.5 character times indicates the end of one message and the start of the next.
• T1.5 (Inter-Character Delay): The maximum allowed gap between bytes within a single message. If exceeded, the receiving device discards the message.

If your RTU network is not working, verify your software’s serial settings correctly handle these timings.

Comparison Summary

Feature	Modbus RTU (Serial)	Modbus TCP (Ethernet)
Architecture	Master/Slave (one master)	Client/Server (multiple clients)
Physical Layer	RS-232, RS-485	Ethernet (IEEE 802.3)
Speed	9.6 – 115.2 kbit/s	10/100 Mbit/s+
Typical Latency	50–100 ms per device	Sub-millisecond
Error Checking	CRC-16	TCP/IP stack + Ethernet CRC
Max Devices	32 (without repeater)	Virtually unlimited
Cabling Distance	Up to 1200 m	100 m per segment (extendable)

3. The Packet Structure

Understanding the raw packet format is key to troubleshooting.

4. The Essential Function Codes

A device’s capabilities are defined by the function codes it supports. Quick reference:

Code (Hex)	Function Name	Data Type	Access
01 (0x01)	Read Coils	Digital Output	Read
02 (0x02)	Read Discrete Inputs	Digital Input	Read
03 (0x03)	Read Holding Registers	Analog Output/Setting	Read/Write
04 (0x04)	Read Input Registers	Analog Input	Read
05 (0x05)	Write Single Coil	Digital Output	Write
06 (0x06)	Write Single Register	Holding Register	Write
15 (0x0F)	Write Multiple Coils	Digital Output	Write
16 (0x10)	Write Multiple Registers	Holding Register	Write

5. A Practical Walk‑Through: From Theory to Implementation

Let’s move from theory to practice. Before you connect to real hardware, you can master Modbus using free, powerful software on your own PC.

Step 1: Know Your Tools

• Modbus Client (Master): QModMaster – open‑source, cross‑platform GUI.
• Modbus Server (Slave): ModbusPal (Java) or Modbux – both free.

Step 2: Set Up Your Test Bench

1. Install both client and server simulators.
2. In ModbusPal, create a slave with ID=1, add holding registers at addresses 0,1,2 with dummy values (e.g., 1234, 5678, 9999). Start the slave.
3. In QModMaster, connect to Modbus TCP, localhost, port 502, slave ID=1.

Step 3: Read Your First Register

Use function code 03, starting address 0, quantity 3. Read – you should see the values from ModbusPal.

Step 4: Write Your First Register

Use function code 06, address 0, new value. Write – the value updates in both client and server.

6. Real Hardware for Practice – Cheap & Easy

Once you are comfortable with simulators, the next step is to talk to real physical devices. Here are three extremely affordable components to build your own Modbus RTU network (total under $30).

All three devices speak Modbus RTU over RS‑485. Connect them to the USB‑RS485 converter, then use QModMaster or a Python script to read weight, toggle relays, and read inputs.

7. Take It Further: Complete DIY Projects

Ready to build your own Modbus‑enabled hardware or a full HMI? These step‑by‑step tutorials show you how.

8. Practical Implementation: Bridging to Code

Python example using pymodbus (TCP)

from pymodbus.client import ModbusTcpClient

client = ModbusTcpClient('127.0.0.1', port=502)
if client.connect():
    result = client.read_holding_registers(address=0, count=1, slave=1)
    if not result.isError():
        print(f"Register 0 value: {result.registers[0]}")
    else:
        print(f"Error: {result}")
    client.close()
else:
    print("Connection failed.")