Best practices for Niagara proxy points

Are they even needed for Px views?

The typical “large scale” usage of Niagara proxy points has historically been in a Supervisor station, such that real-time values could be modeled and thus displayed centrally in Px views on the Supervisor. Prior to AX-3.4, and especially AX-3.5, it was not uncommon for a such a station to have several hundred, or even thousands, of Niagara proxy points—with data originating within various remote JACE stations.

However, with the introduction of “export tags” in AX-3.5, as well as the enhanced, writable “Niagara virtual components”, such usage for proxy points in a Supervisor should diminish, for these reasons:

If a Supervisor needs to serve up PxPages that already exist in a JACE station, simple use of “PxViewTag” export tags in that JACE station can automatically replicate all needed components on the Supervisor—including all necessary Niagara virtual points. Niagara proxy points are not needed. For further details, refer to the document NiagaraAX Export tags.
If engineering PxPages that exist only on the Supervisor, and real-time values and access to right-click actions are needed from subordinate JACE stations (that would previously require Niagara proxy points), consider using Niagara virtuals instead. In some cases, virtual components offer techniques previously hard to do when using proxy points, such as providing a user edit access in a graphic of items like alarm limits. See Niagara virtual components.

Avoid point extensions under Niagara proxy points

Although there are no “rules” against it, adding history extensions or alarm extensions to Niagara proxy points may be considered unwise, as even momentary communications issues between a JACE station and its Supervisor can result in loss of (otherwise recorded) history records or alarm conditions.

Therefore, the following recommendations apply to configuring Niagara proxy points:

Instead of adding a history extension to a Niagara proxy point in the Supervisor station, add it instead to the source point in the remote station. Then, either import such histories into the Supervisor (or, from the JACE station side, export them to the Supervisor).

For related details, see Niagara History Import Manager, Niagara History Export Manager, and History Policies.
Instead of adding an alarm extension to a Niagara proxy point in the Supervisor station, add it instead to the source point in the remote station. Then, configure alarm routing from the JACE station into the Supervisor. For related details, see NiagaraStation Alarms notes.

Note that routines for interstation history archiving (import) and alarm routing routines have integral “retry” mechanisms, such that temporary loss of station communications typically does not result in loss of history data or alarm events. Instead, that data safely resides on the JACE until communications can be re-established.

Avoid links to proxy point actions

Although currently the wiresheet and Link Editor allows you to link to action slots on Niagara proxy points, this has been found to result in issuses, as such links can be lost, typically upon a station restart. Unlike property slots, actions can be dynamically refreshed (rebuilt). If such an action was a link target, that link record is gone. An example scenario is in a Supervisor station, where a “master” NumericWritable component’s set action has been linked to the set action of multiple Niagara proxy points (where each in turn represents a setpoint of some data item proxied in a driver’s network).

Future NiagaraAX releases may prevent linking to proxy point actions in the Link Editor and wiresheet. Until then, avoid links to actions of proxy points.

Equivalent link control may be possible by creating Niagara proxy points in each JACE station (of source items in the Supervisor station), and then linking properties of those proxy points to other driver’s proxy points in that JACE station. For related details, see Link control and Niagara proxy points.

When a Niagara proxy point is required

A Niagara proxy point is required whenever you need to use its data value in local station control logic, that is, as the source of a link. For example, you may have a local “Average” math component that is averaging temperature values sourced from three different stations, using Niagara proxy points. Niagara virtual components cannot be used in this way, because they do not “persist”—they exist only during active subscriptions (typically from users accessing PxPages).

Sometimes, this type of Niagara proxy point usage may be needed in JACE stations that need to directly share (and process) selected data items for control reasons. For a related topic, see Link control and Niagara proxy points.