Adding Custom Operator Buttons to PCS 7 OS Button Sets

Customizing the operator button bar of a SIMATIC PCS 7 Operator Station is a routine engineering task whenever the standard faceplate buttons do not cover the operator actions required by a particular process unit. In a multistation PCS 7 v9.0 SP1 project running WinCC Runtime V7.4 SP1 Update 4, two independent mechanisms are available: editing the master @Buttons11.PDL / @Buttons12.PDL files in the WinCC Options folder, and using the central OS button set configuration exposed in WinCC Explorer. Each method has its own file-system implications, its own upgrade risk, and its own validation procedure. This article walks through both, explains how the OS Project Editor mediates the transfer, and provides a verification and troubleshooting matrix that survives a PCS 7 service-pack upgrade.

Architecture of the PCS 7 OS Operator Button Bar

The operator button bar that appears on every PCS 7 OS picture is composed from a small set of WinCC picture files that the OS Project Editor copies into the project during the compile / download step. The master files are stored outside the project, in the WinCC installation tree, and the editor reads from that location every time it runs. The runtime then displays the picture that lives in the project's GraCS directory. Customizing a button set therefore means inserting the change at one of three points in this chain: the source file in the WinCC Options folder, the picture file inside the project, or the runtime configuration managed through the central OS settings.

Two WinCC surfaces expose this configuration to the engineer:

• Source picture folder at C:\Program Files (x86)\SIEMENS\WinCC\Options\PDL on the engineering station, where the master @Buttons11.PDL, @Buttons12.PDL and other @Button*.PDL files reside. The OS Project Editor reads from this folder when the editor runs.
• Central OS button set configuration opened from WinCC Explorer via Extras > Central OS Settings > Button Sets Configuration. It provides a graphical preview to add, remove, and reorder buttons before transferring the change to the OS runtime database.

Prerequisites

1. SIMATIC PCS 7 v9.0 SP1 installed, and the multistation project open in SIMATIC Manager / PCS 7 Engineering.
2. WinCC Explorer V7.4 SP1 Update 4 on the engineering station and the OS server project.
3. Local administrator rights on the engineering station (required to write to %ProgramFiles(x86)%\SIEMENS\WinCC\Options\PDL).
4. A backup copy of the original @Buttons11.PDL and @Buttons12.PDL stored outside the WinCC installation tree (e.g., D:\PCS7_Backups\PDL_Source\<PCS7_Version>\).
5. Graphics for the custom buttons saved as *.emf, *.bmp or *.png in the project GraCS directory, matching the resolution used by the OS Project Editor for the standard button set (16x16 for toolbars, 24x24 for the operator bar).
6. The WinCC "Scripts" option installed if any C action is used on the custom button.

File Locations and Naming Conventions

The following table summarizes the files and paths relevant to button set customization. All paths are for a 64-bit Windows engineering station with a default PCS 7 v9.0 SP1 install on drive C:.

File names beginning with the @ sign are reserved for system pictures in WinCC. Custom button sets should still use this prefix to be picked up correctly by the central configuration dialog; standard naming conventions in PCS 7 use @ButtonsNN.PDL for the predefined sets and @<Name>.PDL for project-specific sets.

Method 1 — Modifying the Source PDL

The most direct path is to edit the master pictures in the WinCC Options folder. The OS Project Editor will read the modified file the next time the editor runs for the affected OS and copy it into the project.

Step 1 — Locate the source pictures

On the engineering station, open the folder:

List the contents and identify the button set pictures that apply to your project. Common entries are @Buttons11.PDL and @Buttons12.PDL, which contain the standard button bar used by PCS 7 faceplates. Each file is a regular WinCC picture that can be opened and edited in Graphics Designer.

Step 2 — Back up the originals

Copy the original files to a versioned backup location:

Also store a SHA-256 hash for each file (PowerShell example):

Get-FileHash "C:\Program Files (x86)\SIEMENS\WinCC\Options\PDL\@Buttons11.PDL" -Algorithm SHA256 | Select-Object Hash

Record the hash in the project log. After a service-pack install, the hash can be re-computed and compared to detect silent replacement by the installer.

Step 3 — Edit the source PDL

1. Open @Buttons11.PDL (or the relevant set) in Graphics Designer.
2. Inspect the existing button objects; do not delete the standard buttons unless the new set is a deliberate replacement.
3. Add the custom button object from the WinCC object palette (typically Windows Objects > Button).
4. Configure the button's properties: name, position, geometry, foreground / background color, picture (released status), picture (pressed status), tooltip, and operator authorization level.
5. Configure the events: on Mouse Click, attach either a direct tag connection (Set tag action) or a C action that calls a project function.
6. Save the PDL in place. Confirm the file timestamp updated and the file size is non-zero.

Repeat for @Buttons12.PDL if the custom button must appear in more than one set. Each @Button*.PDL is independent and the project compiles a separate copy for each.

Step 4 — Trigger the OS Project Editor

1. In SIMATIC Manager, open the OS object and run OS Project Editor.
2. Select the relevant tab (e.g., Basic Data, Pictures) and click Apply / OK to commit.
3. Watch the editor log under <Project>\<OS>\OSLog\ for lines indicating that @Buttons11.PDL was copied into the project.
4. Open <Project>\GraCS\@Buttons11.PDL in Graphics Designer and verify the custom button is present.

Method 2 — Central OS Button Sets Configuration

The central configuration dialog provides a graphical pick list of the available buttons and a preview window. It is the right tool when the buttons already exist as picture objects inside the project and only the arrangement in the bar is changing.

Step 1 — Prepare a custom button picture

Create a new PDL in the project GraCS folder, e.g., @MyUnitButtons.PDL. Place one or more button objects on the picture, configure their events, and save. The picture must compile without errors, and the button objects must have a meaningful name (e.g., btn_AckUnit).

Step 2 — Open the configuration dialog

1. On the OS server, open the project in WinCC Explorer.
2. Right-click the OS and choose Properties, or use the menu Extras > Central OS Settings.
3. Select the Button Sets Configuration node.
4. Select the button set to edit (e.g., the set bound to the faceplate screens relevant to the modified unit).
5. Click Add; the dialog lists the available buttons scanned from the project's GraCS folder.

Step 3 — Arrange and transfer

Use the preview pane to drag the buttons into the desired order. Save the configuration, then run Transfer (or Download) to the OS runtime. The runtime database is updated and the OS server begins using the new arrangement.

If the button pick list shows some custom buttons and not others, the most common cause is that the dialog has cached its scan of the GraCS folder. Close and reopen the dialog, or restart WinCC Explorer, to force a rescan. This is the exact symptom reported in field cases where the engineer "sees the button most of the time, but not always" in the pick list — a WinCC Explorer rescan typically resolves it.

Method 1 vs Method 2 — Decision Matrix

OS Project Editor — What It Does and Does Not Touch

The OS Project Editor is the agent that synchronizes the engineering data with the OS runtime. It runs whenever the OS object is compiled in PCS 7, and it copies the standard pictures from ...\SIEMENS\WinCC\Options\PDL into the project. It does not run C scripts, it does not interpret button logic, and it does not modify the central button set configuration. The important consequences are:

• Modifications to the source PDL in the Options folder survive a re-run of the editor. The editor reads from the source, not from a snapshot.
• Modifications to the project GraCS picture (when the project copy is edited directly) are overwritten by the editor the next time it runs, because the editor copies the source file over the project copy.
• Modifications to the central configuration are not affected by the editor; they are stored in the runtime database and must be re-transferred after a download.

For predictable behavior, edit the source file in the Options folder rather than the project copy. The Siemens support entry 109812494 — How to design button sets for the PCS 7 OS documents the file layout and the editor's copy step, and lists the expected PDL names that the central configuration dialog scans.

Multistation Project Workflow

For a multistation project with one OS server and one or more OS clients, the workflow is:

1. Edit the master @Buttons11.PDL on the engineering station in the WinCC Options folder.
2. Compile the OS object in SIMATIC Manager; the OS Project Editor copies the modified picture into the project GraCS folder.
3. Download the project to the OS server.
4. If the central button set configuration is used, open it on the OS server, apply the changes, and transfer to the runtime.
5. Download the project to every OS client. Clients that do not receive a download will continue to display the previous button set.

Upgrade Behavior and Backup Strategy

Both methods share one risk: a WinCC or PCS 7 service pack, upgrade, or repair install can replace the files under ...\SIEMENS\WinCC\Options\PDL and reset the project copy. Standard practice in field deployments is:

1. Maintain a versioned backup of the Options PDL folder under D:\PCS7_Backups\PDL_Source\<PCS7_Version>\.
2. Export the entire project after every change to a hot standby, including GraCS, the runtime database backup, and the project archive.
3. After applying a service pack, compare the current ...\SIEMENS\WinCC\Options\PDL against the backup. Use a file comparison tool or the stored hash to detect silent replacement.
4. If a replacement is detected, re-apply the customized files, then re-run the OS Project Editor on each affected OS to copy the customized source into the project.
5. Document the change in the project migration log; the operator should be informed if a button is added, removed, or has its action changed.

The official Siemens release notes for PCS 7 V9.0 SP1 and WinCC V7.4 SP1 Update 4 list the standard picture set shipped in the install. A delta diff against the release notes confirms whether an upgrade has replaced a specific @Button*.PDL.

Verification

After applying the change, validate it with the following checks. Each step is a discrete test that can be executed during a factory acceptance test (FAT) and a site acceptance test (SAT).

1. Static check — Open the OS picture that hosts the button set in Graphics Designer. The custom button must be visible at the expected position with the correct event scripts attached.
2. Runtime simulation — Launch the WinCC Runtime simulation from the engineering station. Click the button. Confirm the connected tag, script, or faceplate action fires and the operator's audit log records the action.
3. Cross-faceplate check — Switch between several faceplate types that share the same button set. The custom button must be present on each (button sets are referenced by name, so a missing entry on one faceplate usually points to a PDL that was not updated).
4. Multistation check — On every OS client, log in with operator rights and confirm the button is present. This validates the multistation transfer / download step.
5. Authorization check — Verify that the custom button respects the same operator authorization as the standard buttons. Use a low-authority account and confirm the button is disabled, and a high-authority account and confirm the button is enabled.
6. Hash check — Compute the SHA-256 of @Buttons11.PDL, @Buttons12.PDL, and any new PDL in the project backup folder; record in the change log.
7. Audit log check — Operate the button and confirm the entry is recorded with the correct user name, time stamp, and tag name.

Troubleshooting Matrix

Safety and Operability Considerations

Custom operator buttons inherit the same authority level as the standard PCS 7 buttons. Apply the same change-management discipline used for the standard operator surfaces: restrict access via the WinCC User Administrator, document the change in the plant log, and validate the action during a factory acceptance test (FAT) and a site acceptance test (SAT). A button that triggers a write operation should always be covered by an interlocking or by an "Are you sure?" confirmation, in line with the project's functional safety design.

For a SIMATIC PCS 7 system, the operator authorization is checked against the "Operator authorization" attribute of the button object. A custom button that must only be available to a specific group (e.g., process operators with level 5) should set this attribute explicitly, and the OS User Administrator must include the group in the matching authorization level.

If the custom button triggers a script that writes a process tag, the script must be reviewed against the project interlocks. A button that bypasses an interlock (e.g., a manual override) is a deviation from the standard interlocks and must be approved by the process safety authority. The PCS 7 change procedure requires that such deviations be tracked in the project modification log.

Related Configuration Surfaces

The button set is one of several operator surfaces that can be customized in PCS 7. The same engineering approach (source picture in WinCC Options folder, OS Project Editor copy, central configuration) applies to:

• Toolbar — defined in @Top10.PDL and related files in ...\SIEMENS\WinCC\Options\PDL.
• Status bar — defined in @Bottom10.PDL and related files.
• Standard faceplate template — defined in the PCS 7 APL library, located under ...\SIEMENS\Automation\PCS7\Library\APL_BlockIcons\.
• User archive toolbar — defined in the user archive picture, customizable via the User Archive editor.

All of these are subject to the same upgrade / backup discipline described in this article. Treat each surface as an independent customization, and keep its master file in the versioned backup directory.

FAQ