The Modbus protocol is quite common both in industrial automation systems and in networks of systems like "Smart Home", automation of small objects (greenhouses, etc.) and the joining of various equipment with a home computer. The emergence of projects such as Arduino and Raspberry Pi has greatly increased the interest in tasks related to robotics, automation and automation. All this ensures the growth of Modbus popularity among amateurs and professionals. The article addresses the issue of testing and adjusting both individual devices and networks based on the Modbus protocol from the standpoint of software requirements for solving such problems and a review of existing tools.

If you are familiar with the architecture of the protocol, then you can safely browse a couple of the following paragraphs and go on to the further description . If not, then a brief introduction to Modbus is provided especially for you.

Modbus, a brief introduction

Modbus is a fairly common protocol in automation systems at the middle and lower (field) levels. Medium is the level of controllers - devices that collect data and control the technological process. Lower or field is the level of interaction of sensors and controllers or sensors directly with the server. More details about the levels in automation systems can be found here .

As a rule, the structure of a typical automation system using Modbus as the base protocol looks like the one shown in the figure at the beginning of the article. For the “environment” for the Modbus protocol, either RS-485/422/232 can be used (you can read more about RS-485 here and here ), Modbus RTU or Modbus ASCII runs on it, or TCP transport protocol in TCP / IP networks, This version is called Modbus TCP. This article will be considered Modbus RTU.

Modbus protocol assumes the presence of one master device on the network (it is called Master or Client) and from 1 to 247 slaves (they are called Slave or Server). A full description can be found on the official website or on the wiki .

The master periodically interacts with Slave devices, reading or writing any information into them. This process is in the form of request-response. A request is a sequence of bytes, called a frame, in which the time between bytes is standardized and depends on the data transfer rate (recall that we are talking about Modbus RTU) and is no more than the length of the interval during which 1.5 data bytes can be transmitted. The time between frames should be no less than the transfer time of 3.5 bytes.

The request format is as follows:

ID - device address (1 byte),
FN - Modbus function (1 byte),
[args] - function arguments (N bytes, depends on the function),
CRC - CRC-16 checksum (2 bytes).

The answer has a similar format:

Almost all fields of the response frame are similar to the request frame, with the exception of the DATA field, it has a different content, depending on the function.

If the device does not support the requested function or the arguments in the [args] field of the request are incorrect for this Slave device, then in the response, the upper bit in the FN field will be set to 1 (i.e., the mask 0x80 will be applied to the FN), and DATA will be posted additional error information.

Each Slave device can have specific data areas and contain additional specific information.
Possible data areas are presented in the table below:

For more information, see the full Modbus RTU description, available as a specification .

Testing devices with Modbus RTU support as part of the development process

Both when developing and setting up devices with Modbus RTU protocol support, you need to have specialized software and hardware. Of the technical means, the simplest option is the RS-485 / USB converter, of all devices of this type, in our opinion, the best choice is MOXA UPORT 1130 / UPORT 1150, the issue price of which will be 5000 - 6000 rubles. There are various domestic solutions, for example, converters from Fractal or OVEN . The design of these devices is quite simple, and with a certain dexterity, such a converter can be assembled independently. More complex are Ethernet / RS-485 type solutions (for example, NPORT from MOXA).

When developing devices with Modbus RTU support, it is often necessary to implement the Slave function, since basically these are various sensors, controlled relays, input / output modules, etc. Master devices are created less frequently. In automation networks, a controller usually acts as a master, and, as a rule, it already has an implementation of a Modbus stack, or an OPC Server / SCADA system, equipped with a Modbus driver.

We will not discuss the development of the Modbus stack directly in this article. The only thing worth noting is the FreeMODBUS library, on the basis of which it is enough just to build a device that supports the functions of Modbus Slave. The implementation example is described in article on Habré .

The second important point in the development of Modbus devices is testing. It all depends on the stage of development and the purpose of testing.

In the initial stages, the Modbus terminal is a useful tool. With it, we can manually construct a request, send it and analyze the response. There are pure terminals, for example, SmartTerminal , Access Port , terminals with Modbus RTU support - Termite from S2-Team, or Pic18 Terminal from Fractal (not updated since 2006), etc. The latter is designed for the equipment of the Fractal company, but it allows to “communicate” with any devices that have None parity set in the port settings, it does not work with other options.

In the development process, a situation often arises when the device accepts the request and responds to it (this can be understood either by the packet receive / transmit LEDs, if you have provided for them in the design, or through a debugger, by setting the breakpoint in the right place), and in the terminal or Some other specialized program, the data is not displayed. In this case, you need a sniffer for the serial port, preferably with Modbus protocol support. As an example, Free Serial Analyzer , COM Port Toolkit . The latter currently seems to have stopped its development.

In the future, it is necessary not only to check whether the device works in principle (that is, correctly respond to requests), but also to determine the mean time between failures with the help of long-term testing. Important aspects here are support for auto-polling with variable load (the number of requests per second) and the availability of the logging function. With these tasks, Modbus Poll or Modscan can help you ; this software is paid, but there is a trial period.

It should be noted that the collected logs will need to be analyzed, that is, to determine the number of requests to which the device has not responded, to detect failures, for example, spontaneous change of data in cells, etc. Of course, you can use a full-fledged SCADA system, or you can develop and write a system for analyzing and visualizing logs yourself. As an option, we recommend paying attention to Insat MasterSCADA . It has a built-in Modbus driver and the version up to 32 points is free, quite easy to learn (there is good documentation and video tutorials on the manufacturer’s website).

At the end of this article, we will define the list of functions of the “ideal” tool for testing and adjusting devices / systems based on the Modbus protocol, and also make a small overview of existing tools.

Adjustment of automation systems using Modbus devices

There are many more people involved in setting up automation systems and simply trying to “make friends” with any device carrying Modbus on board. Based on the specifics of the task, the requirements for the corresponding software will be slightly different.

If it is necessary to connect a controller and a single Slave device, then first of all, you need to establish communication with it using an RS-485 / USB interface converter, a PC, and specialized software or a terminal. In this case, the logic of work and the set of tools is no different from those used in the development of the Slave device at the testing stage. At this stage, no long-term testing is required, followed by analysis of a large number of log files.

In the case when you already have a ready network of devices, you can select the following tasks:

• checking the operation of all devices on the network (polling each device individually and checking the correctness of the answer);
• load testing (polling devices on the network for a long time). It is advisable to do several experiments with different polling frequencies, and then analyze the collected data for the presence of failures, not responses, data corruption, etc.

In this case, you will need either a terminal with the ability to create a list of requests, or a specialized tool such as Modbus Poll, which allows you to poll several devices within one project.

Modbus devices can have certain RS-485 interface settings: the number of data bits, parity, and the number of stop bits. Devices with different settings cannot work on the same network with the same master. Testing and configuring such devices is conveniently carried out using terminal programs that have the ability to quickly switch between predefined port configuration profiles or work with several lines at the same time.

Less frequently, the task of organizing data exchange with a device, whose protocol differs from the standard Modbus RTU specification, arises. We had to deal with the situation when the Slave device protocol logically repeats Modbus (packet structure, timeouts, etc.), but uses functions outside the standard. In this case, it is possible to work using Modbus Poll, it allows you to build arbitrary requests, or a terminal with similar functionality. Standard SCADA-system, usually, is powerless in such a situation, and work with such equipment is carried out through a special OPC server.

Software requirements for working with Modbus devices in master mode

Describing the various tasks that arise during the development, configuration and adjustment of devices with the Modbus protocol, we make a list of requirements for specialized software.

1. Support for COM-port settings (number, speed, parity, number of data bits and stop bits)
2. Setting timeouts (waiting time to receive a response to a request, the time between characters and frames)
3. Standard Modbus Support
4. Non-standard Modbus support
5. Auto-polling single / multiple devices
6. Configure auto-polling
7. Session logging / logging setup
8. Creating profiles to quickly switch between port settings
9. Work in sniffer mode
10. Product license
11. Product Support Developer

Overview of software for working with Modbus protocol

Modbus poll

Let's start with a classic application and quite famous in our “narrow” circles - Modbus Poll from Witte Software.

This program is a master simulator in the Modbus network. The Modbus Poll interface is intuitive. If you imagine the logic of the protocol, then you will not be able to understand the work program.

Advantages : a good logging system, a sufficient number of supported functions (in any case, the most popular ones are present), a large number of appearance settings.

Disadvantages : price (one license $ 129.00), non-standard Modbus is supported as an optional feature, there are no profiles for fast port switching - you have to reconfigure the connection every time.

Modscan32 / 64

The next software in our review will be Modscan from WinTECH. Outwardly, this program is very similar to Modbus Poll, but it has much less functionality.

Modscan has one unique feature for programs of this type - the ability to create forms (a kind of mnemonic scheme). While its functionality is far from real SCADA-systems, but the presence of such a bonus pleases. To date, this is quite a meager tool in its capabilities (meaning the form editor), but let's hope that over time, the developers will bring it to a good level.

Advantages : the ability to create your own forms for viewing data, support for MMI & OLE Automation.

Disadvantages : price (one license $ 84.95), no support for non-standard Modbus, no profiles for fast port switching, non-configurable logging system, a small number of supported Modbus functions.

Termite

Next on our list will be the terminal Termite from S2-Team. Termite is a specialized Modbus terminal. This means that he will take CRC for you, recognize error messages in the answers, etc. Your task is to enter the correct request body in the command field.

Advantages : support of all Modbus-functions, work with non-standard Modbus, convenient system of prompts, the ability to customize the appearance of the software, support profiles for quickly switching between port settings.

Disadvantages : PRO version is paid (one license is $ 10), in the current release there is no possibility to flexibly configure logging.

AccessPort

The program is from the category of "clean" terminals. It does not support Modbus, so when using it, be prepared to read the CRC for your frames yourself. The undoubted advantage is that a serial port sniffer is built into it.

Advantages : the availability of a port sniffer, software free, customizable data presentation, the ability to transfer files.

Disadvantages : it does not support Modbus at all, there is no possibility to create profiles, in the auto-polling mode it is possible to work with only one device, currently the software is not developed.

In conclusion, I would like to add that the network has a sufficiently large number of programs for working with the serial port, but if there is a need to work with the Modbus protocol, then its support in such software is highly desirable. One of the main reasons is CRC calculation, it’s expensive to do it manually, it’s also important that the program could be able to divide frames, otherwise everything turns into a continuous jumble of bytes, and if there is an auto-poll, then this greatly simplifies life.

I would like to add to the list of software and libraries for working with Modbus, with what was rearranged in the comments.
SCADA
FreeSCADA
Modbus TCP / RTU
Advanced TCP / IP Data Logger
Ardsoft Modbus Emulator
Portmon
MODBUS FOR WINDOWS
Peakhmi
Modpoll Modbus Master Simulator
QModMaster
modbus_tk
pymodbus
libmodbus

Thanks to everyone who helped improve the article!

Thanks for attention!