Configuring PCS 7 APL_OP_BUTTON for Mode Selection Faceplates

Overview

The Siemens PCS 7 APL (Advanced Process Library) ships a standardized set of operator faceplate elements that enforce a consistent look-and-feel across every block icon in the operator system. When a project engineer creates a custom function block (FB) — for example a vendor-specific controller, a calculated property, or a derived indicator — the same operator interaction model must be preserved. The central element for mode switching inside an APL faceplate is the APL_OP_BUTTON, which encapsulates the visual push-button, the binary link to the underlying PLC tag, and the operator permission logic in one reusable WinCC object.

The objective of this reference is to walk through every signal that the APL_OP_BUTTON consumes and produces, so that an engineer building a custom block can:

• Expose MAN / AUT / OOS (Manual / Automatic / Out-of-Service) mode selection through the standard faceplate.
• Pass operator authorization correctly via the OS_PermLog permission tag and the OS_Perm input.
• Map the three mode links (AutModOp, ManModOp, OosOp) to internal FB inputs so the WinCC runtime writes the operator's request back to the PLC.
• Reflect the actual current mode through the Status1 output so the csoStMode indicator updates accordingly.

The canonical reference for the APL faceplate conventions is the PCS 7 Libraries APL Style Guide (entry ID 43705259), which documents the APL_OP_BUTTON properties on page 108 of the current revision.

Prerequisites

Before configuring the APL_OP_BUTTON, verify the following items are in place on the engineering station:

• PCS 7 V9.0 SP2 / V9.1 / V10.0 engineering software installed (procedure applies analogously to V8.2 with the matching APL library revision).
• SIMATIC Manager or the PCS 7 Engineering tool open against the target project.
• WinCC Explorer installed locally with the Graphics Designer and the APL library registered under Options → Libraries.
• The custom FB compiled, downloaded to the AS, and available as a CFC chart instance.
• The stUser global script function and the APL styleguide PDF accessible from Start → SIMATIC → Documentation.

Anatomy of the APL_OP_BUTTON Object

The APL_OP_BUTTON is a compound WinCC object that combines a graphics rectangle, a binary link slot, a permission tag slot, and a configurable label. When inserted into a faceplate picture (typically @pg_apl_oa_binary*.PDL) it exposes the configuration attributes listed below.

For the MAN/AUT/OOS mode selector, three separate APL_OP_BUTTON instances are inserted. Each instance is bound to its own BinLink 1 pointing at the corresponding FB input bit (ManModOp, AutModOp, OosOp). The shared PermissionTag is the OS_PermLog output of the FB.

Wiring the Permission Tag: OS_PermLog and OS_Perm

Authorization is enforced by a double-word bitmask. The bit allocation used by PCS 7 is fixed by the APL style guide:

Inside the custom FB the engineer must create a DWORD input OS_Perm (consumed from the user administrator block, e.g. @APL_USERLEVEL) and a DWORD output OS_PermLog that mirrors the bits relevant for the mode selector. The simplest pattern is to AND OS_Perm with the bitmask of allowed operations:

FUNCTION_BLOCK MyCustomFB
VAR_INPUT
    OS_Perm      : DWORD;   // authorization input from UMG
END_VAR
VAR_OUTPUT
    OS_PermLog   : DWORD;   // permission log for APL_OP_BUTTON
    Status1      : WORD;    // current mode reflected to faceplate
END_VAR
VAR
    AutModOp     : BOOL;    // operator command: Auto
    ManModOp     : BOOL;    // operator command: Manual
    OosOp        : BOOL;    // operator command: Out-of-Service
END_VAR
BEGIN
    // Build permission log: only bits 0,1,2 are evaluated by the mode buttons
    OS_PermLog := OS_Perm AND 16#00000007;

    // Status1 reflects the current mode (e.g. 1=AUT, 2=MAN, 4=OOS)
    IF g_bAutoActive THEN
        Status1 := 1;
    ELSIF g_bManualActive THEN
        Status1 := 2;
    ELSIF g_bOutOfService THEN
        Status1 := 4;
    END_IF;
END_FUNCTION_BLOCK

Bind OS_PermLog to the PermissionTag property of every APL_OP_BUTTON instance used for mode selection. The runtime then greys out the button if the logged-in operator does not own the corresponding bit.

Creating AT Views of the Authorization DWORD

For projects that need to read individual bits from OS_Perm inside the FB (for example to disable internal interlocks when the operator has no right to command), create an AT view. This avoids manual bit-shifting and keeps the code self-documenting:

VAR
    // AT view of OS_Perm — same memory area, symbolic bit access
    OS_PermView AT OS_Perm : STRUCT
        AutModOp_perm   : BOOL;   // bit 0
        ManModOp_perm   : BOOL;   // bit 1
        OosOp_perm      : BOOL;   // bit 2
        Spare_03        : BOOL;   // bit 3
        Spare_04        : BOOL;   // bit 4
        Spare_05        : BOOL;   // bit 5
        Spare_06        : BOOL;   // bit 6
        Spare_07        : BOOL;   // bit 7
        OperLevel_Lo    : BYTE;   // bits 8-15: legacy level
        Reserved        : WORD;   // bits 16-31
    END_STRUCT;
END_VAR

The same pattern works for OS_PermLog if the engineer needs symbolic access from the FB body. Keep the AT declaration in the same VAR block as the source DWORD so the compiler knows the layout.

Configuring the Mode Links: AutModOp, ManModOp, OosOp

The three links are inputs of the custom FB. WinCC sets them to TRUE for exactly one cycle when the operator clicks the corresponding button. The FB must therefore implement edge evaluation and a mutual-exclusion rule so that only one mode is active at a time.

// Edge-triggered mode latch
IF AutModOp AND NOT g_bAutoActive_pending THEN
    g_bAutoActive_pending := TRUE;
    g_bManualActive_pending := FALSE;
    g_bOutOfService_pending := FALSE;
END_IF;
IF ManModOp AND NOT g_bManualActive_pending THEN
    g_bAutoActive_pending := FALSE;
    g_bManualActive_pending := TRUE;
    g_bOutOfService_pending := FALSE;
END_IF;
IF OosOp AND NOT g_bOutOfService_pending THEN
    g_bAutoActive_pending := FALSE;
    g_bManualActive_pending := FALSE;
    g_bOutOfService_pending := TRUE;
END_IF;

// Acknowledge the operator request so the next cycle can re-arm
AutModOp := FALSE;
ManModOp := FALSE;
OosOp    := FALSE;

The acknowledgment at the end of the cycle is critical. Without it the APL_OP_BUTTON will keep displaying the "pressed" visual because the link remains TRUE on the WinCC side.

Mapping Status1 to the csoStMode Display

The faceplate @pg_apl_oa_binary105.PDL uses csoStMode as the visual state object. Internally it evaluates the value bound to BinLink 1 of that compound status object. The custom FB must therefore publish a numeric state — not three separate booleans — to that binlink. The convention used by the APL is:

Bind the FB output Status1 to BinLink 1 of the csoStMode status object inside the same faceplate. The standard APL pictures then render the correct color automatically.

Setting the ObjectName in stUser

The stUser object stores the operator's current role level and a list of objects that the logged-in user is authorized to manipulate. When the user changes, stUser is updated and every APL_OP_BUTTON re-evaluates its permission tag. If the ObjectName of an inserted APL_OP_BUTTON is missing from stUser, the button stays disabled regardless of the permission tag.

Procedure:

1. Open the faceplate picture in Graphics Designer.
2. Right-click the APL_OP_BUTTON instance → Properties → Miscellaneous → ObjectName.
3. Enter a unique identifier, e.g. MyFB_Mode_AUT, MyFB_Mode_MAN, MyFB_Mode_OOS.
4. Open the global C-script stUser (normally under Global Script → C-functions → Standard Functions).
5. Append the three identifiers to the array that stUser iterates over when re-evaluating permissions.
6. Recompile the OS and reload the runtime.

Disabling Permission Checking During Commissioning

During the SAT/FAT phase it is often desirable to bypass authorization so that any logged-in engineer can move the block. Set PermissionTag on each APL_OP_BUTTON to 0 temporarily. The button will then always be enabled. Remember to revert the binding to OS_PermLog before the plant is handed over to operations.

Script Diagnostics with apdiag.exe

If a faceplate opens but no button reacts, the issue is frequently a malformed C-script or a missing tag. Run the APL diagnostics utility to dump script errors at runtime:

1. Navigate to %ProgramFiles(x86)%\Siemens\WinCC\uTools\.
2. Launch apdiag.exe on the OS server (or on the engineering station with a local WinCC runtime).
3. Select Live diagnostics → Scripts.
4. Trigger the faceplate in runtime and observe the script trace.

Common findings are "Tag not found" (typo in the BinLink name), "Permission denied" (object not registered in stUser), or "Type mismatch" (BinLink bound to INT instead of BOOL).

Verification Procedure

After completing the wiring, validate the configuration end-to-end:

1. Compile the OS, download the runtime, and activate the project.
2. Open the custom block's faceplate from the plant picture.
3. Confirm that csoStMode displays the current mode with the correct color.
4. Log in as an operator that owns bit 0 (AUT permission). Click the AUT button and verify Status1 := 1 on the AS using STEP 7 online watch.
5. Log out, log back in as an operator that does not own bit 2 (OOS permission). Confirm the OOS button is greyed out.
6. Switch user via the user administrator and verify stUser refreshes the buttons without restarting the runtime.
7. Inspect the @pg_apl_oa_binary105.PDL properties in Graphics Designer and verify the BinLink bindings still point at the new FB symbols after recompilation.

Troubleshooting Matrix

Field-Proven Caveats

• Bit ordering on big-endian controllers: S7-1500 CPUs default to little-endian. The AT view bit layout is therefore as shown in the table; swapping the CPU byte order will scramble the authorization bits without raising a compile error.
• Multilingual labels: When localizing the button label, populate the Text Library entry referenced by the APL_OP_BUTTON rather than hard-coding the string. This avoids drift between the runtime text and the help text.
• Cycle-time impact: The acknowledgment of AutModOp, ManModOp, and OosOp must occur in the same OB1 cycle as the latch, otherwise a 1-second race condition appears in slow loops.
• PCS 7 V10 SCD migration: When migrating a V9 project to V10, the APL_OP_BUTTON instances are carried over but the stUser array is regenerated. Re-register every renamed ObjectName.
• Redundant OS pairs: On redundant OS servers, both servers must be recompiled with the same APL revision. Mixed revisions cause the permission tag to drift after failover.

FAQ