[BUG-5454] system.tag.writeBlocking and alarm properties

I’ve bumped into a bit of unexpected behavior in 8.1.13. It sort of makes sense how this happens, but is so obviously not what anyone would want that I would consider it a bug. Ignition should either refuse to let scripts do this or do something more expected.

Basically, if you try to use system.tag.writeBlocking to change the property of an alarm, it loses all other alarm config information. Here’s a very simple test case:

# Create memory tag with high and low alarms
base_path = '[default]sandbox'
tag_config = {
  "valueSource": "memory",
  "dataType": "Float8",
  "alarms": [
      "mode": "BelowValue",
      "setpointA": 3.0,
      "name": "LOW_SAMPLE"
      "mode": "AboveValue",
      "setpointA": 5.0,
      "name": "HIGH_SAMPLE"
  "name": "reconfig_test",
  "value": 3.14159,
  "tagType": "AtomicTag"
system.tag.configure('[default]sandbox', [tag_config], 'o')
# Now try to adjust the setpoint on one of the alarms
foo = system.tag.getConfiguration('[default]sandbox/reconfig_test', False)

I was expecting (hoping) that would just change the setpointA property of that one alarm to 2.9, but it also loses all of the config for LOW_SAMPLE and HIGH_SAMPLE. Looking at foo, the alarms property is just [{u'setpointA': 2.9, u'name': u'LOW_SAMPLE'}]. The HIGH_SAMPLE alarm is totally gone and LOW_SAMPLE is nothing but a setpoint anymore.

I know the ability to interact with alarm properties via tag paths is newer, so this strikes me as a new implementation issue. I tried to search the release notes since 8.1.13 for any hints that this has been resolved, but didn’t see anything.

I was just mostly surprised that Ignition let me do something that was so destructive without warning me. I can get the behavior I wanted by replacing the writeBlocking line with this:

setpoint_tweak = {"name":"reconfig_test","alarms":[{"name":"LOW_SAMPLE", "setpointA":2.9}]}
system.tag.configure('[default]sandbox', [setpoint_tweak], 'm')

This was a bug affecting version 8.1.13 and it was fixed in version 8.1.14.

Please see our 8.1.14 Release Notes.

Fixed issue where writing to an alarm configuration property would replace all existing alarm configurations with the single configuration being modified.

You should not see this behavior after upgrading to 8.1.14+.

1 Like

Thanks for the info. Sorry I missed that in the release notes. I was trying to search the nightly thread on the forum, and must’ve been using all the wrong keywords. I just found it here.

And welcome aboard! New to IA or just new to forum?