This feature adds a new UI accessible from the Tag Browser as well as system functions for searching for tags that have certain characteristics including:
Tag paths (* can be used as a wildcard)
Quality (including quality subtypes like Bad_Disabled)
The tool also provides functionality that returns tags where a property meets a certain criteria. Any tag property can be selected and compared in the following ways:
Has: Default value has been modified at least once and the value exists in the tag definition.
Has Not: Default value has not been modified at least once and does not appear in the tag definition
Overridden: Tag contains an override on the selected property
Like: Properly has a value like the search string. * can be used as a wildcard.
>, >=, <, <=, =, !=: Numeric property has comparison applied to the noted value.
Note: If you have a custom tag property this isn’t listed, you can manually type it in. Once searched for it will be selectable for reporting as well.
Tags returned in the preview window can be interacted with in the following ways:
Edit tag(s) by opening up the Tag Editor (double click, right click > Edit, or via the pencil icon)
Deleting tags
Copy the selected rows with Tab separated columns
Copy the tag definition as JSON
Copy the path to the tag
Show a single tag in the Tag Browser
Searches can be saved and are saved globally. This means that any search you save will be visible for all users. The preview window can be customized to display whatever properties you would like, and a CSV file can be generated with a seperate set of properties.
If you need to save a search to another Gateway, there is a Copy query as JSON option next to the Configure Tag Report header that will copy the search to your clipboard. You can use the Paste JSON query button to load the query into a designer on a different Gateway.
Finally we added a new system.tag.query system function that exposes all of the search functionality via our scripting system. As the definition of the payload is a bit complex, we implemented a Copy as Script functionality that will copy a script that you can use to return the first 100 rows of your current query anywhere scripting is supported. Feel free to remove the limit, or try the continuationPoint functionality that was added. This can be accessed by running something like the following (assuming results is the value returned from an initial system.tag.query call that limits the result count):
Are there any context menu items related to this at the moment? For example similar to the new “right click on view/window/template, find/replace selected views”, can we have something similar for tags?
e.g.
UDT Definitions:
Show instances (both inside of other UDT defs as well as UDT instances in the Tags area)
Show dependencies (UDT defs that include the selected definition)
UDT Instances:
Show all similar instances (identical to 1st UDT Def option above but uses the instance’s UDT def)
Currently there is not. Something similar to what you are asking about is being actively developed that is building off the APIs developed for this tool. This is just the first stage of a few things we have planned.
This is awesome! Thank you so much for the work to put this together, i’m sure its going to make so much of our little scripting projects not required!
A couple of things that would be godsends that i can’t seem to see implemented:
when searching for traits “Overrides Parent Properties”, is there a way for the report to tell us WHICH properties are overridden, and have that in the report? That is the second hardest hurdle.
Perhaps this could be a column such as “Traits triggered” in the form of a JSON string showing what triggered the search filter?
The “Alarms” column, i expected to return the alarm configuration, but we get something like: com.inductiveautomation.ignition.common.alarming.config.ExtendedAlarmConfiguration@70a5921c
Is there any way we can utilize this to see what the internal alarm configuration is? I basically want a report to tell me what tags have alarms configured (So far so good) and then list the actual alarm configurations such as “priority”, “enabled”, associated data, alarm mode settings etc… (not so good).
Can’t seem to get Parent Data Type to work? I get blank values returned, even when i get results back that are clearly children tag of a parent UDT.
For example: UDT contains “ComFail” and “Fault” tags which are both OPC Boolean tags.
I haven't used this yet so I might be overlooking something obvious, but for me I think I would prefer each overridden prop as a separate item. This would make it easier to sort and filter in a table like in Excel. But definitely agree that this would be incredibly useful
There isn’t currently a way to get a list of all the properties that are overridden on a specific UDT member. The closest the tool currently offers is in the + Property area where you can select the property and Overridden to search for a specific property being overridden. We have a polish ticket open where we might be able to fit returning a list of overridden properties into. I can see how this would be useful.
We are aware of this issue, and will be fixed with the aforementioned polish ticket. It only affects certain types of tags, and using system.tag.query returns what you would expect. We just need to make the UI do the same thing
There are a couple different ways to search for Parent Data Type and each has a slightly different behavior. I just want to make sure the behaviors are matching the expected:
Using the Ancestor filter: Will return all objects that are part of a parent tag linked to the selected UDT type. This will include objects in the _types_ folder. Additional filters can be added to narrow down results.
+ Property area, Parent Data Type property: This should return all UDT Instances that are not part of a UDT Definition.
Either way, something doesn’t look right with what is being returned (would expect more results if option 1 was used, different results if option 2 were used). If you could send me, via direct message, a tag export and a screenshot/json of what your search is I would appreciate it.
I’ll have another go at it, and try the scripting function to analyse the alarm configuration.
The list of overridden properties would be amazing. At the moment there are even some results where i double click and cannot see any green overrides for that tag.
Will also send you a DM about what i’m tying to achieve with the Parent UDT being reported.
Are these query tags by any chance? If so, the value property is set and being evaluated as overridden even though the UI doesn't show it. It just happens to exist in the definition, so it is being returned correctly, but it isn't technically visible. We are still talking through a solution on how to resolve this discrepancy.
One use case I was not able to get work was to compare UDTs between different environments. I would like to be able to take copies of the UDTs, import them onto one system and run the tool to do a diff between them. This would be a way to verify what is on site vs dev for sites that do not have proper source control.
Is this functionality that is indented to be supported?
Fyi, source control can’t compare tag json changes either since they aren’t aware of the structure of tags in the json and dictionaries are unsorted by definition. But I agree that this would be a great feature to add!
@Andrew.Richardson, currently a tag diff isn’t something that we have the capability of supporting within Ignition. The only way to do this would be to export tags from both systems and do a diff between the two files. Because JSON doesn’t guarantee order of objects returned, you would need to manipulate the files after they are generated to get them ordered somewhat similarly.
This idea is something that I do feel would be beneficial to add, and I will add a feature request to open it up for discussion internally.
You really can't blame that on JSON. It is Ignition's implementation of JSON that doesn't maintain order. Use of an order-preserving Map<> implementation instead of a simple HashMap<> would solve that.
IA should be thinking about how to make all of its file formats repeatable and diff'able as part of the push to better support git or other source control technologies.
This doesn’t guarantee diff-ability though, since tags could be removed or added to either or both sides of the comparison. You really need to compare the files in script regardless by searching the json for each tag in both and comparing
I think as long as the tags are always ordered the same exact way every time via some consistent ordering logic, even if both sides made changes, it would be pretty easy then to make reasonable comparisons- I think notepad++ would be able to do it correctly at that point (show adds and minuses on both sides).
Nope. json compare tools have no knowledge of the tag path elements (e.g. the “name” keys) and hence they cannot compare two sets of tag json without them having an identical structure in terms of the tags they contain and the order in which they’re in
