Perspective Tag Indirection and View Property Changes

[simon.wesley]

Hi All,

Ive looked at a few other posts, and i cant seem to find anything quite similar.

I am upgrading a Vision project into perspective and I am trying to figure out the most efficient way to build pages and views that can vary in their respective content. Specifically, differing tag paths once inside the tag folder and some items are also not available on some sites.

I am passing the the site “root” tag path from the browser and we are building out the remaining tag path with Indirect Tag binding, perhaps with a few other parameters.

What i am finding is that our sites are built fairly similar, but not all sites are using the sae Tagpath for the same on screen element, and therefore descriptions change, units, etc.

Is there a design principle i am missing where I can choose what tag goes on screens with ease and without processing at the GUI level with visibilities etc.?

Ive thought of making views that are of same type which i can swap out when navigating with some parameter . However then i am left with some of the content on the additional screens would need to be directed from Meter 1 to Meter 4 on certain sites only (as an example)

its late , and I hope I’m clear enough and I can show screenshots for clarity,

Trying to make a simple system rather than pass parameters until the day is long. I already notice sometimes a screen refresh is required to get the right data in. (might be a different issue)

S

[nminchin]

So you have multiple sites that are mostly the same but sometimes the same devices are called different things? Sounds like a good time to standardise your tag naming if that’s the issue.

Otherwise if that’s not feasible or the right course, then depending on how different the sites are, you could either use, as you say, separate View templates for each site type, or you can handle the minor changes within the View template itself. You can use the expression function
qualityOf({tag}) != 'Bad_Disabled' and qualityOf({tag}) != 'Bad_NotFound'
or
isGood({tag})
to check the quality of tags for their existence and show/hide things based on that.

In either case, I would be keeping track of what “site type” your sites are. You could do that in a number of ways, using the UDT type or a memory tag if you’re using standard tags and not a site UDT. I would then be reading the value of this and then setting the right View template / use in your binding logic.

[simon.wesley]

Thanks for your quick response. and yes i agree that naming would rename would be ideal.

Part of the problem is that the names would have been better purposed as real world names such as:

Group Gas Meter , Test Gas Meter, Group Oil meter, the issue s that the naming follows the configuration of the device (ie Meter 1, Meter 4, Meter 3, etc). SO thats a problem.

Secondly the tag-names are named identical, but the purpose can change:

ie
Alarms
------>Compressor
---------->ALM1
---------->ALM2
--------->TAG1 (memory tag stating what the corresponding # alarm is.
--------->TAG2

Same thing with analogs - generic names.

Its a bad way to maintain a separate Xref list of what is what then search on a table.

I’ve though of using metadata in the tag to define what the tag is,

We used site UDTs originally but the change in the driver and not all at once the previous person broke the UDT instance to allow updating the tagnames one at a time, without the a loss in history etc.however the structure remains unchanged.

Would you think changing names and moving tags around will not destroy history? I’ve found exporting tags and modifying then importing does. might be a setting or my process… so I am leery… I suppose i could test.

Realistically i want to change the tag name to a meaningful, repeatable name that represents the process area and device, rather than a a generic folder OR a folder name for meters, that would solve most of my issues.

WHile on topic, do you pass a value down to a label or the tagpath. i read one updates once on page load and one on refresh of point… which could cause too much GUI load?

Thanks again!

[nminchin]

@simon.wesley

Would you think changing names and moving tags around will not destroy history? I’ve found exporting tags and modifying then importing does. might be a setting or my process… so I am leery… I suppose i could test.

The link between tags and history is purely their tag path. So if you change the tag path of a tag with history, the history will not follow with the new tag name / path. However you can always retrospectively reassign the history to the new tag path in the SQL database. Obviously you will then need to keep track of the tagpath changes which you should be able to use the audit log for. Setting it all up nicely would take a bit of time but i've certainly considered it myself as it would be a super useful tool!

@simon.wesley

Realistically i want to change the tag name to a meaningful, repeatable name that represents the process area and device, rather than a a generic folder OR a folder name for meters, that would solve most of my issues.

This would be my preference and is what I normally do. Either use a description of the device as in your examples (Group Gas Meter), or use equipment ids but ensure they're used consistently across all sites e.g. Meter 1 is always Group Gas Meter, Meter 2 is always Test Gas Meter, etc, regardless if the site has the device or not. For a site like you're describing, I would tend to use descriptive names instead.

@simon.wesley

WHile on topic, do you pass a value down to a label or the tagpath. i read one updates once on page load and one on refresh of point… which could cause too much GUI load?

When you say "to a label", what do you mean? I need a bit more context
If you want the value to live update you need to bind to the tag path.

[simon.wesley]

Apologies, I confused the issue.
What I meant to ask was if I pass the tag path down to the root of my embedded view then I can use the tag path as reference to the object to grab any property. What i read somewhere in the forum that the binding of a tag path is evaluated upon page load…yet the binding of a value is constantly evaluated.

I was looking for advice on best practice to pass the full tag path (so I dot have to hardcore the remainder), and was wondering if there are any performance concerns, as I think I read.

THanks a bunch!

[nminchin]

@simon.wesley

What i read somewhere in the forum that the binding of a tag path is evaluated upon page load…yet the binding of a value is constantly evaluated.

I'm not sure to which topic you're referring, but I always pass tag paths to my embedded views and then use indirect bindings to read tags based on those tag paths passed in.

[simon.wesley]

Thanks Nick, I think I follow you.

The comment i was referring to is in this reply to this topic:

Slow loading times after 8.0.14

Yes. Consider that tag values update repeatedly and asynchronously, while tag paths are typically evaluated only when a Perspective view/page opens. The reduction in work in an Expression Structure that only has to evaluate tag values (from custom props) as opposed to also evaluating tag paths (that are now only part of the custom props) is a win even though there are more bindings overall. Also consider that while an Expression Structure may be needed to deliver consistent data+config to a c…

After re-reading the comment with fresh eyes, I believe what @pturmel was referring to was typical updates to tag values, for tag value/quality updates to a property such as a label, not reevaluating the binding.

h