Tag Behavior around system.tag.getConfiguration

So I'm working on a tool for authorized users to be able to change specific tag values; (On/Off Settings, Cycle Count Thresholds, etc); a mix of PLC and Memory Tags. I wanted to make it dynamic where I can pass in the tag, system looks at the tag, and provides the right "option" for adjustment (Checkbox vs Textfield vs ...). As I was working on it, I noticed some interesting behavior of newly created tags, and tags when changing data types. On Ignition 8.1.32 with plans to upgrade soon.

When using system.tag.getConfiguration on newly created tags:

  • When a new tag is created, 'value' key is missing - which would obviously be Null initially
  • If your new tag keeps the default data type of Int, 'dataType' key is missing.

The other issue I ran into was data type conversions; I made a default Int tag, set the value to 2, changed it to a string, added mumbo jumbo ie: 2dsaw, then changed it back to Int, where Tag Browser preview showed it back to 2. When I did system.tag.getConfiguration, it showed the 'value' key as '2dsaw', but when I did system.tag.readBlocking on the tag, it showed the proper 2?

All in all, no show stoppers and I can work around it (do .get on the configuration for error handling and make assumptions), but I was surprised those fields aren't created initially, and I was curious if anyone knew why that behavior exists?

Behind the scenes, those tag configurations are just a dictionary of properties that get applied to the template you are using to create the tag. For basic atomic tags, that template is an integer data type with some value source. Unless the field is actually modified, it just assumes you will be using the same configuration as template. Once you modify a tag property, it creates that entry for the configuration dictionary.

Taking it one step further, the template setup will be the same for UDTs. When you create an inherited instance of a UDT, it will looks similar to a new atomic tag in that the dictionary will not contain much configuration data, even if it has tons of tags inside.

I don't have a good answer for how it retains the '2' value while switching the data type. You should reliably expect the value to match whatever the current data type is, but I don't know what stores the retained value for a different data type since I do not see it on the configuration.

Overall I don't have any insight into the architecture, but this is my experience working on similar scripting efforts.