niagaraDriver-NiagaraTuningPolicy
Contains properties used in the NiagaraNetwork’s handling of both write requests (e.g. to writable proxy points) as well as the acceptable freshness of read requests of proxy points. You can create multiple tuning policies under the NiagaraNetwork’s NiagaraTuningPolicyMap. You can then assign one or more proxy points to a specific policy. Container for one or more NiagaraTuningPolicy(ies), found in the NiagaraNetwork’s property sheet.
Tuning Policy Properties
A network’s Tuning Policies holds one or more collections of rules for evaluating both write requests (e.g. to writable proxy points) as well as the acceptable freshness of read requests from polling. In some drivers (such as Bacnet), also supported is association to different poll frequency groups (Slow, Normal, Fast). Tuning policies are important because they can affect the status of the driver’s proxy points.
In the network’s property sheet, expand the Tuning Policies (Map) slot to see one or more contained Tuning Policies. Expand a Tuning Policy to see its configuration properties, as shown.
By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (Default Policy). However, you create multiple tuning policies, changing those items needed differently in each one. Then, when you create proxy points under a device in that network, you can assign each point (as needed) to the proper set of “rules” by associating it with a specific tuning policy.
Using only a single (default) tuning policy, particularly with all property values at defaults, can lead to possible issues in many driver (network) scenarios. In general, it is recommended that you create multiple tuning policies, and configure and use them differently, according to the needs of the network’s proxy points and the capabilities of the driver. In particular, tuning policy properties that specify writes from the framework should be understood and applied appropriately. See Tuning Policy properties for more details.
As a simple
example (under a BacnetNetwork), you could change the default tuning
policy’s Write On Startproperty from the default
(true) to false. Then, duplicate
the default tuning policy three times, naming the first copy Slow
Policy, the second copy Normal with Write Startup, and the third copy
Fast Policy. In two of those copies, change the Poll Frequencyproperty from Normal to Slow or Fast, corresponding to its name.
In the Normal with Write Startup tuning policy copy, you could change
its Write On Start property back to true.
Then, only the Normal with Write Startup tuning policy has Write On Start set as true. At this point you would then have four available (and different) tuning policies to pick from when you create and edit proxy points, where you could selectively apply the policy needed.
Tuning policies used by a specific driver may have unique characteristics. Other drivers may have specific considerations for tuning policies. The below is the example of Bacnet driver tuning policy properties:
You access this Property Sheet by expanding followed by double-clicking or right-clicking the network node, clicking and expanding the .
| Property | Value | Description |
|---|---|---|
| Min Write Time | hours minutes seconds (defaults to zero (0)) | Specifies the minimum amount
of time allowed between writes to writable proxy points, especially
ones that have one or more linked inputs. This provides a way to throttle
rapidly changing values so that only the last value is written. The default value (0) disables this rule causing all value changes to attempt to write. |
| Max Write Time | hours minutes seconds (defaults to zero (0)) | Specifies the maximum amount
of time to wait before rewriting the value, in case nothing else has
triggered a write, to writable proxy points. Any write action resets
this timer. The default (0) disables this rule resulting in no timed rewrites. In some cases, setting this to a value, such as 10 minutes, may be useful. Often, a network may have devices that, upon a power cycle or even a power interruption, have writable points that reset to some preset default value or state. Often, in a site-wide power bump of a few seconds, such field controllers (devices on the network) typically reset, but the controller continues normal operation running on a backup battery. Since the network’s default monitor ping is usually 5 minutes, the station (network) may never mark these devices as down, such that a Write On Up does not occur. If a writable point represents an AHU or chiller that defaults to unoccupied following a device reset, the load never restarts until the next day when the schedule toggles. Assigning the point to tuning policy that does have a configured Max Write Time can correct this problem. At the same time, realize that many networks may be configured such that multiple masters may be issuing conflicting writes to one or more points in a device. In this case, exercise caution with this property to avoid write contention that could result in toggling loads. |
| Write On Start | true (default) or false | Determines a writable
proxy point’s behavior when the station starts. true initiates a write when the station first reaches a steady state. false prevents a write when the station first reaches a steady state. Note: Consider setting to false except for critical proxy points, otherwise large networks may experience
write-queue-overflow exceptions. Consider setting this to false for most tuning policies, except for tuning policies selectively assigned to more critical writable proxy points. This is particularly important for large networks with many writable proxy points. For example, a BacnetNetwork with 4,000 writable proxy points, if configured with only the default Tuning Policy (at default values), upon station startup attempts to write to all 4,000 points. This puts a significant load on the station. As a consequence, the BACnet driver (network) may generate write-queue-overflow exceptions. |
| Write On Up | true (default) or false | Determines a writable
proxy point’s behavior when the point and its parent device transition
from down to up. true initiates a write when a transition from down to up occurs. false prevents a write when a transition from down to up occurs. |
| Write On Enabled | true (default) or false | Determines a
writable proxy point’s behavior when the point’s status transitions
from disabled to normal (enabled). true initiates a write when the transition occurs. false prevents a write when the transition occurs. The disabled-to-enabled status transition can be inherited globally by points if the parent device was set to disabled, or network-wide, if the driver network was set to disabled. Therefore, be aware that when left at true all associated writable proxy points receive a write when either the device or network transition from a status of disabled to enabled. |
| Stale Time | hours minutes seconds (defaults to zero (0)) | Defines the period of time without
a successful read (indicated by a read status of {ok}) after which
a point’s value is considered to be too old to be meaningful (stale). A non-zero value causes the point to become stale (status stale) if the configured time elapses without a successful read, indicated by Read Status {ok}. The default value (zero) disables the stale timer causing points to become stale immediately when unsubscribed. A tan background identifies stale proxy points. A stale status is considered invalid for any downstream-linked control logic. Do not configure an amount of time shorter than the poll cycle time. If you do, points will go stale in the course of normal polling. Instead, set this time to be longer than the largest expected poll cycle time. You should configure a Stale Time that is at least three times the expected poll cycle time. Most peer-to-peer networks do experience collisions and missed messages. Setting the Stale Time short will likely produce nuisance stale statuses. If a message is missed, a longer Stale Time allows for another poll cycle time during which to receive the message before setting the stale flag. |
| Poll Frequency (This property may not exist in some driver’s tuning policies, but is instead a separate property of each ProxyExt) | drop-down list (defaults to Normal) | Selects among three rates
(Fast, Normal and Slow) to determine how often to query the component
for its value. The network’s Poll Service or Poll Scheduler defines
these rates in hours, minutes and seconds. For example: Fast may set polling frequency to every second. Normal may set poll frequency to every five seconds. Slow may set poll frequency to every 30 seconds. This property applies to all proxy points. Depending on the driver, there may be a single Poll Service (or Poll Scheduler) slot under the network, or as in the case of a BacnetNetwork, a separate Poll Service for each configured port (IP, Ethernet, Mstp) under its container. The NiagaraNetwork uses subscriptions instead of polling. |
| Use Cov | true or false If the device was discovered, and station database determined that the device indicates support for server-side COV, this property defaults to true. Otherwise, it defaults to false indicating that no proxy points under the device use COV. | Enables and disables a device’s support for COV (change
of value) as a way to monitor proxy point values. Assuming the device supports subscription to the COV service, true triggers the driver to attempt the necessary updates (proxy subscriptions) to the value of each point using the BACnet COV subscription to the device. If the subscription attempt succeeds, the Read Status property of the point’s BacnetProxyExt displays COV. If the subscription attempt fails, the driver uses normal polling and the Read Status property shows Polled. When true, individual proxy points under the device may use COV subscriptions, depending on their assigned tuning policy. When false, the driver ignores any proxy subscription updates. How to find: expand the BACnet network and double-click the BACnet device. Also available on the Device Manager Add window. |
| Use Confirmed Cov | true (default) or false | Controls device updates. If enabled (true), and the assigned proxy points are under a BacnetDevice that supports Confirmed COV notifications, the driver attempts any necessary updates (proxy subscriptions) using BACnet confirmed COV subscriptions to the device. If disabled (false), the driver ignores this property. How to find: expand , BACnet network, expand Tuning Policies and double-click Default Policy |
| Cov Subscription Lifetime | time range (defaults to 15 minutes) | Indicates the lifetime, in minutes, for which the database subscribes for COV notifications, then (if necessary) periodically subscribes again. A value of zero means an indefinite lifetime, although this is not guaranteed to persist across resets of the server device. |
NiagaraNetwork Tuning Policies
A NiagaraNetwork has only three tuning policies as shown below:
You access this Property Sheet by expanding followed by double-clicking or right-clicking the network node, clicking and expanding the .
| Property | Value | Description |
|---|---|---|
| Stale Time | time | If set to a non-zero value, a subscribed proxy point becomes
stale (status stale) if the configured Max Update Time expires without
an update from the server (source station). This stale timer is reset
upon each subscription update. If set to zero (default), the stale
timer is disabled, and a subscribed point becomes stale only while
the source (server) point is also stale. Note: Whenever
a source point of a proxy point has a stale status, for example a
Bacnet proxy point, the proxy point for it will also have a stale
status, regardless of this setting. Stale time is client side, whereas the other two update time properties affect server side operation of the subscription. For example, when a client (Supervisor) station creates subscriptions to a server station (JACE with a field bus), say to update proxy point values on a Px page, subscriptions are set up with the server to observe rules in the Min and Max Update Time values. |
| Min Update Time | Time | The minimum amount of time between updates sent from the server to the client. It is used to throttle data changing at a rate faster than minUpdateTime. Default value is 1 second. |
| Max Update Time | Time | Used by the server to resend the values to the client for
subscribed points, if values have not been sent for other reasons
(such as a change of value or status). Default value is 15 minutes. Note: Relative to tuning policies in other networks, the importance
of NiagaraNetwork tuning policies are secondary,
and then only applicable for a station that has proxy points under
its NiagaraNetwork. In applications, this means
the Supervisor station only. As a general rule, if configuring the Stale Time in a Tuning Policy, it is recommended to be greater than the Max Update Time by a factor of three. |