Leased Tag rate best practice

Ignition
1

I have a perspective project with a couple different leased tag groups. One for "standard" refresh which I use for things like numeric entries and other things that the user sets, and another for "fast" refresh for things like gauges and numeric displays. I've also created two connections to the PLC, one for standard tags and one for leased tags. Standard tags in the Default group are just for alarm tags.

For standard refresh, I have the rate set to 0 for the base Rate (which means from what I understand the tags will not update at all unless there is an active binding on them on the screen or an expression tag) and 1,000ms for the Leased rate. For fast refresh, it's 0 base Rate and 250ms for the Leased rate. All other settings are default, so the Data Mode is Subscribed, Read After Write is false, Optimistic writes is False, Publishing and sampling intervals for OPC UA are -1.

I have noticed in a lot of instances it will take some of my popups several seconds to get leased tag data, especially if it's a "fresh" invocation of the view. My popups have four gauges on them. The gauges are the "SVG Gauges for Perspective" I got off the exchange. I got those specifically because of performance considerations. However, when those popups load, it looks like the gauges "assemble" themselves and it can take more than a few seconds to do so. I don't know if this is specifically because the tags are leased or not, but I'm kind of surprised the loading times are so slow with arguably the most efficient objects possible. This leads me to my question.

Is it better to have the base Rate on leased tags be something as opposed to zero? Like would it be better if every leased tag had a rate of say, 10,000ms and then a faster Leased/Driven rate? I've done some reading about it being an "expensive" process for a tag provider to change the read rate of a leased tag, which is the reason it's recommended to have a tag provider specifically for leased tags. But when most of my tags are leased, would it be better to at least have them scan occassionally rather than never? Is it faster to go from "scanning sometimes" to "scanning fast" than it is to go from "not scanning at all" to "scanning fast", or am I barking up the wrong tree?

2

You are probably suffering from this aspect of Ignition's OPC client:

Note that if there are ANY OPC tags have unknown OPC Item Paths, the corresponding OPC server connection will stay in that eight-second debounce as the tags retry.

For leased tags to have anywhere near sane behavior, there must be NO bad tags at all.

3

What Phil said is true, and also

there is no difference in speed, but what is different is that in one scenario you have a good quality value while you wait for the lease change, and in the other you don't.

edit: is this true? I would think a tag that gets unsubscribed gets something like Uncertain_LastUsableValue quality...

I'm not familiar enough with Perspective or how it uses tag subscriptions to talk about what kind of delays are possible there.

4

This is very good to know. We're still in the development phase, so bad tags are a fact of life as things change and we clean up. But it is of course our plan to have zero bad tags after the FAT. So this may be an issue that will 'go away' once we finish the project.

5

From my own personal experience and what I've noticed, if it's a new tag and it's leased with a 0ms rate, it will show a quality of Uncertain_InitialValue until an active binding leases it. Interestingly enough, I've also noticed that if the path is not valid, it will show as Bad even if nothing is activating that lease. In the course of development I've seen a lot of leased tags go from Bad to Uncertain by fixing the path. So something in the OPC driver is at least checking if the path is valid, even if the tag is not set to be read.