Configuring External Interlock Messages (Permit, Protect, Interlock) via Alarm_8P on MotSpdCL

Configuring External Interlock Messages (Permit, Protect, Interlock) via Alarm_8P on MotSpdCL

In SIMATIC PCS 7 Advanced Process Library (APL), configuring interlock trip messages (for Permit, Protect, or Interlock) on motor block MotSpdCL (FB1856) is accomplished using the block's native external message inputs (ExtMsg1, ExtMsg2, ExtMsg3) rather than inserting standalone Alarm_8P blocks. Standard interlock blocks (Intlk02, Intlk04) lack messaging capabilities. By connecting inverted interlock outputs to ExtMsg1..3, MotSpdCL utilizes its integrated Alarm_8P instance (signals SIG4..6) to generate alarms tied directly to the motor's technological tag. This approach consumes zero additional Process Objects (PO), ensures proper Group Display alarm propagation, and allows operators to jump directly to the motor faceplate.

Table of Contents

Architectural Evaluation: Native ExtMsg Inputs vs Standalone Alarm_8P

When automating variable-speed drives with MotSpdCL (FB1856) in SIMATIC PCS 7, engineers frequently need distinct alarms when a start permissive is violated, an operating interlock trips, or a safety protection interlock opens. Automation architects can technically choose between two engineering approaches:

Engineering DimensionNative External Messages (ExtMsg1..3)Standalone Alarm_8P Block (SFB35)Process Object (PO) Impact0 PO consumed (Embedded in MotSpdCL)Consumes 1 AS RT PO and 1 OS RT POAlarm Tag AssociationLinked directly to technological motor tag (101_PUMP)Assigned to generic Alarm_8P block nameGroup Display PropagationAutomatically illuminates motor overview alarm badgeRequires manual Group Display interconnectionFaceplate NavigationDouble-clicking alarm line opens motor faceplateOpens generic alarm view; no faceplate bindingController Memory OverheadZero additional DB instance overheadRequires separate instance DB and OB execution time

Siemens PCS 7 best-practice design strictly recommends utilizing the native ExtMsg1..3 inputs embedded within technological blocks.

Mapping Interlock Trip Signals (Permit, Protect, Interlock) to ExtMsg

APL interlock blocks (Intlk02, Intlk04, Intlk08) output Out = 1 when all permissive conditions are satisfied, and Out = 0 when an interlock is tripped. Conversely, MotSpdCL external message inputs trigger alarms on rising edges (0 -> 1).

To establish clear, segregated alarms for all three interlock categories, map the inverted interlock signals:

  • Permit Violation (Start Permissive Missing): Connect inverted Intlk_Permit.Out to MotSpdCL.ExtMsg1. Map SIG4 in MotSpdCL to Message Class Process Message or Warning: $$BlockComment$$ Start Permissive Missing.
  • Operating Interlock Trip (Intlock): Connect inverted Intlk_Operating.Out to MotSpdCL.ExtMsg2. Map SIG5 to Message Class Alarm - High: $$BlockComment$$ Operating Interlock Tripped.
  • Safety Protection Trip (Protect): Connect inverted Intlk_Protect.Out to MotSpdCL.ExtMsg3. Map SIG6 to Message Class Alarm - High: $$BlockComment$$ Safety Protection Interlock Tripped.

Step-by-Step CFC Configuration and Message Parameterization

To implement this interlock alarming architecture in CFC, execute the following technical procedure:

  1. Place Interlock Blocks: In the CFC chart containing MotSpdCL, place Intlk04 blocks for Permit, Interlock, and Protect.

  2. Interconnect Interlocks to Motor Inputs:
    - Connect Intlk_Permit.Out -> MotSpdCL.Permit.
    - Connect Intlk_Operating.Out -> MotSpdCL.Intlock.
    - Connect Intlk_Protect.Out -> MotSpdCL.Protect.

  3. Interconnect to External Message Inputs with Inversion:
    - Connect Intlk_Permit.Out -> MotSpdCL.ExtMsg1 (Invert input: Ctrl+I).
    - Connect Intlk_Operating.Out -> MotSpdCL.ExtMsg2 (Invert input: Ctrl+I).
    - Connect Intlk_Protect.Out -> MotSpdCL.ExtMsg3 (Invert input: Ctrl+I).

  4. Configure Alarm Message Texts:
    - Right-click MotSpdCL and select Object Properties. Click 'Messages...'.
    - In row SIG4 (ExtMsg1), enter Event Text: $$BlockComment$$ Start Permissive Not Met.
    - In row SIG5 (ExtMsg2), enter Event Text: $$BlockComment$$ Interlock Tripped.
    - In row SIG6 (ExtMsg3), enter Event Text: $$BlockComment$$ Emergency Protect Tripped.

  5. Compile and Download: Save the dialog. Compile CFC changes (Chart -> Compile -> Changes Only) and download to the AS. Execute an OS compilation (Compile OS -> Changes Only) to update WinCC Alarm Logging.

Verification

Verify alarm generation and faceplate response through these diagnostic tests:

  1. Simulate Interlock Trip: In CFC Test Mode, force an input on the operating interlock (Intlk_Operating.In01 = 0).
  2. Actuator Shutdown: Verify that MotSpdCL.Fwd and SP_Out transition immediately to 0, stopping the drive.
  3. WinCC Alarm Banner Verification: In WinCC OS Runtime, observe the alarm banner. Confirm that an alarm appears reading:
    [Tag: 101_DRIVE_01] Interlock Tripped
  4. Faceplate Navigation: Double-click the alarm line in the OS alarm banner. Confirm that the WinCC system automatically opens the MotSpdCL faceplate with the interlock tab highlighted.

Limitations and Operational Precautions

When configuring drive interlock alarms, adhere to these operational and alarm standards:

  • ISA-18.2 Rationalization: Do not configure high-priority audible alarms on start permissives (Permit). An unmet permissive is an operator prompt, not an emergency trip; assign it to message class 'Process Message' or 'Operator Prompt'.
  • Mandatory Input Inversion: Always double-check the inversion bubble on ExtMsg1..3. Failing to invert will cause continuous standing alarms while the interlock is healthy.
  • First-Out Logic: If an interlock combines multiple conditions, utilize the FirstIn function on Intlk04/08 so operators can identify which specific sensor tripped first.

Engineer FAQ

Can I pass the tag name of the failing sensor into the motor alarm text?

Yes. By interconnecting the sensor's tag string or index into associated values (ExtVa104..07), dynamic placeholders can display the exact instrument name in the alarm.

Why should I avoid using standalone Alarm_8P blocks?

Standalone Alarm_8P blocks consume unnecessary Process Object (PO) licenses and break direct navigation from the WinCC alarm line to the technological motor faceplate.

Does MotSpdCL support more than three external messages?

Standard MotSpdCL provides three external message inputs (ExtMsg1..3). If more are required, consider routing secondary alarms through digital monitoring blocks (MonDiL).

Technical References

Related Articles

Related Tags

  • MotSpdCL
  • Alarm 8P
  • ExtMsg
  • Interlocks
  • Protect
  • APL
6 respuestas