Has anyone had an issue where templates do not fully load in perspective? The first request to a page seems to always leave 1-2 templates showing null data then on the second request the page loads fully. Has anyone else had this issue and if so was there a fix?
What version are you on?
I assume by "template", you mean embedded view. How many embedded views are on there on a single view, and are there multiple levels of nesting? If so, how many?
Is there any thing in common with the views that show this issue? Similar device, level of nesting, etc...
We are on the latest Ignition release.
Yes by template I meant embedded view. There are 2-3 levels of nesting in most embedded views and 10-20 embedded views on any given page.
Most of the components in our pages are embedded views with the exception of buttons / labels to control (start/stop/safety reset) our equipment / devices.
Thanks for the quick response.
This is the kind of thing our support department would like to hear about.
The same is happening with 1 of our customers, but this is not happening in all the perspective clients, but in some. Normally the template load time is about 1-2 sec and then automatically loads the correct values.
In the case for clients that this automatic upload is not correctly working, the user must press F5, and then the templates load correctly. Any remarks on why this could happen?
Ignition Version is 8.1.24
After speaking with support the issue seemed to be too many layers of embedded views. They recommended 1-2 layers of embedded views and this seemed to fix the issue.
Lots of nested Views can also significantly increase initial loading times. As support said, I try to limit mine to 1-2 nests
Ignore the dodgy graphics, purely for testing only, but this is a comparison I did of loading times of embedded views without any nested views compared with one with at most 3 or 4 levels. The proof is in the pudding and it's insane the difference. PS this was done in August 2022 and improvements have been made since then to page load times.
I am having the same issue right now and am wondering what you did to make them load more accurately? I was able to get them to load faster by converting my template views to Flex Containers but am still having issues with them loading incorrect values.
Not loading the bindings correctly usually only occurs when you have a number of levels of nesting of embedded views. Is this the case for you?
We decreased our level of nested views and that fixed the issue.
This sounds like you may have some issues with persistence. If you load values into parameters in the designer and they are set to persist they will load that data initially and then once the parameters are changed they will then load the correct data afterwards. I typically try to keep my parameters clean and have some labels and things to say "No Params selected" or whatever the right thing to say might be.
That's what should happen, but for deeply nested views, more often that not, some will not ever set up the binding correctly in the client and will therefore not receive any further updates. It only happens with deeply nested (ie usually 3+) views. Regardless of persistence setting. If persistence is off, you will see a null for these values. The only way to resolve this at this stage is to remove the extra nesting levels
The way properties are passed into embedded views is interesting, it happens entirely on the client. Most importantly, bindings do not traverse the boundaries of a view.
Passing parameters to an embedded view requires a back and forth between the gateway and the client:
Views have tons of features, and all those features add up to a slow-ish startup while syncing with the client. Which is totally fine for complicated UI's where you're doing bindings, scripts, actions, etc, but incredibly overkill for "template-like" things (embedded views for displaying custom icons, P&ID shapes, etc).
It'd be interesting to see what could be done with a resource that is lighter-weight than a view, something closer to a component. No access to anything beyond the props passed in, and some version of bindings/expressions that run directly in the client.