Propagating Custom Faceplate Modifications Across OS Servers and Distributed Clients

In SIMATIC PCS 7 multi-client architectures, modifying a standard or custom faceplate file such as @PG_Motor_maintenance.pdl and downloading the OS Server project will not update the display on OS Clients. In PCS 7 client-server systems, faceplates are rendered locally on each OS Client from its local GraCS directory. To deploy faceplate changes plant-wide, copy the modified PDL file into the GraCS folder of the Engineering Station, OS Server, and all OS Client projects, or deploy the changes via the Master Data Library followed by an OS Client download. Furthermore, verify that internal APL faceplate C-scripts do not dynamically override visibility settings.

PCS 7 Client-Server Faceplate Architecture

In SIMATIC PCS 7, the Operator Station (OS) employs a distributed client-server topology. While real-time process data, historical archives, and alarm logs reside on the OS Servers, graphical user interface rendering is decentralized. When an operator clicks a motor or valve block icon on an OS Client, the client workstation executes local graphics scripts and instantiates the faceplate window locally.

The client graphics engine prioritizes local files: it searches first within the local client project directory (...\<OS_Client_Project>\GraCS\). Only if a graphic file is absent locally will the client attempt to retrieve it over the network from the server package, which introduces network latency.

Why OS Server Downloads Do Not Update OS Clients

When an engineer edits @PG_Motor_maintenance.pdl in the OS Server project and executes PLC > Download to the server:

The updated file is transferred strictly to the target OS Server station (...\<OS_Server_Target>\GraCS\).
Distributed OS Client stations maintain their own distinct project folders on the network.
Because OS Clients already possess a local copy of @PG_Motor_maintenance.pdl from initial project generation, they continue executing their local, unedited PDL files. Consequently, operator screens on clients show zero graphical changes.

Dynamic Scripting and APL Visibility Overrides

Even when graphic files are successfully distributed, manual modifications to hide elements may be overridden by code:

APL faceplates execute complex C-scripts on startup (such as Init_View and SetVisible).
These scripts inspect user authorization levels, controller block feature bits (e.g. Feature.Bit0 to Feature.Bit31), and operating states.
If an engineer manually sets an object property Visible = False in Graphics Designer, the faceplate script may dynamically re-evaluate the property and set Visible = True during runtime initialization. Modifying static properties alone is often insufficient without adapting the associated script conditions.

Deployment Workflow Across Master Data Library and Clients

Follow this procedure to ensure clean, plant-wide faceplate deployment:

Edit in Master Data Library or Central ES:
- Modify @PG_Motor_maintenance.pdl in the central OS project on the Engineering Station.
Propagate to OS Client Projects:
- Copy the modified file directly into the GraCS directory of each OS Client project in SIMATIC Manager.
Download to All Target Stations:
- Right-click the OS Server project and execute PLC > Download.
- Right-click each OS Client station and execute PLC > Download > Changes (or full download).
Cycle Client Graphics Runtime:
- On running OS Clients, close and reopen the faceplate or change process pictures to flush the Windows GDI graphics cache.

Comparison of Faceplate Storage Locations in PCS 7

The table below contrasts graphic storage behavior across PCS 7 stations:

Station TypeStorage PathFaceplate ExecutionUpdate MechanismRisk if DesynchronizedEngineering Station (ES)<ES_Proj>\wincproj\<OS>\GraCSDesign & TestingDirect save in Graphics DesignerBaseline configuration mismatchOS Server<Server_Target>\wincproj\OS\GraCSServer local runtimeTarget OS Download from ESFaceplates differ between server & clientOS Client<Client_Target>\wincproj\OSC\GraCSOperator interactionTarget OS Client DownloadOperators view outdated faceplate versionsWeb Navigator Server<Web_Server>\WebNavigator\PicturesWeb publishing engineWeb Publisher Wizard executionRemote browser clients display stale screens

Verification

Confirm that faceplate modifications are active plant-wide:

Open WinCC Graphics Designer on the target OS Client station; verify the local @PG_Motor_maintenance.pdl reflects the modifications.
Activate OS Runtime on the client station.
Click a motor block icon to open the motor faceplate, then navigate to the Maintenance view.
Confirm that the targeted display elements are hidden as intended.
Open the faceplate from an alternate OS Client and the OS Server to verify visual consistency across all operator interfaces.

Limitations and Operational Precautions

Observe the following safeguards when customizing PCS 7 faceplates:

OS Project Editor Hazard: Standard @PG_*.pdl files will be overwritten if the OS Project Editor is run with options that regenerate standard pictures. Always back up customized faceplates or maintain them in a central library.
System Upgrades: Custom faceplate modifications must be re-validated during PCS 7 version migrations (e.g. V8.2 to V9.0) to ensure compatibility with new APL block versions.
Do Not Break C-Scripts: Avoid deleting controls referenced by internal C-scripts, as missing object names will cause global script errors and degrade HMI performance.

Engineer FAQ

Why are faceplates stored locally on OS Clients instead of pulled from the OS Server?

Storing faceplates locally on OS Clients optimizes runtime performance by eliminating network file transfer latency every time an operator clicks a block icon, reducing plant bus bandwidth consumption.

How can I prevent the OS Project Editor from overwriting my custom faceplate?

Store a copy of your customized PDL outside the GraCS directory or uncheck the 'Basic Data' overwrite options in the OS Project Editor. Alternatively, implement custom views using user-defined view tabs.

Why did my object become visible again after reopening the faceplate?

Internal APL initialization scripts evaluate process conditions and user authorization levels upon faceplate loading, overriding static visibility properties assigned in Graphics Designer.