Don't name tags "Alarm Metrics" in pre-8.3 projects

Just a heads up and probably not super likely to happen often in the wild. Just an edge case to be aware of for system upgrades. I don't think this is something that needs to be addressed by developers but I wanted to mention this as a consideration if you're upgrading a system to 8.3.

All tag folders in 8.3 have a tag called "Alarm Metrics" which is an awesome new feature to see information about alarms in a folder. If you put a tag named "Alarm Metrics" in a folder it adds an underscore to the normal Alarm Metrics for a folder, which makes them not consistent and breaks potential relational tag bindings you may have in a UDT (as I did in the "Alarms" UDT instance in this screenshot).

If you add another tag named "_Alarm Metrics" it breaks like this (I just wanted to see what would happen)

If you rename a tag to create a collision it will tell you the name is not unique.

If you delete your collision "Alarm Metrics" tag it will rename the Alarm Metrics for the folder back to "Alarm Metrics".

Make sure you don't have tags called "Alarm Metrics" in systems you're upgrading to avoid this. If you do encounter this in the wild, it breaks elegantly and is recoverable without any significant issue.

2 Likes

As you noted Ignition will attempt to detect collisions with anything named Alarm Metrics, just like we do with anything named Parameters in a UDT Definition/Instance at the root level, and will prepend the _ in front of our dynamically generated folders if something conflicts. It will only affect item where this condition exists in which, as you pointed out, could break relational tag bindings depending how you implemented things.

For things to go sideways, you would have to have items named Alarm Metrics and _Alarm Metrics in the same folder. When we initially implemented this for Parameters, there was a thought to keep prepending _ as things got added but this felt like an extreme edge case and it is immediately clear that a problem exists.

Garth