Best practice on using [default] in tag paths for scripts or bindings

Ignition
1

Maybe this is an obvious question, but I wanted to get some feedback on the best practice for writing out tag paths in scripts or bindings in an application - specifically with respect to the use of the “[default]” portion of the tag path. I’m using Perspective v8.0.14 if that matters. I want to make sure the path we choose aligns with the vision of the developer.

We have been putting the “[default]” everywhere - in scripts, direct tag bindings, indirect tag bindings, etc. From what I can tell that isn’t really necessary. If you browse to tag with a direct tag binding you get it for free and it really isn’t an issue, but for indirect tags (whether by binding or using a script that has system.tag.readBlocking(['[default]'+view.params.ItemPath]) its extra typing we could avoid.

Here is how it looks now:
image
image

Apart from being more typing and text it can cause the binding or readBlocking not to work if someone were to parameterize the “ItemPath” with the “[default]” included. This happens easily if someone does copy tag path.

In this case the bindings using ItemPath won’t work if they have [default] already added to them as shown above.
image
image

We are trying to set up some standard objects that can be reused by other designers in any application that require the least amount of work to use. We originally (perhaps incorrectly) made sure to have “[default]” be built into those standard objects so that individuals would not need to include that extra text when parameterizing the objects. I’m not sure if this has always been the case or if something has changed but it appears that if you are referencing a tag in the [default] folder there is no need to include “[default]” in bindings or scripts such as system.tag.readBlocking so our design like that is not necessary and as I mention above actually opens up the possibility of having issues if someone includes “[default]” in their parameterization. Lastly, while most of these standard objects would not reference the System tags, they wouldn’t be able to if we hard coded the [default] as well.

So, is there any downside to not including the “[default]” text like we were doing? This would likely result in most bindings and scripts not having “[default]” in them at all since people would be likely to not type it in. Is there any issue with having bindings or scripts like this?
image
image

1 Like
2

If you want reusable, don’t hard-code the tag provider name (“default”) as it’s likely you’ll want to use tag providers named something other than “default” in the future. The tag provider name does not need to be specified in tag paths as long as the tag provider you want (not necessarily named “default”) is set as the default tag provider for the project. If you’re making a project to be run on multiple servers that also run other projects and using remote tag providers, you’ll be leaving the “default” name behind quickly.

As for your templates/views, you could make the tag provider a separate parameter, or include it in the item path. Neither is necessary when it is set as the default tag provider for the project.

3

+1 for this. Another thing that we do to help reuse is to stick almost everything in a UDT before it becomes a instantiated tag. This lets us quickly repoint different parameters for a tag (tag group, PLC path, historian parameters, etc).

4

This was the conclusion we were coming to, but I wanted to make sure there wasn't something we were missing that could cause unintended consequences. Sounds like there isn't anything we were missing.

Yeah, we utilize UDTs quite a bit as well to instantiate things by just modifiying a few parameters.

5

So after trying to remove some of the defaults I see an odd behavior. When I call a script from my project library in the Script Console it works just fine, but if I call that very same script from a script transform following an expression binding it does not work without the “[default]” in the script. Why would the two behave differently when calling the same script?

The script contained a system.tag.browse command and system.tag.readBlocking. Does the browse require the [default] by chance? It appears from other scripts that readBlocking does not.

6

Transforms run on the gateway. Any tag references in the gateway scope must have the tag provider name.

7

Which is utterly lame, since perspective sessions have a project context.

2 Likes
8

I second that. Scripts on Actions appear to be the same way, but what seems odd to me is that it is tied to the system.tag.browse. system.tag.readBlocking appears to work with no issues, but when you do browse without the default it does something like this:

results = system.tag.browse('MikeStartPB')

BrowseResults [results=[{u'fullPath': MikeStartPB/default, u'hasChildren': True, u'name': u'default', u'tagType': Provider}, {u'fullPath': MikeStartPB/System, u'hasChildren': True, u'name': u'System', u'tagType': Provider}], totalAvailableResults=2, continuationPoint=null, resultQuality=Good]

where it should look like this, iterating through the children:
BrowseResults [results=[{u'fullPath': [default]MikeStartPB/ButtonTextOn, u'hasChildren': False, u'dataType': String, u'name': u'ButtonTextOn', u'tagType': AtomicTag, u'attributes': [], u'valueSource': u'memory', u'value': [Start, Good, Wed Jul 29 18:28:10 CDPBT 2020 (1596065290241)]}, {u'fullPath': [default]MikeStartPB/Category, u'hasChildren': False, u'dataType': Int4, u'name': u'Category', u'tagType': AtomicTag, u'attributes': [], u'valueSource': u'memory', u'value': [0, Good, Wed Jul 29 18:28:10 CDT 2020 (1596065290241)]}, etc...

Read blocking by comparison
image
image

So is it only certain functions that require the [default]?