Fast Modbus ⚡
General information
We produce devices that operate on the standard Modbus RTU protocol. The protocol is old and reliable, but its operation is based on sequentially polling all the registers on the bus. Unfortunately, this limits the polling speed when there are a large number of devices. We have decided to address this limitation and have released our own protocol extension called "Fast Modbus".
The extension uses broadcast commands, which allow to avoid polling each register one by one.
Broadcast commands are a reserved function of Modbus and do not violate compatibility with the standard protocol. Devices that do not support Fast Modbus function without any issues.
Fast Modbus is available in the current controller software release and in Wiren Board devices with the latest firmware.
Below are described the new features of the Fast Modbus extension: bus events and fast scanning of devices. All information applies only to Wiren Board devices.
Article with technical details: Boosting Modbus: arbitration, bus scanning, events.
Bus events
Events are data packets in response to broadcast requests from the master, and are generated when the value of the modbas register changes in the device.
Not all registers generate events. Registers that support events can be distinguished by the ⚡ symbol in the tables of Modbus device registers.
Events occur in two cases:
- When changing the value of the register that supports events.
- When rebooting the device. This is the only event that occurs immediately after device startup.
For analog channels, events are disabled by default in the firmware of most devices, such registers are polled via standard Modbus. Where they are enabled, for example, the motion level in WB-MSW4 and voltage values in WB-MAP, to avoid spam in the line, events are generated only when the value changes by the value of the hysteresis recorded in the firmware. The hysteresis for each such channel is selected by the device manufacturer and cannot be changed by the user. The wb-mqtt-serial driver polls such registers in parallel with events via regular Modbus.
How does it work?
Every 50 ms, the master sends a broadcast request on the bus, which is received by all devices on the bus. If a device generates an event, it sends a response containing the event identifier, its type, and additional data. If there are multiple devices that generate such events, they engage in arbitration, in which the device with a lower Slave ID wins. For more information about arbitration, please refer to github.
The master receives a response from the device and sends a confirmation that the message has been received. Only after that, the device will reset the occurred event. If there is no confirmation, the device will send the same response again during the next request.
The event polling will only work if there are no devices on the network with the same slave ID. This is due to the fact that the arbitration of devices during event polling is done based on its Modbus address, not the device's serial number like for other Quick Modbus functions.
Events are transmitted in a list. If there have been multiple events in the device since the last query, they will be delivered in a single response during the next request. The packet size is limited to 256 bytes. If certain events could not fit into the transmission, they will be delivered in the next packet.
If the register value changed multiple times between events, for example, if the click counter increased by several units, only one event will be generated, and the latest actual value of the counter will be passed during the poll.
If a device on the bus does not support the extension, it will still function and respond to standard queries. Similarly, if a device with Fast Modbus is polled by a master that is unaware of the extension, it will be polled using standard read and write functions.
Working with events
There are currently no special tools for working with events in the controller's web interface. Below are the available methods of configuration.
How to disable events?
In device templates that support fast Modbus, event-based work is enabled for all registers for which event generation makes sense. In some cases, it may be necessary to disable events, for example, if the use of non-standard protocol functions is prohibited by the enterprise's security policy. The controller's web interface does not yet have special tools for working with events. Therefore, you can disable events as follows:
- In the device template, change the value of the sporadic (or semi-sporadic) parameter to false.
- Disable channel polling completely. To do this, in the controller's web interface, in the serial device settings, set the parameter polling period to "Do not poll".
- Disabling event polling
Set the sporadic parameter to false
Set the polling interval to "Do not poll"
Event polling priority
Only one device can respond to an event request at a time. Therefore, if events were generated by several devices, the one with the lower slave ID will respond to the request first. To find out, the devices perform arbitration, which is described in detail at GitHub.
However, it is possible to assign a high priority to an individual device or multiple devices. In this case, devices with high priority will be polled ahead of others even if their slave ID is higher. If multiple devices have a high priority, arbitration will first be conducted among them, and then among devices with low priority.
It is possible to set the priority in the web interface of the controller, in the settings of the serial device driver. If any value other than "In order" is specified for the polling period parameter, the register will have a high priority.
Please note that for event generating registers, the time specified in the polling interval field does not matter. Event queries will be executed every 50 ms. However, the actual response time to events will depend on the number of devices on the bus and events, as well as the presence of errors. Nevertheless, this time will be significantly shorter than when using standard commands.
Scanning devices on the bus
Usually, an installation contains several slave devices in a panel or in a field on one RS-485 bus. Each device has an address that the user can change. During installation, the addresses of the slave devices are copied from the device case and manually entered into the master configuration. This is not very convenient. To simplify the configuration of devices, there is a bus scanning function. It was available in the Wiren Board controller before the release of the Fast Modbus extension. With the advent of the extension, the ability to quickly scan the bus without having to wait for a timeout for each non-existent address was added.
Therefore, with the Fast Modbus extension, scanning works in two modes: fast and slow.
In slow scanning, a script is used that iterates through all possible addresses on the bus and waits for a response from them within a certain time frame. The process takes several minutes and depends on the communication settings of the devices: speed, stop bits, etc. The slow scanning mode is preserved to support devices with older firmware versions.
Quick scanning is performed much faster and allows to detect devices supporting Fast Modbus almost instantly. In quick scanning mode, the master sends a broadcast request to the bus, and devices respond with data about themselves one by one. The order is determined by the arbitration.
Scanning the bus in the Wiren Board controller web interface
Bus scanning only works for devices with Fast Modbus
In releases wb-2304 to wb-2404
In the section Settings → Scanning you can get a list of all Wiren Board devices connected to the RS-485 bus with their serial numbers, connection settings and firmware versions.
The principle of detecting new devices. When scanning the bus, the device model and port settings are read. These parameters are compared with the device parameters recorded in the wb-mqtt-serial.conf configuration file. If at least one of the parameters does not match, the device is detected as new.
Scan function capabilities:
- display of all Wiren Board devices connected to the controller,
- detection of devices with the same addresses on the same bus,
- detection of devices with different communication parameters on the same bus.
Thanks to the scanning function, it is possible to assemble a control cabinet without paying attention to the device addresses - all addresses and parameters can be obtained after assembly and the devices can be configured without disconnecting them from the bus.
In releases wb-2407 and newer
Since scanning is closely related to adding devices to the controller configuration, we removed the separate scanner and moved the bus scanning to the device settings configurator.
Settings → Configuration files → Serial device driver settings → Find and add devices
- Galary
Configuring the serial device driver
Scanning the bus
Changing Modbus Device Addresses
For devices that support Fast Modbus, you can set new addresses by accessing the device using its unique serial number. This is convenient when multiple devices with the same address are detected on the bus. Changing addresses is done using the wb-modbus-scanner utility and is currently not supported through the web interface. Detailed commands and the reference implementation of the utility are available in the utility's repository.
To change the device's address, connect to the controller via SSH.
- Install the utility using the command:
apt update && apt install wb-modbus-ext-scanner
- Stop the wb-mqtt-serial driver using the command:
systemctl stop wb-mqtt-serial
- Execute the command:
wb-modbus-scanner -d /dev/ttyRS485-1 -b 115200 -s 4267937719 -i 3
- Where, /dev/ttyRS485-1 is the port to which the device is connected, 115200 is the exchange rate, 4267937719 is the device's serial number, 3 is the new slave ID.
- As a result, the following output should appear:
Serial port: /dev/ttyRS485-1 Use baud 115200 Change ID for device with serial 4267937719 [FE638FB7] New ID: 3
- Start the wb-mqtt-serial driver again using the command:
systemctl start wb-mqtt-serial
Fast Modbus Supported Devices
Since any manufacturer can implement the protocol, the range of Fast Modbus devices is not limited to the Wiren Board range. Below are the brands of devices known to us.
Wiren Board
All new Wiren Board devices, below are tables with firmware versions.
| Device | The firmware version in which scanning appeared |
|---|---|
| WB-MRx, WB-MWAC | 1.19.0 |
| WB-MDM3 | 2.6.0 |
| WB-LED, WB-MRGBW-D | 3.2.0 |
| WB-MSx, WB-MSWx, WB-MIR, WB-M1W2 | 4.23.0 |
| WB-MAI11 | not supported |
| WB-MAI6 | 2.0.0 |
| WB-MAO4 | 2.2.0 |
| WB-MAPx | 2.4.0 |
| WB-MIO | 1.6.0 |
| WB-REF-U | 1.4.0 |
| WB-REF-DF | 1.1.0 |
| Device | The firmware version in which the events appeared |
|---|---|
| WB-MRx, WB-MWAC | 1.20.0 |
| WB-MAPx | 2.8.0 |
| WB-MDM3 | 2.7.0 |
| WB-LED, WB-MRGBW-D | 3.4.0 |
| WB-MSWx, WB-MIR v.2 | 4.31.0 |
| WB-M1W2 | 4.32.0 |
| WB-MAO4 | 2.4.4 |
| WB-MCM8 | 1.6.0 |
ONOKOM
New models of devices ONOKOM support Fast Modbus, it is better to check the list with the manufacturer.
Useful links
- Upgrading Modbus: arbitration, bus scanning, events - an article with details on implementing the extension
- Extension description on GitHub
- Modbus protocol description
- Scanning utility repository