Do clients store and cache a local copy of tag values? When I read a tag in a gateway tag provider from a client (ie via system.tag.read()) does that request go all the way to the gateway each time? I know that the client polls the gateway for tag values and such at an adjustable polling rate. When I read a tag value will the script wait until a fresh value is received from the gateway or return a locally cached value?
It goes to the gateway if it’s not a client tag.
What if the tag is in a leased scan class with the slow rate set to zero? The gateway may not be actively polling the tag if it’s not visible in any client window. Will the script then wait for the gateway to fetch a value from the OPC server?
Does the client polling rate only apply to tag values that are bound to window components?
There’s no client polling of tags. Tags being read through the binding system are subscribed from the gateway, and the gateway sends change notifications to the clients. No change, no comms traffic.
system.tag.read() and friends make a round trip to the gateway to get the latest value of the tag, and will not cause an OPC read. The script function access doesn’t count as a lease for triggering a faster read pace. Only the binding subscriptions count as a lease.
Kinda true. It is a “subscription” and only changes are sent, but it’s purely polling based, and the polling happens whether you’ve got values changing or not (because… it’s polling, there’s no way to know). The client poll rate setting effects the rate at which this occurs.
As for when you system.tag.read() an OPC tag in a leased scan class with 0 slow rate while it’s currently not leased… I’d assume you get the last value it had. If you want it to go to the OPC server then use system.opc.readValue().
Still confused here… If it’s a subscription then there is no need for polling and vice versa. What, more precisely, is happening at the poll rate?
Changes are not sent from gateway to client unsolicited. Comms between client/designer and gateway are HTTP-based. The gateway is aware of the tags the client is interested in (the subscription).
At the poll rate, the client continually asks the gateway for any values in its subscription that have changed.
Huh. I thought the connection to the gateway used websockets to upgrade to an asynchronous bi-directional messaging connection. /-: