Creating UDTs in Ignition for a project. I am struggling to decide if there is a best place to store metadata (e.g. a description of "Effluent pH"). It appears reasonable to create a Parameter, Custom Property, or Memory Tag. Why would you choose one over others?
I am using a Parameter to point to the correct member of a UDT array in the PLC.
I don't know that there's a best practice, but there's already properties for Documentation and Tooltip on both the UDT and the tags inside your UDT. If your metadata comes from the PLC or device, you'll need to create them as tags. Custom properties are lighter weight than memory tags, so that's a reason to use custom properties over memory tags, but again, I don't know if there's a best practice.
I would always store this in UDT Parameters. This, to me, is the most logical place, since all the configuration for the UDT Instance is already located there. It also makes bulk creation of UDT instance tags simple, rather than having a 2-step process to 1. create the udt instances and then 2. write to the memory tags / add the value overrides.
You can read UDT Parameters like tags, and write to them like tags, so you're not losing functionality.
Edit: I just realised this was posted 7 months ago... better late than never I guess!
Thanks everyone. Old topic but still relevant. I settled on properties largely for the reasons @nminchin listed. There is an overwhelming number of ways to do things and many of them are poor decisions; I wanted to ask before I went down a bad road.
In case it confirms where you settled, we heavily use custom properties as well. I only use parameters when it needs to be bound somewhere else within the UDT (and all of ours have standard parameters for opcServer, opc prefix (including device name), tagGroup, storageProvider, etc.
For everything else where we want to have metadata stored as fixed constants, these are as custom properties. We often default these within our UDTs if applicable (our main use case of this is inserting viewPath strings with governed keys for our auto-deploying HMIs), and we also do defaults at the UDT for something like deviceModel or iconPath strings.
We then write in tons of other custom properties using the Spreadsheet Import Tool, to which we underwrote development. These often include tagPath strings with governed keys for our auto-deploying HMIs, essentially creating different layers of graphs between various assets in a plant. These may also include strings like Label which is a friendlier string to use in our auto-deploying UI vs things like the tag name. I may also write in static values like loss ratios or theoretical performance ceilings for assets like a load block worth of PV panels. Then these can be cached and used in bindings at runtime without having to manage tag polling.
The Spreadsheet Import Tool allows us to create these custom keys in bulk. With the iterator functionality, I can often grab giant tables with tens or hundreds of thousands of cells direct from engineering drawings, then block through where I insert those values including as custom properties. Additionally, the Spreadsheet Import Tool allows us to write custom properties to folders, usually viewPaths and tagPaths as strings for defining views and relationships in our auto-deploying HMI. You can even go crazier by storing things like view and SVG content within document properties.
What's great about custom properties is they can exist anywhere in the hierarchy, whereas parameters only apply to a UDT instance. The same custom property with the same key can exist on folders, instances, atomic tags, or anywhere else.
All of this is why I am strongly in favor of custom properties rather than parameters in tag structures, except for the few cases where parameter functionality is essential.