We currently have two ignition servers running 8.1.35, one on site, and one in the cloud. These are connected via the Gateway Network, and the cloud server has a remote tag provider to the tags on the on-site server. This all works quite well.
We ran into problems though when another group wanted to poll our tags using Opc UA. They currently have access to the OPC UA server in the cloud, with the “Expose tag providers” option enabled so that they can see our tags.
Any tag provider running directly on the cloud ignition server can be seen with no delay and used easily. However, browsing tags on the remote tag provider often times out as they’re browsing. Is this a limitation of the combination of these two modules, or is something incorrectly configured? The ping times between the two servers are only about 40ms, so unless we’re getting a multiplication effect on that from too many round trips, I don’t think that is the issue. Ignition designers on the cloud server can also browse these tags with no issue at all.
As a test we had briefly opened up the local site through a tunnel and connected to it with Opc UA, and were able to browse its tag provider with no issues, but they didn’t want to leave that tunnel open long term.
It would be interesting to get a Wireshark capture of the OPC UA traffic between this other OPC UA client and the Ignition OPC UA server in the cloud. Without seeing exactly what service calls it's making and where it's timing out it's say if anything is wrong.
Ok, I’ll forward that along here and see about getting that wireshark capture from the person with desktop access to that machine.
It may require some coordinated configuration changes - it won't be a useful capture unless the connection is made without security enabled.
What client/software are they connecting with? Might also be useful to see if something like UaExpert can connect/browse without timing out.
UaExpert was one of the ones we were testing with, though it’s not the one they’ll ultimately be using, we were experiencing very long browse times with it as well on the cloud server, but fast when we connect remotely to the onsite.
It's definitely going to be slower than on site, doubly so because you're traversing two internet links. You're going client to cloud, cloud to remote site.
Exposed Tags exposing a remote tag provider without the extra cloud hops is already relatively slow.
But I still wouldn't expect to be seeing timeouts unless maybe the tags in your provider are organized relatively flat, with hundreds or thousands of tags directly under each folder level or something.
The UAExpert was slow even when running locally on the cloud server, as was the other application they were trying to run. I think they’re actually running it from a different VM in the same cloud for the final version.
Ah, yes, it is hundreds of thousands of tags, but they’re many levels of folders. Some folders have ~700-800 UDT instances, each with dozens of tags.
Can't really do anything but guess without some captures that show exactly what operations are slow.
Operations against exposed tag providers when the tag provider is remote are going to be slower, but again... depends what you're doing. Browsing will be the slowest by far, but that's the kind of thing you generally do up front during configuration. Subscribing to tag values once everything is configured should perform relatively well.
If you were e.g. just drying to drag and drop to browse and then subscribe to the whole thing... yeah that would probably time out.
Yeah, we can’t get the trace just yet since they’re actively working on the server, but once it frees up we’ll see about getting that.
And yes, we’re manly working on setting up the new software with the taglist they want, then from then on it will just resubscribe to those when it starts up, but configuring 750 tags took it 2 hours, and we’re currently trying to subscribe another 4000 tags and it’s 4 hours and counting. It crawls the entire tree looking for the UDTs specified, then subscribes to specific subtags of that UDT.
Oof, yeah, if you're recursively browsing an entire remote tag provider, especially one that has hundreds of thousands of tags, it's going to be sloooow.
The OPC UA address space for Exposed Tags is fully dynamic - Nodes don't exist in memory, every service call results in multiple calls to the underlying tag provider as it gathers all the information necessary to complete the service call. Browsing in particular requires multiple calls to the tag provider. In your case, each of these calls is to a remote tag provider over an internet link.
That’s kind of what I thought was the problem a bit. A lot of round trips between the two as it’s browsing. I’ll let them know, but will still look into if we can get you the wireshark if you still need it.