Accessing tag custom properties through scripting

What would be the syntax if I’m looping through the tags through scripting instead of a change script? Here is what I’m using now (that seems slow-ish when I’m testing in the script console):

rootPath = "[TP]Folder/InnerFolder/Section"
pressTags = system.tag.browse(rootPath, {})

instances = []

for tag in pressTags:
	obj = {
		"title": tag["name"],
		"instances": map(lambda x: {"label": x["name"], "tagValue": x["fullPath"], "units": system.tag.getConfiguration(x["fullPath"])[0]["Units"]}, system.tag.browse(str(tag["fullPath"]) + "/Overview"))

print instances

The custom property is called Units and is defined on the UDT of the tags inside the Overview folder. If I do a system.tag.browse() to a tag within Overview, I don’t get any custom properties so I’m using system.tag.getConfiguration() (I could also use*).

I can imagine it is slow, beings as you are calling system.tag.browse() which is already a slow-ish function for every tag at the root path.

Instead, you should use the filter to filter for only the tags that you need and do so recursively, then you can loop through that list adding your custom property where needed building a list of tag paths, then read all of the tags at once.

Also, it looks like you are adding `“/Overview” to the full path of a tag, however, the full path includes the tag name, so unless the “tag” is a folder, then that path would be invalid.

I guess I don’t understand your tag structure, so I can’t really provide useful code, but I would expect you to build a list of all tags to be read, then split that into two lists as you can count on the order, and then build your instances list from that.

Here is another thread that shows something similar to what I would expect, note not all of this applies, you can pretty much ignore the DB stuff for your purposes.

EDIT: [Replied in the first thread - continue it here]

The code I included does what I want, it’s just after I added the system.tag.getConfiguration call, it got noticeably slower (again, it takes about a second so its not a deal at all). I mainly want to understand the best way to get custom properties for a tag through scripting.

Here is a highly redacted version of the tag structure I’m working with:

The blue line is what the root tag path references (18 UDTs with < 20 tags each). Each of the UDT instances by the yellow dashes have a folder called Overview within them and in that folder, there are certain tags that will be displayed on an overview screen, like so:

which translates to this on the view:

I set it up this way so that I can have other tags that won’t be displayed in the Overview screen, and if I want to add other data points to the Overview, I simply add a tag to the folder for that UDT and it appears there dynamically. In this case, the UDT shown above has a Speed, Torque, and Vacuum tag and each of those has a Units custom property coming from the UDT definition (FPM, %, " w.c.l, respectively).

I tried filtering on certain tags, but there is more than one UDT definition I’d be filtering on which have different tags (also, some UDTs have matching tags but they’re outside of the Overview folder), so I couldn’t get a consistent and scalable result…

Tag event script, project script, script transform, doesn’t really matter. There are only two ways to access tag properties.

  1. Use* with dot notation as shown by @PGriffith
  2. Use system.tag.getConfiguration() and access the property from the returned List of Dictionaries.

A small caveat is that system.tag.getConfiguration() currently only returns properties with non-default values, so if you’re trying to access a property with a default value, then you’re stuck with*. I’m not sure where custom UDT properties fall into that.

The reason that adding system.tag.getConfiguration() slows down the script, is because you are calling it multiple times. (~180+ times according to the information you’ve provided). You will see a similar slow down if you use*.

I am not at a place where I can work through a loop that would be faster. If that is something you would like to see then, I can possibly work on it later. I would think you’re going to need some type of recursion though.

1 Like

I don’t know offhand if it does, but does reading UDT/Folder.jsonValues give you access to subnodes?

It seems like it does. I’m refactoring my script to read the entire tag structure once and then I’ll report back. Also, the original custom property was to keep track of the tag units, but I found that I can use the engUnit property instead (duh).