Use tag value as UDT parameter in nested UDT


I would like to use a tag as value for a data type parameter.
I need to drive the “input” of the “AndonStopTimer” to be driven by the tag AndonStop:

Is it possible?

1 Like

I have the same question. I need to reference a tag in a UDT definition and use its value on another tag’s numeric property and all in the same UDT.
Here is the tag that I want to reference:

and here is where I need to use the reference value

I am not able to use a syntax like {[.]Cfg_EU} is there a way to use UDT parameters dynamically?

I also have a need for this (using 8.0.4). When I saw it in the search results I was really hoping there would be a solution posted also, but unfortunately not…even given the thread’s age.

I have same need. Using 8.1

No can do. If it was an option, it would need to be used with care, as I imagine this could add a lot of load onto the CPU.

In any case, if you guys are after it, you should add an idea to the ideas site

I was looking for a similar functionality and came up with something that works, but I’m not sure if this is very efficient. I needed a parameter in a UDT to refer to a tag value which inturn controlled tag paths in the UDT. I came up with using an expression tag in the UDT that refers to the tag value outside of the UDT and then in the UDT parameter used the {[.]tagname} which is referring to the expression tag. In the expression tag I referred to a tag within the same parent path and used {[.]…/tagname}. This did work, but I’m sure it is eating up processing power to do so and I have not tested response time on change. We did this to minimize the amount of editing of parameters we needed to do for UDTs. We just have one tag to edit vs the number of UDTs in a grouping.

1 Like

Just returning to this, this is actually possible now in v8 in a way. If you bind a UDT tag’s property to a UDT parameter, you can then write to the UDT’s parameter from, say, a tag change value script to set its value dynamically.

E.g. if the UDT parameter for the unit is called ‘EngUnit’, the tag path would be:


@nminchin Can you please elaborate a bit on this?

perhaps an example of my use case may help inform your clarification?

I maintain my tag database such that the final OPC item paths for all UDT members can always be derived from the Ignition tag database/UDT folder structure itself (Line* is PLC, Tank* is UDT):

[tagProvider]Line3/Tank2/Level/Value - Ignition tag path
nsu=_URL;s=0:Line3!Tank2.Level.Value - actual OPC item path

So ideally I’d be able to create a new instance of Tank UDT named Tank_whatever, under Line_infinity parent folder, and assuming that
is a valid OPC path, I’d be done (no need to manually configure UDT parameter values).

Unfortunately this doesn’t appear to be possible , as it seems OPC path indirection can only use static UDT paramters :frowning_face::
{OPC Server}:{PLC}!{InstanceName}.Level.Value

I think I effectively need dynamic UDT Parameters (and thus dynamic OPC item paths).

can your described method accomplish this?

Perhaps I’m missing something obvious.

Would the OPC item path be constantly overwritten, albeit with the same data (performance bottleneck)?

You can write to UDT parameters and tag parameters using scripting, but how you achieve that is up to you. I imagine you’d need to use system.tag.getConfiguration to pull back the folder names and then apply those to the UDT parameters. It won’t be an automagic process.

per @nminchin 's comment above, it seems he is suggesting that UDT parameters can in fact be written to, albeit via through a bound tag property.

I’ve tried setting the bindings up (“Value” parameter <> Tag.Value property) and then modifying the tag’s bound “value” property (in the tag browser, not via script), but I get an error

Error writing to value.value: Bad_ReadOnly("The specified value is dynamic and cannot be written.")

Am I misinterpreting his comment?

You’re writing to a tag property, not to a UDT instance parameter. Some tag properties are indeed read-only. UDT instance parameters however are read/write.
E. G.

I believe I have figured this out, let me know if it solves everyone’s problem.

  1. Create a child UDT with parameters used in the OPC tag path.

  2. Create a parent UDT with a child object. Create a parameter that you would would like to pass from the parent to the child.

  3. In the definition of the parent UDT drill down to the child object’s parameters. Change the value of the child’s parameter to the name of the parent’s parameter surrounded by {}

  4. When you define the tag you can change the value of the parent’s parameter and it should pass to the child’s parameter.

@sean.abraham This topic is about using a tag’s value as a UDT parameter value, not a parent UDT parameter value in a child UDT parameter. That could always be done, and you don’t even need to have different parameter names between parent and child :slightly_smiling_face:

I just want make sure this is still the case with 8.1, that you cannot connect the parameter of one UDT to the parameter of another UDT, or the parameter from one UDT as a tag reference inside of another UDT?

I would like to get rid of the redundant parameters for the OPC connection.

Firstly, I would do an audit on all of the UDT parameter names in the system, as these look very inconsistent and will only make development frustrating and difficult.

To answer your question (and as I stated in your other topic), no, you can't bind UDT parameter values to tag values (and this wouldn't be a good idea if you could, for scalability reasons). You can, however, create a parent base UDT with a set of default parameters and their default values.


I don't know of a way to do it exactly like you're describing, but if you have predictable tag names you may be able to set up a script that can do your work for you.

When I have complicated changes to make repeatedly to UDT instances, I create a tag that will trigger a one-time script that does what I need. I've recently published a resource that does this (though the application is different from what you're trying to do).

1 Like