[BUG-13815] After Ignition upgrade to 8.0, windows are loaded with tags in error state

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.

Here is a video showing the issue

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?

Drive overlay opt-out properties with timing from internalFrameActivated, perhaps.

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.

How important is the overlay if things stop working? You could run a startup script: system.tag.setOverlaysEnabled(0) to just disable everything.

Hmm. This has possibilities. Try the following:

  • Create two client tags, a boolean DisableOverlays and a Date OverlayDisableStartTS. Bind this expression to the boolean:
try(now(if({[Client]DisableOverlays}, 1500, 0) < addMillis({[Client]OverlayDisableStartTS}, 1500), 1)
  • Add a client tag change event script watching DisableOverlays that will call setOverlaysEnabled():
system.tag.setOverlaysEnabled(not bool(newValue.value))
  • In your navigation system, wherever you call system.nav.openWindow or .swapWindow, add a write to the timestamp just ahead of the open/swap:
system.tag.write('[Client]OverlayDisableStartTS', system.date.now())

Tweak the millisecond constants in the binding above to suit your needs.

{ The recursive now() sub-expression makes the binding stop polling when not needed. }

1 Like

Thanks, I will try these out!

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:

   now() < {[Client]OverlayDisabledUntilTS}

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.

Thanks @pturmel and @Paullys50!


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.


OK, it would be awesome to get this initial state correct in 8.0.2, so it would work similar to 7.9.

Hi Tuukka,

It looks like 8.0.2 is out now. Is this better in that version? Or do you have other updates on how that upgrade affects it?

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.

1 Like

This issue was fixed in the 8.0.4 nightly build that was uploaded today (8/14).


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.

1 Like

Hi all,

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… :slightly_frowning_face:

And worse, it happens that the Overlay does not disappear. Obliged to change windows then come back so that everything restores correctly.

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.

I’m curious, how did you detect a project update?

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.

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")
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.

1 Like