Calculate output from a cumulative PLC counter only inside a verified counting epoch, using the counter type, reset policy and source quality. A falling value can mean a reset, reboot, rollover or bad record; two values alone may not distinguish them. Keep unsupported intervals unresolved instead of converting every negative difference into production. This fictional event record shows normal increments, a reboot gap and a separate known-modulus rollover with an explicit rate bound.
Separate a valid increment from an unknown reset interval.
Use rollover arithmetic only with the actual counter contract.
Keep duplicate and missing observations out of production totals.
Write the counter contract before subtracting values
Identify the counted event, unit, direction, data type, persistence, reset authority and maximum plausible rate. Rockwell’s CTU documentation, for example, describes false-to-true increments and a signed accumulator with overflow behavior. Do not assume every counter behaves as an unsigned wraparound register.
The measured signal must also represent the business count. A pulse may mean a cycle, a part exit, a reject or a sensor bounce. Identify good units and rework separately. OEE calculation needs compatible counts, not simply the largest tag available.
Keep a new baseline after the reboot
In this illustrative record, the counter rises from 998 to 1003 while uptime rises by 60 seconds, so that interval contributes 5 counted events under the stated unchanged epoch. The next reading is 4 while uptime drops to 10 seconds and a reboot is recorded. Output across that gap is unresolved.
Use 4 as the first observed baseline of the new epoch. A later reading 9 in the same epoch contributes 5 more. The two known intervals contain 10 events. Do not report 14 or assume the unobserved reboot interval produced zero.
| Observation | Counter | Uptime seconds | Treatment |
|---|---|---|---|
| 10:00 | 998 | 1000 | Initial baseline |
| 10:01 | 1003 | 1060 | Verified increment 5 |
| After reboot | 4 | 10 | New epoch; intervening output unresolved |
| 60 seconds later | 9 | 70 | Verified increment 5 |
Apply modular arithmetic only to a verified modulus
A separate fictional transmitted counter has unsigned values 0 through 999, so its modulus is 1000. It moves from 995 to 3 over 10 seconds. If the counter contract guarantees ordinary wrap and the physical maximum is 1 count per second, the plausible increment is 8:1000−995+3.
Without that rate bound or equivalent evidence, more than one full wrap could have occurred. A reset could also explain the smaller value. This teaching counter is not the signed Logix CTU above; actual platform limits and overflow rules must come from its documentation.
(3−995+1000) mod 1000 =8. The 10-second, 1 count/second bound excludes a second full wrap; reset evidence must still be checked.
Preserve event identity, source time and quality
Retain device, tag, source timestamp, receive timestamp, quality and a stable sequence or epoch identifier where available. OPC UA source timestamps describe the source value and must not be silently replaced by polling time. An unchanged value can retain its source timestamp; that alone does not prove disconnection.
A replayed observation with the same identity should not add output twice. A missing interval should not be bridged if reset, rate or source quality is uncertain. Link the exact counting rule to real-time monitoring so a dashboard can show unresolved data rather than a reassuring false total.
- Verify the source semantics
Confirm unit, edge, counter type, persistence and reset/overflow behavior.
- Order and deduplicate
Use stable identity, source context and quality before computing changes.
- Classify the interval
Accept a verified increment or known wrap; start a new epoch or mark uncertainty otherwise.
- Reconcile with physical evidence
Compare counts, rejects and rework with identified production records.
Reject impossible increments instead of smoothing them
For the same 10-second, 1 count-per-second boundary, a reported increase of 988 cannot be accepted as production. Investigate ordering, type conversion, reset handling, rate assumptions and sensor behavior. Do not distribute the difference evenly across the gap to make the chart look normal.
A software total should expose known counts and unresolved intervals separately. If business reporting needs an estimate, label its method and uncertainty as an estimate rather than overwriting the raw observation. OPC UA and MQTT address transport choices, not automatic correctness of the count.
Test the discontinuities before connecting the dashboard
Exercise normal increments, duplicate delivery, out-of-order messages, reset, reboot, rollover, zero elapsed time and missing quality. Retain the expected result for each case. A test using only a continuously increasing tag misses the failure that matters most.
The download includes the reboot record, the separate modulo example and blank fields for your counter contract. Test those breaks in continuity before using the total in an output or OEE report.
A related example from Abolfazl
Check event time, late arrivals and duplicates before trusting a live count.
In English, on founder Abolfazl’s personal blog. This is related reading, not an independent technical source.
Practical checklist
- Define the counted event and unit.
- Verify actual data type and overflow rules.
- Record reset and persistence behavior.
- Keep source time, quality and identity.
- Deduplicate before calculating deltas.
- Use a rate bound for rollover ambiguity.
- Separate known increments from unresolved gaps.
- Reconcile rejects and rework before reporting good output.
FAQ
FAQ
Sources and further reading
Authoritative references used to research and verify this guide.