NOTE: I am using Gateway version 8.1.0 (b2020110211)
I’ve observed an inconsistent behavior when using the scripting functions system.tag.readBlocking and perspective tag bindings on tag paths pointing to alarm configuration properties where the value returned in the tag properties do not match the alarm configuration as returned with system.tag.getConfiguration. This inconsistent behavior is only present when the alarm is initially configured and enabled, after showing up in the alarm pipeline as Cleared, Acknowledged.
For instance, if I have a tag at [default]testTag with an alarm configured in the BelowSetpoint mode, reading the alarm configuration in perspective (either with a system.tag.readBlocking call or a tag binding) with a path like: [default]testTag/Alarms/testAlarm.setpointA or [default]testTag/Alarms/testAlarm.enabled, the values returned from these paths are only updated immediately when the alarm is disabled. If the alarm is enabled and in the pipeline as Cleared, Acknowledged, any changes to the alarm configuration are not reflected in the values returned by these tag paths for a random amount of time until they finally reflect the alarm configuration.
My question now is if alarm configuration properties such as setpoints, labels, etc should be updated while the alarm is enabled? Are there ways to make sure that alarm configurations are committed atomically and with responsive feedback while using the tag path alarm properties? Or should I ditch using tag path alarm properties entirely?
The projects I work with we have been using the tag path alarm properties with good success because we can pass around tag paths to be used by perspective tag bindings with great success until I came across this one behavior that puts a wrench in the spokes.