Modbus is an automation protocol originally specified for serial networks such as RS-485 (Modbus RTU). It has since been adapted for Ethernet networks (Modbus TCP).

At its core, Modbus functions as a request-reply protocol. A single device (the master) initiates queries to which one of the connected devices (a slave) responds. This master-slave dynamic ensures smooth data transfer and network operations.

Data in Modbus is structured around registers. Each register holds a piece of data from a connected device, such as a sensor reading, and these registers can be read by or written to by the master device. The protocol supports multiple data types, including coils or discrete outputs, and holding registers, which can be read and written.

From its roots in factory settings, Modbus has expanded its reach over the decades. Today, it’s used in building automation systems, transportation infrastructure, energy management systems, and many other sectors. Its lasting resilience and adaptability underscore its reliability and the trust industries place in it for seamless communication between devices.

Two predominant Modbus iterations command widespread use: Modbus RTU and Modbus TCP. The former, Modbus RTU, frequently employed over serial lines (either RS-232 or RS-485), represents the classic version of the protocol. In contrast, Modbus TCP caters to Ethernet networks, promising enhanced speed and broader network adaptability. Notably, Modbus TCP typically uses port 502 for communication, making it an essential port to ensure open and secure when deploying Modbus over TCP/IP networks.

Interoperability is a hallmark of Modbus. Its open standard means that it can be used with a vast array of devices regardless of the manufacturer. This, coupled with its simplicity, has led to its extensive adoption in industrial applications.

The communication between devices in Modbus follows a well-defined message structure. Each message (or frame) is composed of different fields confirming the integrity and origin of the message. These fields typically include:

    • Address Field: This specifies which slave device the message is for (in case of Modbus RTU) or which Modbus application (in case of Modbus TCP).

    • Function Code: This dictates the type of action to be taken, be it reading, writing, or other diagnostic functions.

    • Data Field: This contains additional information or parameters needed for the function or any data being transferred.

    • Error Check (CRC or LRC): In Modbus RTU, a Cyclic Redundancy Check (CRC) or Longitudinal Redundancy Check (LRC) is used to detect any errors in the message.

Add support or development partner services

Get a team of experts to assist you! Support is provided by engineers with extensive knowledge of embedded realtime systems. Wan’t more assistance? Get a resident engineer or let RT-Labs take on a role as a complete solution provider. Our customers can be divided into three categories depending on how much one wants RT-Labs to be engaged in the project at hand.

Software Support

Get your own support person! Many times it is a bad move to address support issues as a generic service. Available with all licensed purchases.

Cooperative team

Work with us as a team member. RT-Labs is often invited to be a part of the team, together with in- house technicians or consultants contracted by the customer

Development partner

Do you need to rapidly deploy a complete solution? Do you have a set budget and want better cost control? Do you find it difficult to staff your project? Give us a call.

Call an expert

We don’t do gatekeeping! Call us to get in contact with a skilled person with several control system projects under the belt.

Daniel Udd

Daniel Udd

Software platform, EtherCAT, CANOpen, Group Manager

+46 768 50 74 55

Hans-Erik Floryd

Hans-Erik Floryd

CTO, Software platform, CANopen, EtherCAT

+46 709 68 38 93