i admit, i'm still a little hazy on what's being asked of me, but here we go! i'm looking for some methods for managing UDTs. each project has a different set of UDT definitions, but only just different. ideally, i'd like something like the Master/Slave relationship that projects have. depending on the pump/engine/thing, it has only one or two additional (or fewer) tags that need adding. ideally, we'd like slave projects to inherit the UDT definitions from the Master project. then we can just make sure that UDT list has every option, used or not. and if a new one pops up with a newer gen pump/engine/thing, we can just add it to the master UDT definitions and it'll propagate. can that be done?
why are we looking for this? 2 reasons: 1) someone forgot to add a tag and now it's being referenced in a ton of slave projects that will need that one thing added. 2) newer generation equipment is coming online with additional scada properties that will need to be implemented per unit, per project. it would be nice to just have a central UDT repo for these cases.
Tags and UDT definitions are global resources tied to tag providers, not project resources. There's no inheritance across projects nor across tag providers. They can be distributed/updated via EAM, though.
yeah. i don't think this is the solution. we only have one Ignition server (don't even get me started...) so, if my read is correct, the EAM doesn't really help. so something is missing conceptually with regards to the UDT definitions and how they are implemented vs how they should be implemented.
if i understand correctly, these UDT definitions are just text files residing on the server...if so, it should be feasible to run some awk or python to check a 'master' and write changes to 'slaves' on file change... right? the only issue is that it won't update to currently-opened Designer projects (as i understand), but that's a small price to pay if that works.
This is my understanding based on forum reading - willing to be sat corrected if I am wrong.
All tag definitions (including UDTs') are stored in an IDB using SqlLite. It is possible, to run SQL against this, however, it is not recommended.
8.3 (Due for public beta release Q4 2024 and production release possibly Q1 2025) is making changes to certain aspects of the Ignition framework, however, I am not sure if tags/UDTs'/IDB are part of that. @PGriffith ?
SQLlite is one access at a time only unlike other DB's where multiple simultaneous access is allowed.
If you really really want to do this outside of EAM and manual operation, you might be able to script this using system.tag functions. I honestly don't know if they support UDTs or not. I've never tried it.
i flat out don't see how it can be done in EAM. unless i missed something, EAM is meant to manage multiple instances of Ignition, not multiple projects on one instance.
Yeah, that's what I'm thinking... why does this need to be external?
I don't understand what Ian is trying to fully achieve here, but, for example, the manual has this code:
# UDT Definitions reside in the "_types_" folder, which can be retrieved
# via the Tag Browser : right-click > Copy Tag Path.
# Retrieving the existing configuration is much easier than typing it all out.
tag = system.tag.getConfiguration("[default]_types_/myUdtDef")
# This line is accessing the first tag in our results (the UDT Definition), then returns the
# 'parameters' dictionary, which then provides access to individual parameters.
tag[0]['parameters']['myParam'] = '300'
# Overwrite the existing configuration.
collisionPolicy = "o"
# Write the new configuration to our existing UDT Definition.
# Note that the first parameter is to the parent folder of the Definition,
# not a path to the Definition.
system.tag.configure("[default]_types_", tag, collisionPolicy)
# Once the configure call finishes, myParam on the Definition should have a value of 300.
There is also system tag export and import, so if Ian really wants to do this externally for whatever reason; script the export, process it as they see fit (can you export a definition though, or only an instance), then reimport.
UDT's aren't project specific, but tag provider specific.
I can honestly say I've not tried to do this across tag providers on the same Gateway... so it's possible that EAM won't work either, and if EAM won't work then you are up to either manually keeping this in sync or scripting.
let's see if this helps. i have two pump brands and two clients. which means two projects. each brand of pump spit out a bunch of data to the PLC, which gets built into a UDT definition in each project. (promise, i'm not trying to patronize). client project 1 uses brand 1 pumps, client 2, pump 2. now client 1 decides to use pump brand 2 in their project. we have to update the UDT definitions to encompass the extra data that pump brand 2 sends. i don't care that pump brand 1 does not send those values, we don't look for them anyway. this is now a somewhat unified UDT definition that handles both pump brands in one UDT.
enter pump brand 3.
now multiply all this by 10.
what is happening is updates to one UDT definition is not getting mirrored in other projects. so when the new devices come online, the project gets new bindings from the Master project, but the UDT definitions get overlooked. which means the project, not having an updated UDT definition, promptly .
life is now hard.
i want a central repo, similar to project Master/Slave, where if i update a UDT definition, it propagates to all slaves.
Yes, however, probably help other people help you rather than I... I did Inductive University back in like 2015 and I've forgotten some of it now
What I would suggest you look at is parameterisation (zation, I'm in UK =p)
The Master/Slave you suggest is definition being propgated to instances (IA terms).
We're coming from opposite ends of the spectrum, from reading your other posts, you are a web programmer getting into controls/Ignition whereas I started with controls/wiring/PLCs so I'm not the best to suggest OOP methods here.
. that 
.
.
