All BMS communication protocols (well, almost all) use polling to read point values. This is a simple service, consisting of request-response message pairs. Master device (for example, Tridium Jace) asks for a point – slave device responds with its value. Repeat again, and again, and again.
This service is present in Modbus, BACnet, Lonworks, Sauter novaNet, TAC Xenta, Satchwell NCP, Grundfos GENIbus, you name it. Sometimes it is the only service available, sometimes others (more advanced) services are present as well.
The master determines how often the value should be updated, so it is easy to predict the traffic and make sure the network is “healthy” and not overloaded.
Polling is straightforward to implement – that is the main reason why it is available everywhere. It does not require complex programming or powerful hardware.
- Simple to understand, engineer, develop and troubleshoot
- Two messages (request and response) per point update
- Polling requests are sent all the time, even if the point is not changing
- Polling might miss rapidly changing values, like fast binary inputs. Actually they should not even be “fast” – just faster than polling frequency
These issues become critical when the number of devices and points increases.
Let’s assume there is a relatively small network with 20 devices, each device
contains 50 points and it takes 10ms to send one message – this time period one
could expect for 9600bps serial line. Now to poll all points in all devices
one-by-one we need:
20 devices * 50 points * 10 ms * 2 messages = 20 seconds
So if all points should be available in master device all the time, we could only update each one every 20 seconds or less often. Even if these points are needed just for displaying on graphical interface, it is still quite a slow update rate. Not to mention, if point values are used for alarm generation or in a control logic sequence. This timing will be a deal-breaker!
What could be done to improve the polling performance? A lot.
communication protocol polling