A part count is one of the highest-value tags on any machine. It drives target-vs-actual, feeds the performance term in OEE, and it’s usually already sitting in the PLC’s own memory as a running cumulative counter. Reading that counter correctly takes more than pointing a tag at the address. A counter rolls over, gets reset by a shift change or a job change, and occasionally jumps to a value that was never produced. This guide covers what a counter does over its lifetime, and how to read it without those events turning into a fabricated spike or a silent loss of production history.
Why a counter beats a derived cycle signal
Some machines don’t keep a counter at all, and the workaround is deriving a count from a cycle-complete signal instead, a relay or a bit that pulses once per machine cycle. That works, but it counts a different thing than a real counter does. A cycle signal fires on every cycle the machine runs, including a dry run, a jog move during setup, a cycle that ends in a rejected part, anything that trips the same relay without a finished, accepted part coming out the other end. A counter the PLC’s own program maintains is usually incremented at the point in the program logic where a part is considered done, a narrower definition of “produced” than “the machine moved through a cycle.”
Where a real counter doesn’t exist, a cycle signal is still a legitimate fallback, and it’s exactly the dry-contact case covered elsewhere in this series. Go into it knowing the number will run a little hot on any machine with real dry cycles or rejects, and that a native counter, when one exists, is worth reading in preference to a derived signal.
Check whether the machine has more than one counter, too. Several CNC and PLC programs keep separate totals for different purposes: a lifetime total that never resets, a per-shift total that clears on a schedule, sometimes a per-job total tied to whatever program is loaded. Reading the wrong one produces a plausible-looking number that answers a different question than the one you meant to ask. A lifetime total charted as if it were per-shift production looks like a machine that never stops making parts. Confirm which counter a given address tracks before mapping it, the same way you’d confirm a register’s data type.
What a counter’s own lifetime looks like
A counter doesn’t just count up forever. Three things happen to a running counter tag over its life, and reading it correctly means telling all three apart from each other and from genuine production.
Rollover. A counter stored in a fixed number of bits wraps back to zero once it exceeds what that width can hold, 65,536 for a 16-bit counter, over 4 billion for a 32-bit one. A busy machine on a small counter can hit that wraparound within a single shift. Reading two successive values where the second is lower than the first isn’t automatically a problem. If the first value was near the top of that range and the wrapped math lands on a plausible number of parts, that’s a rollover, not a loss.
Reset. A counter dropping to zero, or near it, mid-shift is often a deliberate reset, a shift-change convention some plants use, a job change, someone clearing the display on the machine’s own panel. The parts made since that reset still count, starting fresh from the new baseline. The math never runs as a negative delta from the old one.
An implausible jump. Occasionally a reading is wrong: a corrupted read, a baseline swap from someone changing which counter the tag points at. A jump far outside what the machine could plausibly have produced in the time between two readings isn’t a rollover and isn’t a reset, and treating it as either would fabricate a huge, false spike in production.
What happens when none of the three explanations fit
A drop that’s neither a plausible wraparound nor a plausible reset, an arbitrary-looking jump that fits neither pattern, is treated as zero. Nothing about it gets guessed at. The next reading re-establishes the baseline from wherever the counter is. Production for that one interval shows as an under-count. It never becomes a fabricated over-count. An under-count with a visible gap is a smaller problem than a number nobody can trust. A gap tells you to go look. A wrong-but-plausible number doesn’t.
The same discipline applies to a forward jump as well
A counter reading that goes up is the normal, expected case, and most of the time the delta between two readings is exactly what it looks like: parts made since the last read. But an upward jump can still be implausible on its own terms. A machine with a known ideal cycle time can only physically produce so many parts in the time between two polls, and a delta far beyond that ceiling, hundreds of parts logged in a gap where the machine could realistically have made a handful, gets the same treatment as a backward jump that fits no pattern: it’s held at zero, not accepted at face value. The next reading re-anchors from there. The ceiling is generous by design, several times the machine’s fastest realistic rate, so it catches a broken reading without clipping a real, busy stretch of production.
What to check on day one
A counter tag reading correctly on day one still deserves a short verification pass before you trust its numbers. Watch it across a normal run and confirm it only moves on genuine finished parts, not on every cycle if the machine also runs dry cycles or scraps parts mid-job. Check the counter’s bit width against the machine’s production rate. A 16-bit counter on a fast machine can roll over more than once in a single shift, so a reading that briefly looks like it dropped may just be a rollover, not a fault. Watch what happens at a shift change or job change too. If the counter resets on its own at that boundary, that’s expected behavior, and the production total for the new shift should start clean from there.
Quick recap
- A PLC’s own counter, when one exists, counts finished parts more precisely than a derived cycle signal, which fires on dry runs and rejects too
- Rollover at a counter’s bit width, 65,536 for 16-bit, produces a real, calculable delta, not a lost count
- A reset to zero or near it is usually deliberate, a shift or job boundary, and the new baseline starts counting fresh
- An implausible jump that fits neither pattern holds at zero instead of becoming a fabricated spike, and the next reading re-anchors from there
- On day one, confirm the counter only moves on real finished parts, and know its bit width against your actual production rate