Executive Summary: The time to open a vision display seems to scale linearly with the number of template parameters connected to UDTs from remote tag providers.
Scenario: Ignition on a remote industrial computer communicating over Gateway Network using a cellular connection. Ignition running on a VM in the cloud, with no visualization on it. I started a project to add the vision displays to the cloud Ignition (for redundancy). Export project from a remote computer, import to cloud Ignition using the remote tag provider for the corresponding remote ignition as the default tag provider.
On the cloud ignition designer, these are the opening times for the display as a function of how many tag paths added to template parameters:
0 15secs
1 21secs
4 38secs
8 56secs
Iām not a crazy person, I didnāt start by re-binding templates and timing openings. I did that experiment after I did a bulk find and replace, and it took 4 minutes (not an exaggeration) to open a display in the designer. So, I started over to do different things to isolate the issue. The best I can tell, the only factor that makes a difference is the number of remote tags used on the screen.
Additional Info:
All templates are parameterized with tag paths.
The UDTs have 20-40 āsubā tags
Ignition Version: 8.0.17
The cellular connection is strong
I removed all gateway scripts from the cloud ignition
I do have a ticket in with support and theyāve taken logs, etc. Very appreciative for that help, but no immediate solution, so I thought I would open it up for to see if anyone had any experience with this issue.
Iām not sure this behavior is that surprising. UDT parameters, by definition, have to ālearnā their structure from a tag definition. As an educated guess, thereās probably a linear process happening on window initialization where each component gets constructed, including custom properties. Each of those custom properties that has a UDT type has to fetch its type information, which would be a distinct call to the remote provider.
It would obviously be more efficient in terms of network traffic to fetch these as a single call, but I think that would involve some fairly significant refactoring of how Vision windows start up to make it more āasynchronousā, which is a fairly dangerous proposition in terms of regressions.
What might be more feasible would be to ācacheā the UDT type information in the property, serialize it with the window, and then reconstruct it ālateā after the window has already been built in the client. That has its own risks (what happens to bindings if the cache disagrees with the current UDT?) but that could technically already happen, so it may not be a big issue in practice.
Disclaimer: As I stated, this is all an educated guess; I havenāt actually read through the code to confirm it, but thatās my hunch. Weād have to mock this up internally to confirm the source of the slowdown. If you tell your support rep to get in contact with me, I can help them get a ticket filed internally for the reproduction effort.
For posterity: in 8.1.18 this should perform somewhat better.
The slow part here isnāt actually the binding (which is truly asynchronous) but the fetch of the remote tag providerās type definitions for custom properties.
There was already a transparent cache in place, but it had a fairly aggressive timeout (10 seconds) which was increased to 30 seconds.
Further, the actual fetching of type information is now attempted in bulk, pending organization of components. That is - component/root container/template A can have as many parameters with user defined types as it wants, and if they arenāt already in the cache theyāll be fetched in a single call. However, any other component will not be ārolled upā into that fetch (though its request would still go through the cache).
For that reason, the most performant advice would be to have every UDT parameter on the root parameter of your window. If you have many template instances (with many distinct UDT parameter types) you may benefit from āseedingā the cache by manually defining a UDT type parameter on the root container for each type used in templates on the window. However, this will be highly situational, dependent upon your network, window layout, etc.
Pssst! Just say no to UDT parameters! Indirect tag binding for the win!
1 Like