Troubleshooting WinCC V6 Inactive Analog Tags on S7-400 Systems

1. Problem Overview

After an uncontrolled shutdown of a SIMATIC S7-400H redundant station (CPU 414-4H) communicating with a WinCC V6.x runtime station over Industrial Ethernet through a CP 443-1 and a CP 1613, operators report that specific faceplate controls become unclickable (start/stop for two pumps and the agitator) and one analog value (total flow) renders in gray (no value, no limit supervision). All other process tags continue to update at their normal 1 s/2 s cycle. The S7 connection in the WinCC Channel Diagnosis remains OK and no CPU fault LED is lit. This combination is characteristic of a corrupted or detached tag binding in the WinCC project, not a PLC-level fault.

The phenomenon is well documented in field service: a small set of WinCC tags lose their external link to the S7 data block, while the S7 connection, the CPU, and the I/O remain fully healthy. The symptom survives a WinCC runtime restart, a project reactivation, and a redundant CPU fail-over, which is the definitive fingerprint of a project-side binding defect rather than a hardware or firmware fault.

2. Reference System Configuration

3. Root Cause Analysis

Three root-cause families explain the field report. They are listed in the order they should be ruled out, since the cost of verification rises from top to bottom.

3.1 Corrupted WinCC tag binding in the graphics designer

The WinCC Graphics Designer stores tag references as numeric internal pointers (the variable ID) inside the picture file (.pdl). If the runtime crashes, the PC loses power, or the WinCC project database is closed abnormally, the pointer-to-tag mapping in PROJECTNAME.dcf can desynchronize. The faceplate still references an ID, but the ID no longer resolves to the same S7 address — or to any address at all. The tag appears in gray because the dynamization in the picture evaluates to "no value" and the picture-level authorization/quality check suppresses the button.

This matches the field pattern: a handful of tags lost, every other tag still updates, communication tests pass, and the project is otherwise functional. Service experience (e.g., the long-standing WinCC V6/V7 behavior reported by integrators) shows that recreating the broken tag resolves the binding permanently.

3.2 Wrong WinCC project assigned to autostart

On Windows startup the WinCC service launches the project listed in AutoStart of the WinCC Explorer. If a different project, a backup copy, or a partially restored project is registered, runtime will use a configuration that does not contain the affected connections. Tag IDs that existed in the original project but not in the autostart project will render as gray. This is the second hypothesis raised during the original field discussion and is quick to check.

3.3 Incomplete user program / dead battery on the CPU 414-4H

On the S7-400H, two backup batteries (one per sub-rack) maintain the retentive bit memories, timers, counters, and the data block contents. A power loss with exhausted batteries wipes DBs that are not marked Non-Retain-protected. The WinCC tag remains valid but reads back zero or undefined values, which the faceplate may interpret as "quality bad" and gray out. The discussion on this exact plant confirmed batteries are healthy, so this branch is closed, but it must still be ruled in/out on every new instance of the symptom.

4. Pre-Diagnostic Checklist

1. Confirm the WinCC PC time and the CPU time are within ±5 s. Time jumps of hours after a power loss can cause the WinCC license dongle or the project to refuse activation silently.
2. Open WinCC Explorer > Channel Diagnosis and verify the S7 channel reports Connected for every configured connection.
3. Open WinCC Explorer > Tag Management and sort the affected tags by Quality Code. A persistent 0x80 (Bad / Configuration Error) rules in favor of a binding defect.
4. From the WinCC PC, ping the CP 443-1 (H1 IP address) and the active CPU's H1 IP. Loss of ping on one CPU but not the other is normal during H sync; loss on both is the problem.
5. In STEP 7, go online with both CPUs (CPU 414-4H > H-Sync) and read the diagnostic buffer. Look for SF / BF / OB85 events following the power loss.
6. Check the WinCC project file's modification timestamp against the backup. If it was modified during the power loss, restore from a known-good backup.

5. Step-by-Step Resolution

The procedure below is ordered from least invasive to most invasive. Each step ends with a verification gate; if the gate fails, proceed to the next step rather than continuing to apply partial fixes.

Step 1 — Verify the autostart project is correct

1. On the WinCC PC, open Start > Programs > Siemens Automation > SIMATIC > WinCC > AutoStart Manager.
2. Confirm the project path matches the expected runtime project.
3. If multiple projects are listed, disable the wrong one and enable the correct one.
4. Restart the WinCC Runtime from the system tray icon.

Verification: The four gray controls become active. If not, proceed to Step 2.

Step 2 — Compare offline and online STEP 7 project

1. Open STEP 7 and connect to the H-station via the H-Sync partner address.
2. Select PLC > Compare Online / Offline for both CPUs.
3. If the online program differs (DBs missing or with different initial values), download the offline program to both CPUs in RUN mode if the CPU supports it, otherwise in STOP.
4. Verify that the data blocks containing the pump command words (DBxx.DBD0, DBxx.DBX4.0, etc.) and the total flow (DBxx.DBD12 as REAL) match the WinCC tag addresses.

Verification: In WinCC Tag Management the affected tags report Quality Code = 0xC0 (Good). If not, proceed to Step 3.

Step 3 — Force a WinCC project reactivation

1. Stop the WinCC Runtime.
2. Open WinCC Explorer > File > Open and select the runtime project.
3. Select File > Reactivate Project from the menu. This rebuilds the runtime database from the picture files and tag definitions.
4. Wait for the activation log to complete with no ERROR lines (warnings about deprecated tags are acceptable).
5. Start the WinCC Runtime.

Verification: Re-check the four tags in Tag Management. If the defect persists, proceed to Step 4.

Step 4 — Delete and recreate the affected tags

This is the field-proven last resort for binding corruption. It is invasive because the tag ID changes, so all picture references must be remapped.

1. In WinCC Explorer > Tag Management, locate the four tags (e.g., CMD_Pump01_Start, CMD_Pump02_Start, CMD_Agitator_Start, TotalFlow).
2. Export the tag definitions to a CSV via Export > Tags for documentation.
3. Delete the four tags. Accept the warning about picture references — they will be relinked in step 5.
4. Recreate each tag with the same S7 address, conversion (BYTE / INT / REAL), limits, and scaling. For the total flow as REAL, verify the Length field reads 4 bytes and the conversion factor matches the engineering unit (e.g., m³/h = raw × 0.1).
5. Save the project.
6. Open every picture that referenced the deleted tags. The reference will show ??? in the right-hand Tag column. Re-select the newly created tag of the same name.
7. For dynamic dialogs that used the tag, reopen the dialog and re-bind.
8. Reactivate the project (see Step 3).

Verification: All four controls are now active; start/stop commands change the bit in the DB within one scan; the total flow value updates and color-codes correctly against its limits.

Step 5 — Replace the CP 1613 driver binding (only if Steps 1–4 fail)

1. Open Set PG/PC Interface. Confirm the access point S7ONLINE points to the CP 1613 driver, not a softnet or TCP/IP fallback.
2. If the binding flipped to a TCP/IP softnet during the power loss, restore it to CP 1613 ISO Ind. Ethernet.
3. Re-establish the S7 connection in Set PG/PC Interface > Diagnostics. The connection should report Online and the partner should be the active CPU 414-4H.

Verification: A bulk read of any DB from the partner CPU returns consistent values.

6. Hardware Health Verification (S7-400H Specific)

Even when the binding is the prime suspect, the underlying hardware must be confirmed healthy to prevent recurrence.

7. Connection and Tag Parameter Reference

For a CP 443-1 ↔ CP 1613 ISO-on-TCP WinCC channel, the following connection parameters must match on both sides. A mismatch is another common cause of "communication OK, but specific tags gray."

When the CPU 414-4H is in H-synchronization, only the master's connection is normally active. The WinCC connection can be configured to the master (IP-A) or to the H-Sync partner address (IP-B); the runtime handles the failover automatically provided the H-Sync Partner Address parameter is set in Set PG/PC Interface or in the WinCC connection editor.

8. WinCC V6/V7 Tag Quality Code Reference

A sustained 0x80 on only four tags is the diagnostic fingerprint of a binding defect. The fix is Steps 3 and 4 above.

9. Faceplate Authoring Pitfall that Mimics This Fault

When authoring or modifying a WinCC faceplate, an Indirect Tag dynamization (e.g., for a template instantiated with a structure prefix) can lose its base pointer if the structure definition is renamed. The faceplate then evaluates to "0" and the button logic gates itself out. Verify in the picture's Properties > Events dialog that the variable is the correct structure element (e.g., STRUCT.Pump01.CMD_Start) and not a stale internal tag.

If the faceplate is a user-defined type, check that the Type in WinCC Explorer > Graphics > User-Defined Types was not duplicated. Duplicate type IDs can map to wrong instances after a reactivation.

10. System Diagnostics for Future Prevention

To detect binding drift before operators see gray buttons, configure a WinCC diagnostics indicator on a status page and dynamize the color from a script that polls the four critical tags once per second. Green if all four are 0xC0, yellow if any are 0x80, red if any are 0x00. Siemens documents this approach in the System Diagnostics in WinCC Unified manual. While that reference targets WinCC Unified, the same pattern is implemented in WinCC V6/V7 using the WinCC Tag Simulator and a small C-script that writes to a status tag.

Complement the SCADA-side check with a CPU-side heart beat: in OB1, write a free-running counter to a DB (e.g., DB99.DBD0 = MW100 incremented every scan). Configure a WinCC event-triggered read of this counter; if it does not change for 10 s, raise a non-acknowledging alarm. This isolates CPU hangs from binding defects.

11. Troubleshooting Matrix

12. FAQ