PLC Counters: CTU, CTD, CTUD, Examples and Tests

Direct answer: a PLC counter counts accepted events, not objects by magic

A PLC counter is stateful logic that changes a current value when a documented input event occurs. A count-up counter (CTU) normally increments on a false-to-true event at its count input and asserts a threshold output when the current value reaches or exceeds the preset. A count-down counter (CTD) decrements toward a defined boundary. An up/down counter (CTUD) has separate up and down event inputs plus reset/load behavior. Those names describe a model, not identical vendor syntax.

For a ten-product batch, create one AcceptedProductPulse, call one uniquely owned counter instance, set its preset to ten, use its Q or platform-equivalent status to request a sequence transition, and accept reset only under a defined new-batch condition. A photoeye held true across 20 scans should count once if the instruction is edge-sensitive. A photoeye that chatters through four false-to-true transitions can count four times. The reliable design therefore proves the whole path: physical event → electrical/raw input → qualified event → counter instance → threshold state → sequence action → field response.

Use an ordinary software counter only when the minimum valid high and low pulse durations remain observable through the input filter, I/O update, network where applicable, task/scan and instruction execution with margin. Use a documented high-speed counter, timestamp input or event task when pulses can occur between ordinary samples. A one-shot after a cyclic input cannot recover a pulse that was never sampled.

The saved production register records plc counters at 530 global and 40 United States monthly searches at KD 18. No later Mangools evidence is invented after credits were exhausted. This page owns broad counter selection, behavior, scan traces, use cases, high-speed handoff and cross-vendor translation. The Mitsubishi counter guide and Omron counter guide own those exact platforms; the CTU function-block reference owns compact runnable syntax/reference intent; and the edge/debounce guide owns deeper signal qualification.

Define the event before writing CTU

Start with an event contract

“Count products” is incomplete. Define which physical feature creates the event, when counting is enabled, which quality/permissive conditions qualify it and how closely products may arrive. For a conveyor:

Download the PLC counter design contract and write these conditions before choosing a mnemonic.

Qualify without hiding signal defects

Create named layers:

RawProductEye
  -> InputHealthy
  -> StableProductState
  -> ProductInCountWindow
  -> AcceptedProductPulse
  -> BatchCounter

Filtering and debounce must be derived from measured valid/invalid durations. A 50 ms stability rule rejects a legitimate 40 ms product. A rising-edge block after a noisy qualified Boolean counts every remaining transition. Fix optics, mounting, wiring and filter first when they violate the signal requirement; do not turn every hardware defect into an opaque timer.

Understand CTU scan behavior

One false-to-true event increments once

This vendor-neutral example expresses intent:

BatchCount(
    CU := AcceptedProductPulse,
    R  := AcceptedBatchReset,
    PV := BatchTarget
);

BatchAtTarget := BatchCount.Q;
CurrentBatchCount := BatchCount.CV;

The exact declaration, call, names, data type and priority vary. Some ladder instructions include internal transition memory; some code paths require an explicit rising-edge instance. Do not add a one-shot automatically. Read the exact instruction help and test the four essential cases: false, first true, held true, and false-to-true again.

Download the PLC counter scan-trace worksheet. Include actual scan/task time and raw input alongside the ideal edge.

Startup edge memory is platform specific

If the input is already true when the CPU starts, should it count? Rockwell's current Logix CTU documentation says prescan sets the count-up enable memory to prevent an invalid first-scan increment. Another IEC implementation can initialize differently depending on whether the instance executes, is retained or is re-created. Test cold/warm start, program enable/disable and skipped call paths.

A counter called conditionally may not update its edge memory while skipped. When execution resumes with input true, the result can differ by implementation. Prefer calling the instance in its designed task every cycle and gate the input explicitly unless the vendor documents another requirement.

Choose CTU, CTD or CTUD by the displayed meaning

CTU shows produced count naturally

Use CTU when operators and logic need the number already accepted. CV=7, PV=10 means seven produced and three remain. Completion becomes true at/above the target under common IEC behavior; confirm exact implementation and what happens beyond the target.

CTD can show remaining count

A CTD model typically loads its current value from PV, then decrements on count-down events and asserts a zero/boundary output. It can match an HMI that should show remaining products directly. The load action, output name and underflow behavior vary. An alternative is one CTU plus a bounded derived value Remaining = MAX(Target - CV, 0), which can reduce duplicated state.

CTUD owns one reversible value

Use CTUD for a buffer where entries increment and exits decrement. Define what simultaneous CU and CD edges mean. CODESYS Standard documents rising edges for each; current Rockwell CTUD documentation states count up executes before count down if both toggle in one scan. Those outcomes may produce the same net value but different transient/status/overflow evidence. Other platforms can define priorities differently.

Design reset, load, retention and ownership

Give each counter one writer

A counter is memory. Calling one instance from two programs or sharing a Rockwell counter structure between instructions can corrupt transition memory and state. Mitsubishi also warns against duplicate ownership of device state, and Omron classic counters share numbered areas. Give each requirement one device/instance, one call location and one reset/load arbiter. Publish derived read-only tags for HMI and sequence consumers.

Reset should not erase evidence prematurely

For a batch:

1. counter reaches target;
2. sequence records completion and moves product;
3. downstream feedback proves transfer/clear;
4. next-batch request is accepted;
5. reset establishes zero; and
6. first new event is accepted only after reset release.

Do not drive reset continuously from “not running,” because that can erase a partial batch whenever a stop occurs. Do not let acknowledgement reset the production count if it is also needed as first-out evidence. Separate operator acknowledge, fault reset, batch reset and maintenance total reset.

Retention is more than the instruction name

Counter state is often retentive while its enabling rung is false, but persistence across program disable, CPU stop or power loss depends on platform memory configuration, instance storage, startup code and battery/nonvolatile behavior. Test each transition. Define whether the physical machine can reconcile a retained partial count; a retained value with product removed during outage can be wrong.

Build reliable batch and buffer examples

Batch count with one state transition

Keep the counter away from the final physical output. Its completion requests a sequence transition; the state machine owns commands and verifies feedback. This prevents BatchCounter.Q from directly energizing a diverter in several places.

AcceptedProductPulse -> BatchCounter

IF State = FILLING AND BatchCounter.Q THEN
    NextStateRequest := TRANSFER;
END_IF;

DiverterCommand := (State = TRANSFER)
                   AND DiverterPermissive
                   AND NOT TransferFault;

Run Structured Text in the simulator →

Test exact target, one over target, late completion, downstream failure, stop/restart and reset denial while product remains in the sensor.

Buffer occupancy with conservation evidence

For entries and exits, the count should agree with physical occupancy within known sensor zones. Add plausibility:

• entry while full is a fault or rejected event;
• exit while empty is a fault or reconciliation event;
• both sensors true requires defined geometry;
• missed pulse produces disagreement with a downstream/independent reference;
• restart requires an inventory or homing strategy.

Do not silently clamp CV between zero and capacity; that hides the event that violated conservation. Preserve a first-out code and the raw/accepted edge history.

Select ordinary versus high-speed counting

Calculate the complete observation budget

Start from worst-case physical pulses. For a wheel encoder with P effective counts per revolution and maximum speed N rpm:

PulseFrequencyHz = P × N / 60

The minimum high and low widths depend on duty cycle and signal method. Compare them with sensor/encoder output, cable/interface, input threshold, configurable filter, I/O update, network update if remote, task interval, phase and jitter. Average line rate is not enough.

An ordinary cyclic path needs margin for both true and false states to be observed. If the pulse can begin and end between samples, use target-supported hardware capture. Reducing task period blindly can consume CPU and create scheduling faults without fixing electrical filtering.

A high-speed counter is a subsystem

A hardware HSC needs:

Handle ranges, overflow and rollover deliberately

Know the current-value datatype

Counter implementations use different datatypes and boundary behavior. CODESYS Standard documents a WORD-based counter family and notes a type difference from the IEC standard model. Current Logix CTU uses a DINT accumulator and documents overflow/underflow bits with wrap behavior at signed limits. Siemens counter blocks support selected integer types in target-specific contexts. Mitsubishi and Omron have generation-specific device representations.

Never assume a universal 32-bit signed range. Record type, minimum, maximum, comparison rule and what happens past the boundary. For lifetime totals, archive and extend the value before rollover. For position, use modular delta math. For buffer occupancy, treat boundary violation as diagnostic evidence rather than wrapping.

Preset changes can alter status immediately

If CV=8 and an HMI changes PV from 10 to 6, common CV >= PV behavior makes completion true without a new product edge. Decide whether a running batch may accept the change. A robust recipe manager validates range/type, stages the value and applies it at a batch boundary with old/new audit evidence.

Translate counter logic across vendors

Preserve behavior, not mnemonic spelling

Rockwell ladder CTU and IEC CTU share an up-count concept but not one source-compatible block. Traditional Omron CNT counts down, so translating it to CTU can reverse the operator meaning. An FX3 high-speed C number is a hardware allocation, not merely a counter variable. Write a behavior table and run the same edge/reset/restart/range tests on source and target.

Troubleshoot the first failed boundary

Capture before reset

Record physical event, raw electrical/input state, input quality/filter, accepted pulse, task/program route, instance/current value, preset, completion, reset/load, sequence state, output/feedback and force/test state. Then stop at the first mismatch.

Acceptance tests before release

Download the PLC counter acceptance matrix. Run at least:

1. initial/reset value and status;
2. one clean edge increments/decrements once;
3. held input creates no repeat event;
4. second edge after a valid false interval counts;
5. bounce/noise below rejection threshold does not count;
6. minimum valid pulse is captured with margin;
7. maximum credible rate has no missing/extra events;
8. just below, exactly at and above preset status;
9. reset plus count in one execution;
10. load plus count and reset plus load where supported;
11. simultaneous up and down events;
12. preset changes below/equal/above current value;
13. zero, maximum, underflow, overflow and rollover;
14. disabled/skipped call and re-enable with input true;
15. warm/cold restart and power interruption;
16. HMI mapping, authorization and audit trail;
17. sequence output, field feedback and process response; and
18. force/test removal, project compare, backup and rollback.

PLC counter answer map

Frequently asked questions

What is a PLC counter?

A PLC counter is stateful logic or hardware that changes a current value on defined events and exposes threshold/status outputs. Its input event, reset/load, datatype, range, retention and task/hardware path must be specified.

How does a CTU counter work?

CTU normally increments once when its count-up input changes from false to true. It retains the current value between events and commonly makes Q or a done bit true when current value reaches/exceeds preset. Exact startup, range and reset behavior are vendor specific.

What is the difference between CTU and CTD?

CTU naturally represents events accumulated upward from zero. CTD naturally represents a value loaded from a preset and decremented toward a boundary. Choose based on the state readers need, then verify the target block's load/reset and threshold outputs.

What is a CTUD counter?

CTUD has separate rising-event inputs for increment and decrement, one current value, and reset/load controls. It is useful for buffer occupancy or reversible counts only after simultaneous events, limits and reconciliation are defined.

Does a PLC counter count while its input stays on?

An edge-sensitive counter should change once when the input first becomes true and not again until it becomes false and rises again. Confirm the exact instruction; a separate arithmetic increment executed every scan behaves differently.

Why does my PLC counter count twice?

Check whether the physical sensor or raw input produced two transitions, qualification chattered, the same instance executed twice or another instruction shared/overwrote its state. Correlate waveform, raw input, accepted event and current value.

Why does my PLC counter miss fast pulses?

The input filter, I/O or network update, task period and phase may not observe the pulse's high and low states. Measure minimum width/gap and use a documented high-speed counter or capture feature when cyclic margin is insufficient.

How do I reset a PLC counter?

Use the target instruction's reset input/instruction through one authorized arbiter. Define the allowed machine state, preserve required batch/fault evidence, and test reset with a simultaneous count event and a held operator request.

Are PLC counters retentive?

They often retain current value while the count input is false, but CPU stop/power-loss persistence depends on the platform, memory/instance configuration and startup code. Test the exact target and define physical reconciliation.

What happens when a PLC counter overflows?

It may set an overflow status, wrap, saturate or behave according to a device-specific limit. Record datatype and documented boundary, then test it. Do not allow production totals or positions to reach rollover without a design.

When should I use a high-speed counter?

Use one when the fastest valid pulses cannot be observed reliably by ordinary input filtering, update and task execution, or when phase/direction/latch/compare behavior is required. Select exact electrical and performance specifications from the hardware manual.

Are CTU counters identical across Rockwell, Siemens, CODESYS, Mitsubishi and Omron?

No. They share concepts but differ in structures/instances, types, range, prescan/startup, reset/load priority, language availability, retention, overflow and hardware integration. Traditional Omron CNT even counts down toward zero.

Can a browser counter simulator replace vendor software?

No. It can practise accepted edges, held input, reset, threshold and diagnosis. It cannot validate target syntax, compiler/library, task, retention, input filter, high-speed hardware, electrical signal, machine, process or safety behavior.

Primary sources and review trail

• IEC, IEC 61131-3:2025 publication record. Current PLC programming-language and function-block standard scope.
• Rockwell Automation, Studio 5000 Logix Designer v38 CTU help. False-to-true behavior, structure, prescan, overflow/underflow and warnings.
• Rockwell Automation, Studio 5000 timer and counter instruction index. Language/model routing and RES context.
• Rockwell Automation, Studio 5000 CTUD help. Up/down ordering, structures, reset and execution.
• Rockwell Automation, SLC 500/MicroLogix instruction reference. Installed-base CTU scan/frequency context; do not generalize to Logix.
• CODESYS, Standard library CTUD reference. Rising edges, reset/load, QU/QD/CV and WORD type note.
• CODESYS, Standard counter index. CTU, CTD and CTUD library owner.
• Siemens, S7-1200 current manual/document portal. Resolve current CPU/TIA IEC counter type, instance and retention details.
• Siemens, TIA Portal instruction manual search. Resolve exact release and target behavior.
• Mitsubishi Electric, FX3 programming manual. FX ordinary and high-speed counter device behavior.
• Mitsubishi Electric, current FX5 instruction/standard-FB manual. Current FX5 counter and CTU/CTD/CTUD paths.
• Omron, CP1E/CP2E Instructions Reference W483. Traditional CNT/CNTX decrementing and reset/representation behavior.
• Omron, NJ/NX Instructions Reference W502. Sysmac CTU/CTD/CTUD typed-instance behavior.
• NIST, SP 800-82 Rev. 3. OT access, change, backup and recovery context.
• OSHA, Control of hazardous energy. US servicing energy-control boundary where applicable.
• PLC Programming IO, Mitsubishi counter guide. Versioned Mitsubishi specialist with its own primary-source trail.
• PLC Programming IO, Omron counter guide. Versioned Omron specialist with its own primary-source trail.
• PLC Programming IO, PLC scan-cycle guide. Cross-vendor timing/sampling specialist.

Use the current target instruction help, hardware manuals, controlled project, I/O drawings, process requirement, risk assessment and site procedure. This guide is not a universal syntax sheet, electrical design or safety validation.

Counter implementation checklist

• Physical event and valid/invalid pulse durations are measured.
• Input filter/update/task path can capture events with margin, or HSC is selected.
• CTU/CTD/CTUD/device/HSC choice matches the state question.
• One device/instance and one call/write owner are documented.
• Setting, current value, datatype, range and rollover policy are explicit.
• Reset/load/simultaneous-event priorities are tested.
• Startup, disabled call, stop/run and power-loss behavior are tested.
• HMI writes, reset roles, audit and recipe boundary are controlled.
• Threshold drives a sequence request, with output and feedback proven separately.
• Normal, boundary, fault, restart, high-rate and rollback tests are retained.

A dependable counter is not a box labeled CTU. It is a measured event contract, one state owner, known execution semantics and a complete acceptance record from sensor to process result.