Dynamic Child UDT creation

Ignition
,
1

Hello,

I wanted to know if there is a way to automate Child UDT Creation. For my specific example, I have many controllers (CON_1v0, parent UDT) that can have a variable amount of actuators (ACT_1v0, child UDT). Instead of having a massive amount of ACT tags for each CON parent tag (that will need to be disabled based on the controller), I wanted to know if there was a way that child UDTs are created based on a Parent UDT parameter or some other way when creating a Parent UDT instance.

UDTs Screenshot

Thanks!

2

For this, I would probably suggest using a folder to house your conveyors rather than a parent udt. It might depend on the number of variations though, and if there's any other supporting stuff that's needed. Sometimes I might create a number of variations of the parent udt with differing numbers of conveyors. You could create a base udt with the supporting stuff and inherit from that for your variations.

Alternatively, you ca also create a parent with all conveyors and then disable the instances not needed. This is my least favourite method though, as you then need to expand the instances to know how many conveyors the parent has enabled

1 Like
3

Hi, have you been able to get a work around for this?

4

Do you mean "work around" ? If so, the work around is to not use a UDT where number of children will be variable. Use a folder instead. There is no support in Ignition for dynamically-present members of UDTs.

2 Likes
5

I haven't tested this out but you could try having a dataset tag that holds your UDT types, child UDT types and the amounts of each. Then looping through the dataset you can use the system.tag.configure function to create the UDT instances.

6

yeah eventually I used scripting to do that

7

For cases where there are <5 models of a product that are identical except for a number of sub-components, I usually create device-specific UDTs with the following structure:

  • Base product UDT (contains everything except the differences)
  • Sub-component UDT
  • Model-specific UDT that is a child of base product UDT and contains n number of nested sub-component UDTs

In my work, this is often integrating with slight variants of inverter skids from the same manufacturer with the same data map, but with slightly different model numbers that have different numbers of DC inputs and capacities. This also avoids having to disable unused nested instances.

But in most other circumstances where there's not a fixed, limited number of the variants you're looking to cover and where you need to account for a large number of hypothetical configurations, nminchin and pturmel have the best advice to just use a folder.

1 Like