Back at Ignition development after a 12 year hiatus, so a little rusty yet, and new to perspective.
I created views where I created tags in a folder hierarchy to get it working the way I wanted. I am now converting those tags to UDTs. The UDTs then need to be replicated to use in other views, with different data (string, bool, int, OPC). I was planning on doing a copy JSON and editing in Notepad++, but all I get is the UDT definition, no data values. The data values are there in the created tag, but do not show in the JSON copy. Am I missing something?
I’m still a bit (very) confused with what you've done and what you’re trying to do.
You’ve made a UDT Definition I think, by creating folders and standard tags and converting them into a UDT definition with the context menu option.
Have you created instances of those UDT definitions?
You’ve also created a perspective View, presumably to show tag values from a UDT instance. You should be passing in the tagpath to the udt instance as a param into the View, and then use indirect tag bindings on custom prop to read any tag values from the UDT instance.
Have I (mis)understood any of that correctly?
Edit: note that UDT definitions (aka UDT types) were moved into their own tab in the tab browser in v8. Previously, UDT types and standard tags were all in the one tree hierarchy. (I think I arrived here in v7.6)
Yes, I created folders with tags, that I converted to a UDT. The tags had values in them from the testing before creating the UDT. I created an instance of the UDT and copied it as a JSON to edit it for another instance. The JSON did not include any values in it, only the definitions. On further testing, I edited the values in the UDT instance I originally created and when I copied to JSON again, the values were in the JSON. It appears that if the default values are what is in the UDT instance, it will not include them in the JSON.
If you create a UDT inctance and don’t change anything, the UDT instance json will have the barebones structure which includes:
name of the item (tag / folder / UDTinstance)
type of the item (AtomicTag, Folder, UdtInstance, etc.)
a tags[]array if the item is a folder or UDT instance
the typeId if the item is a UDT Instance
If you override properties on tags or set UDT parameters, that’s when you’ll see these props stored in the UDT instance’s configuration / JSON.
The moment you store more configuration for tags in the UDt instance, these props will no longer use the definition’s values for them.
Also, this isn’t correct. You can still have a property configured in the Udt Instance which overrides the Udt definition that have the same values. e.g. a tag “PV” in the UDT definition could have the eng units set to “L”. In the UDT instance, if you override this to “kL” and then set it back to “L”, this prop will still be marked as an override on that property value, because you’ve essentially added the eng units into the udt instance configuration. This will also now show up in the UDT instance’s JSON.
You want as few properties in your UDT instance tags as possible. Getting off topic a bit… this is one of the reasons using system.tag.getConfiguration with system.tag.configure is so destructive; getConfiguration gets all configuration from both the UDT instance and the UDT definition. So using configure to write back the configuration to the UDt instance tags will apply all of the configuration in the UDT definition as overrides, thus effectively disconnecting it from the UDT definition itself, defeating the purpose of using a UDT.