PLC Timer Exercise: Flashing Beacon and Acknowledgement

This PLC timer exercise uses a virtual flashing beacon to explain on-delay timers, call order, reset behaviour and alarm acknowledgement. You will study a two-timer pattern, calculate an explicit timing model and compare the model with observations from your chosen simulator. The aim is to explain each transition, including the evaluations between one phase finishing and the next phase starting.

The example is a disconnected learning project. Its Beacon and Horn variables are software commands, with no physical lamp, sounder, silo or protective system attached. A flashing screen indicator does not prove a field device works, and a timer preset does not by itself prove an exact output frequency.

If you need preparation, read ladder logic basics and the start-stop seal-in exercise. The first explains Boolean paths; the second explains remembered state and why a held input can differ from a fresh action. Both ideas appear in the timer and acknowledgement sections below.

Define the learning task before selecting timers

The fictional screen has an AlarmActive input, an Acknowledge input and two indicators. While AlarmActive is false, both indicators must be false and the timing sequence must reset. When the alarm becomes active, the beacon sequence begins with a dark phase. It then alternates between dark and lit phases using two on-delay timer instances.

The nominal preset for each timer is 500 milliseconds. That gives a convenient learning target, but this particular feedback pattern includes evaluation and reset effects. Record the observed phase lengths and period instead of describing them as exactly half a second in advance.

The Horn command is separate from the flashing phase. It is true for an active, unacknowledged event and false after acknowledgement. Acknowledging must not stop the flashing sequence. Clearing the alarm clears the acknowledgement state. A subsequent event requires its own acknowledgement under the explicit edge policy described later.

Do not introduce a lamp-test button, multiple priorities or adjustable periods until this small specification is understood. Each addition creates new cases and may obscure whether the first discrepancy comes from timing, stored acknowledgement or the order of assignments.

Understand TON inputs, outputs and instances

The CODESYS TON function block reference describes an on-delay block: a rising input starts the delay, a falling input resets it, and Q becomes true when the input remains true and the preset delay has elapsed. ET reports elapsed time. Use that reference for the documented block, rather than assuming every instruction named “timer” has the same behaviour.

The two timer instances need separate state. Calling one instance twice with different inputs does not give you two independent elapsed-time histories. Declare distinct names and record which one each rung or statement calls.

Schneider Electric's TON reference for the documented Machine Expert version also describes Q in relation to IN, ET and PT, and includes a cycle-related note for very short presets. That is a reason to inspect the relevant runtime documentation, not to generalise that version's special cases to every controller.

02

Read the two-timer sequence in execution order

A structured text sketch of the pattern is:

tOff(IN := AlarmActive AND NOT tOn.Q, PT := T#500ms);
tOn(IN := AlarmActive AND tOff.Q, PT := T#500ms);
Beacon := AlarmActive AND tOff.Q;

The sketch assumes two declared TON instances and sequential execution in the displayed order. It is not a supplied compiled project for every platform. Call both instances on every evaluation in this exercise, including evaluations where their inputs are false, so the reset conditions are evaluated.

At the first call, tOff reads tOn.Q from its previous invocation. The second call can read the newly updated tOff.Q. That asymmetry matters: when tOn becomes done, tOff has already been called for this evaluation. Its input cannot react to the new tOn.Q until a later evaluation in this ordering.

While tOff is delaying, Beacon is false. When tOff.Q becomes true, Beacon becomes true and tOn begins its delay. When tOn.Q eventually becomes true, it prepares the feedback condition that will reset tOff on the next evaluation. Resetting tOff then gives tOn a false input during that same evaluation.

In ladder, identify the equivalent call order and the source of each contact value. Do not assume rearranging rungs leaves the timeline unchanged. The ladder logic simulator guide contains a simpler assignment-order exercise if old and newly assigned values are difficult to distinguish.

Calculate an explicit timestamp model

To make the timing arithmetic reproducible, use this fictional software model before testing a native timer. It is defined here, rather than claimed to be the internal implementation of your PLC:

1. Supply a monotonically increasing timestamp to each evaluation.
2. If a timer's input is false, clear its start timestamp, set ET to zero and Q false.
3. On the first true-input call after reset, store the current timestamp as its start and set ET to zero.
4. On later true-input calls, set ET to the smaller of PT and the current timestamp minus that stored start.
5. Set Q true when the resulting ET reaches PT.
6. Update tOff first, tOn second and Beacon last, as in the sketch.

Both timers begin reset. AlarmActive is true from timestamp zero. Evaluations occur every 100 ms. The table records results after both calls, with ET values in milliseconds and 1 meaning true.

At 1000 ms the beacon remains true because tOff was evaluated before tOn completed. At 1100 ms the feedback resets both timers. At 1200 ms tOff starts a new timed interval with ET zero. Its next completion occurs at 1700 ms.

The observed rising edges at 500 and 1700 ms are 1200 ms apart. The first lit interval lasts from 500 to 1100 ms, or 600 ms, when you hold each computed result until the next evaluation. This is a consequence of this model and call schedule. It is not a measured result from a particular controller.

03

Compare nominal timing with observed timing

Repeat the same model with evaluations every 10 ms. Its first rise is at 500 ms, its first fall at 1010 ms and its next rise at 1520 ms. The observed rising-edge period is therefore 1020 ms and the first lit interval 510 ms. Smaller evaluation steps reduce this model's difference from the nominal timing, but do not make the preset alone a proof of exact frequency.

In a real development environment, collect timestamps or a suitable trace for several transitions. State the task interval, timer type, software version and observation method where known. Separate the start of the first event from later steady cycles; the initial dark interval can differ from dark intervals following a reset.

A screen refresh can omit transitions or display them late. Counting flashes by eye may be a useful rough demonstration, but it is weak evidence for a timing claim. Likewise, the timestamp model above uses supplied time; its arithmetic is not a performance measurement of your browser or laptop.

For the model, try irregular evaluation timestamps such as 0, 450, 550, 950, 1100 and 1250 ms. Predict when each timer first sees its threshold reached and when the reset is actually observed. Keep the sequence monotonic. If timestamps move backwards, stop that test and define how the model should handle invalid time instead of treating negative elapsed duration as normal behaviour.

Test alarm clear and restart during each phase

Clear AlarmActive before tOff finishes. At the next evaluation, both timer inputs must be false, both ET values zero and Beacon false. Restore the input later and check that the first true call starts a new interval; it must not inherit the unfinished dark-phase elapsed time in this model.

Repeat the clear while Beacon is true and tOn is partway through its delay. Then repeat it when tOn.Q is already true. The explicit AlarmActive conditions make the disabled results clear, but you still need to invoke both timers to evaluate those false inputs.

Do not simply stop calling the timing routine and assume its stored results have reset. A skipped call and a call with IN false are different program actions. Check the documented behaviour of your chosen runtime if you investigate conditional calls, disabled tasks or a stopped application.

Record whether restarting the learning tool recreates the instances or preserves any state. That is separate from toggling AlarmActive inside a running project. The online simulator workflow guide explains why project saving, session state and runtime initialisation should be recorded separately.

04

Give acknowledgement its own event policy

A simple level-sensitive expression such as Acked = AlarmActive AND (Acknowledge OR PreviousAcked) accepts an already-held acknowledge input on a new event. Clearing the old Acked state does not prevent that held input from setting it again. Consequently, “the horn always sounds again on every new alarm” would be too broad for that expression.

For this exercise, use a different, explicit policy. A new alarm event takes priority over acknowledgement on its first active evaluation. A fresh acknowledge edge on a later active evaluation silences the Horn command. Holding the button across a clear and a new event does not acknowledge the new event.

Remember PreviousAlarm and PreviousAcknowledge, and initialise Acked false. Sample the current acknowledge level into PreviousAcknowledge at initialisation, and initialise PreviousAlarm false for this declared fresh exercise. On each evaluation:

NewAlarm = AlarmActive AND NOT PreviousAlarm
AckEdge = Acknowledge AND NOT PreviousAcknowledge

If NOT AlarmActive: Acked = false
Else if NewAlarm: Acked = false
Else if AckEdge: Acked = true
Else: retain Acked

Horn = AlarmActive AND NOT Acked
PreviousAlarm = AlarmActive
PreviousAcknowledge = Acknowledge

Update both previous-input values every evaluation, including when the alarm is inactive. Beacon continues to come from the timer sequence. Do not use Acked to reset the flashing timers in this version; acknowledgement changes the Horn command only.

Work through the held-button case

Begin with both inputs false and the acknowledgement state false. This trace is independent of the flashing phase.

Also apply a rising alarm and rising acknowledge together from an inactive, released state. The new-event condition has priority, so Horn is true on that evaluation. Describe the result as a software command observation, not a guaranteed audible pulse or a complete industrial alarm-management policy.

05

Deliberately break one condition at a time

Drive Beacon from tOn.Q. In the timestamp trace, tOn.Q is true at 1000 ms and resets at 1100 ms. That creates a short completion interval in this model, not a simple inversion of the intended phase. Predict the new waveform before running it.

Retain acknowledgement after AlarmActive clears. Start, acknowledge, clear and restart the event. If the old Acked value survives and no new-event rule overrides it, the Horn command can remain false. Keep this failed version's trace beside the corrected event policy.

Move Beacon before the timer calls. In a sequential immediate-assignment model, the output reads an older timer result. Compare recorded transitions at the end of each evaluation. A highlight seen partway through execution is not necessarily the final output value.

Share a timer instance. In a disconnected scratch project, inspect how two calls affect the same state. Do not describe the resulting values as two independent timers. Restore distinct instances before returning to the specified exercise.

Change one feature per experiment and preserve a known project version. A useful fault report names the changed condition, the smallest exposing sequence and the actual result. It does not rely on invented field experience or a claim that every timer failure has the same cause.

Use the exercise to evaluate training depth

A South African learner comparing PLC courses can ask whether the provider teaches timer instances, execution order, boundary cases and measurement. A syllabus that lists TON, TOF and TP does not show whether learners investigate the difference between a preset and an observed output interval.

For a Potchefstroom distance learner, a Gauteng evening class or a Durban technician study group, the same trace can be prepared offline and checked in a later software session. These are suggested learning settings, not claims about local training premises or bookings. The online PLC training guide explains broader format and access questions to ask before choosing a course.

For instrumentation learners, distinguish detecting an alarm condition from acknowledging its presentation. The instrumentation technician learning guide connects that distinction to broader signal interpretation. This exercise supplies no high-level probe specification, silo protection design or accreditation outcome.

Keep a portfolio note with the nominal presets, timer model or native block reference, task assumptions, program order, expected transitions and measured transitions. Include one discrepancy you investigated. That makes the work assessable as a small reproducible study rather than a screenshot of a blinking icon.

Choose relevant next practice

Review the PLC timer learning page for related timer material, checking the current content and access options. This article's timestamp model and acknowledgement tests are not claimed to be automatically graded by that destination.

For the event-state side, inspect the PLC alarm-management learning page. Compare its stated scope with the small policy here. A more complete alarm system can have additional requirements that this example deliberately has not specified.

Continue to on-delay staging practice when you want to study several delayed transitions, or the first-fault annunciator exercise when your main question is which event happened first. The PLC examples collection groups projects by learning purpose so you can choose the next concept deliberately.

06

Questions learners ask about flashing PLC timers

Do two 500 ms TON presets guarantee a 1 Hz beacon?

No. In the supplied timestamp model, call order and reset evaluations lengthen the observed cycle. A native implementation needs its own measured result and runtime assumptions. State the nominal presets separately from the observed period.

Why is ET zero when the next dark phase starts?

This model stores a new start timestamp on the first true-input call after reset. No duration has elapsed since that stored timestamp yet. The next call can then report elapsed time. A reset call is not itself the start of a new enabled interval.

Can I acknowledge the alarm without stopping the flash?

Yes, under the specified separation of variables. Acked affects Horn, while Beacon depends on AlarmActive and the timer sequence. Test that separation while the beacon is in each phase.

What should I ask an AI tutor to calculate?

Provide the timer rules, call order and timestamp sequence. Ask for tOff.ET, tOff.Q, tOn.ET, tOn.Q and Beacon after each evaluation. Then check the 1000, 1100 and 1200 ms rows yourself. Without those assumptions, a confident answer of “exactly one hertz” does not resolve this exercise.