Timer Patterns

The Core Idea

Timer patterns combine timing instructions with logic and memory to create behaviors such as flashing, staged startup, and timeout detection. Each timer needs a defined condition for starting, continuing, and resetting.

What you will learn

  • Make an on-delay timer reset itself to flash a lamp at a repeating interval.

  • Chain two on-delay timers so the second stage waits for the first.

  • Keep a motor command on for a minimum time after a short run request.

  • Check timing behavior across interruptions and repeated requests.

Why it matters

A timer's preset alone does not define the machine's behavior. The surrounding logic determines how it handles repeated requests, interruptions, and failures to finish.

The problem

Three small machines need more than a single delay:

  1. A status lamp must flash while ENABLE_FLASH is TRUE. FLASH_LAMP is the lamp output. Use a 1000 ms timer and switch the lamp near its 500 ms halfway point. Allow one scan for the timer to reset each cycle. When the request clears, the lamp must turn off and the next request must start a fresh cycle.

  2. A two-stage startup begins when START_CMD is TRUE. STAGE_A turns on after a continuous 500 ms request. STAGE_B follows 500 ms later. Clearing the request turns both off and resets both delays.

  3. RUN_REQUEST asks a motor to run. MOTOR_OUT turns on immediately. A brief request must still give it a nominal 1000 ms minimum run; a longer request keeps it on until the request clears. This is a timing exercise, not a motor safety circuit.

An on-delay timer (TON) accumulates time while enabled. Its Done bit becomes TRUE at the preset, and both Done and accumulated time reset when the enable goes FALSE. This lesson builds patterns from that behavior. The earlier on-delay and off-delay timer lessons provide the timer basics.

Predict

The flasher has just reached the end of its 1000 ms period. Its on-delay timer Done bit is TRUE. The timer enable rung contains a normally closed contact of that same Done bit. What happens on the next scan, and why does the lamp light again?

Keep your answer in mind while you run the demo.

Try it

Turn ENABLE_FLASH on. Pause and use Step one scan near a transition if you want to see the timer state change. Watch FLASH_TIMER and FLASH_LAMP for at least three cycles. Then clear ENABLE_FLASH and turn it on again.

Check your prediction

When Done becomes TRUE, its normally closed contact opens on the following scan. That scan disables and resets the on-delay timer, returning its accumulated time to zero. The comparison for the first 500 ms is TRUE again, so the lamp starts a new on phase. The timer then begins counting again. The extra reset scan is part of this circuit's timing, so the steady flash period can be one scan longer than the 1000 ms timer preset.

Look closer

The first rung makes FLASH_TIMER self-reset. The second compares FLASH_TIMER.ACC with 500 ms and drives FLASH_LAMP. The lamp is on during the first half of each period. Driving it from Done instead would make a short pulse at the end of the period.

Watch two full cycles, not one transition. At a 100 ms scan interval, each timer and output change is visible only on a scan boundary. Time from one lamp rising edge to the next should be roughly 1000–1100 ms, including the reset scan. When ENABLE_FLASH clears, the timer and lamp reset; the next request begins at the on phase.

The next pattern is a chain. Its first timer waits for START_CMD; its second timer must start from the first timer's Done bit. If both timers start from START_CMD, they finish together.

Change it

This two-stage program is wired, but both timers start from START_CMD. Turn the request on and observe the mistake. Then change only the contact before SECOND_DELAY so it follows FIRST_DELAY.Done. Run it again. Stage A should come on first and stage B should join it about 500 ms later. Clear the request during the gap and confirm both stages turn off.

Show the guided change

Keep START_CMD on the FIRST_DELAY rung. Replace the START_CMD contact on the SECOND_DELAY rung with a normally open FIRST_DELAY.Done contact. Keep STAGE_A driven by FIRST_DELAY.Done and STAGE_B by SECOND_DELAY.Done. The second delay cannot accumulate until the first one completes. When START_CMD clears, the first timer resets, which also disables and resets the second.

Check yourself

Build a minimum run time for MOTOR_OUT. The challenge editor opens with the four tags RUN_REQUEST, RUN_HOLD, MIN_RUN_TIMER, and MOTOR_OUT. It starts with no rungs. A request must start the motor immediately; a brief request must leave it on for about 1000 ms total. If the request stays TRUE longer, the motor must keep running and turn off after the request clears. Run the behavioral checks as often as you need. They include a second short request after the first run ends.

Hint 1

A direct contact from RUN_REQUEST to MOTOR_OUT forgets a short request. Which tag can remember that a run began?

Hint 2

Set RUN_HOLD when requested, and enable the on-delay timer while RUN_HOLD is TRUE. Think about the two conditions that must both be true before clearing the hold.

Hint 3

Reset RUN_HOLD only when MIN_RUN_TIMER.Done is TRUE and RUN_REQUEST is FALSE. Drive MOTOR_OUT from RUN_HOLD. Put the rungs in that order so the output sees the updated hold state in the same scan.

Show the worked solution

  1. A normally open RUN_REQUEST contact drives a set coil for RUN_HOLD.

  2. A normally open RUN_HOLD contact enables TON MIN_RUN_TIMER with a 1000 ms preset.

  3. Normally open MIN_RUN_TIMER.Done and normally closed RUN_REQUEST contacts in series drive a reset coil for RUN_HOLD.

  4. A normally open RUN_HOLD contact drives MOTOR_OUT.

The set coil remembers even a short request. The timer runs from that remembered state. Its completion alone cannot stop the motor: the request must also have cleared. After the hold resets, the timer resets on the next scan, ready for a second request. The simulator counts in scans, so the observed output transition can differ from the nominal preset by one scan.

What happened and why

All three circuits combine time with state. The flasher uses a timer's own Done bit to create a repeating cycle. The chain uses the first timer's Done bit to begin a second delay, enforcing order. The minimum-run circuit remembers that a run began, times that held state, and clears it only after both the minimum interval and the request have ended.

Choose the pattern by the required behavior. A timer directly on an input handles one continuous delay. Repeating, ordered, or minimum-duration behavior needs the right feedback or memory around that timer. Check the reset path as carefully as the turn-on path.

Common mistakes

  • A flasher timer stays done. Cause: its enable never goes FALSE. Symptom: the lamp does not repeat. Fix: use the timer's own Done bit as a normally closed enable contact, then check the output over several periods.

  • Stage B starts with stage A. Cause: both delay timers follow START_CMD. Symptom: both Done bits rise at about the same time. Fix: enable SECOND_DELAY from FIRST_DELAY.Done.

  • A short request stops the motor early. Cause: MOTOR_OUT follows RUN_REQUEST directly, or RUN_HOLD clears when the request drops. Fix: clear the hold only after the timer is done and the request is clear.

  • A long request stops at the preset. Cause: the hold clears as soon as the timer is done. Fix: keep the request-clear condition in the reset rung.

Enable JavaScript to run the embedded simulator and complete the interactive exercises.