I'm currently doing UDTs for the first time. I had read some tips and tricks from the documentation and the forum, but I'm not sure how to do somethings.
This is the UDT that I'm trying to do is this one:
UDT
├ confg
│ ├ state conf param 1
│ ├ state conf param 2
│ └ state conf param n
├ current order
│ ├ kops folder
│ │ └
│ └ kpis folder
│ └
├ current shift
│ ├ kops folder
│ │ └
│ └ kpis folder
│ └
└ current state
├ current state code
├ param 1
└ param 2
At first, eveything was a giant UDT. But finally I converted kops, kpis, current state and conf to UDTs.
So now I have a tree of UDTs. However, conf have differents values depending on the instance, so for some room it has 10 params and for other it has 12. I read that is not good practice to overrided UDTs, that is better to create a confg udt father and have 3 or 4 types that inherence from that one.
The things is, that if I want to do this, I'll have 3 or 4 different UDTs, but If I want to do this also in the kops and kpis i'll have a lot of differents UDTs.
As you may see, I'm a bit lost. Would be nice any guidance.
UDTs are nice when you want standardization between projects and objects and easy of construction with a lot of similar instances. There is nothing wrong with having UDTs with Folders and Other UDTs imbedded inside each other. You could have a UDT defined with a single instance, but I wouldn't recommend it as you probably could have just made the tags and folder structure directly.
Depending on your use case, it may be better to embed tags into folders in a tag provider and simply copy the folders and tags to make multiple instances and make the required changes there.
The way I think about it it often to break the structure down into the most fundamental components that are the same in many places and turn those into UDTs. KPIs could be a good example of this as they could all have the exact same structure, but you might not want to make a KPI folder to be it's own UDT because every machine or process will have different KPIs and number of KPIs associated with it that need their own instances and flavors.
It's all how you want to organize and maintain the tags. You don't have to use UDTs anywhere, they aren't a requirement for the software. But they can make your life easier or harder depending on how you use them.
If you want to track the performance of 10 Process lines that are all the same, it could useful to make that a big UDT as long as they are the THE SAME. As an engineer, I have yet to see any 2 process lines be similar enough to dedicate a UDT too without extrapolating a lot of the detail away. but maybe you don't need the detail and it makes sense to group them all together. at the end of the day, it's all data in tags grouped in folders. A UDT is just a fancy folder.
UDTs should be used in cases where an "object" is used multiple times and has defined "attributes" (i.e. tags), and multiple instances of the object exist (or could exist).
This makes it easy to make standard templates for use with each instance of the object. Parameters to the UDT will determine the tags and OPC tag paths as needed and the tags themselves will end up in the same location for all instances, making indirection possible.
Personally, I always have a folder inside of the UDT with direct bindings to the UDT parameters so I can read them as tags instead of having to add ".param" to the end of the tag path for each parameter I want to read.
Also note, each UDT definition's parameters should be unique so that UDTs can be nested without name collisions.
The best thing about this approach is that if an attribute is added to these objects in the future the UDT definition can be updated and it is populated to all instances. Similarly, if you need to add an attribute to some of the instances you could make another UDT with the original UDT as the parent UDT definition, extend it with the additional attributes, and and update the datatype for only those specific instances and everything else remains unchanged and unbroken. The template can then also be updated to show/hide this new attribute based on the existence of the tag.