Disabling the OK Button in Siemens PCS 7 IL Faceplates

Siemens PCS 7 operator faceplates are designed around a two-step command philosophy: the operator first presses the command button (e.g., Open, Close, Start, Stop) and then confirms with a dedicated OK button in the command execution area. This two-step sequence is intended to prevent inadvertent actuator changes on critical equipment. On certain types of plant — particularly batch skids, packaged units, and process stages where the operator already has clear situational awareness — the second confirmation step becomes friction rather than safety. This document covers the supported and unsupported paths for hiding or disabling the OK button on IL (Individual Library) faceplates in PCS 7, including the differences between IL-for-PCS 7 and IL-for-S7, the role of the @APLCommandExecutionSteps tag, and the fallback Operator-Control Enable property.

1. Overview — PCS 7 Faceplate Architecture

Every PCS 7 faceplate is a WinCC picture (PDL file) that is composed of:

• A base PDL that contains the static layout, the tag references, and the C-script or VBA logic that drives the object.
• An operation area PDL (also called the command area) that contains the command buttons. In a 2-step faceplate the operation area contains the primary command button plus the OK button that appears in the Command execution strip.
• A set of internal tags that are typically prefixed with @ and live in the WinCC internal tag table. These control the runtime behavior (step count, visibility, operator permission flags, etc.).

The APL (Advanced Process Library) and the older IL (Individual Library) differ in how the operation area is constructed. APL faceplates read the configured step count from a runtime-internal tag and toggle the OK button visibility accordingly. IL faceplates for PCS 7 follow the same convention as APL, but IL faceplates that were originally authored for plain S7 (without PCS 7 shell services) use C-scripting for the command flow and do not read the same internal tag. The remainder of this article separates these two cases clearly because the remedy is different.

For the underlying WinCC faceplate concept, refer to the SIMATIC PCS 7 Operator Station (V9.0) manual and the SIMATIC PCS 7 APL Style Guide (V9.0).

2. Understanding the Two-Step Command Execution

PCS 7 supports a configurable command execution model with three canonical values:

The numeric value is read at faceplate instantiation time from the @APLCommandExecutionSteps internal tag (or, in some projects, from a project-wide equivalent that the APL Style Guide documents as StepOp). The faceplate compares this value against its visibility condition for the OK button graphic object and decides whether to render the control.

3. APL vs IL Faceplate Differences

The key discriminator is the command input mechanism. APL and modern IL-for-PCS 7 faceplates receive the operator action through WinCC property bindings and read the internal tag at configuration load time. IL-for-S7 faceplates use an On Click C-action that immediately issues the command to the PLC; the @APLCommandExecutionSteps tag is never queried, so changing its start value has no effect on the OK button visibility.

4. The @APLCommandExecutionSteps Tag

The @APLCommandExecutionSteps tag is an unsigned 16-bit WinCC internal tag that is referenced by every APL/IL faceplate that supports the step concept. It is created automatically the first time the APL Style Guide is applied to a project.

Changing the start value is a configuration-time change. The new value is only read the next time the faceplate is instantiated — typically when the picture containing the faceplate is closed and reopened, or when the WinCC runtime is restarted. If the change does not appear immediately, perform a full Graphics Designer recompile and reload the runtime.

5. Step-by-Step: Hiding the OK Button in IL Faceplates for PCS 7

The procedure below assumes a standard PCS 7 V9.0 SP1 or later project with the IL library already installed and at least one IL block type (e.g., a motor block, valve block, or PID controller) already compiled into the master data library.

Prerequisites

1. Engineering Station (ES) with WinCC Explorer and Graphics Designer installed.
2. Write access to the project and a current backup (export the project from the SIMATIC Manager / TIA Portal before any change).
3. User must be a member of the SIMATIC HMI Windows group with Configuration rights.
4. Confirm the faceplate being edited is an IL for PCS 7 faceplate and not an IL for S7 faceplate. Open the base PDL in the Graphics Designer, select the OK button graphic object, and inspect Properties > Events > Mouse > Click Action. If the field contains a C-script (e.g., BOOL bRet; or printf(...)), it is an IL-for-S7 faceplate and the procedure in this section will not work — proceed to Section 7 instead.

Procedure

1. Open the WinCC Explorer for the OS server that hosts the project.
2. In the navigation tree, expand Tag Management > Internal Tags.
3. Right-click the @APLCommandExecutionSteps tag and choose Properties.
4. On the General tab, set the Start value field to 2.
5. Click OK to commit the change.
6. Open the Graphics Designer, recompile all ODKs (Online-Display-Kits) and ODKs+ that reference the affected block types: Tools > Compile > OS Pictures.
7. Activate WinCC Runtime (or wait for the OS server to be restarted, depending on the project lifecycle stage).
8. Open a picture that contains the IL faceplate. The OK button should no longer be rendered in the command execution area. Pressing Open or Close should now issue the command immediately.

6. Alternative Method: Operator-Control Enable Property

The Operator-Control Enable property is a per-object permission that exists on every standard WinCC control and on every faceplate graphic object that ships with PCS 7. Setting it to No (or 0) grays the control out at runtime and prevents operator interaction. The control remains on screen, so the operator still sees the visual layout of the faceplate.

Procedure

1. Open the base PDL of the affected IL faceplate in the Graphics Designer.
2. Select the OK button graphic object in the operation area.
3. Open the Properties dialog (right-click > Properties or press Alt+Enter).
4. Navigate to Miscellaneous > Operator-Control Enable.
5. Set the value to No. For a dynamic configuration, attach a tag or expression instead of a constant — for example, a project-specific permission tag such as ProjectPermissions.CommandStep.EnableOKButton.
6. Save the PDL, recompile the OS pictures, and reload the runtime.

The Authorization property is the recommended companion to Operator-Control Enable. Even with the OK button hidden, the C-script that issues the command should still validate the operator's authorization level. This keeps the faceplate behavior consistent with the rest of the PCS 7 security model.

7. IL Faceplates for S7 (Non-PCS 7) — Limitations

IL faceplates that were authored for the legacy S7 HMI environment — that is, a WinCC project that is not part of a PCS 7 shell — use a C-action on the On Click event of each command button to dispatch the operator's intent directly to the PLC. The C-action typically calls a wrapper function (e.g., S7SetBit(...) or a project-specific C function) and then optionally waits for a status bit. There is no read of @APLCommandExecutionSteps in the C-action, so changing the internal tag's start value has no effect on the OK button visibility.

For these faceplates the supported paths are:

1. Use Operator-Control Enable. This is the only configuration-level way to disable the OK button on an IL-for-S7 faceplate without rewriting the C-script. The button is grayed out, and clicks are ignored by WinCC.
2. Use Display = No. This removes the control from the screen entirely. It is the visual equivalent of @APLCommandExecutionSteps = 2.
3. Edit the C-script. Open the base PDL, switch the C-action editor to Edit mode, and rewrite the click handler so that the return statement suppresses the OK-button confirmation path. This requires the original C-script source and the project build environment; it is not a runtime tweak.
4. Migrate the faceplate. Re-author the block type using the APL or IL-for-PCS 7 templates. The migration is the cleanest long-term answer if the project will be maintained for more than one major PCS 7 release cycle.

8. Tag Configuration in the Operation Area PDL

The operation area PDL is the small picture that contains the primary command button and the OK button. In an APL faceplate this PDL exposes a StepOp property on the cmnObj (common object) that is wired at compile time to the @APLCommandExecutionSteps internal tag.

To verify the wiring:

1. Open the operation area PDL of the affected block type. For a valve, this is typically named @APL_VlvOpArea.pdl (or the IL equivalent @IL_VlvOpArea.pdl).
2. Select the cmnObj instance on the PDL canvas.
3. Open Properties > Miscellaneous > StepOp.
4. Confirm that the right-hand column contains the @APLCommandExecutionSteps tag. If the field is empty, the faceplate has been hand-edited and the tag wiring must be restored before the start-value change will propagate.

For IL faceplates that are missing the StepOp wiring, the practical outcome is exactly the symptom reported in the field report: the OK button stays visible regardless of the start value. The fix is to reattach the @APLCommandExecutionSteps tag to the StepOp property, recompile, and reload.

9. Engineering Station vs. Client/Server

The @APLCommandExecutionSteps tag is stored in the WinCC internal tag table of the OS server. In a multi-client configuration, each client receives the tag value from its assigned preferred server. The implications are:

A common failure mode is to edit the start value on the ES but forget to download the OS project to the runtime server. The Graphics Designer shows the new value, but the runtime keeps the old one until the OS project is downloaded. Always check the OS Project Editor > Compile and Download log for a successful transfer.

10. Verification and Commissioning

After applying the change, perform the following verification steps before signing off the modification:

1. Visual verification. Open a representative picture that contains at least three different IL faceplate types (e.g., a motor, a valve, a PID controller). Confirm that the OK button is not visible in the command execution area of each.
2. Functional verification. With the operator logged in at the required authorization level, press Open on a valve faceplate. The actuator should start to move within the configured command execution timeout (default 5 s in PCS 7 V9.0, per the Operator Station manual). Repeat for Close.
3. Audit trail verification. Open the WinCC Alarm Logging / Audit trail. The operator action should be recorded as a single entry, not as a "click on Open" followed by a "click on OK" entry.
4. Authorization regression check. Log in as an operator that does not have the command authorization level. The primary command button should still be grayed. If the primary button is enabled, the C-script authorization check has been bypassed — investigate before going live.
5. Failover regression check (redundant servers only). Force a failover from OS Server 1 to OS Server 2. Repeat the visual and functional verification on the now-active server.
6. Client regression check. Open the same picture on at least one client station. Verify the OK button is still hidden and the command executes with a single click.

11. Troubleshooting Matrix

12. Safety and Operational Considerations

Removing the OK-button confirmation step reduces the friction in the operator workflow but it also removes a built-in safeguard against inadvertent commands. Before deploying the change to a live plant, the following items should be reviewed and signed off by the process safety and operations teams:

• Confirm that the affected actuators are not part of a Safety Instrumented Function (SIF). The OK-button step is a Human-Machine Interface (HMI) confirmation and is not a substitute for the safety PLC, but removing it from the HMI on a SIF-protected actuator can complicate the operator's mental model.
• Review the operator competency matrix. If the panel is staffed by junior operators, the two-step confirmation is often a useful training aid.
• Document the change in the project Functional Specification. Future modifications to the project may rely on the documented two-step behavior; removing it without documentation is a common cause of audit findings.
• For 21 CFR Part 11 regulated environments, ensure the audit trail captures the operator action on the primary button press. Without the OK button, the audit entry is generated by a different trigger and the audit query templates must be updated.