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
system.tag.writeBlocking(['[default]sandbox/reconfig_test/ALARMS/LOW_SAMPLE.setpointA'],[2.9])
foo = system.tag.getConfiguration('[default]sandbox/reconfig_test', False)
print(foo)
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')