Vision Display using Remote Tag Provider, Displays Slow to Open

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