Save the previous count before a PLC counter reset

Symptoms and what each points to

• The previous count reads 0 after every reset. The counter cleared before the copy ran, or the field points at the live register.
• The previous count climbs with production. The field points at the live current-value register and shows the batch in progress.
• The previous count rewrites itself while the reset button is held. The copy is level-triggered, so it repeats every scan the button is down, and after the first scan the counter already reads 0.
• The saved value arrives garbled or at the wrong magnitude. The HMI field's data type or digit format does not match the register format.
• The live count stops counting after the change. The reset contact has ended up gating the counter rung or another rung it should not touch.

The capture rung

The rule is capture before clear. The counter rung stays untouched:

STR C1        count input
STR C3        reset contact
CNT CT0 K5    counter, preset 5

and the capture rung sits below it:

STRPD C2      one-shot, closed for one scan on the rising edge of the reset request
LD CTA0       load the counter's current value
OUT V2000     store it as the previous count
OUT C3        pulse the bit that resets the counter

Ladder runs top to bottom, once per scan. In the scan where the operator presses reset, the counter rung executes first with C3 still off, so the count stands. The capture rung then copies CTA0 into V2000 and switches C3 on. On the next scan the counter sees C3 and clears to 0, the one-shot has already dropped out, and C3 goes off again. The copy always reads the pre-reset value, because the clear can only happen a scan after the copy. Counter instructions live on this scan order; PLC up down counter scan timing and direction logic works the same timing through for counting in both directions.

Two checks before you rely on the rung: that one scan of C3 is a complete reset for your counter instruction, and that C3 drives nothing else in the program.

Some high-speed counter modules can do the capture themselves. A module with a store function saves the current count on a store signal, and the manual's store modes define what the counter does next. A module with a latch input copies the current value into its latch register on the rising edge of the latch signal, and the manual states whether counting pauses while latched. If your module has either, the saved value lives in the module's own register and the previous-count field reads that instead of a V-memory copy.

Why the one-shot matters

STRPD closes for exactly one scan per rising edge, so one press gives one capture and one reset. Drive the same rung with a plain contact and the copy repeats every scan the button is down. The first copy saves the count. The second, one scan later, reads a counter that has already cleared and writes 0 over the saved value. The same edge-versus-level distinction decides whether a pulse ever reaches a screen at all: why an R_TRIG pulse never shows on the HMI screen is the display-side version of the same fault.

Point the two screen fields at the right registers

The previous-count field reads V2000. The live-count field reads CTA0. Match each field's data type and digit count to the format the PLC manual prints for that register. A mismatch shows a nonsense value, and an HMI panel that shows nonsense numbers from a PLC BCD analog register is that fault worked through in detail. Confirm both mappings online, with each field compared against its register value while the line is idle, before you test a reset.

Example: a reset pressed at a count of 3

The counter carries the preset K5, so its done contact fires at the fifth pulse. The line counts 50 units per minute, one pulse every 60 ÷ 50 = 1.2 s. The operator spots a fault at unit 3 and presses reset.

Scan 1: the one-shot closes once, CTA0 reads 3, V2000 takes 3 and C3 pulses on. Scan 2: the counter clears, CTA0 reads 0 and C3 drops out. The screen shows live 0 and previous 3, and the batch count is safe in V2000.

Counting resumes at once because C3 was on for one scan only. The done contact fires again after 5 more pulses, 5 × 1.2 s = 6.0 s later, and the next reset captures 5.

Had the rung cleared the counter first, the copy would have read 0 and the screen would show previous 0 with the batch gone.

Test a full reset cycle

Run the first test with the line stopped or in a state where a counter reset moves nothing. Then:

1. Note the live count, 3 in the example, and open V2000 online next to the screen.
2. With the line idle, check the previous-count field matches V2000 and the live field matches CTA0.
3. Press reset once. V2000 must take the pre-reset value before the live count goes to 0, and C3 must be on for one scan only.
4. Hold the button down for a full second. Nothing changes: no second copy, and the live count stays at 0 until pulses arrive.
5. Feed 5 pulses. The live count runs 1 to 5, the done contact fires at 5 and V2000 still reads 3.
6. Reset again and check that V2000 updates to 5.

These six steps separate the four failure modes: clear before copy, a level-driven copy, a field mapped to the live register, and a reset bit that disturbs counting. If counting behaves differently after the change, put the previous logic back before the line runs again.

Recommendation

Recommendation: capture on a one-shot, in a rung placed so the copy executes before the reset contact reaches the counter, and map the screen's previous-count field to the saved register. With the sample addresses that is STRPD C2 copying CTA0 to V2000 and pulsing C3 for one scan, on a counter rung left exactly as the validated program has it. Use this ordering whenever the last batch count must survive a reset, and test one full reset cycle online before the line returns to production. If the floor also wants the live and previous counts on a wall board, the board is a notice screen fed by your plant's usual data path and stays out of the counter's reset wiring; shop-floor screens and andon-style boards covers what those screens carry.

Questions