About polling

Polling updates device and proxy point values in a controller station database. Regardless of driver type, each polling service (named Poll Service or Poll Scheduler) operates in the same basic manner.

Many driver networks use a single polling mechanism and thread to adjust polling frequency at the network level in a station. The polling service samples device and point values at one of three poll rates: Slow, Normal, Fast. You configure the time interval associated with each rate. These are arbitrary names. There is no logic that enforces a relationship among their values.

As you work with each network you will encounter differences among pollable objects (pollables are objects that can be polled):

A BacnetNetwork provides a separate BacnetPoll component for each port under its stack’s network component using two threads per network port. You assign the Poll Frequency (poll rate) for a BacnetNetwork under its network Tuning Policy.
NOTE: Multiple threads provide poll statistics that reflect the sum of activity for all the threads. There is no way to determine a statistics breakdown for each thread.
Other drivers configure Poll Frequency for proxy points in each point’s proxy extension.
In the case of device objects, a Poll Frequency property selects the rate directly.
The NiagaraNetwork does not provide device and point polling.

A Poll Frequency property is typically located below the device address properties. It provides a drop-down menu to select among the three poll rates as configured in the network’s polling service.

In addition to the poll rates (Slow, Normal, Fast), a fourth group, Dibs Stack, supports pollables that transition to a subscribed state. This may be a temporary subscription, such as results when viewing unlinked proxy points (without alarm or history extensions) in Workbench or a browser. Or, it may occur when a polling service polls a permanently-subscribed point for the first time. Thereafter, it is no longer dibs-stack polled.

Every 10 seconds, the poll scheduler rebuilds the list of objects assigned to each poll rate. An algorithm breaks up each rate list into optimally-sized groups, which allows the poll thread to switch among the rates. This spreads the message traffic out evenly over the configured intervals causing points assigned to the quicker rates to update multiple times before points assigned to a slower rate update once.

Poll statistics are updated every 10 seconds. Fast, slow, and normal cycle times display the average time to complete a single poll cycle in milliseconds (ms). The poll scheduler algorithm automatically calculates an inter-message delay time to evenly spread out polling messages over the configured rate.

For example, if five points are assigned to a normal rate, the poll scheduler may poll a point in the list every two seconds resulting in a normal poll cycle time of around 10000 ms. This does not mean that it actually took 10 seconds to poll those five points.

Polling priority based on the assigned rate occurs like this:

The scheduler polls the dibs stack first. When first subscribed, a pollable moves to the top of the dibs stack (first dibs). The dibs stack is polled last-in, first-out (LIFO). As long as entries are in the dibs stack, the scheduler polls them as fast as possible with no delays.
When the dibs stack is empty, the scheduler uses the algorithm to poll the components in each rate group.
NOTE: Every ten seconds the poll scheduler rechecks the rate groups for configuration changes. If a pollable’s configuration changes from slow to fast, it takes at most ten seconds for the change to take effect.

About polling

Related Links

Related References