Resolving Initial LockAct State and Protect Interlock Latching After CFC Download in APL Drives

When SIMATIC PCS 7 APL motor blocks (MotL, MotRevL) initialize with 'LockAct = 1' and a latched 'Protect' interlock fault following a CPU download or restart despite healthy field signals, the behavior is caused by interlock block evaluation during controller initialization (OB100) or execution order priority in the cyclic interrupt OB. If input channel drivers (Pcs7DiIn) or interlock logic blocks (Intlk02/Intlk04/Intlk08) execute after the motor block or experience a momentary low state during startup, latched interlocks trip. To resolve this, configure the correct chart runtime execution sequence, verify Feature.Bit28 on MotL, or disable startup latching on the upstream interlock blocks.

APL Drive Block Interlock Architecture (Protect, Permit, Interlock)

In the SIMATIC PCS 7 Advanced Process Library (APL), technological drive blocks (such as MotL, MotRevL, and MotSpdCL) implement three distinct interlock levels:

Permit (Permit): Checked only before starting the drive. Once running, losing Permit does not shut down the motor.
Interlock without Latch (Intlock): Operational interlock. If violated (Intlock = 0), the drive stops. When the interlock clears (Intlock = 1), the drive can be restarted automatically or manually without operator fault acknowledgment.
Protection Interlock (Protect): Critical equipment protection. If violated (Protect = 0), the drive trips immediately, locks the output (LockAct = 1), and latches the fault. The drive cannot start until the interlock signal restores AND an explicit reset command is issued via faceplate (RstOp) or program interconnection (RstLi).

Root Cause of Startup Interlock Latching (OB100 vs Cyclic OBs)

When a CPU restarts after a full download or power cycle, blocks execute initialization code in the startup organization block (OB100) before cyclic processing begins in OB3x (e.g. OB35 at 100 ms):

During the very first cyclic scan, distributed I/O drivers (Pcs7DiIn) communicating over PROFINET or PROFIBUS DP may require several milliseconds to complete module parameterization and establish valid telegram exchange.
Before valid field data arrives, driver outputs default to 0 with quality code 16#00 (Bad) or 16#4C (Uncertain).
If an upstream interlock block (Intlk02 or Intlk08) evaluates this initial 0 state and has latching enabled (L_Pathx = 1), it latches into the tripped state (Out = 0 and Trip = 1), which transfers into MotL.Protect.
Even though the field signal turns green (1) a few milliseconds later, the latch remains locked until manually reset.

Runtime Sequence and Execution Order Priority

A frequent engineering error causing startup lockups is an incorrect Runtime Sequence (Ablaufreihenfolge) in CFC:

If the MotL block is scheduled earlier in the OB35 task than its input driver Pcs7DiIn and interlock Intlk02 blocks, the motor evaluates uninitialized or stale data on cycle 1.
Mandatory Sequence Rule: Ensure blocks execute strictly in topological data-flow order:
1. Input Channel Drivers (Pcs7DiIn, Pcs7AnIn)
2. Logic and Calculation Blocks (And04, Or04)
3. Interlock Blocks (Intlk02, Intlk04, Intlk08)
4. Technological Control Blocks (MotL, VlvL, PIDConL)
5. Output Channel Drivers (Pcs7DiOu, Pcs7AnOu)

Configuring Feature Bits for Interlock Latching and Reset

APL blocks provide extensive configuration flags (Feature bits) to govern reset and startup behavior:

Feature.Bit28 (Disabling operating states on interlock): Configures whether tripping an interlock requires operator acknowledgment before restarting.
Feature.Bit30 (Resetting depending on the operating mode): Determines whether reset commands can be issued in Manual mode, Auto mode, or both.
Interlock Block Latching (L_Path1...L_Pathx): On Intlk02/04/08, setting L_Pathx = 0 converts that path into an unlatched evaluation, eliminating false trip latching upon startup while still providing continuous trip protection.

Comparison of APL Interlock Types and Reset Behaviors

The table below contrasts the operating behavior of the three APL interlock inputs:

Interlock PinEvaluation TimingMotor Tripped WhenAuto-Restart Upon Signal RecoveryFaceplate Acknowledgment RequiredPermitPrior to motor start onlyNot Applicable (Prevents start)Allowed once Permit = 1NoIntlockContinuous while runningIntlock = 0Yes (If Auto mode allows)NoProtectContinuous at all timesProtect = 0No (Latches trip state)Yes (Explicit Reset required)Intlk02 (Latched)Continuous evaluationAny active In = 0No (Latches internally)Yes (Reset on Intlk or MotL)Intlk02 (Unlatched)Continuous evaluationAny active In = 0Yes (Clears when In = 1)No

Verification

Verify correct startup and interlock behavior:

In CFC, open the chart containing MotL and verify that Protect is connected to an Intlk block.
Open the Runtime Sequence Editor (Ctrl+F5); verify the channel drivers execute prior to the interlock blocks, and the interlock blocks execute prior to MotL in OB35.
Perform a CPU warm restart (or download changes); observe the block online.
Confirm that LockAct remains 0 and Protect shows green (1) without requiring manual operator intervention.
Simulate a physical protection trip; verify the block stops, locks (LockAct = 1), and successfully resets via faceplate.

Limitations and Operational Precautions

Review the following technical precautions regarding interlock logic:

Safety Integrity Guardrail: Never bypass or disable latching on critical emergency stops, high-pressure safety switches, or thermal overloads. The Protect input exists specifically to prevent unexpected automatic restarts after dangerous trips.
Group Reset Coordination: If multiple motors trip simultaneously upon startup, use a central pulse generator triggered after OB100 timer completion to pulse RstLi across non-critical drives.
Signal Quality Checking: Verify that Pcs7DiIn.Bad is factored into interlock logic to prevent floating inputs from causing sporadic nuisance trips.

Engineer FAQ

Why does LockAct equal 1 even though all inputs to the Protect interlock are green?

Because Protect is a latching safety interlock. If the interlock was momentarily broken during CPU startup (before distributed I/O drivers initialized), the block latches into the tripped state and requires an explicit Reset (RstOp or RstLi) to unlock.

How does the runtime sequence in OB35 affect block startup?

If the motor block is positioned before the input driver blocks in the cyclic OB execution list, the motor reads uninitialized driver memory on cycle 1, causing a momentary false interlock trip that latches.

Can I reset latched interlocks automatically from logic without operator intervention?

Yes, by connecting a reset pulse (e.g. from an automatic sequence or startup delay timer) to the RstLi input parameter while Feature.Bit30 is configured to accept program resets.