About Bacnet Polling

Since the initial (AX-3.0) release, polling improvements have been made in the NiagaraAX Bacnet driver, culminating in a reworked polling mechanism starting in AX-3.2. This section describes the different Bacnet driver polling mechanisms by different release levels, and notes related areas of possible configuration changes and default behaviors.

Basic Bacnet polling design

Regardless of NiagaraAX release level, the Bacnet driver is unique among all drivers in that there are multiple communication port types available (IpPort, EthernetPort, MstpPort), along with multiple instances of ports supported, all under one network-level component (BacnetNetwork). Thus, the driver design has always used a separate “BacnetMultiPoll” (Poll Service) component for each network port, where each “poll scheduler” component is found under BacnetComm, Network, <port>, as shown in Figure 8.

Figure 8. Separate Poll Service for each port under BacnetComm, Network

You can adjust the basic poll settings used for each port in its own poll scheduler, as well as see individual statistics. The basic operation of each Poll Service, including the four “buckets” (3 rate group + “dibs” stack) is explained in the Drivers Guide, in the section “About poll components”. Note that a “multi-thread” capability exists in all Bacnet Poll Services, as this is sometimes needed even in a (typically speedy) IpPort or EthernetPort link layer, where point polling might involve a BACnet router (say, going between B/IP and slower MS/TP devices).

Also unique to Bacnet polling (in any release) is the interplay with BACnet COV services, where some server devices may offer COV for point updates (as a typically desirable alternative to polling). This affects Tuning Policy configurations, and how you should assign tuning policies for points. For related details, see Bacnet Tuning Policy notes, BacnetDevice properties, and Bacnet ProxyExt properties.

And now for the release-level differences in Bacnet point polling:

Current Bacnet polling (AX-3.2 and later)

Starting in AX-3.2, polling of Bacnet proxy points uses the Basic Bacnet polling design, with the following key points:

By default, any Bacnet proxy point polls only the (one) single, configured property for polling. Thus, if you specify “presentValue,” that is all the point’s out displays from BACnet—no native object status, or currently active level (“bac=n”, if a commandable object), affect the point display.

However, as needed you can add either or both of these extra polled properties, and/or others, by editing the facets of proxy points. See Facets usage to poll additional properties. Also, note that if adding statusFlags (as before) there is a point “status merge”—see Status merger for Bacnet proxy points.
Using an “added slot” method on a Bacnet ProxyExt, it is now possible to poll for data outside the normal boundaries of a single object poll, such as sometimes needed in “Event Enrollment” scenarios. For more details, see Advanced “add DOPR slot” to ProxyExt method.
Efficiencies in polling come about from a “PollListEntries” method, where any “pollable” component (proxy points, Config objects) that is subscribed is added by its poll service into aggregate poll list objects (by containing device), where they are better processed. In addition, “dibs” polling can make more efficient use of bandwidth by using ReadPropertyMultiple to poll objects.

For the most part, these efficiencies do not affect station polling configuration (however, starting in AX-3.2, the “maxDevicePollSize” property of a BacnetDevice, if still present, has no significance).

Notes on AX-3.1 and earlier Bacnet polling

Note that in any AX-3.0 or AX-3.1 system, Bacnet proxy point polling uses the Basic Bacnet polling design, but works differently than current Bacnet polling, as follows:

All proxy points (regardless of property chosen for polling), poll the target object’s Status_Flags property (if present). This reflects in the proxy point’s status, as it is “merged” with the native Niagara status for the point itself. For details, see Status merger for Bacnet proxy points.
Prioritized points (for objects with Priority_Array property) always poll that property in addition to the chosen property, such that this extra information is seen in the point display, using a “bac=n” display convention to show the currently active level.
Points polled from the “dibs” stack in any Poll Service (highest priority) are always polled using the ReadProperty service instead of ReadPropertyMultiple. This individual poll technique does not always make best use of polling bandwidth.
BacnetDevice components use a “maxDevicePollSize” property, a dynamic property that is sometimes added and (initially) auto-calculated when the device is learned or created, going by the property “maxAPDULengthAccepted” in its corresponding Device object. The purpose of this property was to allow tunable “group polling” (ReadPropertyMultiple service, if supported by device), specifying the number of points per poll—where you may adjust it downwards, if found necessary. This was sometimes needed if polling was for points with larger, unbounded data types, such as string or octet-string. Also, this property could automatically decrement on its own, in certain scenarios where polling issues occurred. In these cases, this resulted in more poll list entries (using single ReadProperty service).