Polling Going Deeper

The very basic polling service described in the first part has a limited throughput, so it is not well suited for real applications (except for very small ones) in its original form. Could it be enhanced? Of course.

Divide and conquer

Even a big system could be divided in small parts. Every part should have own master (router / gateway / main controller). This makes a system more complex, expensive, harder to maintain and more error-prone. Still, quite often building management systems are designed with one gateway for every 5-10 field devices like energy meters.

Speed it up

Increasing baudrate is the first thing, which comes to mind. Most serial devices go higher than 9.6Kbps and support 19.2Kbps, 38.4Kbps or even higher speeds. Modbus standard specifies 19.2Kbps, Sauter novaNet uses 19.2Kbps, BACnet MS/TP – 76.8Kbps, Lonworks FT-10 – 78.1Kbps.

But it doesn’t come free – when the speed is increased, device CPU should be more powerful, cable maximum distance shorter, noise sensitivity higher, requirements for cable quality stricter and termination resistors become necessary. Which leads to extra costs in materials and commissioning labour for troubleshooting. That’s why many engineers and manufacturers prefer to keep baudrate low: Grundfos GENIbus and Satchwell Micronet NCP operate on 9.6Kbps.

Get what you need

This is an obvious idea: read only the information which is needed at this moment. As graphical user interface displays only a limited number of points at once, only those should be polled. There are few things, though:

• Quite often point values are used not just for displaying, but also for alarms or trendlogs – then point values are needed all the time
• Software design is much simpler if all points are polled continuously, therefore manufacturers often choose simple route. Especially in case of protocol gateways

What other options are available to increase the point update rate? Point grouping.