We are in the company Lavritech We have been developing automation devices and controllers for several years. We also developed a software ecosystem that can work with various interfaces, including Modbus. At first it was not considered important, but later it turned out that many of our customers need Modbus, so they began to expand its support in their devices and solutions.

How we refined Modbus support

Our ESP32 controllers initially have a subsystem for working with the Modbus bus, but in the first implementations Modbus functionality was limited: the controller supported the simplest devices, there were no ready-made templates. Although for the same relay modules with a small number of functional registers, it was enough.

We registered each Modbus device through registers and a response template in a small window, for example:

Response template (mask) – r1d1,r2d3,r2d1,r2,r1d1,rd2

outputs in order: voltage (1 register, 1 decimal place), current (2 registers, 3 decimal places), current power (2 registers, 1 decimal place), consumed energy (2 registers), network frequency (1 register ) , 1 decimal place), Power Factor (1 case, 2 decimal places)

Users could add support for their devices, but the syntax needed to be figured out. All this was quite “painful” for users, they often added false templates that did not work. Then they tortured our support to find the cause of the problems. We need to do better, so we’ve moved to the second version of Modbus with ready-made templates.

In the second version of the Modbus subsystem for our controller, we added ready-made templates to the firmware. Now users couldn’t install a “crooked” template and screw everything up. The firmware contained the templates that we wrote ourselves. But if you want to add support for a new template and device to the client controller, you have to update the firmware.

A list of ready-made templates, mostly for Wiren Board modules

Our user base continued to grow, so the number of requests from customers increased. First, we wanted to give users the ability to add new patterns to the controller without flashing. Second, users wanted the ability to write their own templates and add them to the controller.

This is how the third current version of the Modbus subsystem in our controller, which we named Modbus FS, appeared. You can read more about it in Lavritech documentation. We created a file system so that templates can be uploaded as files without having to update the entire firmware. Now the user can download the desired templates from our repository and install them on the controller. You can write templates yourself, but then you need to send them to us for review, after which we will publish them.

Additional photos

Slow Modbus

We have dealt with templates and adding devices. But what about the response time? Users have long complained that Modbus devices are slow to respond. Let’s say the light turned on within a second of pressing a button in the app.

For systems with sensors, the response time is not so important, there we poll the devices once every ten seconds. In a smart home, the polling time can be reduced to one second. It is already less risky – the computing power of the ESP32 controller is not so great, it will be loaded with a large number of requests and will not have time to process other tasks. And the more devices on the bus, the more acute this problem is.

Tried the I²C bus of fast discrete input (buttons, switches). However, it is very short, as it is intended for connecting components on a printed circuit board. That is, through I²C, it will not be possible to carry the same control modules and buttons over a long distance. In addition, devices from different vendors are not “friends” via I²C. Finally, users want a simple, universal and reliable way to connect external modules to the controller, and I²C is a crutch, and a capricious one, you need to monitor the quality of the connection.

One of the options for implementing I²C modules is Wiren Board side modules, which have been used for a long time. Yes, everything works very quickly within the side modules, but this configuration is difficult to set up: it is inconvenient to expand, it requires constant control of the order of module connections, and it is also not suitable everywhere. I wanted better.

on exhibition WBCE 2023 We learned that the Wiren Board company has developed a Fast Modbus extension. The idea was beautiful, but would it work in practice? At the exhibition, we agreed with the engineers to send us the equipment under a warranty letter. Still, a demonstration is good, but you always want to feel with your hands. The nomenclature was ordered wide, almost the entire range of modules with support for Fast Modbus. We laid out the devices on the programmer’s desk, assembled the bus, connected it to the PC through the UART adapter and started chasing and catching packets. What is this “beast”? They quickly understood how everything works. The “beast” turned out not to be scary at all. This is how the idea was born to add Fast Modbus support to our Modbus FS subsystem, which was being developed at the time. Was it difficult? At first it seemed that there would be pain and tears, but in fact, no.

Adding Fast Modbus support to our controller

Let’s immediately note two important points: to understand the operation of Fast Modbus, you need to have an iron at hand. It’s good that Wiren Board can send them for free under warranty. And startup developers will not have to bear additional costs. By the way, our programmer did not even begin to understand the work of Fast Modbus until he got the “iron”, because he is lazy and never.

The second moment – everything is great described in the documentation. We spent several days testing Wiren Board modules in every way, looking at flashing lights. The sensations were such that the Modbus devices are located directly in the controller – communication was (almost) instantaneous. We went through the documentation step by step and checked the operation of all functions. We understood the priority of polls, the support of events on the bus, the scanning of the bus. Then came a complete understanding of how everything works. And if there is understanding, then it’s time to implement support in our Lavritech controllers.

We test our software environment first on a Linux PC and then compile the firmware. The programmer looked at the documentation, examples, and then wrote the code. The entire work was divided into four stages:

1. Subscription – the master sends commands to all devices to indicate which registers to monitor.

2. The wizard sends a broadcast request for new data to all devices.

3. Then the device’s algorithm transmits the packets, we analyze them.

4. The last step is scanning the bus via fast Modbus. There were errors here at first, but everything was quickly resolved in the debugging process.

It took one of our programmers a week of evenings just to add Fast Modbus, while solving other work tasks in parallel. That is, all support can be done in one sprint. As a result, we added to our firmware a scanner for devices on the bus, support for events, changing the speed of devices with a single request, etc.

In the code, this all looks like an additional thread that periodically requests data on the Modbus bus, then checks for such packets in a cycle. Essentially, a stream with periodic requests that does not intersect with other data.

As a result, we set the polling interval to 100ms, although the documentation has the option to set it to 50ms. But even 100 ms – the reaction is almost instantaneous.

To enable Fast Modbus in the controller, you need to have a firmware with its support, after that you can activate the option with a check mark in the web interface. There is a mark in the templates: if you want to use Fast Modbus for any registers, put one. That is, the client can choose for which devices he needs Fast Modbus. If Fast Modbus is not needed, communication with such devices and registers will be traditional.

How did Fast Modbus affect the load on the controller? All the same, ESP32 has few resources. We worried about this, but in vain. We even managed to reduce the load. In what way? We increased the polling time of conventional devices to 10 s, and Fast Modbus polling required almost no additional resources. As a result, we even accelerated the operation of I²C devices as the controller freed up resources.

Additional photos

Conclusion

At first, Modbus was not the main thing for us, but the customers needed it, so we gradually finished it. When working on the third version of the Modbus subsystem in our controller, we learned about Fast Modbus. The idea seemed interesting, we decided to add support.

To be honest, we expected it to be more difficult. But Wiren Board moved all the complexity of Fast Modbus to the device and firmware side, so it didn’t take long. It was added literally in a week, it took some time for testing. As a result, it was even possible to reduce the load on the controller, because slow devices often do not need to be polled, and delay-critical devices work via Fast Modbus. The freed up resources even made it possible to speed up work with I²C devices. We are satisfied. We hope our customers will too.

And what do you think about Fast Modbus? Do you have your own use cases? Share in the comments.