Troubleshooting Operator Command Freezes on Grouped AS Blocks in SIMATIC PCS 7 - APL Command Reset Handshakes

When grouping technological AS blocks into custom composite function blocks or wrapper charts following Siemens application examples, operator commands freezing (e.g., ManModOp switching from 0 to 1 and remaining permanently high, refusing subsequent AutModOp commands) occurs because the outer wrapper block continuously overwrites the inner block's input parameters. In the PCS 7 Advanced Process Library (APL), operator commands (*Op) are designed as single-cycle pulse handshakes: the operator faceplate writes a 1, and the inner APL block resets its own input to 0 after processing. If an outer composite block maps these commands via static VAR_INPUT parameters, the outer wrapper's instance DB retains the 1 and perpetually overwrites the inner block every cycle. To resolve this, define operator command parameters as VAR_IN_OUT or implement explicit reset logic in the outer wrapper code to clear the command parameter after execution.

APL Operator Command Processing Architecture: Single-Cycle Handshakes

In SIMATIC PCS 7 Advanced Process Library (APL), interaction between WinCC operator faceplates and controller function blocks relies on a deterministic command handshake mechanism. Technological blocks (such as MotL, MotRevL, VlvL, PIDConL, and MonAnL) feature dedicated operator input parameters ending in Op—for example, ManModOp (Manual mode command), AutModOp (Auto mode command), StartOp, StopOp, OpenOp, and CloseOp.

The APL runtime engine processes operator commands using strict pulse logic:

WinCC Write Action: When an authorized operator clicks 'Manual' on the standard APL faceplate, a WinCC C-script or VBScript writes 1 to the block's ManModOp tag via the S7 Named Connection.
AS Evaluation Cycle: During the next cyclic interrupt scan (e.g., OB35), the APL block evaluates ManModOp. If preconditions (interlocks, ModLiOp = 0, and permissions) are satisfied, the block transitions its internal operating mode to Manual (ManAct = 1).
Automatic AS Reset: Within the very same PLC execution scan, the APL block's internal firmware resets its own input parameter back to 0 (ManModOp := false;). This self-resetting behavior ensures the command functions as a momentary pulse, freeing the block to accept subsequent commands (such as an automatic mode request AutModOp or a sequence command).

Root Cause Analysis: Why Composite and Wrapper Blocks Latch *Op Parameters

When engineers create composite function blocks (grouping multiple APL blocks into a single custom FB or wrapper block to represent complex skids or multi-motor units, as described in Siemens application note 28757820), command freezing is a frequent pitfall.

The problem arises from how data is passed between the outer wrapper block and the inner APL block instances:

If the outer block exposes ManModOp as a standard VAR_INPUT, the outer block receives the operator click from WinCC and stores 1 in its own Instance Data Block (DB).
In the execution code, the outer block calls the inner MotL instance, passing #ManModOp to the inner MotL.ManModOp.
The inner MotL executes, processes the mode change, and clears its own internal input to 0.
The Failure Point: In the very next OB35 scan cycle, the outer block executes again! Because the outer block's VAR_INPUT variable #ManModOp in its instance DB still contains 1 (because WinCC only wrote to it once, and inputs cannot be self-reset by caller blocks across normal input boundaries), the outer block immediately re-writes 1 into the inner block's ManModOp.
As a result, the inner block is held permanently in an active Manual command state. When the operator subsequently clicks 'Auto', the inner block receives AutModOp = 1, but because ManModOp is also simultaneously forced to 1 by the outer wrapper, the block's priority logic (which prioritizes Manual over Auto for personnel safety) rejects the automatic transition.

Siemens Multi-Instance Faceplate Architecture (Entry 28757820 Context)

Siemens Entry 28757820 ('Grouping AS blocks and faceplates in SIMATIC PCS 7') provides architectural guidance on how to integrate multiple technological blocks into a combined operational faceplate. When following this guide, engineers must decide whether to wrap the blocks in a single master SCL function block (Multi-Instance FB) or keep them as discrete blocks in a CFC chart connected via Chart-in-Chart or interlocks.

Multi-Instance Approach: Inner blocks are declared as static variables (VAR) inside a parent SCL block. Faceplate communication binds to the parent block's DB. In this design, operator command parameters must be passed using reference pointers or reset handshakes.
Chart Grouping Approach: Blocks remain independent in CFC, but their block icons are grouped into a composite icon or parent faceplate. In this scenario, WinCC writes directly to each individual block's native tags, bypassing wrapper DB retention.

Remediation Strategies: VAR_IN_OUT vs Explicit Handshake Reset in SCL

To resolve command latching in custom wrapper blocks, engineers can implement two proven engineering solutions:

Explicit SCL Reset Logic in Wrapper Code (Recommended):
Maintain ManModOp as an input or in-out, and after calling the inner block, check if the inner block has processed the command or copy the inner block's reset state back to the wrapper's instance DB:
```scl
// Call Inner Motor Instance
#InstMotor(
ManModOp := #ManModOp,
AutModOp := #AutModOp,
...
);

// Reset wrapper operator commands once inner block resets them
IF NOT #InstMotor.ManModOp THEN
#ManModOp := FALSE;
END_IF;
IF NOT #InstMotor.AutModOp THEN
#AutModOp := FALSE;
END_IF;
```

Use VAR_IN_OUT Parameters:
Declaring operator command variables as VAR_IN_OUT in SCL forces the compiler to pass the parameters by reference (pointer) rather than value copy. When the inner block resets the parameter to 0, it directly overwrites the caller's memory location, preventing re-latching.

Comparative Evaluation Matrix: Command Parameter Passing Techniques

The following table evaluates parameter design strategies for custom composite blocks in SIMATIC PCS 7 APL:

Parameter StrategyMemory HandlingCommand Reset BehaviorWinCC Tag BindingComplexityRisk of FreezingStatic VAR_INPUTValue copied to Instance DBFails (DB retains 1 perpetually)Direct WinCC Tag WriteLowExtreme (Continuous Latching)VAR_INPUT with SCL ResetHandshake reset via codeSuccessful (Wrapper clears tag)Direct WinCC Tag WriteModerateZero (Deterministic)VAR_IN_OUT ParameterPassed by pointer referenceSuccessful (Inner block clears ref)Requires Global Tag DB LinkModerateLow (Requires CFC Wiring)Direct Faceplate Tag LinkBypasses wrapper block DBSuccessful (Native APL logic)Bound directly to inner blockLowZero (Native PCS 7 Standard)

Step-by-Step Implementation: Correcting Command Resets in Composite Blocks

To correct a composite block where operator commands are frozen, follow these steps:

Open Custom SCL Wrapper Source:
- In SIMATIC Manager, navigate to the Sources folder of your S7 Program.
- Double-click the SCL source file containing the composite function block.
Implement Command Reset Handshake:
- In the executable section, locate the call to the inner APL instances (InstMotL, InstVlvL).
- Immediately following the block invocation, add conditional reset code for all operator command tags:
```scl
#InstMotL.ManModOp := #ManModOp;
#InstMotL.AutModOp := #AutModOp;
#InstMotL.StopOp := #StopOp;
#InstMotL.StartOp := #StartOp;

// Execute inner block
#InstMotL();

// Force self-clearing reset on wrapper instance variables
#ManModOp := #InstMotL.ManModOp;
#AutModOp := #InstMotL.AutModOp;
#StopOp := #InstMotL.StopOp;
#StartOp := #InstMotL.StartOp;
```
Recompile SCL Source:
- In the SCL editor, select File > Compile (Ctrl+F9).
- Ensure the compiler reports zero errors and zero warnings.
Update Block Types in CFC:
- Open any CFC chart in the project.
- Select Options > Block Types.
- Select the updated wrapper FB in the Offline block folder and click -> New Version.
- Acknowledge interface changes and compile changes to CPU.
Download and Test:
- Perform a Changes Download to the AS (or test in S7-PLCSIM).
- Verify that clicking Manual resets ManModOp to 0 immediately after mode activation.

Verification

Verify correct operation using the following procedure:

Open the CFC chart containing the wrapper block instance in Test Mode (Ctrl+T).
Add ManModOp, AutModOp, and ManAct to the watch table / dynamic display.
Open the corresponding WinCC faceplate in OS Runtime.
Click Manual. Observe that in CFC, ManModOp briefly pulses to 1 and instantaneously resets back to 0 while ManAct transitions to 1.
Next, click Automatic on the faceplate. Confirm that AutModOp pulses to 1 and resets to 0, and the operating mode successfully transitions to Automatic (AutAct = 1), confirming that commands no longer latch.

Limitations and Operational Precautions

CPU Cycle Timing: Operator command resets occur within the same execution cycle of the block. If communication occurs between blocks in different OBs (e.g., OB1 and OB35), asynchronous task preemption can cause lost pulses unless handshakes are acknowledged across cycles.
ModLiOp Setting: Always verify that ModLiOp = 0 when testing faceplate commands. If ModLiOp = 1, the block is configured for interconnected CFC logic (AutModLi, ManModLi), and faceplate operator commands (*Op) are intentionally disabled by the APL security engine.
Online Changes Download: Updating the interface of a composite block that is instantiated across multiple charts may require CPU memory reorganization. Ensure adequate reserve memory exists before downloading changes.

Engineer FAQ

Why does `ModLiOp` affect faceplate commands?

ModLiOp is the APL mode switch selector. When ModLiOp = 0, mode switching is controlled exclusively by operator commands from the faceplate (ManModOp, AutModOp). When ModLiOp = 1, mode switching is governed by interconnected logic lines (ManModLi, AutModLi).

Can I reset the wrapper input using a CFC inverter block?

No. Connecting external logic to an operator input (*Op) in CFC violates APL conventions and prevents the WinCC faceplate from writing to the parameter, as WinCC writes will collide with cyclic CFC block outputs.

Why do standard Siemens APL blocks not suffer from this issue?

Standard APL blocks have internal micro-code that executes #ManModOp := false; at the end of every scan cycle. The issue only manifests when engineers place an outer wrapper around the block without replicating this reset mechanism.

What happens if WinCC writes to `ManModOp` while the CPU is stopped?

If the CPU is stopped, WinCC cannot communicate via S7 Named Connections, so the tag write will fail with a communication error. Writes only occur when the CPU is in RUN mode.

Can I use `Feature` bits to alter command reset behavior?

No. The self-resetting nature of operator commands is fundamental to APL safety architecture and cannot be disabled via Feature bits.

Technical References

Related Tags

APL
Operator Commands
ManModOp
Composite Blocks
SCL Programming
Multi-Instance
Command Reset

6 respuestas

Troubleshooting Operator Command Freezes on Grouped AS Blocks in SIMATIC PCS 7 - APL Command Reset Handshakes