The idea is simple: instead of getting points one-by-one, let’s request and receive multiple points at once. Naturally, every message will become bigger, but not proportionally bigger. Receiving two points instead of one might lead to 10% increase in message size. That’s because apart from point values, messages contain header, length, device address, cyclic redundancy code, size of which is unchanged.
|1 point||3.5||1||1||2||2||3.5||13 bytes|
|2 points||3.5||1||1||4||2||3.5||15 bytes|
This shows message structure of two Modbus responses: the first with single point, the second with two points data. Full length of Modbus response increased from 13 to 15 bytes (+15%) when payload got increased from 1 to 2 points (+100%). That’s a good scalability.
As always, there are extra requirements to implement grouping:
- Device CPU should be fast enough and have bigger network buffer
- Longer messages are more error-prone – better network quality is needed
- Software should be smart enough to group points effectively
Let’s review how grouping is implemented in a few popular protocols.
Modbus always uses point groups – even a single point request is a group with just one member. There are few limitations though:
- Only one type of points could be grouped together. E.g. input registers with input registers, not with coils
- Groups include sequential points only. E.g. holding registers from 10 till 13, not 10, 12, 19
- Maximum size of a group varies between devices, thus software can’t group points fully automatically and should rely on engineer’s input.
BACnet has probably the most advanced mechanisms to poll group of points. Read Property Multiple service allows to request various properties of various objects. As BACnet devices are much better standardised than Modbus and also have services to specify their memory limitations, software can fully automatically generate polling requests in the most optimal way.
BACnet takes a step further and offers Read Property Conditional service – as its name implies, it returns values only if defined criteria is met. This can reduce traffic even more, but not many devices implement this service.
Grundfos GENIbus telegram can include multiple Application Data Protocol Units (APDU). Each APDU contains multiple points of a single class (type). So in practice, it is easy to request many points of different types in one request.
Nope, no grouping here. And actually, it is not necessary, because polling is a second class citizen in LonWorks. This protocol has much better mechanism, called binding, which is essentially a subscription and will be covered later.
Sauter novaNet addressable memory is quite big. Each hardware and software point in addition to real-time value stores various descriptions, units, types, timestamps and other properties. To deal with it, novaNet offers very advanced grouping capabilities. Points could be requested:
- horizontally – multiple sequential properties (DW) in single point area (MFA)
- vertically – single property in multiple sequential point areas
- randomly – any combination of points and its properties
Is polling the only possible way to request and receive real-time data? No. [to be continued]
communication protocol polling