One of the critical steps is the communication tuning speed between machines and applications. It depends on many factors, including machine type, production process, and application scope. Find out how to improve throughput.
Alleantia IoT Edge has two layers to adjust communication speed: the ‘machine’ and the ‘IIoT App’.
The data acquisition performances, from the 'machine side', can be managed with two parameters, the ‘delay between requests’, configured in the driver at creation time, and the ‘polling period’, configured on the gateway user interface.
1) The ‘delay between requests’ is the parameter that the gateway poller (protocol stack) use to schedule a request to the device. It can be related to a single variable or a group of variables if ‘batch read’ is enabled. In the driver editor, the default is set to 1000 ms, but can be changed.
For the pre-configured drivers in the library, not editable, the ‘delay between requests’ is usually 100ms for general devices e.g. power meters, inverters, and 10ms for the CNCs.
2) The ‘polling period’ affects the delay between two polling cycles of the variables of a device. Each variable can be configured to have a High-Medium-Low priority, in substance associating these variables to three groups. Reading time for all variables in a group in one cycle is determined by the ‘delay between requests’ parameter. The reading time for all variables in a group in two or more cycles is affected by the ‘polling period’ that keep the poller in wait between two cycles. The polling periods for High-Medium-Low can be defined in the ‘COM and Ethernet configuration’ page. In the example here is 1 ms – 1s – 10 s.
Each variable exchanged for a device can be set in one of the Priorities. In the example below, Axis positions in the Heidenhain 640 CNC driver are set to ‘High Priority’ and Execution Mode and Feed Rate to ‘Medium Priority’.
Device capabilities affect the actual performances . In some cases (e.g. old PLCs ad CNCs) we experienced response issues and even device errors / communication breakdowns when the requests where too fast / too frequent and the device couldn’t keep up. So, be careful.
Regarding the IIoT Apps side, we can consider for example MQTT.
The MQTT connector configuration is a separate process that is independent from the device interface. Among many other options, the MQTT connector configuration page enable the definition of the Data Sampling interval.
This is the interval between two different MQTT messages sent to the broker. Their content will include the ‘last available information from the devices’, or nothing if the variables info wasn’t changed in the interval. So, the MQTT message content will align – in an asynchronous model – with the information retrieved from the devices. By the way, to have different MQTT intervals for different variables, is necessary to license and configure multiple MQTT connectors, on the same gateway.
In terms of performances that can be achieved, we tested the full stack with multiple new devices, 10 var per devices, fast device interface, 4 parallel MQTT connectors, achieving a device-to-broker performances of 6-8 ms.
In the picture below, you can also see the example of SQL connector.
The simulators and the resulting performances use a different process, where the simulator use a pre-recorded data set and ‘cycles’ with a dedicated daemon. So the performance information reported in the device page should not be considered as a reference performance information.
If you need support don't hesistate to contact us