Tag Read on remote tag provider behaviour

Ignition
1

Hi,

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?

2

If nothing is bound to a tag in central, it won't be subscribed from central to edge. So the central gateway would not have the current value.

3

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

4

The more efficient ways (I'm partial to the BulkScript Tag Action from my Integration Toolkit) only work on the source gateway.

So yes, doing this in the central gateway is sub-optimal.

FWIW, my Toolkit also has a tags() expression function that you could use on an expression tag in the central gateway's local tag provider. Have a dataset memory tag adjacent to it that contains all of the remote tag paths for which you wish to maintain subscriptions. Perhaps one of these per remote tag provider.

Your scripts would then grab the desired current values from the expression tag's dataset, instead of reading the individual remote tags.

5

I'm at a bit of a loss here with the way things are worded.

You have a scheduled timer script on the central gateway that is calling a script, and that script is issuing tag reads to the remote gateways?

You can specify a timeout on the tag reads within the call.

TagList = ['[RemoteTagProvider]PathToTag1','[RemoteTagProvider]PathToTag2']

readResults = system.tag.readBlocking(TagList,5000)

We do this kind of thing a lot, and we will do some quality checks like

  1. Is the Gateway connected
  2. Check the quality return of a single tag read.
  3. If both are good, we then issue the bulk reads specifying a short timeout.
  4. If the read goes through, we then write out to the database(s)

We never have issues with stale values, so not sure where the subscribed portion comes into play?

6

I did a test after @pturmel's reply, if I am on the central gateway and try and read a tag from a remote gateway, but set the timeout to 80ms, it will never read that tag before the timeout has expired. However if I read a system tag such as gateway name, it will read the value of that consistently with the timeout set at just 30ms.

Over the years I have always assumed (wrongly) that the edge gateways were sending all tags to the central, where it would then store a copy of the latest value. So whilst the tag values may be out of date by 1 second (remote gateway comms rate) I'd always thought reading that tag would be just as performant as a read on local but possibly slightly out of date.

However it appears that when you do a read on the tag it's actually reading over the gateway network and not a cached version on the central gateway.

Post was for more my own understanding of the inner workings, I'm sure if I have been of that assumption, then others would be too. It's good to know and be able to factor it into future decisions.