Access UDT root custom property inside a Tag Expression

Ignition
1

Hi

I have a UDT that has custom property at root level and inside UDT I have some tags inside a folder.

I want those tags access root custom property in expression. What is the correct syntax?

In following code the first two dots is used to access root level and the next one is for custom property and API is the name of the custom property. But this is not resolve.

{[.]...API}

If I have a tag in the root of UDT this syntax works:

{[.].API}

So what is correct syntax to read UDT root custom property inside a Tag Expression?

Tested in both 8.1 and 8.3

image
image1041×541 45.6 KB

2

I am not sure how to do this using just the path referencing, but this works tag(concat({ParentInstanceName},".API"))

3

Thanks Markus. This seems a bug to me that path referring doesn't work.

The interesting problem is if I define custom property on one of the internal folder I can't edit it in udt instance in designer.

4

@pturmel In your option which method execute more efficient? (Of course if direct udy tag referencing is working)

5

I had a ticket open on something very similar to this. The resolution from support was what @Markus_Oosthuizen suggested. I don't remember if it was marked as a bug, or just the way it works right now.

6

Have you tried {[.]../.API} ?

7

My mind keeps going to how many times I heard @pturmel say to avoid tag() at all costs.

9

Except you cannot avoid them in expression tags. As there is no such thing as indirect bindings for tags.

10

Yes not working

11

Even this method doesn't work if your insurance is in nested folder.

12

InstanceName means something different at different times. We created a tag on the parent UDT as an anchor for all other embedded UDTs that are used in the parent UDT. I believe it is an expression tag that is the InstanceName. That way the embedded UDT can grab that as a reference to the parent and then get the data that it needs. I would rather have the ability to read the property directly as you can a tag, but that isn't how it is as the moment.

13

The only workaround for this dot problem syntax is to create a tag as reference and put all customs properties on that tag and then easily the udt expression tag reference is work. Note that even folder custom property doesn't have option in designer UI to edit custom property right now.

14

Edit: Realized it works if the tag is in the root folder but nested it doesn't

Seems like IA needs to add a PathToRootInstance syntax

15

Okay so I found a way to make it work.

Create a UDT parameter called pathRoot and set it equal to:

{PathToParentFolder}/{InstanceName}

Then on your tag you can use:

tag({pathRoot}+".API")
16

My problem is using tag() in expression is costly compared to udt tags reference method.

17

Unfortunately with an expression tag then there's no way. tag() is likely your best bet but if you want to avoid that then your options are:

  1. Use a derived tag: [.]../../{InstanceName}.API and then put your expression in the read expression
  2. Move the custom prop into a parameter and reference the parameter
  3. Move all your custom props down onto a tag called properties and then you can reference it with {[.]../properties.API}
  4. Use a reference tag: [.]../../{InstanceName}.API
  5. Use #3 as a reference tag and then use that in your expression tag but then you have two tags (effectively same as #1 but split)
  6. Define the UDT instance name in the path, but then every instance would need to be overridden to put the correct instance name which defeats the purpose, but technically works: {[.]../../udtA.API}
18

Yes I already use option 3 for sake of performance.

But I really hope IA add a ticket and fix this problem

19

Yes this is a big pain point for us too.

we us some expression with:

tag(concat('[.]../../',{InstanceName},'.alarmsDisabled')),"")

to workaround, but we would like to use direct reference with {..}

I think that tag() in expression are managed with readBlocking with more load than subscription mecanism. subject to confirmation of @mgross or @paul-griffith

Moreover, we often delete all udt/tag and generate them, and it seems that using tag() in expression results in a very long udt instance creation process with lots of readBlocking Error in the gateway, probably because in the creation process tag referenced by tag() expression are not always existing, it depends from creation order...

I suppose that this is not a problem with subcription used for {..} member in expression.

20

tag() subscribes to the target tag. Your readBlocking errors are likely something else.

21

In case of tag() used in gateway expression tags ? Ignition use suscription ?
So what why is their use discouraged, especially if the path provided to the tag() does not change ?