C135 PCS 7 (PCS7)
6C
6 Cielo Ciencia y Tecnología
·Publicada en C135 PCS 7 (PCS7)

Configuring Start Permissives, Runtime Interlocks, and Force Modes in PCS 7 APL MotL

Configuring Start Permissives, Runtime Interlocks, and Force Modes in PCS 7 APL MotL

In SIMATIC PCS 7 Advanced Process Library (APL), the MotL motor block differentiates between starting and running conditions. To prevent a motor from stopping when speed or process pressure remains high, do not connect the condition to the Intlock or Protect inputs, because interlocks force an active motor to stop. Instead, connect start-only conditions to the Permit input (which is evaluated strictly during motor startup and ignored while running). To force a motor to remain running regardless of manual stop commands, utilize the forcing input FwdForce (with Force = 1), or configure the OS permission bitmask OS_Perm to dynamically disable the manual stop button (StopManEn) based on operational conditions.

Table of Contents

Executive Summary

In industrial process control with SIMATIC PCS 7, proper differentiation between equipment startup permissives and runtime safety trips is critical for operational safety and equipment longevity. A frequent engineering challenge with the Advanced Process Library (APL) motor block (MotL) involves processes where a motor (e.g. a high-inertia centrifuge, slurry agitator, or cooling lube pump) must not be stopped manually or locally while equipment speed or fluid pressure remains above a critical threshold. When engineers mistakenly wire this speed threshold to the Intlock (Interlock) input, two operational failures occur: first, the interlock immediately trips the motor if speed drops; second, once stopped, the motor cannot restart because residual speed keeps the interlock active. Understanding the distinct roles of Permit, Intlock, Protect, Force, and OS_Perm provides the clean technological resolution.

APL MotL Technological Control Architecture

The APL MotL (Large Motor) block evaluates operational inputs in a strict hierarchical order:

  1. Safety Shutdown / Protect: Highest priority; shuts down the motor and requires operator reset.
  2. Interlock without Reset (Intlock): Shuts down the motor whenever active; restarts automatically when cleared.
  3. Forced Tracking (FwdForce / StopForce): Overrides manual and automatic modes to force motor state.
  4. Start Permissive (Permit): Checked only in STOP state to allow transition to RUN; ignored once running.
  5. Auto / Manual / Local Commands: Standard operator and program actuation.

Permit vs Interlock vs Protect: Functional Differentiation

Understanding the exact runtime mechanics of the three APL interlock inputs is essential:

  • Permit (Permission to Start): Active only when the motor is stopped (Run = 0). If Permit = 0, the motor cannot start. Crucially, once the motor starts and enters the RUN state, Permit is completely ignored. If the permissive signal drops to 0 while running, the motor continues running unaffected.
  • Intlock (Interlock without Reset): Evaluated continuously in both STOP and RUN states. If Intlock = 0 (interlock active), an active motor immediately trips to STOP. It cannot restart until Intlock = 1.
  • Protect (Interlock with Reset): Shuts down the motor on fault and latches the stopped state until an operator resets the block via faceplate or CFC input.

The Problem: Interlocking a Running Motor Based on Operational Speed

If an engineer wants a motor to keep running when speed is high:

  • Connecting 'Speed Not Low' to Intlock creates a logical deadlock: If the motor is stopped, speed is zero, so Intlock is violated and the motor can never start!
  • Connecting to Permit ensures the motor only starts if pre-conditions are met, but Permit cannot prevent an operator from pressing STOP.
  • Therefore, preventing a stop command while running requires disabling stop commands or asserting a run-force condition.

Command Forcing vs Operator Permission Masking

Two proven engineering methods resolve the run-hold requirement:

  • Method 1: Operator Permission Masking (OS_Perm): Set bit OS_Perm.Bit1 (StopManEn) to 0 whenever speed is high. This dynamically disables and greys out the 'STOP' button in the WinCC faceplate, physically preventing the operator from stopping the motor until speed drops.
  • Method 2: Forcing Input (FwdForce): Assert FwdForce = 1 and Force = 1 conditioned upon high speed. While active, the motor remains running forward regardless of manual stop clicks or automatic sequence commands.

APL Motor Interlock and Control Hierarchy Matrix

The following table compares the operational inputs on APL MotL:

Block ParameterEvaluated in STOP State?Evaluated in RUN State?Forces Motor STOP?Requires Operator Reset?Intended ApplicationPermitYes (Blocks Startup)No (Ignored)NoNoPre-start lube oil pressure, valve positions.IntlockYes (Blocks Startup)Yes (Trips Motor)YesNoProcess trips, high vibration, tank overfill.ProtectYes (Blocks Startup)Yes (Trips Motor)YesYes (RstOp)Thermal overload, emergency stop, motor jam.FwdForceForces RUN ForwardForces RUN ForwardNoNoEmergency smoke extraction, run-hold logic.StopManEnN/AEvaluates UI ClickDisables Stop ButtonNoPrevents premature manual shutdown.

Step-by-Step Procedure to Implement Runtime Run-Hold Logic

Method 1: Disabling Manual Stop via OS Permissions (Recommended)

  1. Open the motor's CFC chart in the CFC Editor.
  2. Insert a comparison block (e.g. Comp04 or standard analog limit monitor) evaluating motor speed (Speed_Val).
  3. Configure the comparator output SpeedHigh (TRUE when speed exceeds safe stopping threshold).
  4. Invert SpeedHigh using an inverter or NOT gate so that AllowStop = NOT SpeedHigh.
  5. Connect AllowStop to input parameter StopManEn (or bit 1 of OS_Perm) on MotL.
  6. When speed is high, StopManEn = 0, which greys out the Stop button in the WinCC faceplate.

Method 2: Conditional Forcing for Process-Critical Motors

  1. Connect the run-hold condition (SpeedHigh AND Run) to input parameter FwdForce of MotL.
  2. Connect the same condition to Force (activates forced tracking).
  3. While Force = 1, the motor ignores manual Stop commands and remains running.
  4. When speed drops or process completes, Force resets to 0, restoring standard operator control.

Verification

To verify motor control and permissive behavior:

  1. Pre-Start Permissive Check: With motor in STOP and Permit = 0, attempt to start the motor. Confirm that startup is blocked and faceplate displays 'Permit Missing'.
  2. Permit Loss in RUN: Set Permit = 1, start the motor. Once running, force Permit = 0. Confirm that the motor continues running without interruption.
  3. Run-Hold Stop Prevention: With motor running and speed high, attempt to click the Stop button in the WinCC faceplate. Confirm that the Stop button is disabled or command is rejected.
  4. Safety Trip Override: Trigger a true protective interlock (Protect = 0). Confirm that safety protection overrides run-hold and immediately trips the motor to STOP.

Limitations and Operational Precautions

  • Safety Priority: Never bypass or override safety emergency stop circuits (Protect / ESD) with forcing logic; human safety and mechanical integrity take absolute priority over process convenience.
  • Audit Trail: Forcing inputs (FwdForce) trigger operator alarms and audit logs in WinCC; ensure plant operations understand that forcing is active.
  • Feature Bit Configuration: Review block Feature Bits (e.g. Feature.Bit0 and Feature.Bit22) to ensure startup and reset behaviors match plant operational standards.

Engineer FAQ

Can Permit and Intlock be connected to the same interlock logic block?

No. They serve opposing functions; Permit is a pre-start gate, while Intlock is an active tripping mechanism.

What happens if both FwdForce and StopForce are set to 1 simultaneously?

StopForce takes higher internal priority, causing the motor to transition to or remain in the STOP state.

Why does the motor faceplate show a padlock symbol on the Stop button?

The padlock symbol indicates that the command is locked out by OS_Perm or disabled by the active operating mode.

Technical References

Related Articles

Related Tags

  • https://industrialautomation.net/search?query=simatic-pcs7
  • https://industrialautomation.net/search?query=advanced-process-library
  • https://industrialautomation.net/search?query=motor-control
  • https://industrialautomation.net/search?query=cfc-editor
6 respuestas