Can someone please explain to me how fast a tag switches from the default rate to the leased rate when set to “Leased” mode?
I have a tag group set with leased at 199ms and default at about 13000 ms. I notice a long delay when first opening a screen before the tag value updates. Once it updates it seems to operate correctly with the leased rate.
Is there a way to force it to update? Think of a pushbutton where I need the status bit to show me right away when the button is pressed right after opening a view.
I think the slow rate value is there, but it just isn’t switching to the leased rate in a timely manner creating an issue where the data appears not to be responding. Some insight from Ignition on how this works would be helpful - the help on leased tags doesn’t mention how long before taking effect that can take.
Normally it takes effect a lot faster than that, but for heavily loaded devices switching between rates can be expensive.
To “clean room” test it, try the following:
Set up a new device connection to the device (along-side your existing device connection)
Set up a single tag on a leased scan class / tag group
Put that individual tag in a window. Open that window and observe how long it takes to switch.
If those steps show the leased tags come through quickly, you’re probably running into slowness from Ignition moving those tags from one rate to another behind the scenes when you open the window. In order to alleviate that, we’ll often recommend creating a separate parallel connection to the device that you only put leased tags on. (Step 1 above)
(Behind the scenes in Ignition, there’s a re-optimization that happens when tags move from one rate to another. Having the leased tags on a separate device connection means only tags on that new device connection are re-optimized, avoiding re-optimization on all the tags in your existing device connection which can be somewhat slow.)
We have a ticket in to make this better in the future. It currently works how it has always worked, but it would be nice if we could optimize it a bit.
Sure, but the proposed solution would solve it. The steps are there simply to verify a second device connection to the same device will be a solution.
If he goes through those steps, and it's still slow, then what I mentioned isn't the root of the problem, and we should look elsewhere to try to determine what's the underlying cause. I'd probably look into user-written window initialization scripts, heavy bindings or expensive scripts in the window design, tag configuration, or a number of other things next if steps 1-3 don't demonstrate any improvement.
No need to explore those routes if those first 3 steps demonstrate that there's an easy solution.
To Kevin’s point the test I did would seem to indicate it is more based on the views themselves than the tags. Here’s what I did. Kevin, let me know if this wasn’t your intent.
Created another Device connection to the same processor, just gave it a different name.
Created one tag that bound to this new connection (technically it was a UDT with a couple connections).
Set up the “Indicator” in the UDT to toggle quickly in the PLC so I could observe when the view started getting updated data.
Tested on the same view I already had created (with lots of stuff on it). I had two different connections to the same “Indicator” - one through the original Device connection which has a lot of tags connected to it and another through the new device connection which only had the one UDT instance connected to it (maybe 5 OPC connections total)
a. Both indicators were slow to respond when first opening the page
b. There was maybe a slight improvement on the “new” device, but that was only maybe .5 seconds or less difference and they took 8 or so seconds to begin communicating at all.
c. Side note - if I leave the view and return with in a short time (maybe a minute, maybe less) they work right away with no delay. If I wait a couple minutes and return to the screen they are slow to initially respond again.
I ran a separate test in a new view with nothing else on it. When opening that view both indicators started responding very quickly in less than a second. There was still maybe the smallest improvement in the “new” connection compared to the old.
I don’t have any start up actions on the view, but we use a lot of embedded views for reusable objects we’ve created like pushbuttons. These embedded views have a around 10 or so bindings each inside them. Would you consider this quite a bit that it would slow down that initial leasing change?
Thanks for laying this out. Yeah, it sounds like it has to do with the view structure and bindings.
First thing I’d do to try to optimize is see if you can change any Script Transforms to Expressions. Expressions evaluate much faster. I’d also make sure there wasn’t anything too heavy happening in any Script Transforms, and if there was, think about moving those things to Property Change Scripts or put them behind button Actions if possible.
If you’re still having performance issues, you might look at the way any indirection you have going is evaluating. If it’s going from one embedded view to the next, but keeps requiring tags to move from the slow rate to the fast rate with paths based on indirection, there will be an additional delay for each “layer” of embedded views. Whatever you can do to have as many of these tags subscribe at the root, rather than the embedded views, should speed up the loading. Sometimes this is possible, and sometimes it isn’t.
Also, I’d check your embedded views for components and other things that could take a long time to load. Query bindings that bring back hundreds or thousands of rows can slow things down, as can densely packed components like drop downs or graphs. Labels are really light-weight, but some other components are more heavy-weight and take a little while to load if you have more than 20 or 30 on a screen.
)