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.
I wanted to bump this topic since I'm having the same issue.
I have a very compartmentalized project with conveyor sections. As of right now, I have two tag groups for each section, one for direct tags (which I use only for alarms at the moment), and one for leased tags. However, on my Gateway I only have two device connections. One for polled tags and one for Leased tags.
Would making more device connections, one per section, help with how expensive my switchover is?
Switchover shouldn't be frustratingly expensive, even with a 'large' tag count. Though, displaying the last-scanned value (without bad quality during the subscription change) could greatly improve operator experience...
There's an important detail by the previous poster:
which likely points to a different problem entirely (bad tag read, etc.).
Can you provide a little more detail on your setup & experiences? Which PLC driver? Same 8 sec delay?
We're using a standard data structure for each section with capacity for a certain number of motors, but every section uses a different number of them. The tags always exist in the PLC anyway, but I have a commissioning script that crawls through the program, looks at all the enable tags for each motor group, and disables group UDT instances in Ignition that aren't being used. Before I did that, I was watching the logs for the Device connection status and saw that it was doing tag reads for all kinds of motor groups that we weren't using. After I ran the script, those read for unused groups went away. I'm assuming that improved my communications throughput as it slightly reduced the comms load on my PLC. Those disabled tags have a status of Bad_Disabled as opposed to unknown though, so I'm hoping these don't contribute to that 8 second batching. We're also still in development and we're working on cleaning up bad tags, but if it's better to have them all read, I do have an "enable all tags" script written too just in case.
Also, to update everyone, I tried this (and also made it easy to switch back!).
It did noticeably improve the delays in the tag reads switching from popup to popup. Before the change, every time I launched a popup, it would take at least 12-13 seconds and often in excess of 16-17. After I created 20 groups (a connection for polled and leased for each of the 10 sections), The delay dropped consistently by around half, to between 3-7 seconds. It's still a bit of a long delay, but it's a lot better. The downside is that it increased my PLC comm load from roughly 40% to roughly 60% at a steady state. To @pturmel 's point, I forgot that having bad tags affects this, and I have a few of them that need to be cleaned up. So I think I'm going to roll the changes back for now and see where I'm at after all the tag issues have been resolved.
Disabled tags do not contribute, IIRC. But note that any other item path that is not found, anywhere among the native drivers, will put all of them in this state.
The rest of your delay is the IA Logix driver having to recompute its optimization plan. (My driver doesn't do that--different optimization strategy.)
So if the tag is disabled it won't contribute to the delay if the OPC path is valid? All the tags will always be present in the PLC. They just won't always be used in the actual logic.
)