How to Program Fail-Safe Interlocks with Normally Closed Contacts

To program fail-safe PLC interlocks, engineers typically use physical Normally Closed (NC) field devices so loss of power or continuity drives the system to a safe state. In ladder logic, those devices are usually represented with XIC instructions because a healthy NC circuit presents a logical `1` to the PLC input.

A common beginner mistake is assuming “normally closed” in the field should be programmed as a “normally closed” instruction in the PLC. That is backwards often enough to matter. The physical device state and the logical instruction symbol are not the same thing, and confusing them is how harmless-looking rungs become commissioning problems.

A bounded internal Ampergon Vallis benchmark makes the point clearly: in a review of 500 hazard-based commissioning exercises completed in OLLA Lab, 68% of first-attempt submissions initially mapped at least one physical NC safety device with the wrong ladder instruction, and all affected rungs failed the injected continuity-loss test. Methodology: n=500 learner exercise submissions involving E-stop, overload, or trip-loop validation; baseline comparator = first-attempt logic before guided correction; time window = Ampergon Vallis internal lab review period ending Q1 2026. This supports one narrow claim: physical-to-logical mapping errors are common in early PLC work. It does not support any broader claim about industry-wide incident rates.

The engineering rule is simpler than the terminology: safety interlocks should fail to a known safe state when power is lost, a wire breaks, or a terminal comes loose. Copper has no respect for optimism.

Safety interlocks are designed so that loss of energy produces the safe condition. That design principle is commonly described as de-energize to trip, and it exists because power loss, open circuits, and device failures must not leave hazardous motion or process energy enabled.

IEC 61508 establishes the broader functional safety framework: safety-related systems must behave predictably under fault conditions, not merely under normal operation. In machine control practice, that principle aligns with standards such as NFPA 79, where emergency stop functions and protective circuits are expected to default toward a safe outcome when continuity is lost.

The distinction matters:

- Energize to action is acceptable for ordinary functions such as: - De-energize to trip is preferred for safety-critical functions such as:

• pilot lights
• horns
• non-safety actuations
• emergency stop loops
• motor overload trips
• overtravel limit circuits
• high-pressure or high-high level shutdowns

The reason is physical, not stylistic. Open-circuit faults are common enough in industrial environments that they must be treated as expected failure modes, not edge cases. exida and similar reliability bodies routinely emphasize wiring faults, loose terminations, and loss of continuity as credible contributors to dangerous failures in poorly designed loops.

A physical NC safety device supports this fail-safe behavior because its healthy state requires continuity. If the wire breaks, the input drops out. If the input drops out, the interlock trips. That is the point.

What de-energize-to-trip means in practice

A healthy safety loop usually presents these conditions:

• field contact closed
• current flowing
• PLC input energized or safety relay channel healthy
• run permissive true

A faulted or demanded-trip state usually presents these conditions:

• field contact open
• continuity lost
• PLC input de-energized or safety relay channel dropped
• run permissive false

That is not sophistication. It is disciplined pessimism, which is usually the safer design posture.

How to validate this in OLLA Lab

This is where OLLA Lab becomes operationally useful. Its Simulation Mode and Variables Panel let you rehearse continuity-loss behavior before physical commissioning.

In this article, simulation-ready means something specific: an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior and fault states before it reaches a live process. It does not mean familiarity with ladder syntax alone, and it does not imply site competence by software alone.

In OLLA Lab, you can:

• run the sequence in simulation
• monitor the input tag state in the Variables Panel
• force the safety input from `1` to `0`
• observe whether the permissive drops immediately
• confirm the output de-energizes without requiring a second failure to reveal the mistake

That is a much cheaper place to be wrong than a live conveyor, pump skid, or motion axis.

A physical NC device is a wiring condition; an XIC instruction is a PLC evaluation rule. They are related, but they are not interchangeable labels.

This is the classic trap: a physical NC emergency stop is closed when healthy, so the PLC input sees a logical `1` during normal operation. To allow the machine to run while that healthy signal is present, the ladder rung usually uses an XIC instruction on that input.

Put plainly: physical NC often maps to logical XIC.

If that sounds inverted, it is because the terminology is inherited from two different domains:

• Field device terminology describes the contact in its normal, unactuated state.
• Ladder instruction terminology describes whether the PLC instruction evaluates true when the input bit is on or off.

The names look similar enough to mislead people.

### Mapping table: field device state vs PLC logic

| Field Device Type | Healthy Physical State | PLC Input in Healthy State | Ladder Instruction Usually Required for Run Permissive | What Happens on Wire Break | |---|---|---:|---|---| | NC E-Stop | Closed | `1` | XIC | Input goes `0`, rung goes false, machine stops | | NC Overload Aux | Closed | `1` | XIC | Input goes `0`, motor permissive drops | | NC High-High Level Switch | Closed | `1` | XIC | Input goes `0`, fill command blocked or pump stopped | | NO Start Pushbutton | Open | `0` | XIC for momentary start condition | Wire break usually prevents start, not a hidden unsafe run |

The practical rule

Use the instruction that matches the healthy input bit state required for permissive truth, not the English name of the device.

If the healthy safety input is `1`, use XIC to keep the permissive true. If the healthy safety input is `0`, use XIO to keep the permissive true.

That is the real translation layer.

### Example: correct fail-safe rung

A simple ladder representation is shown below.

• `E_STOP` is true only while the NC field circuit is healthy
• `OVERLOAD` is true only while the overload auxiliary contact remains closed
• if either circuit opens, the rung drops out
• `MOTOR_RUN` de-energizes immediately

Example rung logic:

`E_STOP` XIC in series with `OVERLOAD` XIC in series with `START_PB` XIC driving `MOTOR_RUN` coil.

That is fail-safe behavior at the logic layer, assuming the field design and hardware architecture also support it.

Normally Closed devices are used where loss of continuity must be interpreted as unsafe until proven otherwise. The common thread is not the device type but the consequence of missing the fault.

Emergency stop chains

Emergency stop circuits are typically hardwired as NC loops so pressing the button, losing power, or breaking a conductor all remove the run-enable condition.

In real systems, the E-stop function is often implemented through safety relays or safety PLC architectures rather than standard input cards alone. That distinction matters. Standard PLC logic can model the permissive behavior, but the safety function itself must be designed within the appropriate safety architecture and applicable standards.

Thermal overload contacts

Motor overload relays often provide an NC auxiliary contact that opens on trip. That contact is commonly wired into the motor permissive so excessive current or overload relay actuation removes the run command.

This is one of the first places junior engineers meet the difference between “the motor stopped” and “the motor was stopped safely for a diagnosable reason.” They are not the same event.

High-high level switches

High-high level shutdown devices are often configured so that a healthy circuit remains closed and an alarmed or faulted condition opens the permissive path. In tank filling, chemical dosing, and wastewater lift applications, this helps prevent overflow when the abnormal condition is exactly the moment you do not want ambiguity.

Overtravel limit switches

Motion systems, conveyors, lifts, and CNC axes commonly use NC overtravel limits so that a damaged switch cable behaves like a stop demand rather than an invisible permission to continue moving.

Mechanical collisions are efficient teachers, but expensive ones.

You simulate a wire break by forcing the healthy input state to disappear and then verifying that the logic drops to the safe condition immediately. If the sequence keeps running, the interlock is not fail-safe.

This test should happen before physical commissioning whenever possible. Waiting for first live power-up to discover a hidden continuity assumption is not a serious validation strategy.

Step-by-step wire-break test in OLLA Lab

Use OLLA Lab as a validation and rehearsal environment for the logic behavior. The point is not certification. The point is disciplined fault observation.

Example: `High_Pressure_Switch`, `E_STOP`, or `MOTOR_OL`.

1. Open a scenario with a safety-relevant permissive A motor control, pump control, or process skid scenario is suitable.
2. Identify the safety input tag
3. Confirm the healthy state In many fail-safe designs, the healthy NC device presents `1` to the PLC input.
4. Run the sequence in Simulation Mode Start the motor, pump, or sequence only after confirming the permissives are true.
5. Inject the fault In the Variables Panel, manually toggle the input from `1` to `0`. This represents a broken wire, opened contact, or loss of continuity.
6. Observe the result The run permissive should drop immediately. The output coil should de-energize. Any dependent sequence state should transition to a stop or fault condition as designed.
7. Review the rung logic If the output remains energized, inspect whether the input was mapped with the wrong instruction or bypassed by an unintended branch.

Example test case

If `I:0/1 (High_Pressure_Switch)` is healthy at `1`, then forcing it to `0` during operation should:

• make the XIC instruction evaluate false
• break rung continuity
• de-energize `Pump_Run`
• prevent automatic restart until the fault is cleared and reset logic, if required, is satisfied

That single test catches a surprising amount of bad logic.

What a good validation record looks like

If you want to demonstrate engineering judgment, do not submit a folder full of screenshots and call it evidence. Build a compact validation record with these six parts:

1. System Description Define the process or machine segment, the controlled equipment, and the interlock purpose.
2. Operational definition of correct behavior State exactly what must happen in healthy operation, trip condition, and post-fault recovery.
3. Ladder logic and simulated equipment state Show the rung, relevant tags, and the corresponding simulated machine or process condition.
4. The injected fault case Specify the fault introduced, such as continuity loss on an NC pressure switch.
5. The revision made Document the logic correction, tag remap, reset condition, or alarm handling change.
6. Lessons learned Record the design insight, such as “physical NC required logical XIC because healthy input state was high.”

That format is useful because it shows reasoning, not just software familiarity.

A dangerous rung usually reveals itself when the healthy state and the demanded-safe state are not explicitly defined. If you cannot say what input value represents healthy continuity, you are not ready to trust the rung.

A quick review checklist helps:

- What is the physical device type: NC or NO?

• What input value represents the healthy field condition?
• What input value represents wire break or loss of power?
• Which ladder instruction keeps the permissive true in the healthy state?
• Does the output drop out immediately when continuity is lost?
• Is restart behavior controlled, or does the system auto-restart unsafely when the signal returns?

The last question is not decorative. A trip that clears into an uncontrolled restart is just a delayed mistake.

Spot-the-error example

Incorrect idea: Program a physical NC E-stop with an XIO because the button is “normally closed.”

Why it fails: The healthy input is `1`, so XIO evaluates false in normal operation. Engineers often then add compensating branches or inverted bits to make it work, which is how simple mistakes evolve into opaque logic.

Correct idea: Program the physical NC E-stop with an XIC if the healthy field signal is `1`, so loss of continuity drives the rung false and drops the output.

Digital twin validation can prove whether your control logic responds correctly to modeled equipment states and injected faults before live commissioning. It cannot, by itself, certify the adequacy of the final installed safety function.

That boundary matters. OLLA Lab is useful because it lets engineers compare:

• ladder state
• I/O state
• simulated machine or process response
• fault behavior under controlled conditions

For fail-safe interlocks, that means you can validate questions such as:

• Does a continuity loss remove the run permissive?
• Does the sequence stop in the intended state?
• Does the alarm appear with the right condition?
• Is reset behavior deliberate rather than accidental?
• Does the simulated equipment state agree with the ladder state?

This is the practical value of digital twin work in PLC training and rehearsal: it moves the engineer from syntax to deployability, from “the rung compiles” to “the logic survives contact with a fault.”

OLLA Lab fits as a web-based rehearsal and validation environment for high-risk commissioning tasks that are difficult, expensive, or unsafe to practice on live equipment. That is a credible claim because it is bounded.

Its relevant functions here are concrete:

• a browser-based ladder logic editor
• Simulation Mode for running and stopping logic
• a Variables Panel for observing and forcing I/O states
• realistic industrial scenarios
• digital twin-style equipment simulation
• guided support through GeniAI, the AI lab coach

Used properly, those features let learners and junior engineers practice:

• tracing cause and effect through a permissive chain
• validating healthy-state assumptions
• injecting abnormal conditions
• revising logic after a failed test
• comparing rung truth with equipment behavior

What OLLA Lab does not do is make someone safety-certified, site-authorized, or formally competent by association. Functional safety remains a standards-governed engineering responsibility, not a software shortcut.

Fail-safe interlocks depend on one disciplined idea: the system must move toward safety when continuity is lost. Physical NC devices support that behavior because a broken wire looks unsafe, not healthy.

The programming consequence is the part many engineers initially miss: a physical NC safety device often maps to a logical XIC instruction because the healthy PLC input state is high. Once that distinction is clear, the rest of the validation workflow becomes straightforward:

• define the healthy state
• define the fault state
• inject continuity loss
• verify immediate de-energization
• revise anything that survives the fault when it should not

That is the difference between drawing ladder and validating control logic. The difference is not semantic. It is what stands between a clean commissioning day and a very long one.

- UP (pillar): Explore all Pillar 5 pathways - ACROSS (related): How to Validate PLC Logic with Digital Twins - ACROSS (related): How Software-Defined Automation Compares to Hardware PLCs: A 2026 Architecture Guide - DOWN (commercial CTA): Build job-ready momentum with How to Transition from 24VDC to High-Voltage EV Plant Automation

- IEC 61508 Functional Safety Standard - NFPA 79 Electrical Standard for Industrial Machinery - ISO 13849-1 Safety-Related Parts of Control Systems - exida Functional Safety Knowledge Center - BLS JOLTS Data (U.S. labor market)