Hi,
It feels like the platform is slow while swapping windows. Tag overlays always takes 2-5 seconds to go “normal” after window swap.
If I have a leased tag groups with 2 sec driven class and 60 sec when not in fast mode. Should not the quality overlays when opening a window all be “normal” to begin with, given that all tags has been updated the last 60seconds?
Moreover, I have a template which shows around 30 states from a PLC (multistate indicators). This template uses indirect addressing based on an input “UdtAddress” .When changing the address for the template (actually swapping the PLC behind the path), all indicators loads for 2-5 seconds before updating with the new tag values.
This should not have anything to do with the tag setup right? (I am running OPC tags, through a FT Gateway server.) I expect my remote tag providers to always deliver “normal” quality data to the Front End vision server.
Thanks, i know about that one. It is not the best solution, but i get your point. Guess one could set ‘system.tag.setOverlaysEnabled(0)’ wait 5 sec then ‘system.tag.setOverlaysEnabled(1)’.
The main problem i guess we have(my and your company) is that the Ignition tag database is to slow relative to the vision module.
How crazy is to expect that a Vision-window, with 20 integers, would open with good data within 500ms!
Please email support@inductiveautomation.com, reference this forum post, and provide a copy of your project, or message me directly with a project export.
The changes in 8.0.10 directly affected how expression bindings evaluate on initial window open. Before these changes, expressions would evaluate with bad quality if referencing any tags, since the tag value would be null during first execution. These evaluations will now return an uncertain initial quality (rather than bad) if the initial tag value hasn’t yet been returned from the gateway, and then once the value is returned, will execute again with the proper value / quality. The unknown qualities shown (gray overlays) when toggling between screens is currently intended behavior to show that the tag value has yet to be initially returned from the gateway. There shouldn’t be any bad quality (red overlays) shown on window open unless the tag / binding is in fact bad.
I think I have managed to further specify the issue:
The problem is that sometimes and randomly, an icon of unknown quality appears in some templates.
This problem seems to be associated with the properties of the controls that are bound (property binding) with some tag (such as the “background color” of a button that is contained in the template).
In the designer, when I run “Run diagnostics” on the instance of a template, I can see the following:
Hi Kurt, am I right to assume the following: If we had red overlays before the “fix”, then best case scenario now is that the overlay is now white instead?
I mean, why do we have to wait more than one second before any overlays are gone when all tags are available on the tag providers? What is the reason for the delay?
