Implementing Automatic Faceplate Timeout and Auto-Close in SIMATIC PCS 7 WinCC

In SIMATIC PCS 7 WinCC (V7.3 in PCS 7 V8.1 and V8.2), implementing an automated faceplate timeout mechanism to close inactive faceplates after a predetermined duration (e.g., 5 minutes) must be designed without using blocking sleep functions (such as ANSI-C Sleep()), which freeze the single-threaded WinCC Global Script engine and halt plant-wide script execution. The standard, reliable implementation utilizes the Visible (Display) property change event of the faceplate Picture Window (@OpenFaceplate.pdl) combined with a non-blocking cyclic timer tag, a VBScript Timer comparison, or an internal WinCC timer trigger that sets the Picture Window's Visible property to FALSE when the elapsed inactivity period expires.

Architecture of Faceplate Picture Windows in WinCC

In SIMATIC PCS 7 Advanced Process Library (APL), faceplates do not open as detached operating system windows. Instead, they are rendered inside pre-allocated Picture Windows embedded within the master overview screen (@screen.pdl or @1024x768.pdl). The primary faceplate container is typically named @Faceplate or @OpenFaceplate.

The visibility of this window is controlled by its boolean attribute Visible (or Display). When an operator clicks a motor or valve block icon, the calling script sets Visible = TRUE and assigns the tag prefix. When the operator clicks the 'X' close button, a script sets Visible = FALSE.

The Fatal Hazard of Using ANSI-C Sleep() in WinCC Runtime

Engineers frequently attempt to implement auto-closing by writing a simple C-action on the faceplate opening event:

// DANGEROUS IMPLEMENTATION - DO NOT USE
SetPropBOOL(lpszPictureName, "@Faceplate", "Visible", TRUE);
Sleep(300000); // Sleep for 5 minutes
SetPropBOOL(lpszPictureName, "@Faceplate", "Visible", FALSE);

Why this is catastrophic: WinCC's Global Script C-engine (ccscript.exe) processes script events in a single execution queue. Calling Sleep(300000) halts the entire C-script execution thread for 5 minutes! During this interval, no other C-scripts in the entire project can execute: screen navigation buttons become unresponsive, script-based alarm horns fail to sound, and faceplate commands freeze. After multiple clicks, the script queue overflows, terminating the runtime shell.

Non-Blocking Auto-Close Implementation via VBScript and Cyclic Timers

The safe and robust methodology utilizes asynchronous timestamp comparison via VBScript or cyclic internal tag triggers:

Create an Internal Timestamp Tag: In WinCC Tag Management, create an internal 32-bit unsigned tag named @Faceplate_OpenTime.
Record Open Timestamp: In the faceplate picture window's Visible / Change event, when Visible transitions to TRUE, record the current time:

' VBS Action on Picture Window Visible Property Change
Dim objWin
Set objWin = ScreenItems("@Faceplate")
If objWin.Visible = True Then
    HMIRuntime.Tags("@Faceplate_OpenTime").Write Now
End If

Cyclic Supervisor Action: Create a global cyclic VBScript action executing every 10 seconds:

' Cyclic Global VBS Action (10-second trigger)
Dim openTime, timeoutSeconds, elapsedSeconds
Dim objWin
Set objWin = HMIRuntime.Screens("@screen").ScreenItems("@Faceplate")

If objWin.Visible = True Then
    openTime = HMIRuntime.Tags("@Faceplate_OpenTime").Read
    timeoutSeconds = 300 ' 5-minute timeout
    elapsedSeconds = DateDiff("s", openTime, Now)

    If elapsedSeconds >= timeoutSeconds Then
        objWin.Visible = False ' Close the faceplate safely
    End If
End If

Configuring Dynamic Inactivity Reset on Operator Interaction

To ensure that an operator actively tuning a PID loop or commanding a motor does not have the faceplate abruptly vanish while typing:

Attach Inactivity Reset to Controls: On the command buttons (Start, Stop, Auto, Manual) and setpoint input fields within the faceplate PDLs (@pg_<type>_standard.pdl), attach a lightweight event to update @Faceplate_OpenTime:

HMIRuntime.Tags("@Faceplate_OpenTime").Write Now

This refreshes the expiration counter on every click or keystroke, ensuring the faceplate only auto-closes after 5 minutes of total user inactivity.

Comparison of Faceplate Management Strategies in Industrial Control Rooms

The following table compares different faceplate operational philosophies in process control environments:

Operational StrategyImplementation ComplexityControl Room ClutterOperator FeedbackRisk of Script Queue FreezeManual Operator Closing Only (Default)ZeroHigh (Multiple open faceplates obscure graphics)Full operator autonomyZeroNon-Blocking Asynchronous Auto-CloseModerate (VBScript + Timestamp tag)Zero (Automated cleanup of stale windows)Excellent (Inactivity reset prevents annoyance)ZeroSingle-Faceplate Policy (Auto-Close Previous)Low (Closes previous when new icon clicked)Zero (Only 1 faceplate active at any time)Good (Fast navigation)ZeroANSI-C Sleep() DelayLow (Naive script)UnpredictableSevere (System freezes completely)Critical (100% Guaranteed Freeze)

Verification

Verify the automatic faceplate timeout in WinCC Runtime:
1. In WinCC Runtime, click a pump icon to open its faceplate. Note the exact system clock time.
2. Leave the mouse and keyboard untouched for 5 minutes.
3. Observe that precisely at the 5-minute mark, the faceplate picture window cleanly disappears (Visible = FALSE).
4. Open the faceplate again; at minute 4, click the 'Manual' button to reset the timer. Verify that the faceplate remains open for an additional 5 minutes beyond the click.
5. Open WinCC APILOG (WinCC_Sys_01.log); confirm that script execution queues remain at 0 with no thread contention.

Limitations and Operational Precautions

Never implement auto-closing on safety-critical interlock faceplates or emergency shutdown (ESD) override dialogs where continuous operator monitoring is mandated by operating procedures. In multi-client control rooms, ensure timer tags are created as Internal Tags with Computer-Local Updating (Local Tag); if an internal tag is configured with project-wide scope, opening a faceplate on Client 1 will overwrite the timer on Client 2!

Engineer FAQ

Why does WinCC freeze when I use Sleep() in C-scripts?

WinCC executes ANSI-C scripts sequentially in a single processing thread (ccscript.exe). Calling Sleep() blocks that entire thread, halting all script execution, button events, and dynamic calculations across the entire client station.

How do I make the auto-close timer tag local to each OS client?

In WinCC Tag Management, create the tag as an Internal Tag and check the property 'Computer-local'. This ensures each physical client workstation maintains its own independent faceplate timer.

Can I close the faceplate automatically when the operator navigates to another graphic screen?

Yes. By default, PCS 7 APL closes or docks faceplates when switching process pictures. This behavior is governed by the Picture Tree Manager and the @screen.pdl navigation scripts.