Added Obix proxy points often resemble Niagara proxy points (under Points container of a NiagaraStation in a NiagaraNetwork) in the following ways:
-
Most proxy points for R2 objects, including ones for “input writable” ones such as BinaryOutput, AnalogOutput, MultistateOutput, Loop, and so forth are proxied as read-only points only—writable AX point types like BooleanWritable, NumericWritable, etc. are not selectable. This applies to all nodes and properties that appear in the Discovered table with a “Mode” of “RO” (read only).
However, object commands are available, as actions of the read-only proxy point. See Figure 16 and also Command Notes.
-
Some R2 object properties show a discovered “Mode” of “RW”. Most are configuration types such as alarm limits (e.g. “lowLimit”, “highLimit”), “deadband”, and “notificationClass” as a few examples. If desired, you can proxy such a property as a writable point type, e.g. NumericWritable, BooleanWritable, etc. This allows you to write the R2 property value from the AX station, either by an invoked action on the proxy point, or by linking to the proxy point’s input(s).
By default, right-click actions on a writable Obix proxy point include both
Typically, “standard” control logic linking from AX to an R2 object requires additional engineering on both sides; see Link control into R2 objects.-
native AX actions for the writable point - to change the value of the specific R2 property
-
actions for the commands on the parent R2 object - to directly command that object
In some cases, you may wish to hide some action slots, e.g. ones for the parent object’s commands. Or, if link control (via proxy input) is the only intended method, you may wish to hide all action slots. If hiding any actions, be sure to hide the “forceUpdate” one. See forceUpdate.
-
Figure 16. Proxy point for R2 object or property offers actions for commands, even as read-only point
By default, every Obix proxy point has an available “forceUpdate” action, an admin-level action that results in an immediate fetch of the property’s value. If applicable, the forceUpdate also reflects any R2 configuration changes to the parent object’s display-related property (“units”, “activeInactiveText”, etc.).
However, sometimes you may wish to hide the forceUpdate action slot, working from the slot sheet view of the Obix proxy point. This is especially true if the proxy point has R2 object command actions that are “hidden,” or have other config flag changes. Otherwise, invoking forceUpdate causes config flag changes to those actions to be overwritten with defaults. For example, any R2 command actions previously engineered to be hidden will display, or command actions set to “Operator” will revert to admin level.
A “global” forceUpdate action is on the Points extension of an R2ObixClient. Although seldom exposed on a PxPage, know that it effectively invokes a forceUpdate to all Obix proxy points for an R2ObixClient. Even for just Workbench access, you may wish to hide this action slot (if not already
hidden).
In addition to a proxy point “forceUpdate” action, note by default “normal right-click” commands appear on the action menu for Obix proxy points—providing the source R2 object has commands. Actions display mirroring the configured R2 object’s “commandTags” property strings, where applicable.
If a source R2 control object has “empty” (blank) commandTags properties, note that (by design) corresponding actions do not appear—the same as on the R2 object’s right-click command menu. However, note that those actions do exist on the slot sheet of the Obix proxy point with the Hidden config flag set, by default.
Also by default, note that some additional hidden actions may also exist, depending on the source R2 object type. See Hidden actions for related details.
Actions for R2 object commands that are operator level (“Cmd, Std”) automatically default with the Operator config flag set. See Figure 18 for how these defaults look from the slot sheet of a proxy point.
Such “manual” (often level 8) commands on R2 objects include:
-
manualSet (AnalogOutput, MultistateOutput)
-
manualAuto (AnalogOutput, BinaryOutput, MultistateOutput)
-
manualActive, manualInactive (BinaryOutput)
-
override, cancel, setOverrideValue (AnalogOverride, MultiStateOverride, BinaryOverride)
Note for a few R2 object types, due to the unique “string” content for command names, operator-level actions do not have the operator flag automatically set—for example an Obix proxy point for an R2 “Command” object, or for a BinaryOverride object’s “overrideActive” and “overrideInactive”. If needed, you can explicitly set the operator flags on these actions.
Other hidden actions may also exist on the Obix proxy point’s slot sheet, including commands normally accessible only on the “Command menu” of the JDE (WorkPlace Pro), when that R2 object’s property sheet is displayed in the JDE for an admin-level user.
Examples of such commands for various control objects include:
-
resetAckedTransitions — For all alarm capable objects. Rarely used, it sets any cleared flags in the object’s ackedTransitions property.
-
resetChangeOfStateCount — For BI, BO, MSI, MSO objects. Zeroes out any accumulated COS value (numerical changeOfStateCount).
-
resetActiveTime — For BI, BO, MSI, MSO objects. Zeroes out any accumulated runtime value (numerical elapsedActiveTime).
-
setChangeOfStateAlertLimit — For BI, BO, MSI, MSO objects. To change the numerical COS limit for generating an alert (changeOfStateAlertLimit).
-
resetTotal — For a Totalizer object. Zeroes out any accumulated statusTotal value.
-
resetCounter — For an NdioHighSpeedCounterInput object. Zeroes out any accumulated totalOutput and countOutput.
If needed, you can expose any of these type actions by going to the slot sheet of the Obix proxy point, and clearing the “Hidden”
config flag. As shown in the Figure 18 slot sheet, these hidden actions appear listed with an “h” in the Flags column. However, it is anticipated that typically such actions will be left hidden. Note if hiding or unhiding
command actions, you should hide the forceUpdate action too.
If you need to link local (AX) station control logic into an R2 object input, do this in a similar way as when working between two AX stations (NiagaraNetwork). In either case, you need to create an additional object in the “target input side” i.e. controlled station, and link its output into the object being controlled.
-
In a remote AX station, you do this by making a reciprocal Niagara proxy point looking back at the “controlling” (output) point in the local station. See “Link control and Niagara proxy points” in the NiagaraAX Drivers Guide for details.
-
In the case of the R2 station, you copy one of the three types of “export objects” from the R2 tridiumx/obix jar (ObixAnalogExport, ObixBinaryExport, ObixMultistateExport) and paste it into the station, linking its output into the priorityArray input of the R2 object being controlled. Another link is also required, from the statusOutput of the controlled object back to the feedbackValue input (fIn) of the export object. See R2 ObixExport objects for more details.
Then, back in the AX station with the ObixClient, you rediscover the Points (“lobby” object tree), and add a new proxy point for the “root node” of each added export object, selecting the default writable point (NumericWritable, BooleanWritable, etc.) for each one.
These Obix proxy points provide the array of priority inputs for link control from the local AX station, as well as actions to invoke. Note that as with other discovered R2 objects, in addition to the “root node” they are expandable to select properties to proxy separately. Several config properties may offer utility to proxy as writable types, for instance the “limit” associated properties of ObixAnalogExport objects, providing they are “limit enabled.” See the next section AnalogExport Limit Notes for related details.
Note that in the AX station, when invoking an action on an Obix proxy point for any R2 ObixAnalogExport object that is “limit enabled” (see R2 Obix Export object properties) any value invoked that is outside the high/low limit range results in an “Invalid Argument” popup message, as shown in Figure 19.
In addition, be aware that if the active (highest priority) value at the inputs of the NumericWritable Obix proxy point is outside of the limit range established in the corresponding R2 ObixAnalogExport object, this causes the proxy point to go into a fault state, with an updated “Fault Cause” message similar to:
Write fault: obix.net.ErrException: <err href="/obix/config/almTest/ExportTest/ObixA_Export/.write"/>
When creating Obix proxy points for an R2 JACE under the Points extension, the following tips may be useful:
As needed, use the column sort features when traversing the lobby tree in the Discovered pane. This can save scrolling time.
- When creating ObixPointFolders for organizing proxy points (double-clicking R2 container type objects, or using the button), be aware of the current database level. Each ObixPointFolder has its own Obix Point Manager view, seen when you
double-click it—note this collapses the lobby tree in the discovered pane. However, you can simply re-expand the lobby to
find and add child Obix proxy points.
- For any R2 object for which you need standard AX alarming, create a root-level proxy point for it, then add an AX alarm extension
to it (for example, an OutOfRangeAlarmExt, duplicating the same alarm and fault (min/maxPresentValue) limits as in the R2
source object). Or, to avoid limits duplication in AX, you can add a StatusAlarmExt and simply select the alarm states in
the algorithms for OffNormal and Fault.
Alternatively, you can configure the Alarms device extension under the R2ObixClient to process R2 native alarms within the AX station’s alarm subsystem. This works best for R2 objects that are already being proxied in the AX station.
For more details, see R2ObixClient Alarms.
- Understand the “forceUpdate” action of an Obix proxy point can cause issues in certain cases. For details, see forceUpdate.
As with most drivers, the polling cycle timing is dependent on the number of proxy points currently in the “Dibs”, “Fast”, “Normal” and “Slow” polls. There are also properties of the R2ObixClient that may need to be adjusted from default values, in support of the oBIX “watch subscription”.
An R2ObixClient device’s Watch Interval property controls the polling of the watch, and is found on its Points extension. The default watch interval value is 2 seconds. Typically on an R2ObixClient device, the watch interval should be increased to 10 seconds or more, to reduce the load on the R2 platform.
The parent R2ObixClient also has two related properties, as follows:
-
Watch Safety Factor — Often, you should also increase the watch safety factor (default is 10 seconds). This specifies the time added to the watch interval to calculate the requested “lease time” of the watch. Essentially, this is the “COV subscription lifetime” the AX client is requesting from the R2 server. This is more important if using a shorter watch interval, because the driver calculates two values to use as the requested lease time, choosing the larger of the two:
T1 = watch interval * 2T2 = watch interval + watch safety factor
For large watch intervals, the requested lease time is inherently big (2x). But the safety factor provides an independent way to control requested lease time, such that you could make it 3 or 4 times the watch interval, if desired.
-
Session Timeout — How long the NiagaraAX client waits on a particular request before giving up. If the R2 station takes longer than 15 seconds to return the watch once polled, you may need to increase the session timeout.
The sessionTimeout slot on an R2ObixClient device is hidden by default. Go to the device’s slot sheet and remove the hidden flag from the slot.
Once visible, you can go to the property sheet of the R2ObixClient and adjust upward to tune, if needed.
Enabling debug on the R2 server can be useful to diagnose initial problems, but should never be used unless necessary, as it greatly slows the server’s response time to the Ax Client.
If you encounter errors similar to:
HTTP Error 503:Service Unavailable
this indicates the R2 host has run out of webservice threads. See Other possible R2 host changes.