We have a set up of a couple of cloud hosted gateways, and then some local ones doing the PLC comms and contextualisation. Our central gateways run a few timer scripts to read the values of some tags to then trigger various actions.
Recently we have been getting quite a few network issues causing the gateways to have higher ping than usual between them and these timer scripts are spiking up to 45 seconds (usually less than 100ms) it would appear the 45 seconds is caused from a tag read, in the user manual the default timeout is 45 seconds.
Whats interesting is the missed/slow pings aren't enough to cause a gateway disconnected event yet the tag reads are still timing out. I would have thought if the gateways were still connected and I do a system.tag.readBlocking on the central gateway, would it not just use the tag value as the central gateway currently knows it to be?
That's interesting, so I guess when you open the tag browser in the designer and you get the delay, that is then the central gateway internally doing a read to those tags. Tthat then brings into question the effeciency of what we are doing, currently we have a 1 second timer script that bulk reads the tags, checks for changes and then eventually bulk writes the ones required.
This is to get around the inability to add tags to the built in tag change gateway events via a script, but I am beginning to think there may be a more effecient way. Based on what you have said I wonder how the gateway tag change event scripts work under the hood, are those listed tags then always subscribed? I guess they must be.
We are using the gateway network with remote tag providers if that makes a difference