PLC timer exercise: build a flashing beacon

Difficulty: beginner · 20–40 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: the meal silo at an animal-feed mill outside Potchefstroom keeps overfilling because the loader driver cannot see the panel from the tip point. Fit the spare red beacon on the silo roof and make it flash — half a second on, half a second off — whenever the high-level probe is covered. Add the horn in the bagging area: it must sound with the alarm until someone presses the acknowledge button, but the beacon must keep flashing for as long as the level stays high. If the level drops and comes back, the horn must sound again. Two timers, one latch, no flasher relay from stores.

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 classic flasher is two TONs feeding each other: the off-phase timer enables the on-phase timer, and the on-phase timer's done bit cuts the off-phase timer's input, which collapses both for one scan and restarts the cycle. No special flasher instruction needed, and the pattern ports to any IEC platform.
• Make each phase time a named constant rather than burying T#500ms in two places. The day someone wants a faster flash for a second alarm, one edit beats hunting through rungs.
• The acknowledge is a latch that lives only while the alarm stands: set by the button, cleared when LevelHigh drops. Tying the latch's life to the alarm condition is what makes the horn re-sound on the next event without any extra logic.

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 off-phase timer

TON tOff runs while LevelHigh is true and the on-phase timer is not done: LevelHigh AND NOT tOn.Q. While tOff is timing its 500 ms the beacon is dark. When it completes, its done bit turns the beacon on and starts the second timer.

// LevelHigh AND NOT tOn.Q ──[TON tOff, PT := T#500ms]

Rung 2: the on-phase timer and the beacon

TON tOn times while tOff.Q is true. The beacon output simply follows tOff.Q, so it is lit for exactly the 500 ms that tOn takes to finish. When tOn.Q goes true it breaks rung 1's input, tOff resets, tOff.Q drops, the beacon goes dark, tOn resets too, and the pair starts over.

// Rung 2: tOff.Q ──[TON tOn, PT := T#500ms]
// Rung 3: tOff.Q ──( )Beacon

Rung 4: acknowledge latch and horn

Seal-in on the Acked bit: (AckPB OR Acked) AND LevelHigh. The latch can only exist while the alarm stands, so it self-clears when the level drops. The horn rung is then LevelHigh AND NOT Acked — loud until someone owns the alarm, silent after, re-armed automatically for the next event.

// Rung 4: (AckPB OR Acked) AND LevelHigh ──( )Acked
// Rung 5: LevelHigh AND NOT Acked ──( )Horn

Test the rhythm and the re-alarm

Force LevelHigh and count the flashes against your watch: ten flashes in ten seconds, even spacing. Press acknowledge — horn off, beacon still flashing. Drop LevelHigh, confirm everything clears, then force it again: the horn must sound again because the old acknowledge died with the previous alarm. Last check: watch tOff.ET in the simulator and confirm neither timer ever sticks at done.

The structured text version

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

(* 1 Hz flasher with acknowledge, IEC 61131-3 ST *)
tOff(IN := LevelHigh AND NOT tOn.Q, PT := T#500ms);
tOn(IN := tOff.Q, PT := T#500ms);
Beacon := tOff.Q;
Acked := (AckPB OR Acked) AND LevelHigh;
Horn  := LevelHigh AND NOT Acked;

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.

• Resetting a single timer with its own done bit and expecting a visible flash. The done bit is true for one scan only, so the beacon blips for milliseconds — you need the second timer to stretch the on phase into something a human can see.
• Swapping which timer drives the beacon. Driving it from tOn.Q instead of tOff.Q inverts the phase so the beacon starts lit, which matters when the same pattern later gates a horn pulse or a lamp test.
• Acknowledging with a SET coil and clearing it nowhere. The horn then stays silent on every subsequent alarm forever — the latch must die when the alarm condition drops, or re-alarming cannot work.
• Using the PLC's built-in clock-pulse bit and calling the exercise done. Fine on that one CPU, but the two-TON pattern is the portable answer, and interviews for PLC jobs ask you to build exactly this without the shortcut.

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 second, faster flash rate (250 ms) for an unacknowledged alarm and drop to the slow flash once acknowledged — this is the front door to the annunciator exercise's ISA-style sequence.
• Add a lamp-test pushbutton that forces the beacon and horn on while held, proving the field devices without faking a level alarm.
• Replace the fixed T#500ms with a value from an HMI tag and clamp it between 200 ms and 2 s in logic, so an operator typo cannot stop the flash entirely.

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

Every beginner exercise on this site, this one included, runs on the simulator's free tier — 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. The full curriculum — the structured version of these exercises with feedback on every submission — plus the wiring track, sensor school and cert packs sit in the Basic tier at USD 12 per month and Pro at USD 29 per month. 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, start on the free tier, finish the beginner set, and decide from there.

Reference

IEC 61131-3 standard 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.