niagaraVirtual-NiagaraVirtualComponent

This component supports Baja virtual components (virtuals) in a Supervisor station. These components reside under the NiagaraVirtualDeviceExt (Virtual slot) of each NiagaraStation.

Typically, virtuals are possible only under a Supervisor station’s NiagaraNetwork (the niagaraDriver feature in the host’s license must have virtual attribute set to true). If the Virtuals Enabled property of the NiagaraStation is set to true, the entire component structure of that station can be dynamically modeled using virtuals.

The Workbench icon for each virtual has a small ghost superimposed in the lower right over the normal icon. This visual reminder indicates that you are looking at the virtual component space that represents the remote station’s configuration.

The station provides only two meaningful views for virtual components: the virtual gateway’s Property and Category Sheets. Special manager views for virtuals are not available. Regarding the other views and how they relate to virtuals:

Wire Sheet: not available. The station does not support links to and from virtual components.
Slot Sheet: available but of little practical application. Any changes made to slots (config flags, new slot, etc.) do not persist. However, this sheet displays the cryptic internal naming of virtual slots including the encoded facets and config flags used in ORD bindings from Px pages.
Link Sheet: not available. The station does not support links to and from virtual components.

Figure 88. Virtual properties

To access these properties, expand Config > Drivers > NiagaraNetwork > NiagaraStation and double-click the Virtual node.

Property	Value	Description
Status (vStatus)	read-only	Reports the status of the virtual object. This is not to be confused with the status of the source component in the remote station. For example, a virtual for a proxy point may report {ok}, yet show an `Out` with a status of {down}. A virtual status may initially report {stale} before changing to {ok}.
Type Spec	read-only	Reports the `moduleName:componentType` used to represent the virtual, for example in the Property Sheet for the component.
Slot ORD	read-only	Reports the path to the remote source component relative to the remote station’s slot hierarchy where the leading root portion of the path is `station:\|slot:`.
Last Failure Cause	read-only	Reports a text string that indicates why the most recent attempt to execute failed.
Gateway	read-only	Identifies the station.

Refresh action

A virtual gateway only loads (activates) in memory the virtual components it needs to represent the remote station. Any one of these actions executes a driver-specific call to the device to gather these data. The results appear as child virtual components in the NiagaraStation:

Double-clicking on the gateway’s Property Sheet.
Expanding the NiagaraStation > Virtuals node in the Nav tree.
Viewing a Px page with widgets bound to virtuals under the Virtual gateway.

Viewing activated components places them in a memory cache for some minimum number of seconds. They remain as long as they are active (being viewed). After some maximum time of inactivity, the station automatically deletes the virtual components from this cache. By default, inactive cache life is about one (1) minute. In most cases, this default is fine. You can adjust cache settings for virtual components by changing entries in the host Supervisor’s !\lib\system.properties file. This file includes helpful comments about these settings.

If you are engineering a job while configuration changes are still being made in a remote station (modeled by a NiagaraStation in the local NiagaraNetwork), you may need to use the right-click Refresh action on the virtual gateway.

As a general rule, this action is typically needed when the Nav tree contents for virtuals under a station do not display as expected.