PLC Book› Part II — Ladder Logic Programming Essentials› Chapter 8

Chapter 8 Part II · Ladder Logic Programming Essentials Intermediate ⏱ 45 min read ✦ 6 PLC Programs

Programming Counters

Counters are how PLCs answer the question “how many?” How many bottles have passed the filler. How many cars are still in the garage. How many strokes the press has made since the last tool change. In this chapter you’ll learn the two basic counter instructions — CTU (count up) and CTD (count down) — the one-shot trick that makes them count cleanly, the cascade pattern that lets you count beyond the maximum preset, and how counters team up with timers and incremental encoders to handle real-world process measurements.

What you’ll be able to do after this chapter

Your goals for this chapter:

Explain how a PLC counter holds its accumulator and which control bits — CU, CD, DN, OV, UN — change as the count progresses.
Write a working up-counter (CTU) rung that increments once per part on a sensor edge.
Write a working down-counter (CTD) rung and pair it with a CTU on the same counter file for bidirectional counting.
Apply the one-shot instruction to convert a maintained input into a single clean count pulse.
Build a cascading-counter chain that counts well beyond the limits of a single counter file.
Combine a counter with a timer to measure rate (parts-per-minute, RPM, throughput).
Wire and read an incremental encoder, and explain why a high-speed counter (HSC) is needed for fast pulse trains.
Reset a counter cleanly with a RES instruction and recognise when retention matters.

Key Concepts & Terms

Counter file (C5)Preset (PRE)Accumulator (ACC) CTU · count-upCTD · count-down CU · count-up enableCD · count-down enableDN · done bit OV · overflowUN · underflow One-shot (OSR/ONS)Edge detectionRising edge Reset (RES)Cascading counters Bidirectional counterCounter + timer combo Parts-per-minuteIncremental encoderQuadrature A/B Pulses per revolution (PPR)High-speed counter (HSC)

Section 8.1

Counter Instructions — The Anatomy

A PLC counter looks structurally a lot like a timer — same memory layout, same idea of a preset and an accumulator — but the trigger is different. A timer increments because time passes; a counter increments because an input changes. Specifically, a counter steps up (or down) once each time its rung transitions from false to true. That false-to-true transition is what we call a rising edge, and getting clean rising edges is the single most important programming idea in this chapter.

Every counter instruction stores the same fields:

Field	What it holds	You set it / It sets itself
`PRE` — Preset	The target count. When ACC reaches PRE, the DN bit goes high.	You set it (when programming)
`ACC` — Accumulator	The current count. Steps up by 1 (CTU) or down by 1 (CTD) on each rising edge of the rung.	The PLC sets it
`CU` — Count-Up enable	Mirrors the rung condition of a CTU instruction.	The PLC sets it
`CD` — Count-Down enable	Mirrors the rung condition of a CTD instruction.	The PLC sets it
`DN` — Done	1 when ACC ≥ PRE. The bit you usually wire into other rungs to drive outputs or alarms.	The PLC sets it
`OV` — Overflow	1 if the accumulator tried to count past +32 767 (the upper limit of a signed 16-bit counter).	The PLC sets it
`UN` — Underflow	1 if the accumulator tried to count below −32 768.	The PLC sets it

Figure 8.1 — Counter Instruction AnatomyAn XIC contact feeds the rising edge into the counter; the block stores PRE and ACC; four status bits (CU, DN, OV, UN) are available to other rungs as needed. CTD has the same shape with CD instead of CU.

Two key differences from a timer: nothing happens between edges — the counter doesn’t tick on its own — and the accumulator is retentive. When the rung goes back to false, the counter holds its current value. Just like an RTO, a counter only clears when an explicit RES instruction is targeted at it.

Section 8.2

Up-Counter (CTU) — The Most-Used Counter

The CTU is the counter you’ll write most often. Each time the rung containing the CTU transitions from false to true, the accumulator increments by 1. As long as the rung remains true, nothing further happens — it does not keep incrementing every scan. The next increment requires the rung to go false and then true again.

When ACC reaches PRE, the DN bit goes to 1 — and stays at 1 even if you keep counting beyond PRE. ACC continues to climb past PRE until it either stops (reset) or hits the upper limit (overflow). Use the DN bit in another rung to do whatever the count was supposed to trigger: light a “case full” lamp, divert the conveyor, fire an alarm, advance to the next station.

When to use CTU

Almost any “count parts going past” scenario. Counting bottles into a case-pack of 24. Counting strokes on a press until tool change at 50 000. Counting trips of a fault before requiring service. Counting days of operation. If you can phrase the requirement as “count one event each time X happens, and act when count reaches Y”, you want a CTU.

Section 8.3

Down-Counter (CTD) — Counting Toward Zero

The CTD works exactly like the CTU but in the opposite direction: each false-to-true transition decrements the accumulator by 1. Loaded with an initial preset value, you watch the accumulator count down toward zero — and beyond, into negative territory if you let it.

The DN bit on a CTD has a slightly different meaning than on a CTU: it goes to 1 when ACC ≥ PRE (same logic), but in practice we usually start ACC at PRE and watch it count down. Most engineers set DN inactive in this mode and instead test for ACC ≤ 0 with a comparator (LEQ, EQU, etc.) to detect the empty condition.

Pairing CTU and CTD on the Same Counter File

Allen-Bradley and most other PLCs let two instructions — one CTU and one CTD — share the same counter address (e.g. C5:0). When they share the file, they share the accumulator: the CTU pushes ACC up, the CTD pushes ACC down, and ACC ends up holding the net count. This is exactly what you need for tracking inventory, parking-garage spaces, items in a buffer, or any “in minus out” measurement.

Sign and limits

PLC counter accumulators are typically signed 16-bit integers, so they run from −32 768 to +32 767. Push CTU past the upper limit and OV (overflow) goes high. Push CTD past the lower limit and UN (underflow) goes high. Most well-designed programs reset the counter long before either limit can be reached.

Section 8.4

One-Shot Instructions — Clean Single-Pulse Counting

The single most common counter bug in beginners’ programs goes like this: you wire a maintained switch to a CTU, and instead of getting one count, you get something unpredictable — sometimes one, sometimes none. The problem is that a counter only increments on a rising edge, and it’s easy to write rungs where the rung is true for many scans without ever transitioning false-to-true between increments.

The fix is the one-shot instruction — written OSR (Allen-Bradley Output) or ONS (input form) depending on the platform. A one-shot watches a bit, and produces a single-scan true output the moment that bit transitions from 0 to 1. The next scan and every scan afterward, the one-shot’s output is back to 0 — even though the input is still 1. The next true pulse comes only after the input goes back to 0 and rises again.

Wire a one-shot between your input and your counter and the bug goes away: the counter sees exactly one scan of “true” per real-world event, regardless of how long the operator holds the switch or how long the sensor stays activated.

When you must use a one-shot

Whenever the input to a counter could remain true for more than one scan and you want exactly one count per event: pushbuttons, photoelectric sensors with longer dwell than scan time, latched alarms. If the input is a momentary rising-edge pulse from a fast sensor, a one-shot is unnecessary; the rung transitions cleanly on its own. Use one-shots when in doubt.

Section 8.5

Cascading Counters — Counts Beyond the Limit

One signed 16-bit counter tops out around 32 767. That’s plenty for case-pack and shift-total counts, but not enough for, say, “total kilometres driven by a forklift over its lifetime” or “total parts shipped this year”. For those you cascade two (or more) counters.

The pattern: counter 1 counts events normally up to its preset. The instant counter 1’s DN goes high, two things happen — counter 2 receives a one-shot pulse and increments, and counter 1 is reset to zero. The result is that counter 2 counts in units of “counter 1’s preset” — typically 1 000 or 10 000. Total count is then (C5:1.ACC × C5:0.PRE) + C5:0.ACC.

You can cascade as many counters as you like. Three cascaded counters with PRE = 1 000 each can count up to one billion before any one of them overflows.

Section 8.6

Combining Counters with Timers — Measuring Rate

A counter alone tells you “how many”. A counter combined with a timer tells you “how many per unit time” — production rate, throughput, RPM, flow rate. The pattern is universal:

Set up a TON with a fixed time window — say, 60 seconds.
Set up a CTU that counts events during that window.
When the timer expires (DN fires), copy the counter’s accumulator to a “rate” register, then reset both the counter and the timer.
Display or use the rate register; the cycle restarts immediately.

The rate register holds “events in the previous 60 seconds” — i.e., parts-per-minute. Refresh rate is one update every 60 seconds. To get faster updates with the same accuracy, run several counter+timer pairs offset in time and average them, or use a sliding-window approach. For most applications, a 60-second update is more than sufficient.

Counter + timer combinations also let you measure elapsed time per event: a one-shot starts a timer when the event begins, the same one-shot resets and reads the timer when the event ends. You then know exactly how long each cycle took.

Section 8.7

Incremental Encoders and High-Speed Counters

An incremental encoder is a rotary device that produces a train of pulses as its shaft turns. Mount one to a motor shaft, a roller on a moving belt, or a positioning lead-screw, and each tiny rotation of the encoder produces one pulse. Count the pulses and you know how far the shaft has rotated; track the rate of pulses and you know how fast.

The number of pulses per full revolution is the encoder’s resolution, often abbreviated PPR (pulses per revolution). Common ratings range from 100 to 10 000 PPR, with 1 024 and 2 048 being typical for industrial applications. A 1 024-PPR encoder on a 60 mm-diameter measuring wheel resolves about 0.18 mm of belt travel per pulse — fine enough for most positioning tasks.

Quadrature: Two Channels for Direction

A real industrial encoder has not one but two output channels — typically labelled A and B — that produce identical pulse trains 90° out of phase with each other. The PLC reads both, and from the order in which the edges occur it can tell whether the shaft is turning forward (A leads B) or backward (B leads A). This quadrature arrangement is what makes encoders directional — without it, you couldn’t distinguish forward motion from backward motion.

Figure 8.2 — Quadrature Encoder OutputChannel A’s rising edge precedes channel B’s by 90° when the shaft turns forward. Reverse the shaft and B’s edge precedes A’s. The PLC’s high-speed counter watches both channels and increments or decrements automatically.

High-Speed Counters (HSC)

The catch with encoders is speed. A 1 024-PPR encoder on a motor running at 1 800 RPM produces 30 720 pulses per second. The normal CTU instruction can only count rising edges that the PLC sees during its scan — and a typical scan is 5–20 ms long, so any pulse train faster than about 50 Hz will be missed by a regular counter. To track fast pulse trains we use a high-speed counter (HSC): a dedicated hardware counter built into a special input module that counts pulses on its own, completely independent of the program scan.

The HSC presents its current count to the PLC as a register the program can read at any time. You don’t have to count the pulses in ladder logic — the hardware handles that — you just read the running total whenever you need it. Modern HSC modules handle pulse rates from 100 kHz up to several MHz.

When to spec an HSC

Any encoder over a few hundred Hz. Any flow meter producing a turbine pulse train. Any time you find yourself thinking “regular counters might be too slow”. Spec the HSC module up front when sizing the PLC chassis — adding it later usually means reshuffling I/O and re-running cables.

Worked PLC Programs

Six Programs — From Carton Counting to Encoder Position Tracking

Each program below tackles a real-world counting problem step by step. Pay attention to the one-shot in front of every CTU — that’s the detail that separates a working counter from a flaky one.

PLC Program · CTU + OSR

Carton-Pack Counter — Case Full at 24 Bottles

CTU

The problem: a packaging line drops bottles into a case-pack of 24. A photoelectric sensor at the in-feed detects each bottle as it passes. When the count reaches 24, a “case full” indicator lights and the diverter solenoid fires, redirecting the next bottle into the next empty case. A reset button clears the count when the operator wants to start a fresh tally.

Inputs & Outputs

INPUTS

I:1/0 — Bottle photoeye (NO, 1 = bottle present)

I:1/1 — Manual RESET (NO momentary)

OUTPUTS

O:2/0 — “Case Full” lamp

O:2/1 — Diverter solenoid

C5:0 — CTU, PRE 24

B3:0/0 — One-shot bit

Ladder Diagram (Three Rungs)

A photoeye drives an OSR drives a CTU. The DN bit lights the “case full” lamp. A separate reset rung clears the counter for the next case.

How it works

A bottle blocks the photoeye for ~50 ms (more than one scan). I:1/0 goes from 0 to 1 — but because the OSR sits between the input and the counter, the CTU sees a single scan of “rung true” regardless of how long the bottle is in the beam.
The CTU increments. Accumulator goes from 0 to 1. CU bit pulses true; DN stays at 0.
Next bottle: same sequence, ACC goes to 2. Repeat 22 more times.
On bottle 24, ACC reaches PRE = 24. DN goes to 1. Rung 1 lights the “Case Full” lamp.
Operator (or the diverter logic) eventually fires the reset. Rung 2’s RES clears C5:0 back to ACC = 0 and DN = 0. Lamp drops. Counter is ready for the next case.

What we learned: always put a one-shot between an input and a CTU when the input could remain true for more than one scan. Without the OSR, the photoeye blocking the beam for 50 ms would generate multiple counts at scan-rate, ruining the count. The OSR converts a long signal into a single clean pulse.

PLC Program · CTD + OSR

Parking Garage — Available Spaces Counter

CTD

The problem: a parking garage has 50 spaces. A loop sensor at the entrance gate detects each car driving in. We want a counter that starts at 50 (full availability) and counts down by one each time a car enters. When the count reaches zero, a “FULL” sign lights at the entrance and the gate is held closed. (We’ll add the increment-on-exit logic in Program 3.)

Inputs & Outputs

INPUTS

I:1/0 — Entry loop sensor

I:1/1 — Manual reset (start of day)

OUTPUTS

O:2/0 — “FULL” sign

C5:0 — CTD, PRE 50, ACC starts at 50

B3:0/0 — One-shot

Ladder Diagram (Three Rungs)

CTD decrements on each entry. An EQU comparator tests for ACC = 0 to drive the FULL sign. The RES sets ACC back to the preset.

How it works

At start-of-day, the operator presses RESET. Rung 2’s RES sets C5:0 back to ACC = PRE = 50. The garage now reports 50 free spaces.
A car drives over the entry loop. I:1/0 goes high for ~2 seconds (cars are slow). The OSR converts this to a single-scan pulse.
The CTD decrements. ACC goes from 50 to 49.
Cars keep entering. ACC counts down: 49, 48, 47…
When ACC reaches 0, rung 1’s EQU comparator fires. O:2/0 turns on. The “FULL” sign lights at the entrance.
If the entry sensor fires again with ACC = 0, the CTD will keep decrementing into negative numbers (−1, −2…). In practice we’d add an XIO of the FULL bit in the entry rung to block further counting once the garage is full — see Program 3 for the bidirectional version.

What we learned: CTD is just a CTU with the increment direction reversed. The DN bit fires when ACC ≥ PRE — so on a CTD that started at PRE, DN is true at start and stays true; we usually use an explicit comparator (EQU, LEQ) on the accumulator instead. RES on a CTD restores ACC to PRE, not to zero.

PLC Program · CTU + CTD shared file

In/Out Buffer Counter — Bidirectional Item Tracking

CTU + CTD

The problem: a workpiece buffer between two machines holds up to 30 items. Sensor A counts items entering the buffer; sensor B counts items leaving. The PLC needs to know the net count (how many items are currently in the buffer) so it can light a “BUFFER FULL” lamp at 30 and a “BUFFER EMPTY” lamp at 0.

Inputs & Outputs

INPUTS

I:1/0 — Entry sensor (A)

I:1/1 — Exit sensor (B)

I:1/2 — Reset

OUTPUTS

O:2/0 — “BUFFER FULL” lamp

O:2/1 — “BUFFER EMPTY” lamp

C5:0 — CTU + CTD share this file, PRE 30

B3:0/0, B3:0/1 — One-shots

Ladder Diagram (Five Rungs)

Two counter instructions, same C5:0 file. CTU pushes ACC up; CTD pushes it down. ACC always equals (entries minus exits) — the live buffer count.

How it works

Start-of-shift: operator presses RESET. ACC = 0. EMPTY lamp lights via the EQU comparator.
Item enters the buffer. Rung 0’s CTU increments. ACC = 1. EMPTY lamp drops because ACC is no longer 0.
More items enter. ACC climbs to 5, 10, 15…
An item leaves the buffer. Rung 1’s CTD on the same C5:0 file decrements. ACC drops by 1.
Whenever ACC reaches 30, the shared C5:0/DN bit goes high → FULL lamp lights. The downstream machine knows to slow down.
Whenever ACC reaches 0 again, the EQU comparator fires → EMPTY lamp lights. The upstream machine knows the buffer needs feeding.

The clever bit

Two counters sharing one file is a feature, not a bug. Allen-Bradley designed counter files specifically to allow this — and most other PLC families have an equivalent pattern (Siemens uses one CTUD instruction with both inputs; CodeSys/IEC 61131-3 uses CTUD function blocks). The ACC of the shared file is your bidirectional counter.

What we learned: for any “in minus out” measurement — buffer levels, parking spaces, inventory counts, items in transit — point a CTU and a CTD at the same counter file. ACC will always hold the net count. Use comparators (EQU, LEQ, GEQ) on the accumulator to drive lamps and alarms at any thresholds you need.

PLC Program · Cascading counters

Lifetime Stroke Counter — Cascade for 100 000 Counts

CASCADE

The problem: a stamping press needs a tool-change reminder every 100 000 strokes. That number is well above the 32 767 limit of a single counter file, so we cascade two counters: the first counts 0–999 and the second counts groups of 1 000. When the second counter reaches 100, we’ve counted 100 000 strokes — and the alarm fires.

Inputs & Outputs

INPUTS

I:1/0 — Press cycle sensor (one pulse per stroke)

I:1/1 — Tool-change reset

OUTPUTS

O:2/0 — “Tool change required” lamp

C5:0 — CTU, PRE 1 000 (units)

C5:1 — CTU, PRE 100 (thousands)

B3:0/0, B3:0/1 — One-shots

Ladder Diagram (Five Rungs)

Two stages. The “units” counter rolls over every 1 000 counts and ticks the “thousands” counter once. The thousands counter alarms at 100 — i.e. 100 000 total strokes.

How it works

Press cycles. Each stroke is converted by an OSR into one clean count pulse and feeds C5:0. ACC of C5:0 climbs 1, 2, 3 … 999.
On stroke 1 000, C5:0/DN goes high. Rung 1 fires its OSR and increments C5:1 — the “thousands” counter — by 1. Simultaneously rung 2 sees DN and fires a RES on C5:0, dropping it back to 0.
The OSR on rung 1 is the key — without it, C5:0/DN would stay high for the brief moment before the RES, and we’d risk multiple ticks of C5:1. The OSR guarantees exactly one increment per overflow.
C5:0 resumes counting strokes 1 001, 1 002 … 2 000. At 2 000 the cycle repeats and C5:1 ticks to 2.
After 100 000 strokes total, C5:1 reaches 100 = its preset. C5:1/DN goes high and rung 3 lights the tool-change lamp.
After the tool change, the operator presses RESET. Rung 4 issues a RES on both counters in sequence — the one rung clears the entire cascade.

What we learned: cascading counters is mechanically simple — each stage’s DN bit feeds the next stage’s CTU through an OSR, and a RES on the same DN bit rolls the lower stage over to zero. Total count is always (upper × lower-PRE) + lower. Use as many cascade stages as you need; each one multiplies your range by its own preset.

PLC Program · Counter + Timer combo

Parts-Per-Minute Production Rate

RATE

The problem: a packaging machine needs to display its current production rate in parts per minute on the operator HMI. Each part triggers a sensor at the discharge. We want a number that updates once a minute and represents how many parts came off the line in the last 60 seconds.

Inputs & Outputs

INPUT

I:1/0 — Part-discharge sensor

OUTPUTS

N7:0 — Rate (parts/minute) for HMI display

C5:0 — CTU, PRE 32 000 (effectively unlimited)

T4:0 — TON, PRE 600 (60 s @ 0.1 s base)

B3:0/0 — Sensor one-shot

Ladder Diagram (Four Rungs)

A 60-second TON gates the rate window. The CTU counts parts during the window. When the timer expires, MOV transfers the count to N7:0, RES clears the counter, the timer reloads — fresh window starts.

How it works

Window starts. T4:0/DN is 0, so rung 0’s XIO passes power and the TON begins counting. ACC = 0, climbing toward PRE = 600 (60 s).
Parts arrive throughout the window. Each part triggers the OSR and increments C5:0. At any moment, C5:0.ACC = “parts so far this minute”.
60 seconds later, T4:0/DN goes high. Three things happen on this scan:
- Rung 0’s XIO blocks. The timer instantly resets ACC and DN both back to 0. (DN was high for one scan only.)
- Rung 2’s XIC TMR DN passes for that one scan. The MOV instruction copies C5:0.ACC to N7:0 — the rate value the HMI displays.
- Rung 3’s XIC TMR DN passes for that one scan. The RES clears C5:0 back to 0, ready for the next window.
Next scan: TMR DN is back to 0, so rung 0’s XIO passes again, the TON restarts, the counter starts counting from 0, and the rate displayed on the HMI holds at the value just measured for the next 60 seconds.

What we learned: count rate = (events) / (time window). The trick is to measure both during the same window, transfer the count to a display register on the timer’s expiration, and reset everything for the next window. The same pattern measures bottles-per-hour, RPM (with shaft pulses and a 1-second window), litres-per-hour (with flow pulses), or any other rate. Adjust the timer preset to change the update rate; adjust the counter preset to set an alarm threshold.

PLC Program · Encoder + HSC

Conveyor Position Tracking with Incremental Encoder

HSC

The problem: a labelling station needs to know exactly how far the conveyor belt has travelled since the last label was applied. A 1 000-PPR incremental encoder is mounted to a measuring wheel that rolls on the belt. The wheel has a 100 mm circumference, so each pulse equals 0.1 mm of belt travel. We need a register that always shows belt distance in millimetres since the last reset.

Inputs & Outputs

INPUTS

I:1/0, I:1/1 — Encoder channels A and B (wired to HSC module)

I:1/2 — Reset (label-applied feedback)

OUTPUTS

N7:0 — Distance in mm (display register)

HSC pulses → register updated by hardware

O:2/0 — “Apply label” trigger when distance ≥ 500 mm

Ladder Diagram (Three Rungs)

Hardware HSC handles the pulses. Ladder logic just reads HSC.ACC, scales it to mm, and watches for thresholds.

How it works

The encoder produces pulses on channels A and B as the conveyor moves. The HSC module is configured for “quadrature mode” so it automatically increments on forward motion and decrements on reverse, and rejects any pulse jitter.
The HSC accumulator updates in hardware at the encoder’s pulse rate — kHz or even MHz. The PLC scan never sees the individual pulses; it only reads HSC.ACC when convenient.
Rung 0 runs every scan. The DIV instruction divides the raw pulse count by 10 to convert to millimetres (1 000 pulses per revolution × 100 mm circumference = 10 pulses per mm). The result is stored in N7:0 for the HMI.
Rung 1’s GEQ comparator watches N7:0 and energises the “apply label” output the moment distance reaches 500 mm.
The labelling station applies the label and pulses its “label-applied” feedback. Rung 2’s RES clears the HSC accumulator back to 0. Distance starts counting from 0 again, and the next label applies after the next 500 mm of belt travel.

Why this needs an HSC, not a CTU

At a typical conveyor speed of 1 m/s with a 1 000 PPR encoder, the pulse rate is 10 000 Hz — or one pulse every 100 µs. A regular CTU running on a 10 ms scan cycle would miss 99 out of every 100 pulses. The HSC is hardware that counts between scans, so no pulses are lost.

What we learned: pair an incremental encoder with a high-speed counter for any distance, position, or speed measurement on real machinery. The HSC handles pulse counting; ladder logic handles scaling, threshold detection, and reset. Use a quadrature-capable HSC if direction matters; use a single-channel HSC if it only counts one way.

Common Student Mistakes

Things to watch out for in this chapter:

Forgetting the one-shot in front of a CTU. If your input could remain true for more than one scan, the counter will increment once per event only with an OSR. Without it, you get unpredictable extra counts whenever the input dwell happens to span a scan boundary.
Forgetting to RES a counter. Counters are retentive: they hold their value when the rung goes false and they hold it across PLC power cycles (in retentive memory). Every counter needs an explicit RES path.
Using the DN bit on a CTD that started at PRE. If you preset a CTD and load ACC = PRE, DN is true at start (because ACC ≥ PRE). It only goes false once ACC drops below PRE. To detect “empty”, use an EQU comparator on the accumulator instead.
Counting at scan rate by accident. If your “input” rung is a comparator like GEQ N7:0 100 and the value sits above 100 for many scans, the counter increments every single scan. Always feed counters from edge events (real input transitions or one-shot pulses), not from level conditions.
Trying to count high-speed pulses with a regular CTU. A typical PLC scans every 5–20 ms, so any input faster than ~50 Hz is too fast for a normal CTU. Use a high-speed counter module for pulse rates above 100 Hz.
Cascading without a one-shot on the carry-over. When the lower-stage DN goes high, that signal stays high until the RES fires — that’s at least one extra scan. Without an OSR, the upper-stage counter could increment twice per overflow.
Using a single-channel encoder when direction matters. A single-channel encoder cannot distinguish forward from reverse rotation. If the load could ever move backward (lash, bounce, vibration), use a quadrature (A + B) encoder and a quadrature-capable HSC.

Quick Recap

The eight things to take away from Chapter 8:

Counters increment on the rising edge of their rung, not on level. They are retentive — only RES clears them.
CTU counts up on each rising edge. CTD counts down. Both can share the same counter file for net “in minus out” measurement.
The one-shot (OSR / ONS) converts a maintained input into a single-scan pulse. Use it whenever the counter’s input might stay true for more than one scan.
Counter status bits — CU, CD, DN, OV, UN — are bits in memory. Any rung can read them. Use DN for “preset reached”; use comparators (EQU, GEQ, LEQ) on ACC for any other threshold.
Cascading counters chains stages so that each upper stage’s preset multiplies the lower stage’s range. Three stages with PRE = 1 000 each can count to one billion.
Counter + Timer combinations measure rate (parts-per-minute, RPM, throughput). Timer defines the window; counter counts events in the window; MOV the result on timer expiration; reset both for the next window.
Incremental encoders produce pulse trains proportional to motion. Quadrature (A+B channels) gives direction information. Resolution × wheel circumference gives mm-per-pulse.
High-speed counters (HSC) are hardware modules that count pulses faster than the PLC scan can. Use one whenever you have an encoder, a turbine flow meter, or any pulse train above ~100 Hz.

Review & Self-Assessment

Chapter 8 Review Questions

Try answering each question on your own first. Tap to reveal the answer when you’re done.

Q1List the five status bits a counter file holds, and say what each one means.+

CU — count-up enable, mirrors the rung condition of a CTU; CD — count-down enable, mirrors the rung condition of a CTD; DN — done, true when ACC ≥ PRE; OV — overflow, true if the accumulator tried to count past +32 767; UN — underflow, true if the accumulator tried to count below −32 768.

Q2When does a CTU increment its accumulator?+

On every false-to-true transition of its rung — the rising edge. If the rung stays continuously true for many scans, the accumulator only increments once. The next increment requires the rung to go false and then true again. This is why we use one-shots when the input might dwell longer than a scan.

Q3What is the role of an OSR/ONS instruction in a counter rung?+

The one-shot converts any duration of input “true” into a single-scan pulse. It sees the input transition from 0 to 1, fires its output for exactly one scan, and then stays false until the input returns to 0 and rises again. Placing an OSR between an input and a CTU guarantees one count per real-world event regardless of input dwell — it’s the fix for the most common counter bug.

Q4How can you build a counter that tracks the net difference between items entering and leaving a buffer?+

Point a CTU and a CTD at the same counter file. The entry sensor (through an OSR) drives the CTU; the exit sensor (through another OSR) drives the CTD. Both instructions share the accumulator: every entry pushes ACC up by 1, every exit pulls it down by 1. The accumulator therefore always equals (entries − exits) — the live net count.

Q5A 16-bit signed counter has reached its upper limit. What happens next, and what bit tells you?+

A signed 16-bit counter tops out at +32 767. The next increment causes the accumulator to wrap to a negative value and the OV (overflow) bit goes to 1. In a well-designed program you’d reset the counter long before this could happen, or use an XIC of OV in your fault-detection rung to flag the condition. Below the lower limit (−32 768), the equivalent is the UN (underflow) bit.

Q6Two counters are cascaded with the lower stage having PRE = 500 and the upper stage PRE = 200. What is the maximum total count this cascade can reach?+

500 × 200 = 100 000 counts. The lower stage rolls over every 500 events and ticks the upper stage by 1; the upper stage’s DN fires after 200 such rollovers, which corresponds to 200 × 500 events at the input. Cascading multiplies your effective range by each stage’s preset.

Q7Describe how to measure parts-per-minute using a counter and a timer.+

Set up a 60-second TON that auto-recycles itself (XIO of its own DN feeds the timer’s enable). Set up a CTU driven by the part-detect sensor through an OSR. While the timer runs, the counter accumulates parts. When the timer’s DN fires, a MOV instruction transfers the counter’s accumulator to a display register, then a RES clears the counter. The timer auto-resets and the cycle starts again. The display register holds “parts in the last 60 seconds” = parts-per-minute.

Q8What is a quadrature encoder and why are two channels needed?+

A quadrature encoder produces two pulse trains — channels A and B — that are 90° out of phase. By comparing which channel’s edge fires first, the PLC can determine direction: if A leads B, the shaft is turning forward; if B leads A, the shaft is turning backward. With only one channel you’d see pulses but couldn’t tell forward from reverse motion — direction information is lost. Quadrature is essential whenever the measured shaft can rotate in either direction.

Q9Why can’t a normal CTU count the pulses from a fast incremental encoder?+

A normal CTU only sees rising edges that occur during the program scan, and the typical scan is 5–20 ms. An encoder running at, say, 10 kHz produces a pulse every 100 µs — far faster than the scan can detect. Most pulses arrive between scans and are missed entirely. A high-speed counter (HSC) module solves this by counting in dedicated hardware that runs continuously, completely independent of the PLC scan. The HSC then presents its current accumulator to the PLC as a register that ladder logic can read at any time.

Q10An encoder with 2 048 PPR is mounted to a measuring wheel of 200 mm circumference. How many pulses correspond to 1 mm of belt travel?+

Each revolution of the wheel produces 2 048 pulses and advances the belt by 200 mm. So one mm of belt travel = 2 048 / 200 = 10.24 pulses. In a real program you’d typically scale this with a DIV (HSC.ACC ÷ 10 for an approximate mm value) or with a CPT/MUL/DIV combo if you need full precision. Adjust the wheel size or the encoder PPR if you need more or less resolution.

Q11Why does the program in Worked Example 4 need an OSR on the carry-over rung between the lower and upper counter stages?+

When the lower counter’s DN goes high, it stays high for at least one full scan — and possibly more if the RES is delayed. Without an OSR, the upper counter would see “input true” for multiple scans and could increment more than once per overflow, throwing off the cascade. The OSR ensures exactly one increment of the upper counter per rollover of the lower counter, regardless of how many scans pass between DN going high and the RES clearing the lower counter.

Q12A counter’s accumulator is at 47 of preset 50. The PLC loses power. After power is restored, what does ACC read?+

47. Counter accumulators are retentive by default — they’re stored in non-volatile or battery-backed memory and survive a power cycle. Only an explicit RES instruction (or operator action through programming software) clears them. This retention is exactly what you want for cumulative counts like maintenance hours or stroke totals; it’s also why you must include a deliberate reset path in your program rather than relying on power-cycling to clear a count.

Need help wiring an encoder, sizing an HSC module, or designing a parts-counting program?

Get one-on-one tutoring or commissioning help from Dr Ahsan Rahman — Head of Electrical Engineering, with two decades of experience teaching counter logic, encoders, and high-speed counting applications.

Request Consultation →