Resolving Siemens PCS7 Loop-In-Alarm Grayed-Out Page Issue

Problem Overview

In a Siemens PCS 7 plant, the Loop-In-Alarm function (called Loop into alarm in older operator station dialogs) is the standard mechanism that an operator uses to jump from an active message in the WinCC Alarm Logging view directly to the process picture containing the block that triggered the alarm. When the function works correctly, the operator double-clicks an alarm row, the OS performs a picture change, and the destination faceplate / overview area becomes live with current process values.

The fault condition covered in this article is the following: after the picture change fires, WinCC opens the correct process picture but the picture is rendered grayed out, as if the runtime data connection to the AS had been severed. The same picture opened manually from the plant overview, area tree, or status bar buttons still updates normally. The issue is reproducible on every alarm, on every picture referenced from the alarm line, and on every OS server in the multiproject. The fault is therefore not in the CFC chart logic, not in the faceplate dynamic scripts, and not in the physical CP 443-1 / plant bus connection - it is in the OS runtime data layer that is created during the OS download.

Symptoms and Identification

Use the following checklist to confirm that you are looking at the fault described in this article and not at a similar but unrelated problem:

1. Double-clicking an alarm row opens the correct picture (same picture name that the Open picture property of the CFC block specifies).
2. The opened picture is displayed, but every dynamic field, bar, and numeric indicator is grayed out. No values update.
3. Closing the picture and opening the same picture via the area selector, the standard overview button, or the picture tree opens a fully working, live picture.
4. The condition is present for all alarms and all referenced pictures, not just one tag or one faceplate.
5. The OS Runtime is running on both OS servers (redundant OS1 active, OS2 standby). On redundant failover the symptom is identical.
6. Restoring a known-good backup of the OS project on disk does not clear the symptom.

If any of the items above does not match your observation, the cause is more likely to be a corrupted CFC chart, a deleted picture in WinCC Explorer, a wrong picture assignment in the OS_Picture attribute of the CFC block, or a server-package distribution problem on the terminal bus. In those cases follow the standard OS Project Editor check first.

Root Cause Analysis - Server Reference Mismatch

When the operator triggers Loop-In-Alarm, the C-function attached to the alarm row in Alarm Logging is executed. According to the Siemens support entry ID 71178 - Specific features when using "Loop in Alarm", this C-function performs two things:

1. Calls a picture-change to open the configured process picture.
2. Calls the appropriate faceplate instance so that the block's runtime data is wired into the dynamic wizard of the faceplate.

Step 2 is implemented by passing a fully qualified server / picture reference such as:

The reference is rebuilt every time the OS project is compiled and downloaded from the engineering station (ES). If the build process cannot resolve the picture name back to the local picture database on the OS server - typically because the picture database, the package, or the @local picture prefix mapping has been corrupted - the reference resolves to a phantom picture that has no dynamic connection. The picture is still displayed because the static graphic file exists, but the runtime tags cannot be subscribed to. WinCC therefore shows the picture with all dynamic fields grayed out.

The diagnostic evidence is the server prefix shown on the picture's Info dialog (open the picture on the OS, click the ? in the button bar and choose Picture Info):

The presence of the explicit WinCC Projectname_OS1:: prefix - instead of the expected @local - means that the C-function in Alarm Logging is still holding the old picture reference generated at the previous compile / download cycle, while the new picture database on disk is now keyed on the local prefix. The two naming schemes no longer match and the dynamic subscription fails silently.

Why a Restore from Backup Does Not Fix It

Restoring a previous backup of the OS project from the ES archive restores the picture files, but it does not regenerate the C-functions stored inside the Alarm Logging runtime database on the OS server. Those C-functions are produced by the ES compile pass and written into the project's GraCS / Library folders at OS download time. If the original ES compile generated a corrupt or stale reference - for example because the OS Project Editor was interrupted, an anti-virus scan locked files during download, or a redundant OS partner had a different picture database revision - the backup only restores the picture files but leaves the broken references in Alarm Logging. The symptom therefore persists.

Pre-Requisites and Tools

Before starting any rebuild procedure, verify the following:

• Engineering station (ES) and both OS servers (OS1, OS2) are on the same SIMATIC PCS 7 version, hot-fix level and ES service pack.
• The ES user is a member of the SIMATIC HMI and SIMATIC NET Windows groups and has local administrator rights on the OS servers.
• Plant bus and terminal bus are reachable (ping the OS servers by NetBIOS name from the ES).
• You have a complete, current backup of the multiproject on a network share or removable media.
• WinCC Explorer is closed on all OS servers during the rebuild; deactivate the WinCC Runtime on OS1 and OS2 to release the picture database locks.
• Custom faceplates, user-defined C-scripts in the project's Library folder, and the @Faceplate picture family are backed up separately - the rebuild described below does not touch CFC charts on the AS.

Diagnostic Procedure

Execute the following checks in order before choosing a remediation path. Record each finding.

1. Open the picture manually on OS1. From the button bar select Info and confirm the server prefix is @local.
2. Trigger a Loop-In-Alarm from any active message. In the opened picture press Info again and note the prefix. If it reads WinCC Projectname_OS1::..., the symptom is confirmed.
3. On the ES, open the project in SIMATIC Manager (or the PCS 7 Plant View in newer versions) and select the OS. Run OS Project Editor with default options. Download the result to OS1 only and re-test. If the issue disappears, the OS Project Editor regenerated the Alarm Logging C-functions and you can continue with the standard download to OS2.
4. If the OS Project Editor does not fix the issue (the case observed in the field), continue with the full rebuild procedure below.
5. On each OS server, open the file <ProjectPath>\OS\<OS_Name>\GraCS\Config directory and check that the picture file referenced by the Loop-In-Alarm function exists and has a recent modification timestamp. A missing or zero-byte file points to a half-completed download rather than a reference mismatch.
6. Compare the file SSM.cfg on OS1 and OS2 - the segment sizes and the checksum in the header should be identical on a healthy redundant pair. A mismatch means the previous redundant sync was interrupted.

Solution A - OS Project Editor (preferred, non-destructive)

Use this path when only standard PCS 7 graphic objects were changed. It rebuilds the picture tree and the Alarm Logging C-functions without overwriting custom faceplates stored in the project's Library.

1. On the ES open the multiproject and select the OS.
2. Choose Options > OS Project Editor from the menu bar.
3. Accept all defaults on the Picture Tree tab. On the Message Configuration tab confirm that Loop in Alarm is enabled for every area.
4. Click OK. The ES regenerates the Alarm Logging functions and rewrites the GraCS folder entries.
5. Compile and download the OS to OS1. Activate Runtime, trigger an alarm, perform Loop-In-Alarm and verify that the picture is live.
6. If verification passes, repeat the download to OS2.

Solution B - Full OS Project Rebuild (definitive)

Use this path when Solution A does not clear the symptom, or when previous OS Project Editor runs have produced inconsistent results. The procedure removes the OS from the multiproject, deletes the on-disk OS project on both servers, and rebuilds the OS as a fresh object before downloading it for the first time.

Step B1 - Capture the configuration

• On the ES export the OS assignment table (which AS is assigned to which OS, picture-tree depth, language set, redundant partner).
• Export the alarm classes, message priorities and the Loop-In-Alarm mapping from the CFC chart properties of the block types in the master data library.
• Back up the entire <ProjectPath>\OS folder on the engineering station to a safe location.

Step B2 - Remove the OS from the multiproject

1. In SIMATIC Manager right-click the OS object (OS1) in the plant view and choose OS > Remove from multiproject. Confirm the dialog.
2. Delete the on-disk OS project folder on the ES (default location ...\<Project>\wincproj\<OS_Name>).

Step B3 - Clean the OS servers

1. On OS1 stop the WinCC Runtime. Open WinCC Explorer > File > Close.
2. In Windows Explorer delete the entire OS project folder (default C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects\<Project>_OS1).
3. Empty the recycle bin. Repeat for OS2, deleting ...\<Project>_OS2.
4. Verify that no WinCC processes (CCArchiveMgr.exe, CCAlgRt.exe, PDLRT.exe) are still holding file handles. Reboot the OS servers if necessary.

Step B4 - Recreate the OS in the multiproject

1. Back on the ES, insert a new OS object into the multiproject: right-click the project > Insert New Object > OS.
2. Set the OS type (server / client / standby), assign the correct AS and the redundant partner (OS2), and recreate the same area hierarchy that existed before. Use the exported table from Step B1.
3. In the new OS object, run OS Project Editor to regenerate the picture tree and the Alarm Logging C-functions.
4. Re-import any custom faceplates from the backup taken in Step B1 into the new Library folder.

Step B5 - Compile and download

1. Compile the OS. Make sure the compile finishes without warnings about unresolved picture references.
2. Download the OS to OS1. Activate Runtime. Trigger an alarm and execute Loop-In-Alarm. The Picture Info dialog should now show @local as the prefix.
3. Download the OS to OS2 (the standby partner). Activate the redundant Runtime.
4. Force a redundant failover (deactivate OS1) and verify that OS2 serves Loop-In-Alarm correctly with live pictures.

Loop-In-Alarm Function Reference

The Loop-In-Alarm C-function is generated by PCS 7 when the OS is compiled. The function is stored per alarm in the Alarm Logging configuration and has the following logical structure (illustrative, not the literal generated source):

// Generated by PCS 7 OS Project Editor
int LOOP_IN_ALARM_FUNC(LPCSTR szPictureName, LPCSTR szServerPrefix)
{
    // 1. Build the picture reference expected by WinCC
    char szRef[256];
    sprintf(szRef, "%s::%s", szServerPrefix, szPictureName);

    // 2. Request the picture change on the active OS server
    DM_PICTURE_CHANGE(szRef);

    // 3. Wire the block instance to the faceplate dynamic wizard
    DM_SET_FACEPLATE_INSTANCE(szRef, GetCurrentTagInstance());
    return 0;
}

The szServerPrefix argument is normally the literal string @local. When the ES compile generates an absolute WinCC Projectname_OS1:: prefix, it is because the project database that stores the prefix string on the ES and the one that the OS reads at Runtime startup have diverged - usually after a partial OS download or after restoring an OS project backup on disk without re-running the ES compile.

Server Name Reference - @local vs Explicit Project Prefix

The fix in the rebuild procedure is to ensure that every entry written by the ES compile uses @local exclusively, so that the picture is always resolved against the OS on which the operator is currently working - and that OS always has the picture file in its own GraCS folder after a complete download.

Verification Steps

After applying Solution A or Solution B, perform the following verification sequence on each OS server, with Runtime active:

1. Generate a test alarm by forcing a CFC block value out of range. Wait until the message appears in the active alarm list.
2. Double-click the alarm row. Confirm that the picture opens and that all dynamic fields (PV, SP, OUT, mode) are not grayed out and update at the configured scan rate.
3. Open the picture's Info dialog. Confirm the prefix is @local.
4. Open the same picture manually from the area tree. Confirm both copies show the same live values.
5. On the redundant standby server, repeat the test. Force a failover by deactivating the active OS Runtime. The previously standby server becomes active; Loop-In-Alarm must continue to work without restarting the WinCC Explorer.
6. Open a faceplate (if the project uses PCS 7 APL / industry library blocks) from the picture. Confirm that the faceplate shows the correct instance name and live values.
7. Check the WinCC diagnostic files (WinCC_Sys_<ServerName>.log and WinCC_Service_<ServerName>.log) for any error entries containing the strings DM_PICTURE_CHANGE, LoopInAlarm, or Picture not found. The log should be clean.

Prevention and Best Practices

• Always run OS Project Editor on the ES after every change to the area hierarchy, the picture tree, or the message configuration, and before downloading to the OS servers.
• Never copy OS project folders manually between ES and OS servers; always use the SIMATIC Manager download path so that the Alarm Logging C-functions are regenerated.
• Disable real-time anti-virus scanning on the OS project folders (default locations under C:\Program Files (x86)\Siemens\Automation\WinCC\WinCCProjects) - file locks during scan are a frequent cause of partial OS downloads.
• Before every OS download, confirm that the redundant OS server is synchronized (Redundancy Control > Status). A desynchronized pair is the most common root cause of stale picture references after a download.
• Keep the ES, OS1 and OS2 on identical Windows service pack, .NET Framework and SIMATIC software levels. A mismatch on the ES compile output against the OS Runtime version is a known source of broken picture references.
• Document the picture reference policy in the project quality plan: always @local for server-relative pictures; explicit prefix only when targeting a remote OS client.
• Maintain a tested full backup of the multiproject on offline storage so that the destructive Solution B can be executed without losing custom faceplates or the runtime archive configuration.

FAQ