Implementing Multi-Instance Faceplate Popups in SIMATIC PCS 7 WinCC - Dynamic TagPrefix and C-Script Window Allocation

In SIMATIC PCS 7 WinCC, custom popup windows (such as motor interlock bypass dialogs) that overwrite each other or allow only a single window to open concurrently are caused by hardcoded Picture Window names in C-scripts. To support multiple simultaneous popup instances across different equipment, use WinCC's dynamic TagPrefix architecture combined with a multi-window allocation pool (e.g., cycling through @FpAdd1, @FpAdd2, @FpAdd3) or instantiate PCS 7 APL standard faceplate management APIs (SSMOpenTopField / OpenFaceplate).

The Single-Instance Picture Window Bottleneck in WinCC Graphic Designer

When automation engineers develop custom function blocks (e.g., custom Motor FB200 or Interlock Bypass FB255) and create custom WinCC popup dialogs:
* The Common Programming Flaw:
The C-script tied to the equipment icon typically contains hardcoded references:
c // Flawed static script: forces all motors into the same window SetVisible("ProcessScreen.pdl", "BypassWindow", 1); SetPictureName("ProcessScreen.pdl", "BypassWindow", "Bypass_Popup.pdl"); SetTagChar("Selected_Motor_Tag", "Motor101");
* The Problem:
Because BypassWindow is a single physical Picture Window object on ProcessScreen.pdl, clicking Motor2 immediately overwrites Motor1's parameters. If an operator tries to compare interlocks for two motors side-by-side, the system fails.
* The PCS 7 APL Architecture:
In contrast, standard PCS 7 APL faceplates allow opening multiple windows concurrently because APL maintains a pool of top-level picture windows (@FpAdd1, @FpAdd2, @FpAdd3, etc.) managed dynamically by the Picture Tree Manager and Split Screen Manager (SSM).

Dynamic TagPrefix Architecture for Reusable Popups

To make a single popup picture (Bypass_Popup.pdl) serve hundreds of different motors without duplicate code:
* Tag Naming Convention:
All structure tags associated with a block share a common prefix:
* Motor101.BypassActive, Motor101.InterlockBypassed, Motor101.ResetCmd
* Motor102.BypassActive, Motor102.InterlockBypassed, Motor102.ResetCmd
* The TagPrefix Property:
The Picture Window object in WinCC features a built-in property named TagPrefix. When TagPrefix is set to "Motor101.", any internal object in Bypass_Popup.pdl requesting the tag "BypassActive" automatically resolves to "Motor101.BypassActive" at runtime.
* Elimination of Global Tags:
Using TagPrefix completely eliminates the need for temporary global tags (e.g., Selected_Motor_Tag), ensuring complete isolation between concurrent windows.

Comparison Table: Custom C-Script Popups vs Standard APL Multi-Instance Pools

The table below compares different popup window implementation strategies in WinCC:

Feature / MetricHardcoded Picture WindowDynamic Multi-Window PoolStandard PCS 7 APL FaceplatesSimultaneous Open WindowsExactly 1 (Overwrites previous)2 to 6 (Configurable pool size)Up to 8 concurrent floating faceplatesCode MaintenanceLow initially, broken multi-userModerate (Clean C-script pool manager)Zero (Automated by APL framework)Tag AddressingGlobal intermediary tagsDynamic TagPrefix on Picture WindowAutomatic AS-OS structure tag prefixingScreen Docking / PinningFixed coordinatesDynamic coordinates based on cursor clickAutomatic cascade and user pinningMemory / GDI ImpactMinimalLowOptimized by Split Screen Manager

C-Script Window Allocation Algorithm for Multi-Instance Faceplates

The following C-script demonstrates how to implement a rotating 3-window allocation pool in WinCC Graphic Designer:

// Dynamic Multi-Instance Popup Opener
void OpenBypassFaceplate(char* lpszParentPic, char* lpszTagPrefix, int mouseX, int mouseY)
{
    char szWinName[32];
    int i;
    BOOL bFound = FALSE;

    // Check if tag is already open in one of the windows (bring to front)
    for (i = 1; i <= 3; i++) {
        sprintf(szWinName, "PicWindow_Pool_%d", i);
        if (GetVisible(lpszParentPic, szWinName)) {
            char* currentPrefix = GetPropChar(lpszParentPic, szWinName, "TagPrefix");
            if (strcmp(currentPrefix, lpszTagPrefix) == 0) {
                SetPropChar(lpszParentPic, szWinName, "Top", mouseY);
                SetPropChar(lpszParentPic, szWinName, "Left", mouseX);
                return; // Already open; refreshed position
            }
        }
    }

    // Find first available closed window
    for (i = 1; i <= 3; i++) {
        sprintf(szWinName, "PicWindow_Pool_%d", i);
        if (!GetVisible(lpszParentPic, szWinName)) {
            bFound = TRUE;
            break;
        }
    }

    // If all are open, overwrite window 1 (FIFO rotation)
    if (!bFound) {
        i = 1;
        sprintf(szWinName, "PicWindow_Pool_%d", i);
    }

    // Configure and open window
    SetPropChar(lpszParentPic, szWinName, "TagPrefix", lpszTagPrefix);
    SetPictureName(lpszParentPic, szWinName, "Bypass_Popup.pdl");
    SetPropWord(lpszParentPic, szWinName, "Left", mouseX + 15);
    SetPropWord(lpszParentPic, szWinName, "Top", mouseY + 15);
    SetVisible(lpszParentPic, szWinName, TRUE);
}

Step-by-Step Procedure to Implement Reusable Bypass Popups

Design Generic Popup PDL:
In Graphic Designer, create Bypass_Popup.pdl. Place buttons and status indicators. For tag dynamics, specify relative tag names without block prefixes (e.g., BypassActive, InterlockBypassed).
Add Window Pool to Base Graphic:
On your main overview picture or base screen template, insert 3 Picture Window objects named PicWindow_Pool_1, PicWindow_Pool_2, and PicWindow_Pool_3.
* Set properties: Visible = FALSE, Adapt Picture = TRUE, Title = TRUE.
Attach Opener Script to Equipment Icons:
* On the motor block icon, open the mouse click event.
* Call OpenBypassFaceplate(lpszPictureName, "Plant/Area/Motor101.", x, y).
Add Close Script Inside Popup:
Inside Bypass_Popup.pdl, add a close button (X) with the standard WinCC C-script:
c // Closes the containing picture window dynamically SetVisible(GetParentPicture(lpszPictureName), GetParentPictureWindow(lpszPictureName), FALSE);
Compile and Test Runtime:
Save all pictures, launch WinCC Runtime, and click multiple motor icons sequentially.

Verification

To verify multi-instance popup behavior:
1. Open the WinCC OS Runtime plant overview.
2. Click Motor 1. Confirm that PicWindow_Pool_1 opens displaying Motor 1 telemetry.
3. Without closing Motor 1, click Motor 2. Confirm that PicWindow_Pool_2 opens alongside Motor 1 displaying Motor 2 telemetry.
4. Click Motor 3. Confirm that PicWindow_Pool_3 opens concurrently, displaying all three motor popups simultaneously.
5. Close Motor 2. Click Motor 4. Confirm that PicWindow_Pool_2 is re-utilized cleanly for Motor 4 without corrupting Motor 1 or Motor 3.

Limitations and Operational Precautions

GDI Handle Consumption: Each open Picture Window consumes Windows GDI handles and WinCC memory resources. Limit concurrent floating window pools to a reasonable maximum (typically 3 to 6 per client console).
TagPrefix Trailing Dot: Always verify that the trailing dot (.) is included when passing the TagPrefix string (e.g., "Motor101."). Omitting the dot results in tag resolution errors like "Motor101BypassActive".
Multi-Client Concurrency: Because Picture Window properties are strictly local to the running WinCC Client session, multiple operators on different clients can open the same or different motors without interference.