Virtual limitations and guidelines

Virtuals are transient. They do not persist. The station dynamically creates and subscribes to them only when you access them. They are not permanently stored in the station database. This precludes any linking to or from virtuals as links would be lost. Nor are point extensions (alarm, history) supported for virtual components. These features require the use of proxy points, which are persisted in the station database.

Limitations

Values from remote stations needed within station logic require proxy points. For example, a math Average object that averages zone temperatures originating in multiple controller stations requires a proxy point for input to define the relevant (remote station) data source.

Point extensions under virtuals are not supported. This includes alarm and history extensions, although from a best-practices perspective, such extensions are often misplaced in proxy points.

Using virtuals on Px pages is recommended only after finalizing most other component configuration, including finalzing facets and the config flags of any (target) control points that will be incorporated. The reason is that the virtual ORD syntax used in a Px widget binding to the point actually includes that point’s facets and config flags (used at the time of widget creation), encoded into the (persisted) ORD itself. So, if a target point has a subsequent facets change, a Px page with a virtual binding to it may require re-engineering.

Guidelines

To summarize, here are some quick application guidelines for virtual components versus proxy points:

To link station logic in to or out of the data item, use a proxy point.
To alarm or trend/log (history) a data item, use a proxy point.
To use the value of a data item only while a user is looking at a Px view, use a virtual component.
To configure values in the device for one-time commissioning, use a virtual component.