How to Build XOR and NAND Logic Gates in a PLC with OLLA Lab

To translate Boolean algebra into IEC 61131-3 ladder logic, engineers map abstract logic states to scan-based contact behavior and output coils. In OLLA Lab, XOR and NAND are not just drawn as symbols; they are validated against simulated I/O, fault states, and machine-response logic before any live deployment.

Boolean algebra and ladder logic are related, but they are not interchangeable. Boolean expressions are abstract and effectively timeless on paper; ladder logic is executed by a PLC in a scan cycle, with real inputs, stored states, and output updates. That difference is where many beginner errors begin.

An internal benchmark from Ampergon Vallis makes the point narrowly: 68% of users failed their first discrepancy-alarm build when implementing XOR behavior in OLLA Lab [Methodology: n=500 beginner logic sequences, task defined as building and testing a two-input discrepancy alarm in the simulation environment, baseline comparator = first-attempt pass/fail against expected truth table and simulated behavior, time window = Jan-Feb 2026]. This supports one limited claim: translating Boolean intent into correct ladder structure is harder than recognizing the truth table. It does not support any broader claim about industry-wide engineer competence.

Boolean algebra describes logical relationships. IEC 61131-3 Ladder Diagram (LD) describes how those relationships are implemented in a scan-based control system.

The practical distinction is this:

- PLC logic is executed cyclically: read inputs -> execute logic -> write outputs.

• Boolean algebra treats variables such as A and B as abstract logical states.
• Ladder logic maps those states to tags, memory bits, and physical or simulated I/O.
• Boolean expressions are read as static relationships.

That scan-cycle behavior matters because a rung is not merely a symbolic equation. It is evaluated in sequence using the controller’s current image of the process.

### Basic translation matrix: Boolean to ladder logic

The standard first mappings are straightforward:

• AND -> contacts in series
• OR -> contacts in parallel
• NOT -> normally closed contact representation
• TRUE output condition -> energized coil or internal bit
• FALSE output condition -> de-energized coil or cleared bit

These mappings are foundational, but they are not the whole story. The engineering task is not just to represent logic. It is to represent logic in a form that remains observable, testable, and safe under realistic process conditions.

Why the physical layer changes the meaning

A Boolean variable is not a wire. In a PLC, a tag may represent:

• a 24 VDC field input,
• an internal memory bit,
• a derived status,
• a permissive,
• a trip condition,
• or a simulated equipment state.

That is why “correct” must be defined operationally. In this article, correct means the rung produces the expected output for all relevant input combinations and behaves coherently when tested against simulated process states and fault cases.

Where IEC 61131-3 matters

IEC 61131-3 standardizes programming languages including Ladder Diagram, Function Block Diagram, and Structured Text for programmable controllers (IEC, 2013). It does not erase implementation differences across vendors, but it gives a common execution model and language framework.

That matters because Boolean logic is universal, while ladder implementation is always attached to a controller model, scan behavior, and plant context.

A NAND gate turns false only when both inputs are true. In industrial control, that makes it useful for permissive and inhibit patterns where an output remains available unless a specific combination of conditions is simultaneously satisfied.

The Boolean form is:

• C = NOT (A AND B)

The equivalent ladder interpretation is:

• Output C is on when A is false, or B is false, or both are false.
• Output C turns off only when A and B are both true.

Why NAND appears in industrial logic

In electronics, NAND is often introduced as a universal gate. In industrial automation, the more useful framing is narrower: it is a practical way to express “allow unless these conditions coincide.”

Typical examples include:

• permissive drop logic,
• combined inhibit conditions,
• fault aggregation patterns,
• sequence hold conditions,
• abnormal-state suppression.

This must be bounded carefully. A ladder implementation of NAND is not a substitute for formal functional safety design under IEC 61508 or machine safety validation. It is a control-logic pattern, not an automatic safety case.

Ladder implementation of a NAND gate

A common two-branch ladder form is:

[Language: Ladder Diagram] // NAND Gate: Output is ON unless both Input A and Input B are ON.

|----[/]----------------------------------------( )----| | Input A Output C| | | |----[/]------------------------------------------------| | Input B |

This rung uses parallel normally closed contacts:

• If Input A = 0, the top branch is true.
• If Input B = 0, the bottom branch is true.
• If either branch is true, Output C energizes.
• Only when A = 1 and B = 1 do both NC contacts evaluate false, dropping the output.

Truth table for NAND in ladder terms

| Input A | Input B | Output C | |--------|--------|----------| | 0 | 0 | 1 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

How to build the NAND gate in OLLA Lab

Use the web-based ladder editor to build a compact two-input permissive test:

The important step is not drawing the rung. It is proving the behavior:

• both inputs false -> output on,
• one input true -> output on,
• both inputs true -> output off.

1. Create tags for Input_A, Input_B, and Output_C.
2. Insert two normally closed contacts on separate parallel branches.
3. Assign one branch to Input_A and the other to Input_B.
4. Place Output_C as the driven coil.
5. Run the simulation.
6. Toggle inputs in the Variables Panel and verify the truth table.

A realistic permissive example

Consider a simplified permissive where a maintenance inhibit should remain available unless both:

• A = Remote mode selected
• B = Auto-start sequence active

A NAND-style rung can hold an output true until both conditions are simultaneously present. In practice, this pattern is often embedded inside larger permissive networks, not displayed as a textbook gate.

An XOR gate turns true only when exactly one input is true. In industrial automation, that makes it useful for discrepancy detection, dual-state verification, and fault identification where two signals should not disagree in certain ways.

The Boolean form is:

• C = (A AND NOT B) OR (NOT A AND B)

In ladder terms, XOR is usually built as two parallel branches with cross-coupled NO and NC contacts.

Why XOR matters in machine and process diagnostics

XOR becomes valuable when two signals represent mutually exclusive equipment states.

A classic example is a valve with:

• Open limit switch
• Closed limit switch

Under normal conditions, those two indications should not both be true at once for a simple two-position valve. Depending on timing and travel state, they also should not remain both false indefinitely. The exact alarm philosophy depends on the device and sequence design, but discrepancy logic is often built around XOR or its complement.

Ladder implementation of an XOR gate

[Language: Ladder Diagram] // XOR Gate: Output is ON if A or B is ON, but not both.

|----[ ]--------[/]----------------------------( )----| | Input A Input B Alarm C | | | |----[/]--------[ ]------------------------------------| | Input A Input B |

This rung works as follows:

• Top branch is true when A = 1 and B = 0
• Bottom branch is true when A = 0 and B = 1
• If either branch is true, Alarm C energizes
• If both inputs are the same, the alarm stays off

Truth table for XOR in ladder terms

| Input A | Input B | Alarm C | |--------|--------|---------| | 0 | 0 | 0 | | 0 | 1 | 1 | | 1 | 0 | 1 | | 1 | 1 | 0 |

How XOR supports discrepancy alarms

For a discrepancy alarm, XOR is useful when the alarm condition is defined as “the two state signals disagree.”

Examples include:

• open/closed indication disagreement,
• redundant sensor mismatch,
• commanded state versus feedback mismatch,
• selector-switch disagreement,
• paired status bits expected to be mutually exclusive.

This must still be engineered with context. A valve in transit may legitimately produce temporary disagreement or temporary loss of both end-state confirmations. Good alarm logic usually adds timing, sequence state, or motion context. Raw XOR is a useful core, not the finished philosophy.

How to build the XOR gate in OLLA Lab

Use OLLA Lab to construct and test the discrepancy rung directly in the browser:

The test sequence should confirm:

• 00 -> alarm off
• 01 -> alarm on
• 10 -> alarm on
• 11 -> alarm off

If the rung does anything else, the issue is usually one of three things:

• contact type reversed,
• branch structure incorrect,
• tag meaning poorly defined.

1. Create tags for Input_A, Input_B, and Alarm_C.
2. Add two parallel branches.
3. On branch one, place NO Input_A in series with NC Input_B.
4. On branch two, place NC Input_A in series with NO Input_B.
5. Drive Alarm_C with the branch output.
6. Run simulation and toggle the two inputs through all four states.

The PLC scan cycle makes ladder logic temporal, not merely logical. Inputs are read, logic is solved, and outputs are written in sequence, which means behavior depends on when state changes are observed.

For basic two-input examples, the scan cycle may appear invisible. For real equipment, it is not.

The standard scan sequence

Most PLC execution follows this broad pattern:

1. Read inputs
2. Execute program logic
3. Update outputs
4. Perform communications, diagnostics, housekeeping

The exact details vary by platform, task model, and vendor, but the principle is stable.

Why this matters for discrepancy logic

An XOR discrepancy alarm can behave differently depending on:

• input update timing,
• debounce treatment,
• sequence state,
• one-shot logic,
• timer use,
• asynchronous device motion.

For example:

• a valve may leave both limit switches false during travel,
• one switch may chatter,
• one feedback may lag the other by several scans,
• a simulated or forced input may change cleanly while a real device does not.

That is why scan-aware validation matters. Boolean algebra assumes idealized state relationships. Equipment often introduces delay, bounce, and ambiguity.

Why this matters for permissives

A NAND-style permissive can drop an output only when both conditions become true in the same evaluated state. If one condition is latched, delayed, or derived through another rung, the observed behavior may differ from the simple truth table unless the surrounding logic is understood.

OLLA Lab simulates logic gate behavior by allowing users to build ladder rungs, run them in a controlled environment, toggle inputs, inspect variable states, and compare ladder outcomes against simulated equipment behavior.

That makes it a bounded validation environment for high-risk learning tasks, not a substitute for site acceptance testing or formal safety validation.

What “Simulation-Ready” means here

In this article, Simulation-Ready means an engineer can:

• prove expected logic behavior against defined test states,
• observe I/O causality in simulation,
• diagnose incorrect rung behavior,
• inject abnormal conditions,
• revise the logic,
• and verify the revised behavior before touching live equipment.

How to test a NAND failure case in OLLA Lab

Use the Variables Panel to step through the input combinations:

• Set Input_A = 0, Input_B = 0 -> confirm Output_C = 1
• Set Input_A = 1, Input_B = 0 -> confirm Output_C = 1
• Set Input_A = 0, Input_B = 1 -> confirm Output_C = 1
• Set Input_A = 1, Input_B = 1 -> confirm Output_C = 0

Then inject a fault scenario:

• redefine one input conceptually as a stuck-high permissive source,
• observe whether the output can still be explained from rung structure,
• revise the logic or tag definition if the behavior no longer matches the intended control philosophy.

How to test an XOR discrepancy failure in OLLA Lab

For a discrepancy-alarm model:

- Then simulate a fault case such as:

• Toggle Input_A and Input_B through all four truth-table states.
• Confirm that disagreement states energize Alarm_C.
• one limit switch stuck on,
• both switches forced true,
• both switches false longer than expected,
• command state inconsistent with feedback state.

The Variables Panel is useful here because it exposes state directly.

Why this matters beyond learning syntax

Simulation closes the gap between rung construction and behavioral proof. Research on digital twins, simulation-based training, and cyber-physical validation points to the value of virtual testing for reducing risk, improving understanding of system behavior, and supporting earlier fault discovery in automation workflows (Tao et al., 2019; Fuller et al., 2020; Villalonga et al., 2021).

That does not mean a simulator certifies a design. It means a simulator gives engineers a safer place to find obvious mistakes before the plant does.

A good workflow defines correctness before testing begins. If “correct” is left vague, the simulation becomes theater.

Use this compact evidence structure when documenting a logic-gate build or review:

Define the equipment or control function. Example: “Two-position valve with open and closed feedback used for discrepancy alarming.”

State the expected behavior in observable terms. Example: “Alarm energizes when exactly one feedback is true; alarm remains off when both are equal, subject to any timing exceptions documented separately.”

Define the abnormal condition. Example: “Closed limit switch stuck high during commanded open transition.”

Show what changed. Example: “Added transition timer and command-state qualifier to suppress nuisance alarm during normal travel.”

State what the test revealed. Example: “Raw XOR detected disagreement correctly but over-alarmed during legitimate state transitions.”

1. System Description
2. Operational definition of ‘correct’
3. Ladder logic and simulated equipment state Include the actual rung and the corresponding simulated tag states or equipment states.
4. The injected fault case
5. The revision made
6. Lessons learned

The most common mistake is assuming the truth table is the design. It is not. The truth table is only the starting constraint.

Frequent implementation errors

• Reversing NO and NC contacts
• Confusing signal meaning with signal state
• Ignoring scan-cycle effects
• Testing only the expected case
• Treating permissive logic as equivalent to safety logic
• Failing to define the process state model

A practical correction

When building any gate-based rung, define three things before you simulate:

• what each tag physically or logically represents,
• what output behavior is considered correct,
• what abnormal states must be tolerated versus alarmed.

That discipline removes a surprising amount of confusion. Many “logic bugs” are really specification bugs.

Use OLLA Lab when the engineering task requires rehearsal of logic behavior, I/O causality, fault injection, or sequence validation without exposing live equipment to unnecessary risk.

That includes:

• beginner-to-intermediate ladder practice,
• discrepancy-alarm rehearsal,
• permissive logic testing,
• valve and motor control scenario work,
• analog/discrete interaction review,
• instructor-led lab exercises,
• pre-commissioning logic walkthroughs in a bounded environment.

Based on the product documentation, OLLA Lab supports this through:

• a browser-based ladder logic editor,
• simulation mode,
• variables and I/O visibility,
• scenario-based industrial presets,
• digital twin-oriented validation workflows,
• 3D/WebXR/VR simulation access where enabled,
• guided build instructions,
• AI lab coaching through GeniAI.

The bounded claim is simple: OLLA Lab gives engineers a practical environment to build and test ladder logic against simulated behavior. It does not replace plant commissioning, site procedures, vendor manuals, or functional safety lifecycle obligations.

Boolean algebra gives you the logical form. IEC 61131-3 ladder logic gives you the executable structure. The engineering challenge is the translation between them, especially once scan timing, device behavior, and fault states enter the picture.

NAND and XOR are useful examples because they expose that translation cleanly:

• NAND expresses permissive logic that drops only when conditions coincide.
• XOR expresses disagreement logic that identifies state mismatch.

In both cases, the rung is only the beginning. The real work is proving behavior under normal and abnormal conditions. That is where a simulation environment earns its keep.

Related reading

- See The Shift to Systems Thinking: Moving Beyond Drawing Rungs.

• For a broader standards context, visit our Ladder Logic Mastery Hub.
• See Why “Normally Closed” Contacts Are the Most Important Rungs You’ll Write.
• Ready to test this discrepancy logic? Open the Valve Control Preset in OLLA Lab.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)