A PLC counter is a program instruction that tallies how many times something happens. Every time a designated event goes from false to true, the counter adds one to a running total, and when that total reaches a preset value the counter signals done. The two everyday flavors are the count-up counter, CTU, which increments toward a target, and the count-down counter, CTD, which decrements from one. Counters look simple, but the details of how they detect edges, when they reset, and how fast they can go decide whether they work for a slow batch tally or a fast pulse train.
PLC Counter (CTU/CTD) in one line: A PLC counter is a ladder instruction that increments (CTU) or decrements (CTD) an accumulated count each time its input transitions from false to true, and sets a done bit when the accumulator reaches a preset value. A separate reset instruction clears the accumulator back to zero to start counting again.
A counter carries a small set of values that mirror those of a timer. The preset is the target number of events you care about. The accumulator is the running count of events seen so far. The done bit turns on when the accumulator reaches or exceeds the preset, and a reset input drives the accumulator back to zero. Where a timer counts elapsed time on its own, a counter only moves when the outside world hands it an event, so it is entirely event-driven rather than clock-driven.
The crucial behavior of a counter is that it responds to transitions, not levels. A CTU adds one each time its count input goes from false to true, and then it does nothing further no matter how long that input stays true. This built-in edge detection is what makes a counter tally discrete events instead of racking up a huge number every scan while an input is held on. It also means a slow-changing or bouncing signal can be miscounted if it produces extra transitions, which is why clean, debounced inputs matter for accurate counts.
Count-up and count-down counters are often paired so one keeps a net total. A CTU might increment as parts, strokes, or trucks arrive, while a CTD decrements as they leave or are consumed, and the shared accumulator tracks how many remain. The reset is deliberately kept separate and usually given priority, so that a shift change, a batch completion, or an operator acknowledgment can force the count back to a known starting point regardless of what the count inputs are doing.
In oil and gas, counters quietly track a lot of what a site does. A sucker-rod pumping unit's counter tallies strokes, either to schedule maintenance intervals or to feed production estimates when combined with a per-stroke displacement. A plunger-lift well uses a counter to record plunger arrivals at surface, which is a core input to the cycle-control logic that decides when to shut in and when to open the well. In both cases the counter turns a repetitive physical motion into a number an engineer can act on.
Counters also stand behind flow and event totals. A meter that emits one pulse per unit of volume can be totalized by counting those pulses, though the speed of the pulse train decides whether an ordinary ladder counter can keep up. Compressor and engine controls count the number of starts, because start count is a maintenance and reliability metric in its own right - a machine that has restarted many times in a short window is telling you something about the process feeding it. Counting alarm occurrences or valve cycles serves the same diagnostic purpose.
Because counters accumulate a value that outlives any single event, they are natural candidates for retentive storage. A stroke count or start count that resets to zero every time the controller loses power would be nearly useless for maintenance planning, so these counts are often held in retentive memory that survives a power cycle. That choice, plus a deliberate reset strategy, is what separates a counter that produces trustworthy long-term totals from one that merely blinks a done bit and forgets.
A counter written in ladder logic can only see an input change when the controller scans that rung, so its maximum reliable count rate is tied to the scan time. If the scan takes a few milliseconds and a pulse arrives and leaves within that window, the counter can miss it entirely, or count one event where two occurred. For slow phenomena - rod-pump strokes, plunger arrivals, truck loadouts, batch counts - this is no limitation at all, because events happen far slower than the scan. A software counter is the right, simple tool there.
Fast pulse trains are a different problem. A turbine or positive-displacement flow meter, a shaft encoder, or a high-frequency proximity pickup can produce pulses far faster than any program can scan, and asking a ladder counter to keep up guarantees lost counts and a total that drifts low. The answer is a dedicated high-speed counter, usually a hardware channel on the CPU or an input module that counts pulses in silicon, independent of the program scan, and simply presents the current total to the logic to read.
Choosing between the two comes down to the pulse rate against the scan rate, with margin for jitter. If the fastest event you must count is comfortably slower than the scan and well spaced, a ladder CTU or CTD is fine and keeps the design simple. If pulses can bunch up or exceed what the scan can resolve, a high-speed counter channel is not optional - it is the only way to get a count you can bill on or control from. Many field designs use both: hardware counting for meter pulses, and software counters for the slower event tallies around them.
A CTU is a count-up counter that adds one to its accumulator each time its input goes from false to true, and sets its done bit when the accumulator reaches the preset. A CTD is a count-down counter that subtracts one on each transition, typically starting from a preset and signaling when it reaches zero. Pairing them lets a program track a net total, such as items added versus items removed.
You need a high-speed counter whenever the pulses arrive faster than the PLC can reliably see them during its program scan. A ladder counter only samples its input once per scan, so fast pulse trains from turbine meters, encoders, or high-frequency pickups will be undercounted. A hardware high-speed counter channel counts those pulses independently of the scan and hands the total to the logic, avoiding missed counts.
It depends on whether the counter's accumulator is stored in retentive memory. If it is retentive, the count survives a power loss and continues from where it left off, which is what you want for long-term totals like pump strokes or compressor starts. If it is non-retentive, the accumulator clears on power-up, so counts meant to persist should be placed in retentive storage and reset only on a deliberate event.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.