The engineer sees a one-second central timer normally complete in under 100 ms, then occasionally block for about 45 seconds while reading tags through a remote tag provider. Follow the packet: the central gateway does not necessarily hold a current value merely because its gateway-network connection remains up.
Where does a remote tag-read request travel?
The caller is the timer script on the central gateway. A path such as [RemoteTagProvider]PathToTag1 selects a provider hosted through another gateway, so the request must cross every layer between the script and the PLC-facing gateway.
| Hop | Function | Failure indication |
|---|---|---|
| Central timer script | Calls system.tag.readBlocking and waits for results |
Script duration rises to the read timeout |
| Central remote tag provider | Routes the tag path toward the provider gateway | No locally maintained value when nothing has subscribed to the tag |
| Gateway network | Carries the request and response between gateways | Latency, loss, or retransmission delays the individual transaction |
| Local gateway and tag provider | Obtains the tag value and quality from the PLC communication side | Slow or failed downstream access prevents a timely response |
| Return path | Returns values and quality codes to the central script | The blocking call remains incomplete until a response or timeout |
Layer one comes first. Check the physical and routed path before changing script logic: interface state, link errors, packet loss, latency in both directions, and congestion along every hop. A ping samples reachability; it does not prove that a separate application transaction completed within its deadline.
Which remote-tag strategy fits this case?
| Approach | Traffic behavior | Response to a network disturbance | Best fit |
|---|---|---|---|
| One-second central polling | Issues repeated bulk reads across the gateway network | A blocking call can occupy the script until its configured timeout | Small, intentionally polled sets where delayed data must be rejected |
| Source-gateway change handling | Processes changes where PLC communication and tag values already reside | Change detection does not depend on a central read completing | Actions that can execute on the source gateway |
| Persistent central subscription with a local cache | Maintains selected remote values and lets scripts read a consolidated local result | Scripts can inspect cached value quality without initiating an individual remote read for every cycle | Central coordination that genuinely requires remote data |
| Bounded central polling | Checks connection and one tag, then performs one bulk read with a shorter explicit timeout | Fails faster than the 45-second default and prevents one read from dominating the timer | Central logic that cannot be relocated or subscribed |
Move change detection to the source gateway when the required action can run there. It removes the gateway-network round trip from the detection path and avoids polling unchanged values every second. If central coordination is mandatory, maintain subscriptions for the required remote paths and expose a consolidated local dataset or equivalent cache to the central scripts. Use bounded polling only when each cycle needs an on-demand remote transaction.
Why can reads time out while the gateways remain connected?
Connection state and transaction completion answer different questions. A connected indication says the gateway session has not crossed its disconnection criteria. A tag read still requires a request, processing at the remote side, and a response before the caller's deadline. Intermittent delay or loss can disrupt that exchange without lasting long enough to declare the gateway disconnected.
The observed 45-second spike matches the stated default tag-read timeout of 45 seconds. That duration points to a request waiting for its deadline rather than merely executing slowly inside the comparison or write logic.
| Observation | Interpretation | Next check |
|---|---|---|
| Gateway connected; read takes about 45 seconds | The session stayed up, but the tag transaction did not complete before the default deadline | Read result quality and gateway-network diagnostics |
| Ping becomes slow or intermittent | The network path is degraded | Loss, interface errors, routing, and congestion on both directions |
| Nothing on the central gateway references the remote tag | No central subscription is maintaining that value | Bindings, configured event tags, or another explicit subscription consumer |
| Tag browser also pauses | The delay is in the remote tag data path rather than only in the timer's change logic | Compare browser and scripted-read timestamps |
A direct call to system.tag.readBlocking therefore cannot be treated as a guaranteed read of a central cache. If nothing on the central gateway is bound or subscribed to that remote tag, the central gateway has no continuously maintained current value to return.
How should the recommended design be implemented?
- List every remote tag used for change detection and group the paths by remote tag provider.
- For actions local to the PLC-facing gateway, configure source-side tag-change handling for the known tag list. Keep the comparison and resulting local action on that gateway.
- For actions that must remain central, create persistent references to the required remote tags and consolidate their values and qualities into a local dataset or equivalent memory structure. A script should consume that local structure rather than issue individual remote reads each second.
- When polling remains necessary, read the paths in one bulk operation and set an explicit timeout appropriate to the application's failure budget. The demonstrated form uses
5000rather than the 45-second default:
TagList = [
'[RemoteTagProvider]PathToTag1',
'[RemoteTagProvider]PathToTag2'
]
readResults = system.tag.readBlocking(TagList, 5000)- Before the bulk operation, check gateway connectivity and perform a single-tag read. Continue only when the returned quality is acceptable.
- Validate the quality of every bulk result before comparing values or writing to a database or another tag. Treat timeout or bad quality as an unavailable sample, not as an unchanged process value.
- Prevent a new one-second cycle from accumulating behind an unfinished blocking call. Confirm the timer's execution mode and record start time, finish time, result quality, and skipped-cycle behavior.
How do you isolate the failing hop?
- Timestamp the timer immediately before and after
system.tag.readBlocking. A roughly 45-second interval isolates the delay to the blocking read path. - Repeat with one remote tag and the explicit
5000timeout. Record elapsed time and the returned quality. - Compare a local tag read on the PLC-facing gateway with the remote read from the central gateway. A fast local read and slow central read place the fault between gateways; slow results at both locations move the investigation toward the local provider, driver, PLC link, or device.
- Observe the same remote path in the tag browser. A matching delay confirms that the behavior is not unique to the timer script.
- Correlate read timestamps with gateway-network diagnostics and network measurements. Check both directions because the request may arrive while the response is lost or delayed.
- After the physical path is stable, compare central subscription state. A tag referenced by no binding, event, or subscription consumer must not be treated as a centrally cached current value.
What pitfalls cause the delay to recur?
Do not use gateway-connected status as a data-quality bit. Do not accept the last application value after a failed read unless the control design explicitly permits stale data and exposes that state to downstream logic. Do not poll a large remote set every second merely to detect changes when the work can execute beside the source provider.
A shorter timeout limits blocking time but does not repair packet loss or create a subscription. Likewise, persistent subscriptions reduce repeated on-demand reads but still require quality and age checks during a network interruption. Keep value, quality, and timestamp together so central logic can distinguish a current sample from retained data.
FAQ
Can I make system.tag.readBlocking return in less than 45 seconds?
Yes. Pass an explicit timeout, such as system.tag.readBlocking(TagList, 5000). The call then fails faster, but the script must check every returned quality before using the values.
Does a connected gateway mean remote tag reads will succeed?
No. Connection state can remain healthy while an individual request or response is delayed or lost. Test the tag transaction and inspect its returned quality separately.
Can I read the value already known by the central gateway?
Only when a central binding or another consumer maintains a subscription or local cache for that remote tag. With no subscription, a blocking read must follow the remote data path.
Does moving tag-change logic to the source gateway remove the 45-second delay?
It removes the central remote read from the change-detection path. Verify the result by interrupting or degrading the inter-gateway path and confirming that source-side changes still execute while central logic records unavailable or bad-quality remote data.