A properly added bound label (to a Niagara virtual) can provide the same Px access as if bound to Niagara proxy point. Other Px widget selections, such as a field editor (property selection) are also supported.

In general, it is recommended that you make Px bindings to a specific property of a Niagara virtual, rather than a whole virtual component. This can improve both performance and graphical rendering (for example, if a Bound Label, this technique can also allow the “Status” (Color) option to work).

In Figure 127, note the selection of a specific property of the Niagara virtual, via the Select Ord popup dialog. In this example, the selected component is expanded, and the property “Out” is selected.

To do this, double-click in the top field (Ord) of the Make Widget dialog after dropping the Niagara virtual. This produces the Select Ord dialog, where you then expand the selected virtual to select its desired property (as shown being done in the Figure 127 example). Double-click to select and close.

If only the value or status is wanted for display in a bound label, you could further expand the Out property in the Select Ord dialog, and select either Value or Status.

You must further select “Value” or “Status” of a selected “Out” property in the case of a selected “virtual to virtual”. Otherwise, the Px value displayed is likely to be: vStatus {ok} (instead of the end target value). Alternatively, you can edit the BoundLabel Px widget’s BFormat (text) property value from the default: %.% to instead: %value% or %status% or %value% %status%.

For example, consider the Figure 128 Px example of two groups of 3 bound labels. each bound to a Niagara virtual representing a control point.

In the two preceding examples, the BFormat text formatting (Format Text or “text” property), was left at a default %.% value. If needed, support for additional text formatting is also available Bound Labels. For example, to add leading (or trailing) static text around the %scripted% portion, after adding the widget.

However (and again), it is more efficient to specify a particular property of a Niagara virtual (initially, in the Select Ord dialog before widget creation). That is, instead of adding a Px widget bound to the root of a Niagara virtual component, and then specifying a particular %propertyName% in its text formatting.

In the case of doing the latter, note that all properties of the target Niagara virtual become loaded from viewing the Px page, not just the single property specified by the text formatting. You can use “spy” troubleshooting pages to observe this behavior as applied to Niagara virtual components. See the next section, Spy page diagnostics.

Niagara virtuals have writable properties. This lets you expose properties that may need adjustment onto PxPages, using standard “drag and drop” techniques. Figure 129 shows such an example, for an alarm limit for a proxy point’s alarm extension.

If users have proper permissions on such Niagara virtuals, they can make configuration changes that are written to the (actual) source component.

Note the “class types” for Niagara virtuals include a Niagara virtual type for each of the eight NiagaraAX “control points”, that is a NiagaraVirtualNumericPoint, NiagaraVirtualNumericWritable, NiagaraVirtualBooleanPoint, and so on. This results in better overall handling of point status in Niagara virtuals on PxPages. This also helped in development of the “export tags” feature for Supervisor auto-configuration, first introduced in AX-3.5. Starting in AX-3.7, these eight class types are sourced from the niagaraVirtual module, along with most other Niagara virtual component types and views.