OPC Tags Frozen but Connected: Fix Schneider and GE Data Stalls

The link light is green. The tag is dead. Here is how to chase missing data before you blame the network.

Why can OPC tags freeze while the connection stays healthy?

An OPC server bridges the PLC to SCADA, HMIs, and historians. A healthy connection status confirms a channel is reachable, not that every item is receiving fresh data. A tag may retain its last value or show stale or bad quality when its address, scan settings, subscription, or PLC communication load is wrong. Start with the affected tag's quality and timestamp, then compare it with a known changing PLC value.

Could the PLC address mapping be wrong?

Yes. PLC edits can move variables, shift array indexes, or change data types while OPC item definitions still point to the old location. Compare the PLC tag table and OPC item list side by side, including the exact address, register or data block, element index, and type. For a Schneider Modicon M340 processor exposed through Modbus TCP, check the device memory map and how the OPC driver translates %MW, %M, or %Q references into its own addressing scheme. Do not assume an offset is unchanged after a program revision.

Test with an approved, safely changing PLC value and watch the matching OPC item and timestamp. If the PLC value changes but the OPC item does not, verify the mapping and driver configuration before replacing cables.

Can scan rates or subscriptions make tags lag?

Yes. Aggressive polling or a crowded subscription can cause delayed or skipped updates even while the session remains connected. Compare the requested scan rate with the server's actual update rate, queue behavior, and the PLC's response time. Group tags by process need: a slow temperature might use a 1000 ms interval, while a faster signal might require 200 ms if the controller and application support it. Validate timing against process requirements rather than treating these example values as universal settings.

For OPC UA, check revised sampling and publishing intervals, monitored-item status, and queue settings. Where suitable, use a deadband to reduce unnecessary change notifications. For OPC DA, review group update rates and item quality. Retest the affected tags after each adjustment.

Could too many clients saturate PLC communications?

Yes. SCADA, HMIs, historians, engineering laptops, and maintenance tools may all poll the same PLC. If communication capacity is strained, some item reads may time out or arrive late. Check active client connections, driver diagnostics, device response times, and retry counts. Remove redundant polling where possible and retest under normal load. A Schneider M340 Ethernet communication module is one example of the communication hardware whose diagnostics may help identify bottlenecks.

On a GE Fanuc / Emerson PLC platform, check the actual controller, OPC server, and driver documentation for supported connections and diagnostics rather than assuming all generations expose identical OPC UA capabilities. If an OPC UA session stays connected but monitored items stop updating, inspect subscription status, keep-alives, and security or certificate events. Re-create the affected client subscription when appropriate, then confirm that the item quality and timestamps recover.

What should an engineer check first?

Trust quality flags and timestamps over link LEDs. First compare the OPC item with its PLC source address and data type. Next check actual scan or subscription rates against the requested rates. Then measure PLC communication load, timeouts, and retries. After resolving the fault, keep a verified copy of the OPC item list under change control and reconcile it after PLC edits.

Author: Liang Weiguo is an industrial automation engineer with over 10 years of experience in PLC, DCS, and control systems.