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.
To access these properties, expand 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 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.