How machines communicate: Modbus protocol

The Modbus protocol is the most common industrial protocol for M2M-interaction. It is a de facto standard and is supported by almost all manufacturers of industrial equipment.

Due to its versatility and openness, the standard allows the integration of equipment from different manufacturers. Modbus is used to collect readings from sensors, control relays and controllers, monitoring, etc.

In the article we will analyze the implementation of the Modbus protocol, data formats, software for working with the protocol. Let's try in practice to read data from the device.

Modbus history

Modbus was introduced in 1979 by Modicon (now Schneider Electric). It was an open standard working on the RS-232 interface. Later, a protocol implementation for RS-485 and Modbus TCP interfaces appeared. The protocol quickly gained popularity, and many manufacturers began to implement it in their devices.
Later, the rights to the protocol were transferred to the non-profit organization Modbus Organization, which until now owns the standard.

In the description of the Modbus standard, terminology inherited from the relay logic languages ​​is used. For example, some registers are called coils (English coil).

Physical level

  • RS-232/422/485 – serial interfaces common in industry. RS-422/485 interfaces provide signal range up to 1200 meters. Modbus RTU / ASCII protocols are used.
  • TCP / IP networks – any ethernet interfaces can serve as a physical data transmission channel. Modbus TCP protocol used

Logical level


Modbus protocol differences

Modbus ASCII

The data is encoded with characters from an ASCII table and transmitted in hexadecimal format. The beginning of each package is indicated by a colon, and the end by a carriage return and line break. This allows the protocol to be used on long delay lines and equipment with less accurate timers.

Modbus RTU

In the Modbus RTU protocol, the data is encoded in binary format, and the time slot is used as a packet delimiter. This protocol is critical for delays and cannot work, for example, on modem lines. At the same time, the overhead of data transmission is less than in Modbus ASCII, since the length of the messages is less.

Modbus TCP

The packet structure is similar to Modbus RTU, the data is also encoded in binary format, and packed into a regular TCP packet, for transmission over IP networks. The integrity check used in Modbus RTU does not apply, since TCP already has its own integrity control mechanism.

Package format


Formats of a package of different implementations of Modbus

All Modbus devices interact by following the master-slave model. Requests can be initiated only by a master device, slaves can only respond to requests, and cannot start data transmission on their own. Depending on the implementation of the protocol, the packet headers differ. Here are the main components of the package, which is important to know:

ADU (Application Data Unit) – The entire Modbus packet, with all headers, PDUs, checksum, address, and markers. It differs, depending on the implementation of the protocol.

PDU (protocol data unit) – the main part of the package, the same for all implementations of the protocol. Contains payload itself.

Device address – the address of the recipient, that is, the slave device. Up to 247 devices can be located in one segment of the Modbus network. Only slaves have different addresses, the master has no addresses. The address “0” is used for broadcast requests from master, while slaves cannot respond to these broadcast packets.

Check sum – packet integrity checking algorithms. Modbus RTU and ASCII use 2 bytes of checksum. The Modbus RTU uses the CRC16 algorithm, while the Modbus ASCII uses a simpler and less reliable LRC8. In Modbus TCP, the checksum is not added to the ADU, since integrity is checked at the TCP level.

We will not analyze additional headers specific to each individual protocol implementation, since this is not significant when working with the protocol at the application level.

Modbus registers and functions

In simplified form, the Modbus request structure consists of a function code (read / write), and data that must be read or written. At the same time, function codes are different for different data types. Let us examine what are the registers, and functions for working with them.

  • Discrete inputs – discrete inputs of the device, read only. The range of addresses of registers: from 10001 to 19999. They have the function "02" – reading a group of registers
  • Coils – discrete device outputs, or internal values. Available for reading and writing. The range of addresses of registers: from 20001 to 29999. It has the functions: “01” – reads a group of registers, “05” – write one register, “15” – write a group of registers
  • Input Registers – 16-bit device inputs. Available for reading only. The range of addresses of registers: from 30001 to 39999. Have the function: "04" – reading a group of registers
  • Holding registers – 16-bit device outputs, or internal values. Available for reading and writing. The range of addresses of registers: from 40001 to 49999. They have

Despite the names, the inputs and outputs can actually be internal variables, store counters, flags, or be control triggers. There are also other register ranges, but in the vast majority of devices they are not used, so we will look at four basic types of registers. Different devices can be involved in different ranges of registers, or all at once.

Work examples

For an example of working with the Modbus TCP protocol, we will use the most simple console utility modbus-cli written in the Ruby language. It makes it easy to read and write data in the Modbus registers.

Let's try to read the state of the transmitted packet counters on the Advantech EKI-5524SSI industrial switch. First you need to determine the addresses of the registers that store the necessary information, for this we will look into the documentation of the device. Description of registers are in the section "Modbus Mapping Table":


Description of register values ​​in the EKI switch documentation

It can be seen that the value of the transmitted packets for one port is stored in four registers, and for the first port it is registers from 38193 to 38197. A description is given of the data storage format, from which it follows that an integer number of transmitted packets is stored in hexadecimal format written as 0xAB4130, from right to left.

Make a request:

$ modbus read 192.168.0.17 38193 4
38193 0x0000
38194 0x0000
38195 0x0000
38196 0x3459

read – reading command. The program itself understands what specific read command to use, depending on the address of the register, in our case the command “04” will be used to read 16-bit registers.

192.168.0.17 – IP address of the device.

38193 – the starting address of the register.

four – offset relative to the starting address. We read four registers for port 1, as follows from the datasheet.

We receive the answer containing values ​​of four registers. We see that the number of packets is small: 0x3459, that is 13401, – the switch has been switched on recently.

Disadvantages of the Modbus protocol

In fairness, it is worth mentioning the shortcomings of the protocol. Since it was developed more than 40 years ago, when the processor performance was significantly lower and the protocols were developed without taking into account data protection, it has a lot of minuses:

  • The protocol does not provide for authentication and encryption of transmitted data. Therefore, when using Modbus TCP, it is necessary to use additional VPN tunnels.
  • The slave device cannot initiate data transfer, so the master must constantly poll slave devices
  • The slave device cannot detect loss of communication with the master. This problem directly follows from the previous one.

However, despite all the shortcomings, Modbus is still the most common industrial protocol, and due to its openness, makes it easy to combine devices from different manufacturers. Low demand for resources allows the protocol to be integrated into the most low-power devices.

Equipment with Modbus support

Advantech offers a wide range of industrial equipment with Modbus protocol support for any tasks: automation, control, data collection and transmission.

ADAM-6000 and WISE-4000 — Remote I / O Modules

The modules of the ADAM-6000 and WISE-4000 series allow you to remotely control digital and analogue inputs / outputs using the Modbus TCP protocol. Used to control peripheral devices and collect data in slave mode. Can work together with a programmable logic controller, or connect directly to a SCADA server. ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀

EKI-1200 – Modbus gateways for interface conversion

To convert Modbus RTU / ASCII protocols to Modbus TCP, Modbus gateways are used. The EKI-1200 series devices have up to four RS-232/422/485 serial interfaces, and two Ethernet ports. They allow you to combine devices with different protocols into one network. For example, connect a slave device that supports only Modbus RTU via an RS-485 interface to a Modbus TCP network segment.

APAX-5000, ADAM-3600, WISE-5000 – automation controllers

The controllers support Modbus RTU functions as slave / master and Modbus TCP client / server.

Application examples

Greenhouse monitoring system

The Advantech monitoring solution integrates the TPC-1070H, ADAM-6024, ADAM-6050, ADAM-6060 devices and WebAccess software in an enclosure near agricultural land. By connecting to various sensitive devices, the ADAM-6000 modules can obtain real-time environmental data and control equipment switching to ensure that the greenhouse is in an optimal environment for plant growth. Thanks to Advantech’s special feature — graphical condition logic (GCL), users can define their own control logic rules and load these rules into the ADAM-6000 Ethernet I / O modules, and then the modules automatically execute the logic rules as stand-alone modules. controller. Another feature – Peer-to-Peer (P2P) uses the most open and flexible Ethernet network to not only simplify the implementation process without a controller, but also save hardware costs.

All received data is then transmitted via Ethernet to a computer with a TPC-1070H touch panel. Thanks to the cooling system without a fan and a front panel that complies with the IP65 standard, the TPC-1070H is a robust and compact design suitable for a variable operating environment, and its powerful computing capabilities are capable of processing large amounts of data. To manage devices, Advantech WebAccess allows engineers or managers to view, monitor and configure a monitoring system via an intranet or the Internet using a standard web browser from any device, including tablets and smartphones.

Monitoring solar water heating systems

The engineering company had to be able to control the amount of solar energy, temperature and water consumption in the solar water heating system for an Olympic-sized pool provided by their newly developed solar panel. They should also be able to directly monitor these values ​​and their alarms on LCD panels and save these values ​​for future use.

Advantech's Adam modules provided a solution to the customer that used data acquisition modules connected via RS485 and a two-wire bus to transfer data from all sensors. This system architecture has two main advantages: first, it allows you to add more sensors of data acquisition modules to the system at any time, and, second, it is very easy to add additional tags to the software for monitoring and recording these values ​​on a PC.

Similar Posts

Leave a Reply