OPC Server Connected but Tags Frozen: A Field Fix Guide for Allen-Bradley and Emerson Systems

Why a Green Connection Lies

The Inst Tools article "OPC Server Connected but Not Updating Several Tags" starts with a scenario every engineer dreads. The OPC server shows a healthy connection. However, several tags sit frozen at their last value. The channel is alive, yet real-time data flow is partially dead.

I have chased this fault three times in the last five years. Each time, the network team declared victory first. The real cause sat in tag configuration, scan rates, or PLC communication load. Therefore, treat a green connection as one data point, not a diagnosis.

The article lists eight causes. First, PLC address mapping mismatch after program changes. Second, scan rate and subscription misconfiguration. Moreover, it covers PLC communication saturation, deadband filtering, device group faults, cache refresh failures, conditional PLC logic, and network packet fragmentation. That list matches my field experience almost exactly.

Root Causes Ranked by Field Frequency

• Address mapping mismatch: PLC code changes move variables. The OPC server keeps polling the old, dead address. Tags freeze at the last value.
• Scan rate overload: Aggressive polling, such as 100 ms on 5,000 tags, overflows server and PLC buffers. Some updates get skipped.
• Deadband filtering: Analog values change less than the deadband, so the server never publishes them. A 1% deadband on a 4-20 mA loop hides small moves.
• Device group faults: One wrong rack, slot, or IP setting freezes only that group. Other groups keep working, which misleads you.
• PLC comm processor saturation: Too many clients, including maintenance laptops, starve the comms CPU. Reads queue and drop.

Moreover, check the PLC program itself. Some variables only update when a sequence step or machine state is active. Finally, remember packet fragmentation. Huge block reads can fragment and arrive late, breaking individual update cycles.

Allen-Bradley Case: ControlLogix and EtherNet/IP Limits

We hit this fault on a water treatment plant. A ControlLogix L83 fed a Kepware OPC UA server over EtherNet/IP. After a program update, 40 flow tags froze. The connection stayed green.

1. Step 1: Open the OPC test client and read the tag quality. Stale values with good quality point to the PLC side. Bad quality points to the server side.
2. Step 2: Export the PLC tag database and diff it against the server address map. We found a UDT restructure that moved flow tags to a new data block.
3. Step 3: Check CIP connection counts. ControlLogix Ethernet modules support a limited number of forward-open connections. Our third SCADA client pushed the total over the limit.
4. Step 4: Tune the scan rate. We moved slow-moving analog tags from 100 ms to 1,000 ms. CPU load on the OPC server dropped by half.
5. Step 5: Force a full tag rescan after every PLC download. Reboot the affected device group, not the whole server.

However, do not skip the simple check. Verify the PLC actually writes to those addresses during the current state. Therefore, watch the value in the programming software first. Ten minutes there saves ten hours in the control room.

Emerson Case: DeltaV OPC and the Deadband Trap

An Emerson DeltaV system feeds OPC DA clients through its built-in OPC mirror. After a historian upgrade, operators reported slow-updating temperatures. The controller data looked fine in the operator display.

1. Step 1: Compare the live operator value against the OPC client value. A constant lag confirms a server-side filter, not a controller fault.
2. Step 2: Check the deadband setting on the client subscription. The upgrade had reset it to 2%. Temperature loops moving slowly never crossed the threshold.
3. Step 3: Reduce deadband to 0.2% for critical analog tags. Keep 1% or higher for high-noise vibration and pressure signals.
4. Step 4: Review the DeltaV OPC subscription rate. Match it to the module execution rate, typically 1 to 5 seconds for process loops.
5. Step 5: Document every deadband exception. Undocumented filters will haunt the next engineer during a trip investigation.

Finally, test the fix properly. Force a manual step change in a test area. Confirm the OPC client value follows within one scan cycle. Therefore, you prove the full chain from controller to client.

Conclusion & Action Advice

Frozen OPC tags with a green connection are a configuration fault, not a network fault. Therefore, build a standard response. First, check tag quality in a test client before touching anything. Second, diff the PLC address map after every program download. Third, audit scan rates and deadbands against the process dynamics. Moreover, count your CIP connections and client sessions before adding hardware. Finally, add a stale-tag alarm to your SCADA. A tag that has not changed in two scan cycles should page someone. Trust in your data is built one stale tag at a time.

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