PCS 7 V9.1 SP2 Interlock Buttons Greyed Out on WinCC OS Clients

Problem Summary

In PCS 7 V9.1 SP2 plants configured with one Engineering Station OS (ESOS) running a WinCC Application and two operator stations (OS1, OS2) configured as WinCC Application Reference single-user projects, the motor faceplate Interlocks and Permissive buttons render correctly on every OS but remain greyed-out (non-clickable) on OS1 and OS2 even though they work normally on the ESOS. Buttons are visible, faceplate dynamic elements update, and the operator has full WinCC Administrator rights. This is a tag-linking and OS project-type symptom, not an operator-authorization failure.

Affected Environment

Symptoms vs. Root Cause Matrix

Root Cause Analysis

PCS 7 V9.1 SP2 faceplate buttons evaluate an enable condition that combines three signals:

1. The operator authorization level (User Administrator configuration).
2. The current state of the interlocking/permissive structure tags read from the AS.
3. The presence of a valid symbolic I/O binding between the faceplate's internal tags and the AS data block addresses.

When OS1 and OS2 are WinCC Application Reference projects, the symbolic tag binding is not the same as the ESOS binding. The Reference project must be able to resolve symbolic names back to its own AS program reference. If the Reference project is misclassified, or if the tag paths still resolve to the ESOS namespace, the runtime sees no valid tag link and the button is forced to a disabled state to prevent write attempts against a non-existent address.

Three independent root causes are common in this configuration:

1. WinCC Application Reference project mis-typed - the Reference was created/imported as a multi-user or server-style project rather than a single-user Reference.
2. Symbolic tag path drift - the OS Reference still references symbolic names generated for the ESOS compile pass instead of its own compile pass.
3. Server data not generated - the ESOS WinCC Application must produce server data (alarm/tag/text library export) that the Reference clients consume during their own compile. Without this step, the Reference clients fail to resolve the symbols and silently grey the controls.

Diagnostic Procedure

Run this sequence in order before applying any corrective action. Each step narrows the failure domain.

Step 1 - Confirm Operator Authorization

1. On OS1, launch WinCC Explorer > User Administrator.
2. Open the group assigned to the operator and verify level Operator (Level 4 - Process Controlling) or higher is granted. Interlock release typically requires level 6 (Process controlling - higher) depending on the APL block version in use.
3. Confirm the operator is a member of the group and that no Time zone / shift exclusion is active.

If the operator level is correct, proceed. If not, fix the level first - the greyed-button symptom can be reproduced purely by insufficient rights and would also affect the ESOS.

Step 2 - Inspect the Reference Project Type

1. In SIMATIC Manager, open the OS1 Reference project.
2. Select OS > Object Properties > Computer.
3. Verify Type of OS = WinCC Application Reference and Computer properties > Type = Single-user project.
4. If the type is Multi-user, Server, or Standby, this is the failure. Re-assign the project to a single-user Reference before continuing.

Step 3 - Validate the Tag Resolution

1. On OS1 in WinCC Explorer, open Tag Management.
2. Filter on the structure tag prefix used by the affected motor block (e.g., AS1_MOT_, MOD_, or the APL internal @-prefix family).
3. Confirm tags exist and are linked to the correct AS channel/unit.
4. If tags exist only under an ESOS_ namespace, the Reference is still resolving against the ESOS project. This is the symbolic path drift root cause.

Step 4 - Check Server Data Generation on the ESOS

1. In SIMATIC Manager, navigate to the ESOS under the plant hierarchy.
2. Right-click the WinCC Application node under the ESOS computer.
3. Confirm the action Generate Server Data is greyed out (meaning it has already been run) or click it and let it complete. The action writes the *.rcp server data files that WinCC Application Reference clients depend on.
4. If Generate Server Data was never executed, the Reference clients cannot bind symbolic names. This is the third root cause.

Step 5 - Check "Allow Runtime on ES"

1. On the ESOS, open WinCC Explorer.
2. Right-click the project root and select Properties > Options.
3. Confirm Activate Runtime on Engineering Station is enabled. Without this flag, the ESOS compile pass may produce a partial tag set that does not match the OS Reference compile pass.

Solution - Method A: Correct the OS Reference Project Type and Re-bind Tags

1. Delete the existing OS Reference projects (OS1, OS2) from SIMATIC Manager.
2. Reinsert each as New Object > OS > WinCC Application Reference (Single-user).
3. Assign the correct AS program reference per the AS-OS assignment table for the plant.
4. Open each Reference project and verify Tag Management > S7 Channel > Connection points to the correct AS and not to the ESOS.

Solution - Method B: Generate Server Data and Recompile References

1. On the ESOS in SIMATIC Manager: WinCC Application > right-click > Generate Server Data.
2. Wait for the action to complete (progress bar in the dialog) and check <ProjectPath>\ESOS\wincc\ServerData\ for new *.rcp files. These files hold the compiled tag, alarm, and text-library stubs the Reference clients consume.
3. On each OS Reference project: WinCC Application > right-click > Compile OS.
4. After compile, validate Tag Management - the OS Reference must now show tags under its own namespace, not under an ESOS prefix.

Solution - Method C: Update Symbolic Tag Paths on Reference Projects

If the tags on OS1/OS2 are still resolving to symbolic names generated by the ESOS compile pass:

1. Open each OS Reference project in WinCC Explorer.
2. For every structure tag instance bound to the affected motor: Properties > Tag > Symbolic.
3. Replace any path of the form ESOS\AS1\... with the local path OS1\AS1\... or OS2\AS1\... depending on the station.
4. Recompile and download the OS Reference.

Recompilation and Download Procedure (Full Plant)

Apply this end-to-end sequence only after all three root-cause checks pass:

1. AS compile: Charts folder > right-click > Compile. Resolve any compile warnings/errors.
2. AS download: Charts > right-click > PLC > Download. Use Download to Target System - Entire Program.
3. OS compile (ESOS): WinCC Application (ESOS) > right-click > Compile OS.
4. Generate Server Data (ESOS): WinCC Application (ESOS) > right-click > Generate Server Data.
5. OS compile (each Reference): WinCC Application Reference > right-click > Compile OS. Repeat for OS1 and OS2.
6. OS download (each Reference): WinCC Application Reference > right-click > PLC > Download.
7. Activate WinCC Runtime on each station in turn and confirm the operator logs in with a user that holds the required authorization level.

Verification Checklist

Edge Cases and Field-Proven Caveats

• OS Reference attached to the wrong AS: If the AS-OS assignment table was edited after the Reference was created, the Reference will silently bind to the wrong controller and the motor will appear as a "phantom" instance. Re-run OS > Assign OS/AS to recover.
• CFC changes not compiled to OS: If interlocks were added to the CFC chart but only the AS was downloaded, the OS still holds the old interface definition. The button enable signal cannot resolve and the button is greyed. Always recompile OS after AS changes.
• Text library mismatch: After enabling a new language on the ESOS, the OS References will grey the buttons until they consume the updated text library. This is part of the Generate Server Data step.
• Faceplate version mismatch: Mixing APL faceplate versions (for example, an older @MOT block on the ESOS and a newer one on the Reference) produces incompatible enable-condition tags. Confirm faceplate version with WinCC Explorer > Graphics Designer > @PCS7Typicals.
• Operator-level "Process controlling - higher" not granted: APL motor blocks use operator level 6 by default for interlock release. Lower levels produce a greyed button even when the tag binding is perfect. Check User Administrator > Authorization levels.
• Alarm/message configuration not generated: If only server data is generated but message configuration is missing, the OS Reference may compile with empty alarm tags, which can propagate into the faceplate enable logic for some custom blocks.
• Redundant OS pair interacting: Even though this configuration is not server-client, an OS Reference can still be set as Standby in PCS 7. Standby mode disables write operations until a master takes over - the symptom is identical to a greyed button.

Standards and Documentation

• SIMATIC PCS 7 V9.1 SP2 - OS Configuration Manual (Siemens Support 109769602): covers WinCC Application Reference project types and AS-OS assignment.
• SIMATIC PCS 7 V9.1 SP2 - Service Manual, chapter "Compiling and Downloading OS" (Siemens Support 109769594): describes Generate Server Data workflow and compile order.
• SIMATIC PCS 7 V9.1 SP2 - Operator Station Manual (Siemens Support 109769612): documents Runtime on ES option and OS Reference single-user configuration.
• SIMATIC PCS 7 APL Style Guide - Faceplate Enable Conditions (Siemens Support 109769570): documents authorization-level requirements for APL motor blocks.

FAQ