CTU (Count Up) increments its accumulator by one each time its rung transitions from false to true, and sets its done bit when the accumulated count reaches the preset.
Join 1900+ learners practicing PLC programming
How it works
A CTU has three pieces of data — a preset (PRE / PV), an accumulator (ACC / CV) and status bits — and one rule: the accumulator increments by exactly one per false-to-true transition of the rung. Not per scan. The instruction is inherently edge-sensitive: a part sitting in front of the sensor for five seconds is one transition and therefore one count, no matter how many thousand scans elapse. When ACC reaches PRE, the done bit (DN in Allen-Bradley, QU/Q in IEC) turns on.
Two behaviours surprise people. First, the CTU keeps counting past its preset — DN simply stays on while ACC ≥ PRE. If ACC must stop or roll over at the preset, that is your logic’s job, typically a reset rung fired by DN. Second, the counter never resets itself: power flickers and false rungs leave ACC untouched, because counters are retentive. Clearing one takes an explicit RES instruction addressed to the counter tag (Allen-Bradley) or a true condition on the R input pin (IEC function block).
That retentiveness is a feature. Counters accumulate across events that are minutes or shifts apart — total parts today, press cycles since the last service, faults this week. The scan cycle view: on the scan where the count rung first evaluates true, the CTU executes with a rising rung-in condition, ACC increments, and any later rung examining ACC or DN sees the new value in the same scan.
The full Logix status picture is worth knowing for troubleshooting: CU (count-up enable) mirrors the rung-in condition, DN reports ACC ≥ PRE, and OV flags overflow when ACC passes its maximum (32,767 for SLC-style INT counters; Logix counter ACC is a DINT). In the IEC 61131-3 CTU function block the pins are CU, R, PV in and Q, CV out — same machine, different labels.
Across vendors
| Platform | Name / syntax | Notes |
|---|---|---|
| Allen-Bradley (Studio 5000 / RSLogix) | CTU | Block instruction on the rung: CTU Counter, PRE, ACC with .CU/.DN/.OV bits. Reset with a separate RES instruction addressed to the counter. |
| IEC 61131-3 (CODESYS, OpenPLC) | CTU FB | Function block with CU, R, PV inputs and Q, CV outputs; each usage needs an instance. Q is true while CV ≥ PV; R := TRUE clears CV. |
| Siemens (TIA Portal) | CTU | IEC counter with an instance DB per counter. Legacy S5/STL counters (S_CU) still appear in migrated programs. |
| Mitsubishi (GX Works) | OUT C | OUT C0 K10 counts rising edges of the rung into counter C0 with preset 10; the C0 contact closes at the preset. RST C0 clears it. |
Every dialect agrees on the semantics that matter: one count per rising edge, done while count ≥ preset, retentive until an explicit reset.
In practice
| Part_Sensor CTU Batch_Counter | |-----] [----------------------------[ PRE 10 ]-| | Batch_Counter.DN Divert_Gate | |-----] [--------------------------------------( )------| | Gate_Closed_Eye RES Batch_Counter | |-----] [------------------------------------[RES]------|
Ten parts fill a box: the sensor pulses the CTU, DN fires the diverter at ACC = 10, and once the gate has cycled, the RES rung clears ACC to zero for the next batch. The counter keeps its value between parts precisely because counters are retentive — and is cleared only at the moment the process says the batch is really finished, not merely when DN turns on.
| Press_Cycle_Cam CTU Cycle_Counter | |-----] [-----------------------------[ PRE 50000 ]-| | Cycle_Counter.DN Service_Alarm | |-----] [-------------------------------------(L)--------| | Maint_Reset_Key RES Cycle_Counter | |-----] [------------------------------------[RES]-------|
The press cam pulses once per stroke; at fifty thousand cycles the DN bit latches a service alarm. The alarm is latched (OTL) rather than driven by OTE because the maintenance technician resets the counter with a key switch — which clears DN — but the alarm record should persist until maintenance signs it off separately.
Wear on a press is a function of cycles, not hours, so a counter is the correct instrument here; the equivalent time-based job would use an RTO retentive timer.
Gotchas
Feeding a counter a condition that is true for many scans and expecting many counts
CTU counts transitions, not scans and not duration. One long pulse is one count. If you need "count every scan while true", you actually need an ADD — and probably a rethink.
Forgetting the RES rung entirely
Counters are retentive: ACC survives false rungs, mode changes, and power cycles. A batch counter with no reset path counts to its overflow across days of production. Every CTU should have a deliberate answer to "what clears this, and when".
Resetting the moment DN turns on
Firing RES directly from DN clears the counter on the same scan the batch completes — downstream logic that needed to see DN true may miss it. Reset on the process event that truly ends the cycle, or one-shot the DN handling first.
Assuming counting stops at the preset
ACC sails past PRE with DN simply staying on. Comparisons like EQU Counter.ACC 10 break when ACC hits 11 — use GEQ, or use DN, which already means "at or past preset".
Missing counts from fast inputs
The rung sees the input image, once per scan. Pulses shorter than the scan time vanish, and two pulses inside one scan merge into one edge. For encoder-speed signals use a high-speed counter input, not a ladder CTU.
Drop the instruction on a rung in the browser simulator, toggle the inputs, and watch the rung state, accumulator values and outputs update scan by scan.
Questions
CTU increments its accumulator (ACC / CV) by one each time its rung transitions from false to true. When the accumulator reaches the preset (PRE / PV), the done bit (DN / Q) turns on and stays on while ACC ≥ PRE. The count value is retentive — it holds through false rungs and power cycles until an explicit reset (RES instruction or R input).
In Allen-Bradley, a separate rung with a RES instruction addressed to the counter tag clears ACC to zero and drops DN. In IEC 61131-3 platforms (CODESYS, TIA Portal), drive the R input of the CTU function block true. In Mitsubishi, RST C0. Counters never reset themselves — a missing reset rung is the most common counter bug.
No. The accumulator continues to increment past the preset on further rising edges; the done bit simply remains on while ACC ≥ PRE. If the count must cap or restart at the preset, add logic — typically a RES fired by the process event that completes the cycle.
Usually sensor chatter: a marginal photo-eye or vibrating proximity switch produces several false-to-true transitions per part, and the CTU faithfully counts each edge. Debounce the signal with a short TON before the count rung, fix the sensor alignment, or use a sensor with hysteresis.