Home › Guides › PLC Ladder Logic Advanced

PLC Ladder Logic Advanced: Timers, Counters and Sequencers

Basic ladder logic — contacts, coils, and simple start-stop circuits — will take you surprisingly far. But real machines need more: delays before an action, counts of products or cycles, sequences that must happen in order, and programs organised so that a fault can be found without reading five hundred rungs. This advanced guide covers the instructions that make those programs possible: timers, counters, sequencers, shift registers and subroutines, with worked examples for each. It builds directly on our PLC basics and ladder logic guide and deliberately does not repeat the basics; if scan cycle, contacts and coils are new to you, start there first.

As with all our control guides, this is generic educational material from standard PLC practice. Instruction names and details vary slightly between PLC brands, so the concepts and the logic patterns here transfer everywhere, while the exact instruction names and addressing should always be checked against the manual for the controller you are actually using. The worked examples use generic addresses and plain descriptions rather than any vendor's proprietary format, and they are written to be understood and adapted, not copied blindly into a running machine.

Timers: on-delay, off-delay and retentive

A timer is an instruction that measures time and changes an output when a preset time has elapsed. The on-delay timer, usually called TON, is the workhorse: when its input turns on, it starts timing, and when the accumulated time reaches the preset, its output turns on. If the input turns off before the preset, a standard TON resets to zero. The classic use is a delayed start: a conveyor starts, and five seconds later a second conveyor starts, so that material does not pile up at the transfer point. Another is a warning: a beacon sounds for a few seconds before a machine starts moving, giving people time to clear the area.

The off-delay timer, usually called TOF, works the other way round: its output turns on immediately when the input turns on, and when the input turns off, the output stays on for the preset time before switching off. The classic use is a cooling fan or an extraction fan that must keep running for a set time after the machine stops. The retentive timer, usually called RTO, is the third type: it accumulates time across multiple input pulses without resetting when the input drops out, and it needs an explicit reset instruction. Retentive timers suit totalising jobs, such as accumulating the total running time of a pump over a shift, where the time must survive stop-start cycles.

Choosing the preset and the time base is part of the design, not an afterthought. A timer with a one-second time base and a preset of five gives a five-second delay; the same preset with a ten-millisecond time base gives a fiftieth of a second. Always check the time base your controller uses for that instruction, and always document presets in the program comments, because a preset of 50 means nothing to the next engineer unless the unit is stated. When a timer misbehaves on site, the first checks are always the input condition, the preset, the time base, and whether the timer is being reset by another rung you forgot about.

Counters: counting up, counting down, and high-speed counting

A counter counts events: products passing a sensor, cycles completed, batches produced. An up-counter increments its count each time its input pulses, and sets its output when the count reaches the preset. A down-counter starts from the preset and decrements, setting its output at zero. The classic use of an up-counter is batching: count ten bottles, then stop the filler and index the next tray. The classic use of a down-counter is a remaining-quantity display: load a batch size, count down as products are made, and signal when the batch is complete.

Counters, like retentive timers, need an explicit reset, and forgetting the reset is the most common counter fault on a real machine: the counter reaches its preset on the first batch and then never counts again, because nobody reset it for the second batch. Build the reset into the sequence itself — reset the counter when the batch completes and the next batch is acknowledged — rather than relying on an operator remembering to press a reset button. High-speed counters are a separate case: ordinary PLC inputs scan too slowly for fast pulse trains from encoders, so high-speed counter inputs are hardware modules that count independently of the scan cycle, and they are the right tool for position and speed measurement.

Sequencers: machines that move step by step

Most real machines are sequences: clamp, drill, retract, unclamp, index, repeat. A sequencer is a program structure that models that sequence directly. The program holds a step number, and each step enables the outputs for that stage of the process and waits for the conditions that mean the stage is complete — a cylinder extended sensor, a timer elapsed, a part present signal — before advancing to the next step. The step number itself becomes a powerful diagnostic: when a machine stops, the current step number tells you exactly which stage it stopped in, and the step's conditions tell you what it is waiting for.

Build sequencers with a clear rule: each step should have one job, a clear completion condition, and a defined next step, including what happens on a fault. A step that waits forever with no timeout and no alarm is a machine that will stop mysteriously at 3 a.m. with no clue for the night shift. Add a step timer that raises an alarm if a step takes far longer than normal, and add a manual step-advance or step-reset facility for commissioning and fault-finding, properly guarded so it cannot be used to bypass safety. A well-built sequencer reads like the machine's own story, and a maintenance technician can follow it rung by rung without needing the original programmer.

Shift registers and data movement

A shift register moves bits through a sequence of positions, one step at a time, and it is the natural tool for tracking things that move through a process. Imagine bottles on a conveyor passing a reject station: a quality sensor detects a faulty bottle, and a bit representing that bottle is loaded into a shift register. Each time the conveyor indexes, the bit shifts one position, and when the bit reaches the reject position, the reject mechanism fires — for that bottle and no other. Without a shift register, tracking which bottle is faulty after it has moved down the line requires complicated counting and timing that breaks the moment the line speed changes.

Shift registers also serve as simple memories and as ways to sequence outputs: loading a pattern of bits and shifting it through outputs produces a repeating sequence of actions, such as a light chase or a staged start-up. The key discipline is to shift on a clean, single event — one index pulse, one sensor edge — and to clear the register on a reset or a product changeover. A shift register that shifts twice on one event, because its shift input stays on across two scans, will track the wrong bottle, and that is a fault that looks like a sensor problem until someone watches the register itself.

Subroutines: organising a program you can maintain

A subroutine is a block of program that is called from the main program, runs, and returns. Subroutines organise a large program into understandable pieces: a main routine that handles the sequence, a subroutine for a repeated function such as a dosing calculation or a valve test, and a fault routine that runs when an alarm occurs. The same subroutine can be called from several places, which means a function is written and tested once instead of copied into five rungs where four copies will be updated and one will be forgotten.

Use subroutines for functions, not for hiding logic. A subroutine should have a clear purpose, clearly documented inputs and outputs, and no hidden side effects on unrelated parts of the program. Avoid calling subroutines conditionally in ways that make the program's behaviour depend on scan history that is hard to follow, and be careful with subroutines that run only occasionally: an output driven only inside a subroutine that is not called will hold its last state, which can be surprising. Document the call structure — which routine calls which, and when — at the top of the program, because the next engineer to fault-find it will thank you for a map.

A worked example: a simple batching sequence

Consider a small batching station: a conveyor feeds bottles past a filler, and every ten bottles the conveyor stops, the filler indexes, and a counter resets for the next batch. The sequencer holds the steps: run conveyor, count bottles with an up-counter on the bottle sensor, and when the counter reaches ten, stop the conveyor and advance to the index step. A timer in the index step allows the indexing mechanism time to complete, and a sensor confirms the index before the sequencer returns to the run step and resets the counter. A shift register is not needed here, because the bottles are counted in place rather than tracked down the line — and recognising which tool fits the job is itself part of the skill.

Now add the fault handling that makes this a real program rather than a demonstration. If the bottle sensor stops pulsing while the conveyor is running, a timer raises a jam alarm. If the index sensor does not confirm within its time, the sequencer holds and alarms instead of running the conveyor into a jammed mechanism. If the operator presses stop, the sequencer pauses at a safe step rather than mid-index. Each of these behaviours is a few rungs, and each is worth more than any clever optimisation, because a machine that fails safely and explains itself is a machine that production trusts.

Common advanced mistakes

The most common advanced mistake is using a timer or counter without understanding its reset behaviour, so a program works on the first cycle and fails on the second. The second is building a sequencer with no timeouts and no step display, so a stopped machine gives no clue about where it stopped. The third is copying a rung or a subroutine five times instead of structuring it once, so a later change is applied to four copies and missed on the fifth. The fourth is writing clever code that only its author can read: nested jumps, undocumented bits, and rungs that do three jobs at once. Clarity is a functional requirement in control programs, because the person who fault-finds your program at 3 a.m. may be you, tired, and clarity then is worth more than elegance ever was.

What to learn next

From here, move on to analog signals, PID control and troubleshooting, which adds continuous control to the discrete logic covered here. For the drawings those programs are built from, see our AutoCAD Electrical basics, schematics and panels and reports and automation guides, and for the power systems behind the machines, our ETAP load flow and short-circuit and protection guides. Our AI tools for engineers page covers documentation workflows, while program logic itself remains human engineering work.

Frequently asked questions