Prior to AX-3.7, this component was the “NiagaraVirtualGateway”, with all child virtual components sourced from the niagaraDriver module. Starting in AX-3.7, the virtual gateway architecture changed such that a separate niagaraVirtual module is used. Note that Niagara virtuals operation is essentially unchanged, except for improvements. For related details,
see Niagara virtuals in AX-3.7.
Every NiagaraStation component in a station’s NiagaraNetwork has a frozen NiagaraVirtualDeviceExt (Virtual) slot, at the same level as other device extension slots (Points, Schedules, etc.).
Successfully accessing components under this Virtual device extension (gateway) dynamically adds them as Niagara virtual components (or Niagara “virtuals”) while they are subscribed, but they exist only in memory—they are not persisted in the station database like proxy points.
The following sections provide more details on a Niagara Virtual Device Ext:
Any Virtual gateway provides virtual component access only if the following are all true:
-
The local station’s host is so licensed. Typically, licensing applies mainly to a Supervisor host—for further details see Licensing.
Therefore, in most JACE stations, any NiagaraStation’s Virtual gateway is non-functional.
-
The parent NiagaraStation component is enabled, and its property “Virtuals Enabled” is set to true. By default, this property is set to false, for station security reasons—see Security and Niagara virtuals for more details.
The property sheet of a Niagara Virtual device extension (gateway) has a “Virtual Info” slot that provides a number of status properties, including a “Last Failure Cause” property, as shown in Figure 114.
In the Figure 114 example, the Virtual gateway has a fault status, because even though the station’s “Virtuals Enabled” property is true, the (JACE) host running this station is not licensed for Niagara virtuals. In this typical case, note the last failure cause is “Niagara Virtual Components are not licensed”.
In a Supervisor station, this specific failure cause would not appear. However, a Niagara Virtual gateway in a Supervisor station may still be disabled, or even in fault (say, if the remote station is running an earlier release than AX-3.4). In any case, the failure cause property provides fault details.
As a Baja virtual gateway, the Niagara Virtual device extension (gateway) only loads what is needed or “activated” as virtual components in the memory space of the station. For a general overview of how this works, see Gateway activation.
Activation of a Niagara Virtual gateway results in some number of “client virtual subscriptions” to those components exposed, when any of the following occurs:
-
a Virtual device extension is expanded in the Workbench Nav tree
-
a Virtual device extension is expanded in its Workbench property sheet
-
a Px page (with widgets bound to virtuals under that Virtual device extension) is being viewed
By default, viewing activated components places them in a memory “cache” for some minimum number of seconds, where they remain
as long as being active (viewed). After some maximum time of inactivity, virtual components may be automatically deleted from
this cache. By default, inactive cache life is around 1 minute. In most cases default settings are fine, however, associated
cache settings for Niagara virtual components can be adjusted by changing entries in the host’s (Supervisor’s) !\lib\system.properties file. Note this file includes self-doc comments about these settings.
Starting in AX-3.7, the cache of frequently-accessed virtual components is also stored persistently in one or more files under the station’s folder, by default. These “niagara virtual archive” (.nva) files are under the station’s default niagaraDriver_nVirtual subfolder, as cache1.nva, cache2.nva, and so on. They are typically created upon station shutdown, and provide faster Px page loading. For related details, see
Niagara virtuals cache (Virtual Policies).
Note that if engineering a job while configuration changes are still being made in a remote station (modeled by a NiagaraStation in the local NiagaraNetwork), it may be necessary to use the right-click Refresh action on the Virtual device extension, as shown being done in Figure 115.
As a general rule, a Refresh action is typically needed when the Nav tree contents for Niagara virtuals under a station are “not as expected.”