Tag folder binding

Ignition
1

Hi,

I’ve noticed that it is possible to bind to a tag folder.

A tag folder binding seems to always return 2. I changed tags inside the folder but the binding is not recomputed.

Is there an actual purpose for tag folder binding?

Thanks

2

Can you show what you are referring to, maybe take some screenshots?

You tagged Perspective, so are the bindings on components within a View?

3

I’ve setup a binding on the text prop of a label:

Capture d’écran du 2022-09-19 00-07-08
Capture d’écran du 2022-09-19 00-07-081781×990 136 KB

4

So Ignition doesn’t put you in a box, if you want to bind to an actual folder it will let you (as you see). But why did you try? What are you wanting to happen?

Why a folder returns a value of 2 isn’t something I know the answer to.

5

I can't say I know the reason why, but this value will increase each time the folder is renamed, and your binding has been updated to reflect the new naming. It could be useful for change monitoring if it also incremented when tags were added or renamed within the folder, but it does not.

6

Of course if you rename you just broke the binding.

1 Like
7

Lol, that was my first thought.
I'm sure in other versions, binding to a folder returned the tags within as a json object with their tag values...

8

I figured it would go without saying. I guess not. My original post has been edited for clarity.

9

It’s presumably some kind of property of the folder. But since it’s not in the manual, I guess it’s best not to use this property, lest this return value change in the future.

10

I’m not 100% positive, but that 2 value could potentially refer to the Quality sub-code: Good_WritePending.

11

This wouldn’t make sense if the bound value can increment by one on every rename.
Please, give it a try yourself. You can reproduce by following the steps below:

  1. Create a handful of custom value properties with bindings to folder names, say folders named 1, 2, 3, 4, 5, etc etc
    (It doesn’t have to be numbers, it can be anything you’d like as long as you have bindings to match the name you are going to change the folder name to.
    All these bindings will have data quality of Bad_NotFound as the folders do not exist for any of bindings yet.)
  2. Then create a tag folder and name it 1 (the binding value for this folder name will be 2)
  3. Then rename that folder to 2 (the binding value for this folder name will be 3)
  4. Then rename that folder again to 5 (the binding value for this folder name will now be 4)
  5. Then rename that folder name back to 1 (the binding value for this folder name will now be 5) and so on and so on.
  6. Delete the folder.
  7. Create a new folder and call it 1 (the binding value for this folder name will be back to 2)
12

If you read the meta-node jsonValues of a folder, you get the values of the subnodes:
system.tag.readBlocking("[default]folder.jsonValues")

>>> 
[[{
    "memory": 132,
    "opc": 4
}, Good, Mon Sep 19 08:29:11 PDT 2022 (1663601351271)]]

I suspect the 2 value is the Configuration Version property; you can read it directly and compare:
system.tag.readBlocking("[default]folder.cfgVersion")

>>> 
[[2, Good, Mon Sep 19 08:30:45 PDT 2022 (1663601445536)]]
2 Likes
13

Are these folder props documented anywhere public?

14

So in the end there is no actual purpose to bind on a folder, right?

15

The question to you is what were you expecting by binding a folder?

16

I feel like it should be the same as binding to a UDT instance. Thats essentially a “folder” in its own sense?

All of the contained tags should return into the prop?

With the question of performance, you could bind to a 1 million tag UDT instance just as easily as you could a 1 million tag folder. But I can’t see the 2 every being nearly as useful to an end user as returning the values inside

EDIT: The more I think about it, the worse I think a 2 is to return. What if you accidentally are bound to a folder instead of a single tag and now 2 represents some incorrect state. At that point, if it didn’t return the contents of the folder, I’d almost it raise an exception?

1 Like
17

I was expecting the folder binding to recompute when a child tag is added, modified or deleted.

18

My first thought too. If you bind a folder by mistake, you should get an overlay otherwise you might not notice you bound it wrong

2 Likes
19

You probably should expect nothing. The fact that you get a version number surprising IA staff kinda suggests that reading folders was not an expected operation.

1 Like
20

Yes, I know. I was just replying to @jlandwerlen regarding my initial expectation when I tried it out.