Modbus Protocol Guide

Modbus is a widely-adopted open-source protocol that enables communication between hundreds of devices from multiple manufacturers. This overview discusses what the Modbus protocol is, how it works, and how to implement it in your process control system.

Table of Contents

The Modbus protocol has a long-standing history in industrial automation. Developed in 1979 by Modicon (now Schneider Electric), Modbus enables communication between hundreds of devices, including Human-Machine Interfaces (HMIs), Programmable Logic Controllers (PLCs), Remote IO modules, smart sensors, and more. Its master-slave architecture allows devices to share data efficiently, whether through early serial communication methods like RS-232 or through modern TCP/IP over Ethernet.

Today, Modbus remains in use in industrial control systems because of its proven reliability, broad compatibility, and ability to evolve with modern networking technologies. Follow along as we take a deeper look at Modbus, exploring the advantages, data model, and fundamental architecture of this powerful open standard protocol.

Advantages

Simplicity

One of Modbus’s greatest strengths is its simplicity. The protocol is straightforward to understand and implement, requiring minimal overhead. This makes it easy for engineers to configure, set up, and integrate into both new and existing systems. Whether using Modbus RTU for serial communication or Modbus TCP/IP for Ethernet networks, the protocol’s clear structure ensures quick deployment and reliable operation.

Open and Royalty-Free

Modbus is an open, royalty-free protocol, meaning that any manufacturer can implement it without licensing fees. This has led to its widespread adoption, ensuring compatibility between a wide range of devices from different manufacturers. This flexibility helps businesses avoid vendor lock-in and promotes interoperability across diverse environments.

Versatility

Modbus is versatile enough to support both simple and complex industrial applications. It can operate over serial communication (Modbus RTU) or Ethernet networks (Modbus TCP/IP), allowing for deployment in both local and distributed systems. Its data model, which includes coils, discrete inputs, input registers, and holding registers, makes Modbus suitable for reading both binary (on/off) data and more complex analog values. This flexibility makes it useful for everything from small device networks to large-scale SCADA systems.

Reliability

With over four decades of use in industrial environments, Modbus has a long history of reliability. Its ability to maintain stable communication even in harsh environments has made it a trusted solution for control applications. Whether for monitoring smart sensors, controlling actuators, or exchanging data between systems, Modbus ensures robust and consistent communication.

Wide Industry Support

A vast array of industrial devices and control systems offer Modbus support, making it easy to integrate into existing setups. From PLCs to HMIs and SCADA systems, Modbus provides a common language that many devices can speak, reducing the complexity of industrial networks. Its broad support means that manufacturers often include Modbus compatibility as a standard feature in their products, enhancing ease of integration across various platforms.

Control System Diagram Using Modbus — *Figure 1 – Network using Modbus protocol to connect devices from multiple manufacturers*

How Modbus Works

Master-Slave Architecture

At the core of Modbus is a master-slave (client/server) communication model. In this model, the master (client) device, often a PLC or HMI, initiates communication by sending requests to one or more slave (server) devices, such as VFDs or control modules. The slaves will respond to the master’s requests but cannot communicate with each other directly. This architecture keeps communication simple and organized, allowing the master device to oversee and control the entire system.

Transport Layers

Modbus typically operates over two primary transport layers: Modbus RTU and Modbus TCP/IP.

Modbus RTU uses serial communication (RS-232, RS-485) and is well-suited for smaller local networks. It provides a compact, binary representation of data, making it efficient for devices that need to communicate in real time. Modbus RTU also supports multi-drop networking when using RS-485, allowing multiple devices to communicate over a single serial bus.

In contrast, Modbus TCP/IP operates over Ethernet, enabling faster and more reliable communication over complex networks. This version allows Modbus to integrate easily with modern IT infrastructures and internet-based control systems.

For systems using both serial and TCP/IP connections, Modbus RTU over TCP provides a streamlined solution. RTU over TCP allows for serial devices to communicate using the TCP transport layer by wrapping RTU frames coming from serial devices within TCP/IP packets. This means that both RTU and TCP/IP communications can be sent across the same Ethernet connection.

Modbus RTU

The Modbus RTU (Remote Terminal Unit) protocol is a widely used serial communication protocol in industrial automation and control systems.

Operating over serial interfaces like RS-232, RS-422, or most commonly RS-485, Modbus RTU uses a binary format for data representation, which ensures efficient and compact messaging. Each message includes a Cyclic Redundancy Check (CRC) for error detection, enhancing communication reliability.

Modbus TCP/IP

Modbus TCP/IP is a variant of the Modbus protocol designed to facilitate communication over Ethernet networks using the TCP/IP stack. Unlike Modbus RTU, it encapsulates Modbus messages within TCP/IP packets and includes a Modbus Application Protocol (MBAP) header for additional routing and transaction management. This header replaces the CRC used in Modbus RTU, as TCP/IP layers inherently provide error checking and correction. Modbus TCP/IP maintains the same function codes and data structures as Modbus RTU, ensuring compatibility while leveraging higher data transfer rates and broader network integration capabilities. It supports client-server communication models and allows for multiple simultaneous connections, making it suitable for complex networked environments.

Modbus RTU over TCP

Modbus RTU over TCP is a method of transmitting Modbus RTU frames within TCP/IP packets without altering the original RTU frame structure. This approach encapsulates the entire Modbus RTU message—including the CRC—inside a TCP/IP packet, enabling traditional serial Modbus devices to communicate over modern Ethernet networks transparently. It bridges the gap between legacy Modbus RTU devices and modern networks without requiring changes to the device firmware or protocol implementation.

While this method allows for easy integration and extended communication ranges, it may introduce redundant error checking due to the presence of both CRC and TCP/IP error mechanisms. Additionally, since it is not an official Modbus standard like Modbus TCP/IP, compatibility between different devices and software may vary. For these reasons it is often best to use Modbus TCP/IP whenever possible.

Modbus ASCII

Modbus ASCII is a variant of the Modbus serial protocol that encodes messages in ASCII. In this format, each byte of data consists of two hexadecimal ASCII characters, making the messages human-readable but increasing their size compared to Modbus RTU’s binary format. Communication in Modbus ASCII begins with a colon (:) character and ends with a carriage return and line feed (CRLF), serving as start and end delimiters for each message.

Error checking uses a Longitudinal Redundancy Check (LRC) instead of the Cyclic Redundancy Check (CRC) used in Modbus RTU. Modbus ASCII is beneficial in environments where the communication medium supports only text-based data or where message readability is important. However, due to its larger message size and slower data transmission, it is less efficient than Modbus RTU and is not a viable choice for applications where high-speed communication is critical.

Data Model

The Modbus data model revolves around a set of data types that represent distinct kinds of information in a device. Accessing these data types requires using specific function codes defined by the protocol. The Modbus data model consists of four primary categories:

Coils – 0x (Read/Write Bits): Single bit read/write registers used to represent binary output states.
- Function Codes: 1 (Read Coils), 5 (Write Single Coil), 15 (Write Multiple Coils)
- Address Range: Typically addresses start from 00000.
- Usage: Control outputs like relays, actuators, or indicators.
Discrete Inputs – 1x (Read-Only Bits): Single bit read-only registers representing binary input states.
- Function Codes: 2 (Read Discrete Inputs)
- Address Range: Typically addresses start from 10000.
- Usage: Monitor inputs like switches or status flags.
Input Registers – 3x (Read-Only Words): 16-bit read-only registers used to hold analog input data.
- Function Codes: 4 (Read Input Registers)
- Address Range: Typically addresses start from 30000.
- Usage: Read analog inputs, such as temperature or pressure values from smart sensors.
Holding Registers – 4x (Read/Write Words): 16-bit read/write registers used for general-purpose storage.
- Function Codes: 3 (Read Holding Registers), 6 (Write Single Register), 16 (Write Multiple Registers)
- Address Range: Typically addresses start from 40000.
- Usage: Store parameters, configurations, and operational data.

Illustration Showing Modbus Register Types

Message Structure

The Modbus protocol uses a specific message structure to maintain data integrity when communicating with other devices. The Modbus message structure is designed to be simple and efficient, providing flexibility while enabling a range of operations. Modbus RTU and Modbus TCP each have a slightly different structure, as shown below.

A Modbus RTU message consists of:

Slave Address (1 Byte): Identifies the target device in a network, ranges between 1 and 247.
Function Code (1 byte): Specifies the operation to perform, such as reading or writing data.
Data (Variable length): Contains the details needed for the function code. If the function code is a read operation, the data field specifies the starting address and the number of items to read. For write operations, it includes the address and the data values to be written.
Cyclic Redundancy Check (CRC) (2 bytes): A checksum calculated from the message content to ensure data integrity. The CRC is checked by the receiving device to confirm that the message has not been corrupted during transmission.

A Modbus TCP message consists of:

MBAP Header (7 Bytes):
- Transaction Identifier (2 Bytes): Used to match requests with responses.
- Protocol Identifier (2 Bytes): Always set to 0x0000 to indicate the Modbus protocol.
- Length (2 Bytes): Specifies the number of remaining bytes in the message.
- Unit Identifier (1 Byte): Indicates the target address, similar to the slave address in Modbus RTU.
Function Code (1 byte): Defines the operation requested, identical to the function code in Modbus RTU.
Data Field (Variable length): Contains the function-specific details, such as the address and the data to be read or written.

Notes

Bit Representation: Coils and discrete inputs are single bits.
16-bit Address Space: Each data type uses a 16-bit addressing scheme, allowing for up to 65,536 addresses per data type. It is common practice to combine two or more registers to represent 32-bit integers or floating-point numbers, though the method to do this may vary between devices. For example, when using EBPro to configure a project the “4x_Double” register type will combine two 16-bit holding registers into a single 32-bit space.
Zero-Based vs. One-Based Addressing: Modbus addresses can be zero-based or one-based, depending on the implementation. For one-based addressing, all addresses start at one instead of zero. Consult device documentation to determine the correct addressing method.
Endianness: Modbus specifies Big-Endian byte order for registers (most significant byte first). However, when dealing with multi-register values, different devices may use different word orders.

Function Codes

In Modbus, function codes define how the master interacts with the slave devices. Common function codes include:

Read Coil (Function Code 01): Allows the master to read the state of one or more coils.
Write Single Coil (Function Code 05): Allows the master to control the state of a specific coil.
Read Holding Registers (Function Code 03): Retrieves data from holding registers for processing.

A complete listing of Modbus function codes is shown below. Please note that support for these functions may vary depending on the devices you are using.

Function Code Table

Function Type			Function Name	Function Code	Note
Data Access	Bit access	Physical Discrete Inputs	Read Discrete Inputs	2
		Internal Bits or Physical Coils	Read Coils	1
			Write Single Coil	5
			Write Multiple Coils	15
	16-bit access	Physical Input Registers	Read Input Registers	4
		Internal Registers or Physical Output Registers	Read Multiple Holding Registers	3
			Write Single Holding Register	6
			Write Multiple Holding Registers	16
			Read/Write Multiple Registers	23
			Mask Write Register	22
			Read FIFO Queue	24
	File Record Access		Read File Record	20
	File Record Access		Write File Record	21
Diagnostics			Read Exception Status	7	Serial Only
			Diagnostic	8	Serial Only
			Get Com Event Counter	11	Serial Only
			Get Com Event Log	12	Serial Only
			Report Server ID	17	Serial Only
			Read Device Identification	43
Other			Encapsulated Interface Transport	43

The master’s request will contain the function codes, instructing the slaves to either send data back or update specific values. By using different function codes, Modbus ensures flexible, targeted communication between master and slave devices. For a more detailed description of the Modbus protocol and its function codes, please visit The Modbus Organization website.

Using the Modbus Protocol

Serial vs. Ethernet

When implementing Modbus, selecting the appropriate version depends on device requirements and your network infrastructure. Modbus RTU is ideal for serial communication over RS-232 or RS-485, commonly used in smaller or legacy systems. Serial communication is known for its efficiency and simplicity but has limits in terms of speed and distance compared to modern networks.

On the other hand, Modbus TCP/IP operates over Ethernet, providing faster communication speeds and easier integration with more complex, distributed networks. When choosing between them, consider factors like network speed requirements, system complexity, and the existing wiring infrastructure.

Setting Up Modbus Communication

Selecting Hardware and Software
Start by ensuring that your system components support Modbus communication. Many industrial devices come with built-in Modbus support, but you may need dedicated Modbus modules or gateways for some setups.
Configuring Master and Slave Devices
In the Modbus protocol, the master device initiates communication, while slave devices respond to its requests. Begin by assigning each slave device a unique address. For Modbus RTU, configure the baud rate (speed of communication), parity, and stop bits, ensuring all devices share the same settings. For Modbus TCP/IP, configure IP addresses and network settings to enable seamless communication across Ethernet.
Understanding Baud Rate and Address Setup for Modbus RTU
When using Modbus RTU, setting the baud rate is crucial for reliable communication. Higher baud rates allow for faster data transmission but may increase the risk of errors over long distances. Ensure that all devices share the same baud rate, parity, and stop bit configuration. Properly assign addresses to each device to avoid conflicts.
Network Configuration for Modbus TCP/IP
For Modbus TCP/IP, each device in the network needs a unique IP address and must have access to the same local subnet. Ensure your network infrastructure supports the desired data speed and can handle the number of devices communicating simultaneously.

Modbus and EBPro (Video Tutorial)

Setting up communication for Modbus devices in EBPro is straightforward, requiring just a few steps to get connected to any Maple Systems HMI. For a demonstration, please review our step-by-step video tutorial below for more information on how to connect an HMI and PLC using the Modbus protocol.

Watch on YouTube

Modbus Data Types in EBPro

In addition to the standard 0x, 1x, 3x, and 4x Modbus registers, EBPro supports additional data types that can be used for specific purposes. The following table details the purpose of each data type and their associated function codes.

Troubleshooting Tips

Diagnosing Communication Issues

If devices are not communicating properly, check for mismatches in baud rate, address conflicts, or wiring issues for Modbus RTU. For Modbus TCP/IP, verify that IP addresses and subnet configurations are correct. Incorrect device configuration is the most common cause of communication failures, so it is best to confirm your settings before attempting other troubleshooting steps.

Tools for Monitoring Modbus Traffic

Modbus monitoring and simulation tools can help you confirm your settings before starting operations. Modbus testing tools such as ModRSsim can be used to test and analyze network traffic, providing both TCP/IP and RTU slaves for testing. This tool can help identify issues like incorrect function codes, invalid addresses, or data corruption, allowing you to quickly pinpoint and resolve communication problems in both Modbus RTU and Modbus TCP/IP setups.

Considerations

Security: Modbus does not include inherent security features like encryption or authentication. Additional measures may be taken to protect network traffic, such as routing Modbus communications through a Modbus-OPC/UA gateway for additional security.

Address Limitations: While the Modbus address space is extensive, some devices may only have access to a subset of these addresses. It is best to consult the manufacturer’s documentation to determine the accessible memory ranges for your device before connecting.

Data Types: The basic Modbus data model does not natively support complex data types like floating-point numbers, though these data types may be used through additional conventions or combining registers. For example, in the EBPro software using the “4x_Double” data type will automatically combine two 16-bit registers into a single 32-bit register for holding larger values.

Conclusion

The Modbus protocol remains a cornerstone of modern industrial control systems, thanks to its simplicity, versatility, and open nature. Whether used in PLC communication, SCADA systems, or energy monitoring, Modbus continues to provide reliable, efficient data exchange across a variety of industrial applications. As we move toward Industry 4.0 and the Industrial Internet of Things (IIoT), Modbus is likely to evolve and find new applications, integrating seamlessly with advanced technologies to meet future automation needs.

If you’re planning your next industrial project, consider implementing Modbus for its proven performance and flexibility. Explore our range of Modbus-compatible PLCs, HMIs, Remote IO, and Gateways, and ensure your system is ready for both today’s challenges and tomorrow’s opportunities.

Resources

Controller Information Sheets

The list below contains every Modbus driver available for use in the EBPro HMI configuration software. Click on the link for a specific driver to view the Controller Information Sheet for that device type.

NOTE: EBPro has multiple drivers that use the Modbus protocol, some of which are brand-specific. If you encounter connection issues when using a generic Modbus driver, try searching for the device manufacturer in the EBPro driver list to see if there is a Modbus version specific to that manufacturer.

Generic Drivers

Brand-Specific Drivers

Contact Us

Would you like to know more? Our friendly and knowledgeable sales team can connect you to the resources you need. For information on pricing, availability, and more, send an email message to sales@maplesystems.com, or contact our team by phone at (425) 745-3229.

cMT-G03 – Communication Protocol Gateway

View All Industrial Control Software

AVEVA Edge

Linux Ubuntu

HMI Software (EBPro)

HMI+PLC Software (MAPware -7000)

PLC Software (MapleLogic)