PLC Interlocks and Permissives: Start Chain, Trips and First-Out Logic in TIA Portal

• Permissive to start, interlock to keep running; the two need different logic and different reset behaviour.
• Latch a trip so it cannot clear itself before anyone sees it.
• A Ready bit without a reason bit forces the operator to phone maintenance to find out what is missing.

Permissive, Interlock and Trip

A pump that needs suction pressure before starting has a permissive. A pump that must stop if suction pressure is lost has an interlock. Often both apply to the same signal with different limits, and writing them as one condition is where machines start behaving unpredictably.

None of this replaces a safety system. Emergency stops, light curtains and guard locking belong in a safety relay or a fail-safe CPU with a certified architecture. PLC interlocks are process protection, not personnel protection, and the two must be designed separately.

Building the Permissive Chain

Write the permissive as a single rung of normally open contacts in series, ending in a Ready coil. Each contact is a condition that must be true.

• Guard doors closed and locked.
• No active trip present.
• Downstream equipment ready to receive.
• Air pressure and lubrication healthy.
• Mode selected and no manual override active.

Keeping them in one visible chain is the point. Going online, an engineer sees the whole start condition at a glance and the open contact is obvious. Splitting the same conditions across six networks with intermediate flags makes fault finding slower for no benefit.

Field wiring convention

Wire safety-relevant field contacts normally closed so that a broken wire produces the safe state. Then the PLC input is true in the healthy condition and a normally open contact in the program reads correctly. Getting this backwards means a cut cable leaves the machine believing everything is fine.

The same reasoning applies to the stop button in the basic start/stop circuit.

Interlocks, Latching and Reset Handling

An interlock is evaluated every scan while the machine runs. When it fails, the machine must stop and the reason must survive long enough to be read.

1. Detect the condition and set a bit in the fault word.
2. Latch the fault so it stays set even if the condition clears immediately.
3. Drop the run command and stop the equipment.
4. Record which fault was first, because a single trip usually causes several.
5. Require a deliberate reset before the fault bits clear.

First-out detection

When a motor trips, its downstream equipment often trips too. Without first-out logic, five faults appear simultaneously and nobody knows which came first. Capture the first fault into a separate register at the moment of the trip and hold it until reset. It is a few lines of code that saves hours on site; the complete SCL is in first-out capture code below.

Reset that means something

A reset should clear latched faults only when the underlying conditions have actually cleared. An auto-reset that fires every scan hides the fault entirely, and the machine appears to stop for no reason.

Publishing Status So the Operator Can Act

The logic is only half the job. If the machine will not start and the screen says nothing, an operator's only option is a phone call.

Publish three things to the HMI interface data block:

• Ready: a single bit summarising the permissive chain.
• NotReadyReason: an integer identifying the first missing permissive, mapped to text on the panel.
• FaultWord and FirstOut: the latched interlock bits and the fault that tripped first.

On the panel (laid out as in HMI screen design best practices), map the reason integer through a text list so the operator reads "Waiting for guard door 2 closed" instead of a number. The configuration is covered in the HMI sequence status screen, and the fault word, latch and reset that feed Any_Fault are built step by step in HMI alarm configuration: IO mapping and alarm mapping FC. The worked example below continues that project.

Worked Example in TIA Portal: Conveyor Motor M1 Start Chain

The theory above becomes concrete with one motor. This example continues the project from HMI alarm configuration in TIA Portal, which already provides DB_IO (field signals, 1 = healthy), "DB_Alarm".Alarm (15 latched alarms with reset) and "DB_Alarm".Any_Fault. Here we add the start chain for conveyor motor M1, a contactor feedback trip, first-out capture and the not-ready reason. The same address rule applies: %I only in FC_InputMapping, %Q only in FC_OutputMapping, symbolic DB members everywhere else.

Signals, data block and program structure

Create a global optimized data block DB_Motor (DB30):

OB1  Network 1   CALL "FC_InputMapping"    // %I  → DB_IO
OB1  Network 2   CALL "FC_AlarmMapping"    // DB_IO → DB_Alarm.Alarm, Any_Fault (incl. %X15 trip)
OB1  Network 3   CALL "FC_MotorM1"         // Ready, Run_Cmd               (LAD)
OB1  Network 4   CALL "FC_MotorStatus"     // NotReadyReason, FirstOut     (SCL)
OB1  Network 5   CALL "FC_OutputMapping"   // DB_Motor.Run_Cmd → %Q0.0

Which condition is a permissive and which is an interlock

Classify every condition before writing a single contact. The table is the specification for the two networks that follow.

Network 1 – the permissive chain

Network 2 – start/stop seal-in with the Any_Fault interlock

This is where "DB_Alarm".Any_Fault from the alarm lesson blocks the start command and stops a running motor. The position of each contact in the rung decides whether it acts as a permissive or as an interlock.

// SCL equivalent of Network 2
"DB_Motor".Run_Cmd := ( ("DB_IO".Start_PB AND "DB_Motor".Ready) OR "DB_Motor".Run_Cmd )
                      AND "DB_IO".Stop_PB_OK
                      AND NOT "DB_Alarm".Any_Fault;

Because Any_Fault is the collective bit of a latched alarm word, the motor cannot be restarted until the operator has reset the alarm, and reset only works once the field contact is healthy again. That is the "reset that means something" rule from above, implemented once for every alarm.

Contactor feedback trip on spare bit %X15

Add one network to FC_AlarmMapping, before the Any_Fault network, using the spare bit of the alarm word and an IEC timer instance "T_M1_Feedback" (TON_TIME). Add a 16th discrete alarm on the HMI: trigger bit 15, class SS_System, text "M1 contactor feedback missing – check K1, overload and control fuse".

// FC_AlarmMapping – M1 commanded but contactor not confirmed for 2 s → latch %X15
"T_M1_Feedback".TON(IN := "DB_Motor".Run_Cmd AND NOT "DB_IO".M1_Running,
                    PT := T#2S);
"DB_Alarm".Alarm.%X15 := "T_M1_Feedback".Q
                         OR ("DB_Alarm".Alarm.%X15 AND NOT "DB_Alarm".Reset_Cmd);

When the trip latches, Any_Fault drops Run_Cmd, the timer input goes false, and the latch keeps the alarm until reset. The 2 s value must be longer than the contactor's pull-in time plus input filter delay.

First-out capture code (FC_MotorStatus, SCL)

One fault usually causes others: low air pressure stops a cylinder, a guard is opened to look, the MPCB trips on the stalled motor. All three alarms are latched, but only one is the cause. First-out stores the alarm that arrived while the register was still empty and holds it until everything has been reset.

// FC_MotorStatus – TEMP: #w : Word;  #i : Int;
// First-out: capture the first alarm bit while FirstOut is still 0
IF "DB_Motor".FirstOut = 0 AND "DB_Alarm".Alarm <> 16#0000 THEN
    #w := "DB_Alarm".Alarm;
    FOR #i := 0 TO 15 DO
        IF #w.%X0 THEN
            "DB_Motor".FirstOut := #i + 1;   // 1 = %X0 (HS-01) … 16 = %X15 (M1 feedback)
            EXIT;
        END_IF;
        #w := SHR(IN := #w, N := 1);
    END_FOR;
END_IF;

// Clear only after every alarm has been reset
IF "DB_Alarm".Alarm = 16#0000 THEN
    "DB_Motor".FirstOut := 0;
END_IF;

Because the register is written only while it is 0, later alarms never overwrite it, even if they have a lower bit number. Only when two alarms latch in the same scan does the lower bit win, which is acceptable at a 10 ms cycle. On the HMI, show FirstOut in a symbolic output field with a text list (0 = "No trip", 1 – 15 = the alarm texts HS-01 … SS-05, 16 = "M1 contactor feedback missing").

Not-ready reason (FC_MotorStatus, SCL)

// Same order as the permissive chain in FC_MotorM1 Network 1
IF NOT "DB_IO".HS_SafetyDoor_OK THEN
    "DB_Motor".NotReadyReason := 1;
ELSIF "DB_Alarm".Any_Fault THEN
    "DB_Motor".NotReadyReason := 2;
ELSIF NOT "DB_IO".Downstream_Ready THEN
    "DB_Motor".NotReadyReason := 3;
ELSIF NOT "DB_IO".SS_AirPressure_OK THEN
    "DB_Motor".NotReadyReason := 4;
ELSIF NOT "DB_IO".Auto_Mode THEN
    "DB_Motor".NotReadyReason := 5;
ELSE
    "DB_Motor".NotReadyReason := 0;
END_IF;

On the panel, add the HMI tags DB_Motor_Ready, DB_Motor_Run_Cmd, DB_Motor_NotReadyReason and DB_Motor_FirstOut, then place a Ready lamp, a Running lamp and two symbolic I/O fields (mode Output) linked to the text lists. The screen-building method, object properties and animations are the same as in Build the same HMI screens in TIA Portal.

Interactive Start-Chain Simulator: Permissives, Interlocks and First-Out

Try the worked example live. Switch the field conditions, press START and STOP, trip faults while the motor runs and watch both ladder networks conduct in green. The panel shows the not-ready reason and the first-out fault exactly as the HMI would.