PLC two hand control program for a press

Difficulty: advanced · 60–90 minutes

This is a build-along exercise, not a reading page. You get a short job card of the kind a contractor actually receives, an I/O table to wire against, and a worked solution to check yourself with once your own version runs — plus the test sequence that proves it, because a program you haven't tried to break is a program you haven't tested. Sketch first, build second, test third. Same order as on site.

The job card

Job card: a pneumatic press at a gasket-cutting shop in Benoni closes with enough force to take fingers, and the operator has been caught cycling it with one hand while feeding material with the other — the second palm button is cable-tied down. You are asked to program proper two-hand control logic in the simulator as a training exercise: the press may only close while BOTH palm buttons are pressed, the two presses must land within 0.5 seconds of each other, releasing either button must open the press immediately, and a tied-down button must lock the press out until both buttons are fully released. Be clear with the apprentice: on the real machine this logic lives in a safety relay or safety PLC rated for it — this exercise teaches the logic, not a substitute for the hardware.

Read it the way a foreman hands it to you. Every requirement on that card is a test case: when you think the program is done, walk the card line by line and force each condition in the watch table. Any line without a matching test you actually ran means you're not done yet. That habit — card in one hand, watch table in the other — is what separates a programmer who commissions clean from one who gets the call-back at month end.

I/O assignment

Wire your simulator project to this table exactly. Half the value of an exercise like this is tag discipline: name the points the same way the table does and the solution steps further down will read straight onto your rungs without translation.

A note on the Type column: DI is a digital input, DO a digital output, AI and AO are analogue in and out, and M is an internal memory bit that never leaves the CPU. The addresses use IEC notation (%I, %Q, %M). If your head is in Allen-Bradley land, map %I0.0 to I:0/0 and carry on — the logic doesn't change, only the spelling of the addresses.

Think before you build

Don't open the ladder editor yet. The notes below are the design decisions that determine whether your program works first time or fights you for an hour. Read them, then sketch the rung shapes on paper. Pencil and the back of a delivery note is fine — most working programs start exactly there.

• The synchronity check is one timer on an XOR. Exactly one button pressed starts a 500 ms TON; if the second button arrives in time the XOR goes false and the timer dies quietly; if the timer finishes, one hand has been hovering or tying down and you latch a lockout. One rung carries the whole safety idea.
• Anti-tie-down means the lockout clears only when BOTH buttons read released. A cable-tied button keeps the XOR true through every cycle attempt, so the lockout latches and stays — the operator must physically undo the tie to ever cycle again. That is the behaviour that protects the hand.
• Say it plainly in the program comments and to the apprentice: ISO 13851 type III two-hand control on a real press requires safety-rated hardware — monitored dual channels, cross-fault detection, a safety relay or safety PLC. A standard PLC scan can fail unsafely; this exercise is for understanding the logic the safety device implements.
• A separate Armed bit, set only while both buttons are released and consumed the moment the valve fires, forces a full release between every cycle — not just after a lockout. Without it, an operator can tie one button down and tap the other in a fast rhythm that resets the 0.5-second timer on every tap, and the press cycles on one hand.

Step-by-step solution

Build one rung at a time and test after every rung. Never write the whole program and then test the lot — when five rungs go in untested and the machine misbehaves, you're debugging five suspects instead of one. The steps below follow that order. In the pseudo-rungs, ] [ is a normally-open examine, ]/[ is normally-closed, and ( ) is the output coil.

Rung 1: the one-button timer

An XOR of the two buttons (one pressed, one not) drives a TON with PT of T#500ms. While both are released or both are pressed the XOR is false and the timer stays at zero. The timer's done bit means one hand has been alone on a button for half a second — the signature of tie-down or one-handed cycling.

// (BtnLeft XOR BtnRight) ──[TON tSync, PT := T#500ms]

Rung 2: latch the lockout

Set Lockout on tSync.Q; reset it only when NOT BtnLeft AND NOT BtnRight. The reset condition is the anti-tie-down core: a tied button can never go false, so the lockout can never clear while the tie is on. The lamp follows the latch so the operator knows why nothing happens.

// tSync.Q ──(S)Lockout
// [/]BtnLeft──[/]BtnRight──(R)Lockout
// Lockout ──( )LockoutLamp

Rung 3: arm, then the press output

Two pieces. An Armed bit sets only while both buttons read released, and is reset the moment the valve fires. The valve rung is BtnLeft AND BtnRight AND (Armed OR PressValve) AND NOT Lockout AND EstopOK. The valve can only fire from an armed state; the (Armed OR PressValve) branch keeps it in while both palms stay down, but because both button contacts gate the whole rung, releasing either palm drops the valve instantly. Re-firing needs Armed again — which needs both buttons released. Hold-to-run, with a mandatory full release between cycles.

// [/]BtnLeft──[/]BtnRight──(S)Armed   // both released = re-armed
// ──┬─[ ]Armed──────┬─[ ]BtnLeft──[ ]BtnRight──[/]Lockout──[ ]EstopOK──( )PressValve
//   └─[ ]PressValve─┘
// [ ]PressValve ──(R)Armed

Test it like a safety officer

Both buttons within 0.5 s: press closes. Hold both: stays closed. Release one: opens instantly. Now the attack cases: press one button, wait a full second, add the second — must NOT close, lamp on. With the lockout lit, release only one button and press again — still locked. Release both, then a clean two-hand press — closes. Then the tapping attack: force one button permanently TRUE and pulse the other in a 0.3-second rhythm — the press must fire at most once and then refuse everything until both buttons are released. Time the 0.4 s and 0.6 s boundary cases explicitly.

The structured text version

The same logic in IEC 61131-3 structured text — each output written as a boolean equation you can read aloud.

(* Two-hand control logic (training exercise) *)
(* Real presses: ISO 13851 type III demands safety-rated hardware *)
tSync(IN := BtnLeft XOR BtnRight, PT := T#500ms);
IF tSync.Q THEN Lockout := TRUE; END_IF;
IF NOT BtnLeft AND NOT BtnRight THEN
  Lockout := FALSE;
  Armed := TRUE; (* re-arm only from a full release *)
END_IF;
PressValve := BtnLeft AND BtnRight AND (Armed OR PressValve)
              AND NOT Lockout AND EstopOK;
IF PressValve THEN Armed := FALSE; END_IF;
LockoutLamp := Lockout;

Ladder wins this argument when an electrician has to fault-find your program at 02:00 with a multimeter mindset — the rung looks like the circuit diagram it replaced, and that familiarity is worth real money on a breakdown. ST starts winning when the pattern repeats: ten pumps with the same interlock shape is one ST function called ten times, where ladder hands you ten near-identical rungs to keep in sync by hand forever. Learn both. Build the exercise in ladder first, then write the ST version and confirm the two behave identically in the simulator. That translation skill — same logic, two languages — is exactly what technical interviews and commissioning work both test.

Common mistakes

Every mistake below comes from a real program: either one of ours from years back, or one we were called in to fix. Check your build against the list before you call the exercise done.

• Requiring only simultaneity, not synchronous actuation. Plain BtnLeft AND BtnRight passes the demo and fails the cable-tie: with one button tied down the press becomes a one-hand machine, which is precisely the injury this control exists to prevent.
• Sealing the valve in around the palm buttons. Any seal branch that bypasses the button contacts means a released palm no longer opens the press — the operator's free hand is now reaching toward a machine that no longer needs both hands to stay closed. A seal may only carry the armed state inside the both-buttons AND, never around it.
• Clearing the lockout on a timer or on the next button press instead of on both-released. Either shortcut quietly removes the anti-tie-down property while every normal-operation test still passes — the failure only shows when someone actually ties a button down.
• Treating this PLC program as the safety system. A standard PLC has no guaranteed failure mode: an output card can fail with the valve energised. The exercise is the logic; the real machine needs the safety relay, dual-channel buttons and monitored contacts that ISO 13851 demands.
• Relying on the 0.5-second lockout alone for anti-tie-down. Tie one button down and tap the other in a 0.3-second rhythm: the XOR timer resets on every tap, never reaches half a second, and the press cycles on one hand. The Armed bit, set only on a full release of both buttons, is what actually closes that hole.

Most of these share one root cause: the rung shape doesn't match the intent, so the program passes the obvious test and fails the edge case. That's why the solution steps force the edge cases deliberately instead of stopping at "it starts and it stops". Steal that habit for every program you write from here on.

Take it further

Got it working first time? Good — now make it earn its keep. Each extension below changes the spec the way a real client does: after you've finished. Treat each one as a fresh job card, and re-test the whole program afterwards, not just the new part. Regressions hide in the rungs you didn't touch.

• Add a maximum-stroke timer: if the press is commanded closed for more than 3 seconds, open and lock out — a stuck valve detector built from one TON.
• Add a single-stroke mode: each valid two-hand press gives exactly one close-open cycle, and a new cycle needs both buttons released first — notice how much of the anti-tie-down logic you reuse.
• Study a real two-hand safety relay's datasheet (synchronous monitoring, dual channels, cross-fault detection) and map each feature onto the rungs you just wrote — the annunciator exercise's first-out thinking helps with the monitoring mindset.

If you build even one extension, screenshot the finished rungs and keep them somewhere organised. A folder of working, tested exercise solutions is the start of a portfolio — and hiring engineers ask candidates to explain a rung far more often than they ask to see certificates.

Run this in the simulator

The sandbox on the free tier lets you build the core rungs of this advanced exercise yourself — no card details, no install, signed up and on a rung inside two minutes. The watch table is the part that matters here: force the inputs, watch the outputs, and run the test sequence from the solution steps against a live scan cycle instead of imagining it. To be straight about what's paid: the guided version of this exercise — graded checkpoints, feedback on every submission, plus the fault-injection variants that break your program the way a real plant does — sits in the curriculum on the Basic tier at USD 12 per month and Pro at USD 29 per month, alongside the wiring track, sensor school and cert packs. Training centres and engineering departments wanting this in a lab should look at the Teams tier (USD 199 per seat per year, minimum 5 seats); the training-centres page carries the institutional details and the contact form. If you're an individual learning the trade, prove the core rungs in the free sandbox first and decide whether the graded track is worth the money. And once this one runs clean, line up the next exercise a notch harder — the step up is where the skill gets built.

Reference

International Society of Automation covers the background theory behind this exercise, and it's worth twenty minutes of your time after the build — theory sticks better once your hands have done the work. The languages used here are defined by the IEC 61131-3 standard from iec.ch, and your CPU vendor's manual remains the canonical source for how a specific controller executes them.

What we don't claim

This site is not SAQA-registered, not MerSETA-accredited, and not an NQF-registered qualification provider. Our completion certificates are course-level only — they describe what you covered, not an NQF Level X qualification. The CCST cert from ISA is the portable industry credential we recommend; we are not an ISA cert delivery partner either, but our cert packs are CCST-aligned. The exercise on this page is practice material written by working programmers: finishing it proves the skill to yourself and to the simulator's progress tracking, not to a regulator.