PCS7 ES-OS Download: Fixing Custom APL Faceplate Display

Problem Overview

When commissioning a SIMATIC PCS 7 V9.1 project with one Engineering Station (ES) and one Operator Station (OS) configured as a single-station, the project compiles and the runtime behaves correctly on the ES. After the OS is downloaded from the ES, the standard APL faceplates open normally on the OS, but custom (self-made) faceplates built on top of the APL MOTL (motor) block type are not displayed. The standard call button is rendered on the OS picture, but the user-defined button that triggers the custom faceplate popup is missing or inactive.

This symptom is specific to projects that mix Siemens-supplied APL blocks with user-created faceplates, and it almost always traces back to one of three configuration gaps: server data was not regenerated after the custom WinCC graphics were added, the ES-to-OS download was performed before all OS-side prerequisites (DCOM, firewall, NetPro, user rights) were in place, or the custom faceplate scripts/COM containers were not registered on the target OS runtime.

Affected Components and Versions

Root Cause Analysis

The dominant root cause is missing or stale server data on the OS. WinCC server data is the compiled image that the OS runtime uses to resolve block instances, faceplate types, and tag connections. When you add a custom faceplate to an APL motor block on the ES and then download to the OS without first regenerating the server data and re-downloading the OS, the OS picture cache still references the original faceplate set, so the custom button script is never instantiated.

Secondary causes, in order of frequency in the field:

1. DCOM / firewall on the Security Controller has not been configured for the ES-OS download, which silently drops part of the transfer.
2. OS server properties in NetPro / HW Config (for example, the S7 connection target, the OS server name, the assigned OS) were not fully configured before the download.
3. User authorizations on the OS project are missing for the operator who opens the faceplate; the custom button can be hidden by the authorization layer.
4. PLCSim is in use and the OS simulation path is not aligned with the manual's PLCSim setup procedure, which is known to break jump-to-faceplate behavior.
5. Graphics files copied manually (PDL, EMF, script library files) to the OS outside the official download path, leaving the WinCC internal references desynchronized.

Pre-Download Configuration Checklist

Complete every item below on both the ES and the OS before you perform the ES-OS download. The full list of preconditions is documented in the official Siemens support entry referenced at the end of this article.

Step 1 - Configure DCOM and Firewall on the Security Controller

Siemens specifically calls out the Security Controller in the ES-OS download prerequisites. The Security Controller is the DCOM server that brokers the ES-OS download session; if its launch and activation rights are not granted, the download completes with partial state on the OS.

1. On the ES and on the OS, open Component Services (dcomcnfg.exe).
2. Navigate to Component Services » Computers » My Computer » DCOM Config.
3. Locate Security Controller (registry appid is part of the WinCC / PCS 7 install).
4. Right-click » Properties » tab Security.
5. Under Launch and Activation Permissions select Customize and add the WinCC service user, the interactive user, and the local administrators group with full rights.
6. Under Access Permissions add the same accounts.
7. On the EndPoint tab, ensure authentication is set so that the Security Controller is reachable from the remote station.
8. Open wf.msc (Windows Firewall with Advanced Security) and create inbound rules for the WinCC / PCS 7 executables (CCEServer.exe, CCProjectMgr.exe, WinCCExplorer.exe) on the dedicated profiles.
9. Reboot both stations after the changes.

Step 2 - Generate Server Data on the ES

This is the step that resolves the visible symptom in roughly 80% of the reported cases. Server data is what the OS runtime consumes; without it, the custom faceplate scripts are present on disk but never bound to a block instance.

1. Open the PCS 7 project on the ES in SIMATIC Manager.
2. Select the OS in the component view.
3. Right-click » OS » Generate Server Data (or, from WinCC Explorer: OS Project Editor » Next » Generate Server Data).
4. Wait for the wizard to finish. The output window should report a clean compile with zero warnings on the custom faceplate scripts.
5. Save the project, then run the OS download again.

Step 3 - Re-run the ES-to-OS Download

1. In SIMATIC Manager select the OS in the component view.
2. Right-click » Download » OS (or use the WinCC Explorer Download OS dialog).
3. Choose Complete download the first time after a custom faceplate change; afterward, you can use Changes only.
4. Confirm that the project path on the target OS is the same path used by the OS runtime service. Mixing path mapping breaks faceplate resolution.
5. Restart the WinCC runtime on the OS when prompted.

Step 4 - Custom Faceplate Wiring for MOTL

If the custom button is still missing after step 3, the faceplate wiring is the next suspect. A self-made faceplate on top of an APL block must be wired through the standard interface of the block type, otherwise the OS runtime does not render the user-defined area.

1. Open the custom faceplate in the WinCC Graphics Designer.
2. Confirm that the faceplate is a copy of the APL MOTL faceplate (@MOTL.pdl) renamed to a project-local name, not a brand-new PDL with the same name.
3. On the Properties » Events of the button that opens the custom view, verify the C action calls the standard WinCC function OpenPicture(...) or PDLRTSetVisible(...) with the correct picture name and tag prefix.
4. Confirm that the tag prefix on the button matches the structure tag the block instance generates. A common mistake is to hard-code the prefix from the ES, which becomes wrong after download if the OS picture tree prefix differs.
5. Recompile the OS and re-download.

Step 5 - User Authorization on the OS

Custom faceplate elements often sit behind a higher authorization level than the standard APL views. The button can be deliberately hidden when the operator's group lacks the right number.

1. Open WinCC Explorer on the OS (after the download).
2. Go to User Administrator.
3. Compare the authorization levels assigned on the ES vs the OS. The OS-side database is downloaded with the project, but if you maintain users separately on the OS, the levels can drift.
4. Add the missing authorization (for example, level 5 for operator, level 6 for process control) to the test operator's group.
5. Re-login on the OS runtime.

Step 6 - OS Server Properties (NetPro / HW Config)

The OS server properties define which PC station is the runtime target. If the ES was rebuilt or the PC station name changed, the download can land on the wrong logical OS even when the physical machine is correct.

1. Open the PC station in HW Config on the ES and confirm the OS server application is inserted and assigned to the same OS as the one you are downloading to.
2. In NetPro, select the S7 connection from the AS to the OS and verify the partner IP, partner rack, partner slot, and connection name.
3. Right-click the OS in NetPro » Object Properties and verify the OS name matches the WinCC project name on the target PC station.
4. Save and recompile (NetPro » Compile and Check All).
5. Re-run the OS download.

Step 7 - PLCSim Caveat

If you validate the project on the ES with PLCSim and the OS-side simulation is enabled, the jump-to-faceplate behavior is known to be unreliable. The behavior is not a faceplate bug; it is a known interaction between the OS simulation layer and the standard OpenPicture function used by the APL blocks.

1. Disable OS simulation in WinCC Explorer » OS Project Editor » Runtime Settings.
2. Test on the live OS runtime connected to PLCSim over the S7 connection (ES-side only).
3. If you need a simulated OS, follow the Engineering Manual or PCS 7 Compendium Part A setup procedure for PLCSim + OS.

Step 8 - Diagnose With apdiag.exe

When the custom button is still not visible, the WinCC utility apdiag.exe is the fastest way to confirm whether the faceplate is opened, the script fires, and the picture resolves.

1. On the OS, navigate to C:\Program Files (x86)\SIEMENS\WinCC\utools.
2. Launch apdiag.exe.
3. Click Output Window.
4. On the running OS picture, click the custom faceplate button (or, if it is invisible, click the location where it should be rendered).
5. Capture the messages in the output window. The relevant lines are OpenPicture calls, the resolved picture name, the tag prefix, and any PDLRT errors.
6. Compare the picture name and tag prefix with the ES-side reference. A mismatch is the smoking gun.

Verification

After every change, validate with the following sequence. All checks must pass before the issue is considered resolved.

Troubleshooting Matrix

Field Notes and Best Practices

• Treat every custom faceplate change as a full OS download trigger. The changes-only download is reliable for tag and color changes; for new picture elements or new C actions, do a full download at least once.
• Keep the custom faceplate file name prefixed with @ (for example @MyMotl.pdl) and the picture name identical between ES and OS. The @ prefix is required for it to be treated as a faceplate by the WinCC picture tree.
• Maintain a single WinCC project path. ES project path and OS project path should be byte-identical, otherwise picture references must be remapped manually.
• Use the same Windows user for the WinCC service and for the engineering login; mixed identities re-trigger the DCOM and authorization issues even after a correct download.
• Document the custom faceplate changes in a project CHANGELOG; this shortens the next round of troubleshooting by an order of magnitude.

Frequently Asked Questions