I have an Ignition Edge instance as a remote gateway to our main Ignition Gateway (cloud-based). Driven Scan classes et al, are all well and good - but I must be missing something! I want to reduce the update time to the main server NOT the local Vision client which is running as the operator’s HMI. The biggest reason for the remote connection is to utilize our full Ignition instance and it’s associated SQL server for historizing the data at the Edge. We would run a Vision client from the main Ignition Gateway only in the case of remote support. So, as far as I can tell, when I change the scan class of a tag to a slow rate of 60 seconds, for instance, I’m changing it locally as well. Is there a separate spot to set the update rate on the Outgoing Connection in the Gateway network??
Ideally, I would have one very slow update rate to the main Gateway (and a relatively slow rate for the historical scan class) and have the local operator press a button that would trigger the driven scan class on the outgoing connection up to a relatively high speed when they wanted us to remote in and help them out.
Any insight (or directions to the appropriate section of the manual) would be appreciated!
I had the same issue in your linked discussion.
I noticed the same thing that when I changed the scan class it changed the update rate on both the local vision client and the main Ignition gateway.
I am trying to limit communication to the main gateway to keep it from hogging the DSL connection that it is on. I currently have the scan classes set to values that are acceptable to both but not ideal for either.
Unfortunately, right now there is no separate timing settings for remote gateway communication. It queues up changes as they occur, and tries to deliver them as quickly as it can. I don’t think it would be too hard to add some sort of “max update rate” somewhere that let you specify a slower rate… though anything more complicated than that (driving it based on some condition, etc) might be tricky.
Mainly I wanted to confirm that you’re not missing anything- all of the timing settings (driven scan class, etc) are related to changing the rate at which the actual tag changes. The remote subscriptions just run directly against the tag, forwarding the changes on.
The MQTT Transmission module might be more appropriate in this case, or provide more options. I am interested in improving the range of functions the remote tags offer for this, but I can’t say when we’d be able to get something in.
From the outside looking in, I was expecting to find some such settings in the Outgoing Connection page on the Edge product, similar to the settings there for Historical sync.Since this is what Edge Enterprise is for (connections to a main Gateway) I would expect some control over what and how often tags are synchronized. By that I mean I would expect that in addition to either separate scan classes or polling rates for Connections, I’d also like to be able to pick which tags are sync’d.
Edge of network devices are often going to be a cellular connection and everyone needs to keep their phone bill down to a dull roar. SO, if Edge Enterprise is supposed to “bring Igintion to the Edge” then I would certainly expect to see a bit more granularity as it matures.
As I think more about it, - and I’m a long way from being a developer, so I’ve no idea if this is feasible - but it might be easier than fooling around with the Gateway connection itself… BUT
If you could pick which tags are subscribed to, (or “synchronized”) then you could set those tags being sync’d to a different, slower, scan class. If you needed a tag in both camps, just make a duplicate tag as an expression tag with the root tag as the exp value. Then you could put one tag in each scan class.