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 (Figure 12).
Some driver networks do not have Tuning Policies, for example an RdbmsNetwork for a database driver. Also, the NiagaraNetwork
has greatly simplified Tuning Policies.
By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (“Default Policy”). However, you typically 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 Niagara 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 Start” property 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 Frequency” property 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 4 available (and different) tuning policies to pick from when you create and edit proxy points, where you could selectively apply the policy needed.
The following sections provide more Tuning Policy details:
Tuning Policy properties for typical field bus drivers are as follows:
-
Min Write Time
Applies to writable proxy points, especially ones that have one or more linked inputs. Specifies the minimum amount of time allowed between writes. Provides a method to throttle rapidly changing value so that only the last value is written. If this property value is 0 (default), this rule is disabled (all value changes attempt to write).
-
Max Write Time
Applies to writable proxy points. Specifies the maximum “wait time” before rewriting the value, in case nothing else has triggered a write. Any write action resets this timer. If property value is 0 (default), this rule is disabled (no timed rewrites).
In some cases setting this to some value, for example 10 minutes, may be useful. Often, a network may have devices that upon
a power cycle (or even a power “bump”), have writable points that reset to some preset “default” value or state. Note that
often in a “site-wide” power bump of a few seconds, such field controllers (devices on the network) typically reset, but a
JACE continues normal operation on 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. Here, 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 issues like
this.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. Exercise caution with this property in this case, to avoid “write contention” that
could result in toggling loads.
-
Write On Start
Applies to writable proxy points. Determines behavior at station startup.
-
If true, (default) a write occurs when the station first reaches “steady state.”
-
If set to false, a write does not occur when the station reaches “steady state.”
Consider setting this to false in 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), will upon station startup attempt to
write to all 4,000 points, putting a significant load on the station. As a consequence, it is possible that in this scenario the Bacnet driver (network) may generate “write queue
overflow” exceptions.
-
-
Write On Up
Applies to writable proxy points. Determines behavior when proxy point (and parent device) transitions from “down” to “up.”
-
If true, (default) a write occurs when the parent device transitions from down to up.
-
If set to false, a write does not occur when the parent device transitions from down to up.
-
-
Write On Enabled
Applies to writable proxy points. Determines behavior when a proxy point’s status transitions from “disabled” to normal (enabled).
-
If true, (default) a write occurs when writable point transitions from disabled.
-
If set to false, a write does not occur when writable point transitions from disabled.
The disabled-to-enabled status transition can be inherited globally by points if the parent device had been set to disabled—or network-wide if the driver network was set to disabled. Therefore, be aware that if left at truein tuning policies, that all associated writable points receive a write upon either the device or network when it transitions from status “disabled” to “enabled.” -
-
Stale Time
Applies to all proxy points.
-
If set to a non-zero value, points become “stale” (status stale) if the configured time elapses without a successful read, indicated by Read Status “ok.”
-
If set to zero (default), the stale timer is disabled, and points become stale immediately when unsubscribed.
By default, proxy point status “stale” is indicated by tan background color. In addition, stale status is considered “invalid” for any downstream-linked control logic. For more details, see the User Guide section “About “isValid” status check”.
Stale time is recommended to be specified 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 for some reason, then another poll cycle time or two is allowed for the message to be received before setting
the stale flag.
-
-
Poll Frequency
(May not exist in some driver’s tuning policies, but is instead a separate property of each ProxyExt) Applies to all proxy points. Provides a method to associate the tuning policy with one of 3 Poll Rates available in the network’s Poll Service: Fast Rate, Normal Rate, or Slow Rate. The default poll frequency is “Normal.”
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 BacnetComm > Network
container. The NiagaraNetwork uses subscriptions instead of polling.
Tuning policies used by a specific driver may have unique characteristics. For example, under a NiagaraNetwork, its TuningPolicy has only three properties: Stale Time, Min Update Time, and Max Update Time. For more details, see NiagaraStation component notes.
Other drivers may have specific considerations for tuning policies. For more information, refer to the “Tuning Policy Notes” section within any NiagaraAX driver document.