Does anyone know if there is a practical way to capture the tags that a Perspective page (with its constituent views and components) is referencing while the page is viewed?
I am hoping that there is a means within the designer, gateway or even a Perpective browser session where I can determine which tags any given page actually consumes or references (whatever the correct term is). I would need explict tag path/names (those resolved from the indirect tag bindings defined in the designer).
I’ve tried a number of approaches but so far can only get a count of tags that the gateway is monitoring or serving to the project, I haven’t managed to prune this down to just tags that the project’s views refer to.
Background: To make the development of my first project easier I initially included quite a number of tags from my PLC (CompactLogix). Many of these tags are based on large PLC-defined UDTs and have a significant number of member objects (often arrays) which resulted in the gateway monitoring tens of thousands of tags (most of which are submembers of the parent PLC UDT tags). This served my development purposes as I could create indirect tag bindings in my Perspective views and be confident that they would resolve to a tag associated with the project. The downside is my project is running really slow because my device tag count is overloading the realtime tag provider. I suspect the tags that I actually use with the project are less than 5% of the monitored tags. Rather than trying to determine and then selectively removed the tags that are superfluous, I thought it would be easier to delete all the tags from my project and then add back in only the necessary (consumed) tags.
I also have a number of alarm and historically logged tags that are not directly consumed by a view, I have a good hold of which these are so adding these back in after the view-consumed tags would not be an issue.
Thanks for reading and any assistance you can offer,
Simon
I don’t know of any ‘simple’ ways of doing this, but I guess you could make a script that parses a view’s json and stores tag bindings…
Next you’ll need a way to find tags that are used in scripts, which you could also find by parsing and looking for system.tag.* function calls I suppose.
It shouldn’t be too hard if you’re familiar with scripting.
/!\ Note that I’m just guessing, this might not be a viable solution. /!\
This is practically impossible to do since indirect bindings could be reading any tag based on the inputs provided, and these could be dynamic.
Your best net would be to try to capture whenever a tag is subscribed to and add it into a lost over a few weeks or so to capture hopefully all dynamic usagesfor how or if that’s possible, that I can’t answer!
True it kinda depends how you made all the bindings...
I have a script that "scans" the view.json files, in this example its just the text, but you could look for
propConfigs containing bindings of type tag
best check up a view.json to see how the bindings there are constructed if you want to make a script to scan for them
It doesn’t matter how they’re stored though, for example an indirect tag binding could be referring to a custom prop value, but that custom prop value could itself be indirectly bound to something else, and that could be passed any number of values into it, from static values to values from script transforms, to queries, etc etc. It’s an insane amount of work needed to properly and entirely map out a list of all used tags with both direct and indirect usages. And if you can’t get it all the way, there’s not much point in getting any way since what you’ll be left with is an incomplete list anyway
Hi and thanks for all the suggestions.
Being my first project it is not on a particularly grand scale so I only have about 20 pages and the parameters passed to the constiuent views are defined on the main view of each page and cascade down into nested instances of components and embedded views. So thankfully not a lot of concern with dynamic references to indirect bindings.
I thought I was onto something in the gateway status page when I set the log activity level to trace on my device’s status page. The tag reads were all there but not filtered to what was being consumed in an active view, just everything. I was hoping there would be some way to monitor the tag data stream from the gateway to the browser as presumably this would be limited to only the tags that the ssesion requires (consumes). However, on reflection, I imagine that the tag structure (names and paths) would not be directly exposed to the browser so as to prevent the PLC structure from being published in the HTML and visible through dev tools.
For now I am going with the suggestions regarding the view.json files. As my python scripting improves I’ll be able to make short work of it but for now I am just examining the file and using replace to substitute a typical set of literal parameters wherever references are made to the view’s params in an indirect tag binding. I then do a final search on the file for “tagpath” and I get a fairly succinct list of consumed tags.
Because I have a lot of common structures in the PLC I can then extrapolate from the findings of one view/paramater-set to similar instances.
I’m finding Perspective to be a double-edged sword, it seems that you can do almost anything but you need to wield powerful tools (python, css, etc) adeptly to leverage the opportunities, especially once a project gets too big to maintain with mouse clicks.
Tip: Don’t make your tag folders and UDTs match your PLC’s tag hierarchy. Common mistake, but handcuffs you.
Make Ignition’s tag hierarchy (and UDTs) match an operational view of your process and its repeating elements. Then your pages/views/windows/templates will be much more reusable (and predictable).
