Many driver networks use a single polling mechanism (Poll component, named “Poll Service” or “Poll Scheduler”) adjusted at the network level in the station. In the case of a BacnetNetwork, a separate BacnetPoll is used for each port under the BacnetStack’s Network component, as shown in Figure 13.
The Niagara Network does not use polling, but uses subscriptions only.
Regardless of driver type, the Poll Service provides a “poll scheduler” that operates in the same basic manner.
A driver typically uses a single thread for all polling on that specific network. However, there are some exceptions to this
model. For example, polling in a BacnetNetwork uses two threads per network port. It is important to note that if a driver’s Poll Service uses multiple threads, that poll statistics
reflect the sum of activity for all the threads—there is no way to determine a statistics breakdown for each thread.
The Poll Service provides three different configurable poll rates (Slow, Normal, Fast). Note these are just arbitrary names—there is no logic that enforces a relationship between their values. Meaning, the slow rate can actually be configured for a faster interval than the normal rate, without issues.
“Pollables” (mainly proxy points) are associated with one of three “rate” groups (Slow, Normal, Fast) via either:
assigned Tuning Policy in each point’s proxy extension (BacnetNetwork)
assigned Poll Frequency in each point’s proxy extension (most drivers other than Bacnet)
In the case of device objects, a Poll Frequency property is used to select the rate directly.
The poll scheduler maintains a group of four rate “buckets” to service “pollables”, three of which correspond to these configured poll rates (slow, normal, fast).
A fourth “dibs stack” bucket is allocated for 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 permanently subscribed point is first polled (thereafter, it is no longer “dibs stack-polled”).
Every 10 seconds, the poll scheduler rebuilds the list of objects that are assigned to each of the poll buckets. An algorithm is used to break up the list of objects for each poll bucket into optimally-sized groups, which allows the poll thread to switch back and forth between the rate buckets. This algorithm is designed to spread the message traffic out evenly over the configured intervals, and to allow points assigned to quicker buckets to update multiple times before points assigned to a slower bucket update once.
Poll statistics are updated every 10 seconds. Fast, slow, and normal cycle times display the average time in milliseconds (ms) to complete a single poll cycle. The poll scheduler algorithm automatically calculates an inter-message delay time to evenly spread poll messages out over the configured rate.
For example, if there are 5 points assigned to a normal rate/Tuning Policy, then it may poll a point in the list every 2 seconds. In this case, the normal poll cycle time would be around 10000 ms, but that does not mean that actually took 10 seconds to actually poll those 5 points.
Priority of polling by the scheduler occurs in this fashion:
Dibs stack. When first subscribed, a pollable moves to the top of the dibs stack (first dibs). The poll scheduler always polls the dibs bucket before doing anything else. The dibs stack is polled last-in, first-out (LIFO). As long as entries are in the dibs stack, they are polled as fast as possible with no delays.
When the dibs stack is empty, the scheduler attempts to poll the components in each “rate” bucket using an algorithm designed to create uniform network traffic.
For example, if the fast rate is configured to 10 seconds and there are 5 components currently subscribed in the fast bucket, then the scheduler will attempt to poll one component every 2 seconds.
Every ten seconds the poll scheduler rechecks the buckets for configuration changes. So if a pollable’s configuration is changed
from slow to fast, it takes at most ten seconds for the change to take effect.
You can manually reset poll statistics using the Reset Statistics action to the Poll Service (Figure 14).
Properties of the Poll Service component for typical field bus drivers include four writable properties and various read-only statistics properties, as follows:
Poll Enabled
If true (default), polling occurs for all associated pollables (proxy points, devices) under the network component, or if a BacnetPoll, under that BacnetStack, Network, Port.
While set to false, polling is suspended and further value updates from polling do not occur.
PollService actions Enable and Disable allow access to this property, see Figure 14.
The three Rate properties below are named arbitrarily, however, typical convention is to use them as named. For related information,
see Poll scheduler operation.
Fast Rate
Target poll interval for pollables assigned to this rate group (default often is 1 second).
Normal Rate
Target poll interval for pollables assigned to this rate group (default often is 5 seconds).
Slow Rate
Target poll interval for pollables assigned to this rate group (default often 30 seconds).
All remaining properties are read-only statistics properties.
Statistics Start
Timestamp reflecting either the last manual reset of poll statistics, or if statistics have not been reset, the first “steady state” time immediately following the last station restart.
Average Poll
Average time spent during each poll event. This does not relate to the total time required to complete a poll cycle for any of the three rate buckets. It is the time spent polling a given group before pausing and switching to another group of objects, either in the same or a different poll rate bucket.
Busy Time
Displays a percentage of time spent by the poll thread actually polling points, across all poll buckets. Includes (in parentheses) a ratio of “(time spent polling/total time since statistics were restarted)”.
Given a small amount of time is spent transitioning between poll buckets, and with the thread sleeping to evenly space out polling messages, it is unlikely to ever see Busy Time reach exactly 100%. However, any percentage above 95% indicates that the poll thread is basically spending all of its time actually polling. Also see Using poll statistics in tuning poll rates.
In the case of the Poll Service for a Bacnet network port, because two threads are used for polling, it is possible to see
a Busy Time approaching 200%. In this case, divide the Busy Time in half to get an average busy time for each thread.
Total Polls
Total number of polls performed, along with the time spent actually polling. Note that this time is the same time indicated in the ratio of the Busy Time property. Typically, the total poll count indicates the number of times any object has been polled. It is not a running total of the actual poll cycles.
Example 1. Total Polls, Example
You have 2 points assigned to a fast policy of 1 second, 2 points assigned to a normal policy of 5 seconds, and 2 points assigned to a slow policy of 10 seconds. When the statistics update every 10 seconds, you would expect the total polls to increment by 26, where:
Total polls = (2 fast/1 sec * 10 sec) + (2 normal/5sec * 10 sec) + (2 slow/10 sec * 10 sec)
Total polls = 20 fast + 4 normal + 2 slow
Total polls = 26
In some cases, such as a BacnetNetwork, Total Polls may indicate the number of poll messages sent to devices. Potentially, there could be multiple points being processed in a single message, such if performing “read property multiple” for BACnet devices, or possibly when performing COV subscriptions.
Dibs Polls
Percentage and ratio of the number of dibs polls versus the total polls.
Fast Polls
Percentage and ratio of the number of fast polls versus the total polls.
Normal Polls
Percentage and ratio of the number of normal polls versus the total polls.
Slow Polls
Percentage and ratio of the number of slow polls versus the total polls.
Dibs Count
Current and average number of components in dibs stack.
Fast Count
Current and average number of components in fast queue.
Normal Count
Current and average number of components in normal queue.
Slow Count
Current and average number of components in slow queue.
Fast Cycle Time
Average cycle time of the fast queue.
Normal Cycle Time
Average cycle time of the normal queue.
Slow Cycle Time
Average cycle time of the slow queue.
Depending on driver, additional statistics properties may be present in a Poll component. For example, a BacnetPoll has additional properties Device Count, Point Count, and Object Count. See the specific driver document for unique Poll Service features or notes.
Copyright © 2000-2014 Tridium Inc. All rights reserved.