Three maintained switches controlling one output is often presented as a ladder-logic exercise, but the real engineering question is more precise: should the output be on when an odd number of inputs are true, or should operating any switch simply reverse the output’s previous state? Those are different requirements. The first is combinational XOR, or odd parity. The second needs state memory and edge detection.

For three maintained selector switches, the usual specification is odd parity: the lamp is on with one or three closed switches and off with zero or two. Writing that requirement down before drawing contacts prevents a plausible-looking rung from implementing the wrong Boolean function.

Three-input XOR is true when the number of true inputs is odd; it is not the same as a remembered toggle command.

Start with the eight input states

The expected output sequence for inputs S1, S2, and S3 is 0, 1, 1, 0, 1, 0, 0, 1 as the binary input states advance from 000 through 111. In plain language, one closed switch turns the output on, two closed switches turn it off, and all three closed switches turn it on again.

That last state is where many explanations go wrong. Three-input XOR is an odd-parity function, so 111 must produce a true result. An implementation that only recognizes “exactly one input is true” is not XOR; it deliberately excludes the three-true state. Conversely, OR-ing the three pairwise XOR expressions produces a different function: it is true whenever the inputs are not all equal, which includes the two-true states and therefore also fails the required truth table.

The safest commissioning practice is to treat the truth table as the acceptance test. Do not judge the program from two or three convenient switch positions.

Cascade two-input XOR stages

XOR is associative, which permits the expression (S1 XOR S2) XOR S3. In an SLC 500 program, one internal bit can store the result of the first stage. A second rung then combines that bit with S3. This gives each rung a small, inspectable purpose and makes the online state easier to diagnose.

For a contact implementation, each two-input XOR stage uses two parallel paths: the first path examines input A as true and input B as false; the second examines A as false and B as true. The two paths join at one coil. Repeat the same pattern with the intermediate bit and the third input.

The intermediate bit exposes the S1 XOR S2 result before the second stage combines it with S3.

Example address plan

On a typical RSLogix 500 training project, S1, S2, and S3 might be I:1/0, I:1/1, and I:1/2. The first rung writes B3:0/0 as the intermediate result, and the second writes O:2/0 as the lamp command. These addresses are examples only; the installed I/O configuration must determine the real mapping.

The intermediate address should have one writer. Reusing B3:0/0 elsewhere, or placing another output instruction for O:2/0 later in the program, can overwrite a correct result during the same scan. Cross-reference both addresses before blaming the XOR pattern.

Word-level XOR is not automatically a Boolean shortcut

The SLC 500 instruction set includes an XOR instruction for bitwise exclusive OR between word operands. Rockwell Automation’s SLC 500 Instruction Set Reference Manual documents the supported operands and destinations. That instruction is useful for masks and packed status words, but it does not remove the need to define which input bits participate in a single parity decision.

For three discrete inputs, cascaded contact logic is usually clearer to maintenance personnel. A word-level implementation can be justified when a program already packs many status bits and explicitly reduces them to a parity result, but the reduction step must still be visible and tested.

Do not confuse parity with a toggle function

A maintained three-way lighting arrangement changes its output whenever any physical switch changes position. In pure Boolean terms, the output at any instant can be represented by the parity of the three switch positions. No stored state is necessary because the switch positions themselves hold the state.

Momentary pushbuttons are different. If pressing any of three buttons must toggle a lamp, the PLC must detect a rising edge and invert a retained command bit once per valid press. Directly applying XOR to three momentary inputs only describes which buttons are pressed during that scan; it does not remember the previous lamp state.

Real pushbuttons may also bounce. A toggle design therefore needs input conditioning, a one-shot, ownership of the retained bit, and a defined startup state. For related scan and data-handling patterns, the guide to using one SLC timer value to set another timer shows why data movement and rung order should be explicit.

Commission the logic as a function, not a picture

First test the two-input intermediate bit by itself. It should be true for 01 and 10, and false for 00 and 11. Then test the final output across all eight three-input states. Record the observed state rather than relying only on the green rung highlight, because forcing, duplicate coils, and online display refresh can disguise the actual output ownership.

Next verify power-up behavior, program-mode transitions, input substitution, and the response to a failed or disconnected field circuit. XOR logic can detect disagreement, but it is not a safety diagnostic by itself. If the switches participate in a protective function, the design needs safety-rated inputs, discrepancy monitoring, fault detection, and a risk assessment appropriate to the machine.

Hardware and migration options for legacy and current controllers can be reviewed through the PLC and PAC systems collection, but the processor family, I/O voltage, addressing, and program ownership must be confirmed before adapting this example.

Why the internal-bit version is easier to maintain

A single expanded rung can express three-input odd parity directly, but it requires four parallel combinations and becomes harder to inspect as more conditions are added. Cascading two-input stages makes the Boolean intent obvious, provides a diagnostic checkpoint, and maps cleanly between RSLogix 500 addresses and named BOOL tags in Logix Designer.

Editorial view: the best ladder solution is the one whose truth table, memory behavior, and failure response can be explained during a maintenance handover. An internal bit is not wasted memory when it prevents the next engineer from mistaking odd parity, exactly-one logic, and a remembered toggle for the same function.

Frequently asked questions

Should the output be on when all three switches are closed?

Yes, if the requirement is three-input XOR or odd parity. Three true inputs are an odd count, so the output is true. If 111 must be false, the required function is “exactly one,” not XOR.

Can the SLC 500 XOR instruction replace the two ladder stages?

It performs bitwise XOR on word operands. It can be part of a packed-bit solution, but three individual input bits still need to be arranged and reduced so that the destination bit represents the required parity. For a small discrete circuit, two contact stages are generally clearer.

Does the intermediate bit add a one-scan delay?

Not when the rung writing the intermediate bit executes before the rung reading it in the same routine and task. The second rung sees the value written earlier in that scan. Program order must remain documented and controlled.

What changes if the field devices are momentary pushbuttons?

A momentary-button toggle requires edge detection and stored output state. Combinational XOR alone cannot remember whether the lamp was previously on or off.

Is XOR suitable for a safety voting circuit?

Not by itself. Ordinary XOR only evaluates Boolean states. Safety applications require a validated safety architecture, diagnostic coverage, discrepancy timing, appropriate hardware, and verification against the applicable risk assessment.

By PLC ProTech Editorial Team