UDT with nested UDT and instance the parent UDT with proper name of the child UDT

Hello Gents, I try to implement Tag instance in the UDT definition, noticed the name of the instance seems not able to be changed, i.e I have UDT call UDTa and UDTb, within the uDTa , I created a tag instance of the UDTb and named it as memberB, in the controller I have tag call PT101 which is the instance of the UDTb. When I instance this UDTa, I would like to have the memberB name changed to real tag name say PT101, is there any way can do that?

No, member names within UDTs are fixed, just like it would be with a "C" language structure.

Thanks for the quick reply. So, is there way I can UDT with two parent UDTs?

You mean "mixing" members of one with members of another? No. "C" doesn't do that either.

If you need dynamically named members or a variable number of members, then you need a tag folder, not a UDT.

But keep in mind that part of the point of UDTs is to establish a consistent set of names that will make user interface parameterization work. Don't break that paradigm or you will suffer for it.

What are you trying to achieve that you can't do with a UDT parameter or by creating a memory tag called "udtName" inside UDTa and UDTb?

1 Like

You wouldn't want to do that anyway because then you lose the biggest advantage of Ignition, which is rather simple indirection. You want your sub-UDTs to be named the same so you always know where the relevant tags are.

What you really want is a string parameter that binds to a string memory tag in the UDT.

You'll end up with a string parameter to the parent UDT that is then bound to part of each of the sub-UDT parameters.

For instance,

Parent.Name = PT101
Parent.UDTa.Name = {Parent.Name}a
Parent.UDTb.Name = {Parent.Name}b

Pseudo-code, of course

Thanks for you guy's answer, what I really like is to archieve is that to allow the UDT instance reflect the device directly. i.e. I have a device called Storage Tank, and I have 5 same Storage tanks, each tank has common attributes say ID, description, locationetc. and one level transmitter and one valve, the transmitter and valve have their own structure which are defined as UDTb and UDTc, the Tank will be defined as UDTa. for the tank 1 the level transmitter is LT101 and Valve is SV101, Tank 2 has LT102 and SV102 and so on, it would be nice and straight forward for Tank1/LT101 and Tank1/SV101 rather thanTanks1/Level Transmitter/LT101 and so on.

image

This will be much easier for understanding what I want to do.

Well, you cannot. UDTs have a fixed structure within instances. :man_shrugging:

And that would break ordinary tag path parameterization in any user interface you build.

1 Like

You should be using folders with tags created with those UDT instances in this case instead of nested UDT instances.

This breaks me sometimes, since usually I would name UDT instances with their p&id label (BL01_FT101 for example) but for parts where it makes sense to template them, you can't do that, so you have to name them something else. I normally use a more descriptive name in this case like Inlet Flow, but it breaks the standard of using p&id labels which I don't like.. But of course, as you said, without fixed names, parameterisation of graphics is impossible

1 Like

Well, dynamic data needs to be in a tag, or in a tag property. And when parameterizing a UI, those names are, in fact, dynamic. :man_shrugging:

1 Like

Display-wise on the interface side it's still relatively easy to do so with memory string tags bound to string parameters.

Also, you could name them generically like "FIT-XXXX" and "PIT-XXXX" etc

Instead of extra tags, I just bind to the UDT instance parameter values which works. It's really just an "issue" in the display in the designer and for selecting trend tags if you're using the standard tag browser tree view (i've made my own which uses the params).

1 Like

That's true if you're providing custom trends like that. I use unique suffixes on my UDT parameters (for inheritance/nesting reasons) but the same template might be used by different UDTs so using the parameters directly doesn't work in my case, which is why they're bound to memory tags that share the same location and name within every UDT.

Just thought of another alternative solution, as part of the "parent" UDT there could be a memory tag of some sort which specifies the relevant "sub-UDT" locations/tag(s) that are used for indirection, if you're worried about how tags are displayed in the tag tree. This would keep your sensors all in one folder and still allow them to be easily referenced within templates for the "parent" UDT.