In ignition 8 vision windows are loaded quicker than in 7.9, but they show all the tags with error overlay for first second or so. This is more visible with windows with more tags. 7.9 loads the same window without the error overlays after it has been cached in first run. this looks bit nasty to the users, and especially when we load dialogs, it is very visible to end users.
In the red debug block the multistate indicator is just dropped from the tag browser, the tag quality is dropped from tagâs quality value, and the property quality is linked to quality property in multistate status.
Tag count is ~ 15000 tags in the provider
Window cache is auto, but having it as âAlwaysâ has no effect, and having it âneverâ makes it bit slower (makes sense because the initial load happens everytime)
Any suggestions? Is there any way to show some loading overlay in the whole window, or any way to hide the loading time overlays?
Some tricks could be done like this. Few challenges are that when internalFrameActivated triggers, the tags are still in error overlay, which means there should be some hard-coded wait time. This time is unfortunately not constant, especially between windows. Also another problem is that we have thousands of these tags, so setting opt-out on all of them adds quite a lot of work. Is there any way to disable them in single batch?
Another option would be just toggle visibility of the root element or loading layer over everything, but that adds same problem with the timing. If there would be some way of identifying that window loading is done, that would resolve the issue.
We had this same problem in 7.9 and used a âloadingâ component to cover everything with visible set on when window opened and visible set off in a component running event script a top level (in tree) component. If I recall correctly, this wasnât 100% (might still see an quality overlay or two very briefly on initial page load), but got us pretty close. We donât want to display values that may be incorrect for long without quality overlays, but temporarily disabling quality overlays is an interesting option.
It works quite nicely now, I did small changes to code:
Now there are two client tags DisableOverlays boolean and OverlayDisabledUntilTS DateTime
DisableOverlays has Expression:
try(
now() < {[Client]OverlayDisabledUntilTS}
,0)
Tag Event Value Changed: system.tag.setOverlaysEnabled(not bool(currentValue.value))
And when I load any window, I use code: system.tag.write('[Client]OverlayDisabledUntilTS', system.date.addMillis(system.date.now(), 1500))
This adds the support of changing the estimated load time of each window, based on their complexity. To make it bit nicer, I would also wrap the tag write call to some project library, so the complexity is hidden in normal use.
Thereâs also a bug here thatâs probably going to be fixed in 8.0.2 - the quality on initial window load should be INITIAL_VALUE, not STALE, which is what itâs currently reporting as (and what causes the error overlay, instead of the âpendingâ quality overlay.
The behavior here hasnât been changed - the issue I described in my earlier post still has pending code changes that havenât been approved yet. At this point they may be in 8.0.3, or may slip to 8.0.4.
I also met similar widgets overlay issue (red debug block) as shown in the previous video by tuukka. So will Ignition 8.0.4 fix the issue without doing any script update like pturmelâs suggestion?
8.0.4 nightly/rc removed the red overlay, but the problem still exists with a different overlay now. This is swapping between screens with the tab strip. Between 1 to 3 seconds to load everything, depending on the amount of components on the screen.
Disabling the navigation mode on the tab strip and adding a mouse click script is a good workaround, but I would prefer not to have to do the extra work.
has there been a change in the last versions concerning this OVERLAY?
Is it possible to deactivate it, without deactivating all OVERLAYS?
Itâs really not beautiful during navigationâŚ
And worse, it happens that the Overlay does not disappear. Obliged to change windows then come back so that everything restores correctly.
best
Yes, we've seen this as well--in one case it was enough of a problem that we programmed an automatic page swap away/back after project updates to work around it (v8.0.12). I think I saw something addressing this further in release notes for a later version, but we're waiting for 8.0.15 due to another issue in 8.0.13 & 14.
We didn't really detect the project update, though the workaround we implemented was to eliminate the stuck overlays we were experiencing after updates. It's on a single window full screen project where apparent "pages" are actually containers shown/hidden by navigation buttons. This gives the appearance of instant page changes. Since users never leave the main window, they couldn't flip pages to get rid of the persistent overlays that would sometimes appear after pushed updates on version 8 (didn't have the problem on 7.9.x).
We added a startup "loading" window that looks just like the loading overlay on the main window with a window script that swaps to the main window after a second. A client start-up script invoked later uses system.nav.swapTo to open the new startup "loading" window.
When we push an update, the client sees the main window (with loading overlay shown by script in visionWindowOpened event). Then it swaps to the new identical appearing "loading" window we have in the client startup script and a second later back to the main window. We see the loading symbol as it does these swaps, and we no longer have stuck overlays after pushing updates.
The above did the job, but won't go back to whatever window the client had open in a project with multiple main windows. Take a look at [System]Client/System/LastProjectUpdate. It reflects client update time (not project update time), so you can use an expression like this to get seconds since client update:
Checking for seconds since update greater than 0 and less than something, you could try swapping to a window passing a parameter with the current window path to swap back to a second later.
All that said, hopefully this persistent overlay issue is gone in later versions.
I think we still have the same (or similar issue) - upgraded to 8.0.15, but this has not helped.
On Page swap (using the Navigation Tabstrip and using page Swap Buttons) we randomly see elements (sometimes a few and sometimes many) get stuck with the OPC_Waiting overlay (white with Tag and clock).
It seems to be more prevalent when swapping pages quickly, but thats only an impression. Swapping to another page and back sometimes clears all the overlays, and sometimes clears some of the overlays.
There doesnât appear to be any problems with the associated Tags nor the gateway and we dont seem to be nearing any loading limits.
Anyone have any ideas how to trace this.
EDIT :
After posting this, I noticed that all the elements showing the overlay contain an expression which uses the tag() function in the format
tag(âTagPath/â+{Template Property}+"/TagElement")
eg If(tag("[default]Digital Inputs/"+{Digital Input.DeviceID}+"/Input")=1,color(255,255,255),color(170,170,170))
I assume the Tag function is asynch to the page population and sometimes doesnât complete before the page is displayed?? Not sure if this helps the situation any.
