Alarm ack differences between R2 and
AX
Be aware of the fundamental difference about “alarm ack permissions” between the
AX alarming model and the R2 alarming model:
- In the
AX system, a station user needs “admin write” permissions on the Alarm Class used to route the alarm in order to acknowledge
it, regardless of what permissions (if any) that user may have on the source component that generated the alarm.
- In an R2 system, a station user needs “command, alarm” permissions on the source object that generated the alarm in order
to acknowledge it, regardless of what permissions (if any) that user may have on any of the NotificationClass objects.
Keep this in mind when assigning
AX user permissions (using categories) to components in the
AX station, noting the difference between accessing actions/properties of Obix proxy points vs. acknowledgement of alarms originated
from those points.
Alarm handling discontinued from R2 Web Supervisor
Although the ability to see and acknowledge native r2 alarm/alert events from
AX is included (as previously described), the source R2 station (Controller) must have its NotificationService config properties
set as follows:
- archiveMode=archive_local_no_SQL
- alarmArchiveAddress, checkbox cleared
This prevents continuation of any R2 Web Supervisor handling of the station’s alarm/alert events.
Possibility of inadvertent acknowledgements
Acknowledgement from
AX can occur on individual events (within the popup window for that alarm source) or on all events if Acknowledge is pressed while that row is highlighted in the Alarm Console—regardless of how many underlying alarms may exist. This may
prove problematic in actual job use. Note this especially applies if many R2 alarm-capable objects are not represented as
Obix proxy points in the station.
Alternative to importing native R2 alarms
If alarming is critical, for the reasons previously noted you may wish to transition all alarming to “native
AX” alarming, instead of using the ObixClient Alarms feature. Do this by creating Obix proxy points for all objects that require
alarming (or runtime/COS count events), and then adding to each point the necessary alarm extension(s), configuring them in
AX. Note that extensions for R2 “alert” type events (runtime, COS counts) are found in the alarms folder of the kitControl palette.
In this “alarm re-engineering” scenario, you would typically create equivalent AlarmClasses for the NotificationClass objects
used in the R2 station, configured with similar priorities and alarm recipient components.