exercises · South Africa
PLC staggered motor start with on-delay timers
Build a PLC staggered motor start: three fans started 5 seconds apart on TON timers to tame inrush after load-shedding, with an instant collective stop.
Difficulty: intermediate · 45–75 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.
Open the simulator and build along →The job card
Job card: the extraction system over the curing ovens at an East Rand rubber plant runs three 15 kW fans. When power returns after load-shedding, all three contactors pull in on the same half-second and the combined inrush — each motor drawing six to eight times rated current for the first moments — takes out the 250 A main breaker, so the whole plant stands dark for another twenty minutes while someone walks to the substation. Stage the fans: fan 1 immediately on a start command, fan 2 five seconds later, fan 3 five seconds after that. Stop must drop all three at once — staging applies to starting, never to stopping. And settle the restart question explicitly with the foreman: after an outage, may the system restart itself, or must someone press start? He wants self-restart, so build it with a power-return delay and write the decision down.
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.
| Tag | Type | Address | Purpose |
|---|---|---|---|
AutoRun | DI | %I0.0 | Run selector switch, maintained position. TRUE = extraction system commanded to run. A maintained selector (not a momentary button) is what makes self-restart after an outage legitimate. |
StopPB | DI | %I0.1 | Stop pushbutton, normally closed, wired fail-safe. TRUE = healthy and unpressed. Drops all three fans instantly. |
OverloadOK | DI | %I0.2 | Series chain of all three fans' overload auxiliaries, normally closed, fail-safe. TRUE = no overload tripped. |
Fan1 | DO | %Q0.0 | Fan 1 contactor coil, starts immediately on a run command. |
Fan2 | DO | %Q0.1 | Fan 2 contactor coil, starts 5 seconds after fan 1. |
Fan3 | DO | %Q0.2 | Fan 3 contactor coil, starts 10 seconds after fan 1. |
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.
- Run all the stage timers off the single Run signal, not off each other's outputs in a daisy chain. With parallel TONs at 5 s and 10 s, each fan's start time is one timer's accuracy from the command; chain them off each other and every stage inherits the jitter and failure modes of the one before.
- The maintained selector is what makes auto-restart honest. With AutoRun still TRUE when power returns, the system restarts itself — staged, after a settling delay — because that is what a maintained command means. If the foreman had wanted a human in the loop, the answer is a momentary start button and a seal-in, and the difference between those two rungs IS the restart policy.
- Add a power-return settling delay (10 s) before stage one. When the grid comes back, the plant's compressors, chillers and everything else are all starting in the same minute; your three fans waiting out the first ten seconds is the same etiquette as the borehole exercise, scaled up.
- Stopping is never staged. Stop, overload and the selector all gate every fan output directly, so any of them drops all three contactors in one scan. The staging lives only on the start side of the logic — keep it structurally impossible to confuse the two.
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 run signal with settling delay
tSettle is a TON timing from PLC power-up (IN tied TRUE, PT of T#10s). Run is AutoRun AND StopPB AND OverloadOK AND tSettle.Q — no seal-in, because the maintained selector IS the memory. This one rung encodes the foreman's restart decision; the comment above it should say so in plain words.
// AlwaysOn ──[TON tSettle, PT := T#10s]
// [ ]AutoRun──[ ]StopPB──[ ]OverloadOK──[ ]tSettle.Q──( )Run
Rungs 2-3: the stage timers
Two TONs in parallel, both with IN from Run: tStage2 at T#5s and tStage3 at T#10s. Both reference the same Run edge, so fan 3 starts 10.0 seconds after the command regardless of what fan 2's timer did. When Run drops, both timers reset together, and the next start gets the full stagger again.
// Run ──[TON tStage2, PT := T#5s]
// Run ──[TON tStage3, PT := T#10s]
Rungs 4-6: the fan outputs
Fan1 follows Run directly. Fan2 is Run AND tStage2.Q; Fan3 is Run AND tStage3.Q. The AND with Run in every output rung is the collective-stop guarantee: whatever the timers hold, no Run means no fans, this scan.
// [ ]Run ──( )Fan1
// [ ]Run──[ ]tStage2.Q ──( )Fan2
// [ ]Run──[ ]tStage3.Q ──( )Fan3
Test the stagger, the stop, and the blip
Start with a stopwatch on the three outputs: 0 s, 5 s, 10 s, every time. Press stop at 7 seconds — fans 1 and 2 drop instantly and fan 3 must never appear. Restart and confirm the stagger runs fresh from zero, not from where the timers were. Cycle PLC power with the selector on: all fans stay off for the 10-second settle, then stage up by themselves — the foreman's self-restart, demonstrated. Finally blip Run off for 200 ms at 8 seconds in: all fans drop, and the restart staggers from the top. Decide whether that full re-stagger on a blip is acceptable, and note what you would add (a short TOF on Run) if it is not.
The structured text version
The same logic in IEC 61131-3 structured text — each output written as a boolean equation you can read aloud.
(* Staggered three-fan start, IEC 61131-3 ST *)
tSettle(IN := TRUE, PT := T#10s); (* settling delay from PLC boot *)
Run := AutoRun AND StopPB AND OverloadOK AND tSettle.Q;
tStage2(IN := Run, PT := T#5s);
tStage3(IN := Run, PT := T#10s);
Fan1 := Run;
Fan2 := Run AND tStage2.Q;
Fan3 := Run AND tStage3.Q;
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.
- Daisy-chaining the timers off the previous fan's OUTPUT (tStage3's IN from Fan2). Now an overload that takes out fan 2 also silently strands fan 3 off, and the fault report says 'fan 3 intermittent' when fan 3 was never the problem.
- Using a TOF somewhere in the start path because the on/off naming blurred at 17:00 on a Friday. The symptom is fans that keep running after a stop for exactly the stagger time — the stop test in the steps catches it in seconds, which is why the stop test exists.
- Staging the stop 'for symmetry'. Stopping is the safe direction; there is no inrush argument for delaying it, and a delayed stop on an extraction system means smoke keeps NOT being extracted for ten extra seconds while the logic admires its own symmetry.
- Building self-restart without the settling delay. The fans then stage up during the worst seconds of grid return, sharing the supply with every compressor on the property — the staging tamed your own inrush but joined everyone else's. Ten seconds of patience is free.
- Leaving the restart policy implicit. The same rungs with a momentary button and seal-in mean 'a human must restart'; with a maintained selector they mean 'restart yourself'. Plants have flooded and ovens have cooked because nobody wrote down which one was intended.
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.
- Make the stage interval an HMI setpoint clamped between 2 and 30 seconds, and add per-fan run-feedback inputs with a 2-second discrepancy alarm — command versus confirmation, the same upgrade the star-delta exercise suggests.
- Generalise to N motors with an array of outputs and one stage-interval timer driving an index — the jump from three hand-written rungs to a loop is the same one the annunciator exercise makes with its channels.
- Combine with the star-delta exercise: three large motors, each with its own star-delta sequence, staged 15 seconds apart — a realistic compressor-house restart, and a genuinely satisfying thing to watch run in the simulator.
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 intermediate 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 — 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.
Start in the free sandbox →Reference
Motor soft starter on Wikipedia 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.