It’s client-wide (unless it is gateway-wide–haven’t checked) so every time you open a window with this script it affects all windows (though that’s not visible if other windows aren’t showing overlays at the time).
If you swap windows quickly, you can get interesting effects, like a previously scheduled enableOverlays function invoked later running right after the visionWindowOpened event so overlays are displayed after all.
I’m sure #2 could be worked around, but overall I like a loading overlay better because disabling overlays means we display incorrect “as configured” data on the page without any indication it is incorrect before live data arrives.
EDIT: Counterpoint–we could probably make the as-configured appearance of each component/template look the way we’d like them to before live data arrives so they display our own version of uncertain, rather than incorrect state.
Check how many tags you use for a window in gateway webpage - > Status → Vision Clients (select client session). If you use udt or nested udt all tags from udt in templates all tags from udt are subscribed. If you have big udt it is better idea to use tag path as parameter to template, and then get value by indirect binding.
I use indirect addressing/binding for everything, with a few exceptions. I have as little as 24 subscribed tags for a screen, and it lags just the same as the screens with larger amounts of tags.
Tag group for the majority of the tags talked about is a default subscribed group @ 500 ms. I have lowered this to 300 ms with no change. PLC is a ControlLogix 5580.
I would very much doubt that lowering the rate would help your issue.
There are ways to get very fast tag updates (@pturmel’s Ethernet IP Module). The question is, do you really need that update rate? How quickly are the tag values changing?
There’s a moderately significant edge case (accessing templates through scripting) affecting Vision performance that’s fixed in 8.1.19+; upgrading may help with apparent performance regression from 7.9. It’s not a panacea, but it may help if you’re using lots of scripting.
Delay to subscribe tags if they are leased and weren’t previously subscribed: if your tags aren’t in direct mode, you could try changing to direct mode.
Delay to deliver new values to client.
I’m doubtful the subscription rate affects these much, though it may reduce delay to get newly subscribed leased tag values related to first delay noted above (only applies if tags are leased):
Do you get periodic quality overlays on your screens or only on initial screen load? Just wondering if your PLC connection may be Overloaded. First thing that came to mind with seeing a default scan rate of 300-500ms.
Those are some of the first things I checked. @500 ms for the default subscribed tag base, the overload is sub 10%. When I bump the rate faster from 350-400 ms, the overload is sub 50%, so that’s not the issue. Out of all of the screens with lag, most have indirect tags, though some have a few expressions.
Last time I talked to someone on support at Ignition, they said running at sub 10% is perfectly fine / normal. I maybe have 1 or two tag expressions total. There are no calls on screens that run scripts. Most of the tags I am pulling from are within UDTs. I don’t recall any being from an AOI.
Another issue is using the template repeater. It lags very bad when generating the templates inside of it. All tags inside are indirectly addressed. I hope that’s not another “you shouldn’t use template repeaters”, because that’s just one more thing added to the list that are “functions” of ignition yet don’t work well enough to use.
Right?! I feel like this is a major issue but its not getting the attention it deserves. I just keep reading “you shouldn’t use that” for different functions in ignition because they don’t work well. It seems like there’s only one specific way to do things, using one specific method, and if you don’t do it that way it you won’t be successful. Kind of a bummer TBH.