[BUG-13815, 15230]Components showing stale tag overlay when they first appear in a window

We are experiencing a strange lag when switching from one display to another in Ignition Edge V8.0.2, where for an unknown reason, the components display visual overlays regardless of the nature of the tags bound to them.

image

Hi jose.granero

This issue has already been reported and we are tracking it internally. We are actively working on a solution and will keep you updated when a fix has been made.

Thanks,
Anthony

Thank you Anthony

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

I just did the update with the nightly build today (8/15) and the problem is still there.

I’m going to have someone look in to this and get back to you.

Any news about this issue?, we have the same problem as tashby, it hasn’t been solved in 8.0.4 yet and to us it’s critical.

Hi,

Could you please do the following, hopefully it help us save some time and fix it ASAP: Go to Help>Diagnostics, then go to “Logging Levels” and search for “vision.binding.tag-binding”. Turn that to Trace, and then go back and switch the screen a few times so that you see it. After that, go back to the diagnostic window, go to Console, and copy/paste that into a text file or here, so that we can see exactly which properties are going bad.

The problem was that the ticket was written up with “Stale” values, which is a specific quality code, and we adjusted many uses of that. But looking at this post again, it seems some bindings are going to “conversion error” state temporarily, probably due to the order in which values are coming in. We should be able to track it down quickly if we know more about what’s going on from the logs.

Hi Colby,

Thank you for your help,
We’ve done what you said about trade the “vision.binding.tag-binding” and we found an error, after solve it the lag is quite faster, now is only about one or two seconds.
Despite of it I attached you the log file, then you can see if there is another thing we can improve. Also the gateway log file.

On the other hand, we have seen that Ignition service doesn’t start automatically when we start the PC. We need to execute the start command from your .bat file.
Maybe this could be because the nightly version we’re using Ignition Edge 8.0.4 ?

Kind regards.
LOGRONO_Ignition_logs_20190821-1233.rar (983.0 KB)
Logs_console.txt (97.7 KB)

Here’s a capture from mine. Ultimately, it was trying to do a tag expression on a path from another binding that would result in a path based on whether the tag existed or not. So I think it’s waiting on the other binding to finish first before the second binding could work. Maybe there’s a way to delay the screen showing after bindings have a couple seconds to initialize before showing the error overlays?

here’s an image of what it looks like before links resolve

then after a couple seconds.

Hi,

Ok, thanks, that’s helpful. Can you post an example of one of the bindings? Also, one different thing that stands out: is the loading of your background image being affected by this? Maybe the path is stored in a tag? I was just trying to figure out why the imagery would take seconds to load as well.

This is still happening in Ignition Vision 8.0.5.


It seems that at the first expression execution there’s no value from tag… after second all is OK…

Hi @zxcslo, I reviewed this with Colby and he thinks this is a different but very similar bug as 13815. We’ve filed a new ticket and linked it above.

1 Like

The 8.0.7 nightly build from today contains a change that is relevant to the overlay issue presented here earlier. In short, null values on initial load were categorized as bad quality instead of uncertain quality, which is why the red overlays were appearing. There will still be overlays while bindings are loading, but they should use the grey overlay.

@zxcslo this change doesn’t really impact your case, since the error your seeing in the GIF is showing an unsupported operand exception due to performing arithmetic operations in a script on a null (NoneType) value. In that case, you’ll need the script to account for a null value while loading the bound value, otherwise the error will continue to occur.

Thank you for the feedback Paul.