Hello everyone. Does anyone have any tips that will inform me on how to speed up loading screens and increasing display performance? Expression and indirect addressing objects seems like it takes forever to load and I am staring at a screen with error overlays. It looks pretty bad as you navigate from page to page. TIA!
@pturmel's points address improving performance. If Perspective, this method makes things look a lot better during navigation by hiding the invalid states while waiting for data to arrive:
Hey guys, thanks for the responses. I am using Vision. Will vision never look as good as perspective in terms of the error overlays then? I barely have any data traveling between the gateway and client, so I don’t think there is much to minimize.
A few things to note, don't use UDT parameters, many threads on this, here is one:
Also, I gave up on overlays. Even on the fastest window, I would always get flickering of the overlays. I turned them off during project load, I think it was system.tag.setOverlaysEnabled(0)
One method is to reduce the number of individual bindings that exist on a single page and package tags that are similar (and make sense to be put together) into a dataset and then make the binding the client uses to the dataset rather than each individual tag. Our architect compares this to moving sand with a bucket rather than one grain at a time.
No idea if this can help in your case, but it is something we use often.
{ I would expect that technique to have negative performance. The gateway collects tag changes that it knows a Vision client wants and delivers them in bulk at the client's poll rate. Delivering an entire dataset when not all elements change would significantly increase traffic. }
Since I received a “Ewww!” on my post I’ll add further qualifications to prevent being misunderstood.
A place we would use the dataset method would be on a screen that allows for viewing of all PLC I/O. In that case there can be 10k’s of tags and the most practical way to let the user see the state of any I/O point they want is with a dataset.
In any case, we would use it in places where the main source of consumption on the screen uses a table.
If data is not consumed using a table, other methods are probably better.
Thanks everyone. Is the overlay just something you have to deal with in ignition? I got that impression from other posts as well. Here is a video of some of the overlay lags:
We’ve dealt with this in Vision by delaying display (cover it with some form of loading overlay) for a bit to give time for bound data to arrive. This accomplished what we now use a delayed fade-in transition in Perspective for.
I think it depends on who you ask. IA has released fixes over time that was supposed to solve this, at least that is how they were advertised. But, in my experience none of the fixes actually fixed the overlay problem. As I mentioned earlier, I dealt with them by turning them off. I like the idea of having overlays, but not like how they currently behave.
Though I haven’t done this, turning off overlays for a few seconds on page load and then re-enabling them so configuration errors (as opposed to delayed data arrival) are shown might be a good solution.
Not sure what you mean here, but I like the thought of delaying the display. I will most likely try that as well, thank you.
@jlandwerlen I made a button that turns off the overlays after I read your comment above, so thank you. Though, with a product of this caliber I feel like this shouldn't be an issue to where we have to turn them off. Feels like a dirty fix on our end and we lose functionality because of it. Every screen has at least some overlays, making transitions between windows look pretty terrible at times.
@bmusson Agreed. And its happening on a standard template I am creating, before a large amount of tags even get put into the program. I’m scared to see how it looks when this HMI will actually have an assembly line being displayed on it.
I'm referring to a Perspective solution noted above before I realized this was for Vision:
In Vision applications, we cover up the screen with a loading layer that's visible for a bit on page load and then hidden by a script. We use a script like this in window visionWindowOpened event so we don't need to remember to save the window with loading mask visible in Designer:
And a script like this on the loadingMask component that covers everything else during load:
if event.propertyName == 'componentRunning' and event.newValue:
# Hide this loading mask when loading complete and this layer's (actually a group--groups used for layers) background is running.
def hideMask():
event.source.visible = False
system.util.invokeLater(hideMask, 0)