Virtual applications and advantages

Subscribing to a persistent component only to view a Px page followed by unsubscribing when no one is looking at the page consumes valuable station resources. Using virtual components, a station not only unsubscribes from the virtual component, but it also frees up station resources when it removes the component from the station’s memory.

A driver that offers virtual objects provides two main applications: Px view bindings for the simple polling of values without the station resource overhead of persisted proxy points, and quick review and (if possible) adjustments to one or more properties for objects in native devices.

Low overhead Px bindings

Virtuals in a Supervisor provide the same on-demand subscription of remote real-time data on Px pages as do proxy points, including right-click popup menus to issue actions. However, the Supervisor station overhead from scores of persisted proxy points is gone. Instead, the only persisted items are the ORDs to virtual objects within Px widgets. This results in fewer resources consumed, along with faster station startup.

Upon being unsubscribed, the poll scheduler removes virtual components from the scheduler (or subscription mechanism) and station memory. The only persisted (permanent) records of a virtual object are its ORDs (using virtual syntax) in the Px widget bindings. In some cases, particularly with replicated device applications, this allows a controller station to graphically monitor many more devices than it can monitor using only proxy points.

NOTE: A virtual gateway cannot have its own Px view, but you can use its child virtual components in Px views for other components, for example on the device component itself or its Points extension, and so on.

The Px bindings to virtual objects use virtual ord syntax that includes the virtual gateway within it (and activates it at runtime). Dragging a virtual component to the Px page automatically resolves the ORD and makes your selection in the popup Px Make Widget window, as shown here.

Figure 33. Dragging a BACnet virtual component into a Px editor view with the resulting Make Widget popup

Depending on the driver, Px usage details may differ for virtual components. For example, usage of virtual components in Px views includes special considerations.

Time savings

Virtuals provide a possible savings in engineering time as point discovery and creation using the Bql Query Builder is not needed. Instead, virtual components expand under a NiagaraStation’s virtual gateway to reflect the entire component tree for the station. From the tree you can drag virtuals to Px pages and select appropriate settings in the popup Make Widget windows.

Quick property change reviews

Using the Workbench property sheets to make property changes to virtual components can speed what-if scenarios. Otherwise, you would need to create proxy points, then delete them after reviewing and changing properties. This application applies to both NiagaraNetwork virtual components and BACnet virtual components.

Easy user access

Writable virtuals can easily provide user access to almost any property in a Px page graphic for both display and adjustment purposes. For example, to expose the high alarm limit for a point, a user can expand its alarm extension to reveal child containers, drag the Offnormal Algorithm virtual to the Px page, and in the Make Widget popup window, select the ORD to the High Limit property. Creating a proxy point for this purpose beforehand is not needed.