The classic exercise—three SPST switches control one light so that any single switch toggles the output—reduces to three-input exclusive OR (odd parity). Two-input XOR is a familiar pair of crossed XIC/XIO branches. Extending that pattern with a third parallel branch does not generalize: it implements a sum of pairwise XORs, which lights on three closed switches when the specification requires odd parity only. The accepted fix is an internal relay bit that holds A⊕B, then a second stage that computes (A⊕B)⊕C.

Odd parity across three maintained inputs is XOR—not a three-branch inclusive structure.

Truth table (1 = closed)

Two-input baseline

|--[S1 XIC]-+-[S2 XIO]-+
|           |          +--( Light )--|
|--[S1 XIO]-[S2 XIC]---+             |

Map I:1/0, I:1/1 → O:2/0 in LogixPro/RSLogix 500 simulators (or BOOL tags in Logix Designer). Verify four rows before adding S3.

Why the third parallel branch fails

Y = (S1⊕S2) ∨ (S1⊕S3) ∨ (S2⊕S3) evaluates true for the triple-closed row because each pair differs. Students describe the symptom as the light “sticking on” once two switches close. That is inclusive pairwise behavior, not XOR.

Cascade XOR through B3:0/0 (or a BOOL tag)—do not OR pairwise stages in parallel.

Internal-bit implementation

Rung 2 — S1 XOR S2 -> B3:0/0
|--[I:1/0 XIC]-+-[I:1/1 XIO]-+
|              |             +--( B3:0/0 )--|
|--[I:1/0 XIO]-[I:1/1 XIC]---+              |

Rung 3 — B3:0/0 XOR S3 -> O:2/0
|--[B3:0/0 XIC]-+-[I:1/2 XIO]-+
|               |             +--( O:2/0 )--|
|--[B3:0/0 XIO]-[I:1/2 XIC]---+             |

Because XOR is associative, switch order does not matter. In Logix Designer the same equations become XOR_Mid := S1 XOR S2; Light := XOR_Mid XOR S3; for structured text, or identical contact patterns on BOOL tags. The intermediate bit is written on one rung and read on the next within the same scan, which is intentional and stable for this pattern.

Procedure in LogixPro / RSLogix 500

1. Confirm discrete input and output modules in the simulator (default I:1 / O:2 mapping)
2. Ensure binary file B3 exists with spare bits, or create a BOOL tag named XOR_Mid in Logix Designer
3. Build rung 2 driving B3:0/0 from S1 and S2 crossed XIC/XIO contacts
4. Build rung 3 driving O:2/0 from B3:0/0 and S3 using the same crossed pattern
5. Download, place the processor in RUN, and clear all forces before walking the truth table
6. Momentarily force each input LED and the output lamp once to prove wiring, then clear forces

Address plan and alternatives

Optional diagnostics keep both intermediates: B3:0/0 = S1 XOR S2 and B3:0/1 = mid XOR S3, then drive the lamp from B3:0/1 so online monitors can break the chain at either stage. Word-level XOR instructions can pack many inputs for parity checking, but they obscure the teaching pattern for three switches. Avoid DeMorgan expansions that try to express “not any two true” as a forest of contacts—the internal-bit cascade remains the maintainable form on both training benches and production mode selectors.

Walk all eight parity rows before sign-off

1. Walk all eight truth-table rows with forces cleared
2. Confirm three closed switches light the lamp (odd parity)
3. Toggle each switch alone and prove the output flips
4. If the lamp locks on with two inputs, you still have pairwise OR logic
5. Optional: alarm when two maintained mode switches read true after debounce in real machines
6. Document the boolean identity (A XOR B) XOR C on the rung comments for the next editor

Name intermediates after function (XOR_Mid, ModeParity) rather than anonymous bits so the next edit stays readable. Apply the same discipline across fleets standardized under PLC and PAC systems.