What does the lock trait mean in the tag browser? I only see it on OPC tags, but not on expression tags? I am still getting values from the OPC tags.
If I use the expression function: IsAlarmActiveFiltered, I am not able to use the tag path of any tag with a lock trait since this result in a “Bad_NotFound”. However, if I use the tag path of any of the memory tags without the lock trait then the expression function successfull evaluates the tag.
Is there something I am missing here? The lock trait is not mentioned in the documentation as far as I can see…
Any clarification on this subject is appreciated
The lock simply means that the tag has some permissions attached to it. It could be read only or have custom role based permissions.
However, that shouldn’t be related to what you are seeing in your expression. A Bad_NotFound error would only occur if there is an issue with the expression where you are filtering on an alarm that doesn’t exist. Are you sure the tag path, alarm name, and display paths are all either correct or the wildcard
'*' and the tag has a priority that falls inside the filtered max and min?
Okay, thank you for clarifying that.
I just tried to set the minMax prority to 0 to 4. to catch everything. On some tags I saw that I still get the “Bad_NotFound” but it is still returning false? Can I assume that the error “Bad_NotFound” is just an indication that if a tag with the given priorities is tested with the expression function IsAlarmActiveFiltered. So I can use the function to check all tags within a UDT. So if in some configurations it won’t find any tags that satisfy the criteria then it will have the value false but also throw the error “Bad_NotFound”?
Right. If there are tags that exist within the tag path argument but the alarm name or display path don’t belong to an alarm then you will get a Bad_NotFound error because the alarm doesn’t exist but you also get “false” as a value back because the expression is also letting you know that there aren’t any active alarms using the filter provided.
As for UDTs you can definitely do that by setting the path to be the UDT plus a wildcard character to capture any tags within the UDT. It’d look something like this:
Thanks for straightening out the tags path issue for the original poster. I do not want to sidetrack the Topic or thread, yet before you mark it resolved, could you look at the following for the Lock documentation?
Yes, I deleted the initial h before ttps to prevent the display of the link. This allows me to check the complete URL. In forum posts, it also keeps the initial post from being displayed.
There is another icon that I expect to see someday, the fourth one in the Tag Editor… so there is yet another bookmark about a final test question on “what does that tiny icon mean?”.
If you are referring to this picture. The 4th icon in the tag browser highlighted in red is if the tag has history being stored. The 4th icon in the table below the picture is when the tag has a tag event script. They both have links there describing what they do and how they work.
I will let documentation know that we should also add the lock icon to the table.
Actually, it was the 3rd Icon in the Tag Editor that I can not locate. It looks like a box containing two iterations of the morse code letter A [ : = ] with short and long bars rather than dots. I did find some of the Icons in a document that called them ‘symbols’, maybe easier for musical folks to remember.
There is an example of the icon/symbol at page 175 of 176 in the Tags.pdf section of IgnitionUserManualExport section Ignition Platform.
And the symbol reference is