Use Batch Control Totals to Prove Vision Data Completeness
Close each production batch with independently derived counts and exception states so missing, duplicate, or unlinked inspection records are visible.
The database contains 99,980 inspection records for a batch the PLC says produced 100,000 units. Both systems report healthy, but nobody can identify the missing 20 decisions.
This is a vendor-neutral engineering method. The worked example is hypothetical and must be replaced by measurements from the real product, line, and risk assessment.
What you will learn
Identify the physical, optical, data, or process limit behind batch control totals for vision data completeness.
Convert the inspection need into measurable acceptance criteria.
Compare practical architectures and their trade-offs.
Commission the method using repeatable evidence.
Validate the final system under representative production variation.
Technical foundation
Completeness is a population claim
The required population comes from controlled production events, not from counting rows in the same result store being tested.
Counts need semantics
Produced, presented, inspected, accepted, rejected, bypassed, reworked, scrapped, duplicate, orphan, and invalid are distinct categories.
Closeout is a state transition
A batch remains open while late events or approved corrections can arrive. Closure records the cutoff, totals, exceptions, and authorization.
Related guides on this publication: Machine Vision Traceability: Images, Results, Recipes, and MES and Machine Vision PLC Integration: A Robust Handshake and Machine Vision FAT and SAT: Build an Acceptance Test That Works.
Engineering workflow
1. Define the batch population
Evaluate: batch ID, unit identity, production start and end, split lots, rework, scrap, bypass, and station scope.
Why it matters: ambiguous scope makes counts incomparable.
Measure or calculate: write a population equation and ownership for each term. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: detailed categories require upstream events. Common failure: equating conveyor triggers with produced units.
2. Choose independent counters
Evaluate: PLC completed count, serialization service, reject counter, vision event count, and MES receipt count.
Why it matters: independence helps reveal loss in one path.
Measure or calculate: record monotonic start and end snapshots with reset detection. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: more sources need reconciliation logic. Common failure: deriving every total from one database table.
3. Enforce record identity
Evaluate: unit ID, attempt ID, station, result version, event ID, and disposition.
Why it matters: counts can match while records are duplicated or crossed.
Measure or calculate: check uniqueness and allowed attempt relationships. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: strict keys expose legacy gaps. Common failure: using timestamp as the only key.
4. Handle late and corrected data
Evaluate: watermark, grace period, retry queue, correction record, original link, and authorization.
Why it matters: asynchronous delivery can make an early close false.
Measure or calculate: track event time and arrival time, then close after defined watermarks. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: longer grace delays release. Common failure: silently overwriting prior results.
5. Calculate exceptions
Evaluate: missing unit, duplicate final result, orphan result, unresolved bypass, mismatched reject, and invalid record.
Why it matters: a single net difference can cancel opposite errors.
Measure or calculate: report each exception class and affected IDs. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: exception detail increases storage. Common failure: accepting zero net difference as proof.
6. Govern closeout
Evaluate: acceptance criteria, hold, review, approved exception, immutable summary, signature, and reopening rule.
Why it matters: operations need an actionable outcome.
Measure or calculate: store inputs, equations, software version, owner, and final status. Preserve settings, sample identity, operating state, and the calculation method so alternatives remain comparable.
Trade-off: formal closeout adds procedure. Common failure: marking complete automatically despite exceptions.
Worked example
Hypothetical batch reconciliation: A PLC reports 100,000 produced units. The result store has 99,982 unique final dispositions, including two orphan IDs.
missing linked dispositions = 100000 - (99982 - 2) = 20
The batch is not complete. The two orphans are investigated separately; they do not offset missing known units.
Practical decision aid
| Control total | Independent source | Exception revealed |
|---|---|---|
| Produced units | PLC or serialization boundary | expected population |
| Unique final dispositions | vision result store | missing decisions |
| Duplicate final dispositions | uniqueness query | double processing |
| Orphan results | identity anti-join | wrong or unknown unit |
| Physical rejects | reject confirmation sensor or PLC | routing mismatch |
| Bypass and invalid count | controlled exception log | uninspected population |
Use the table to choose the next controlled experiment, not as a universal product recommendation. A component or algorithm is acceptable only when the complete inspection cell meets pre-agreed technical and operational criteria.
Common mistakes and how to prevent them
Counting rows only. duplicates hide missing records. Prevent it by counting unique governed identities.
Using one source for both totals. common loss is invisible. Prevent it by selecting independent counters.
Ignoring rework attempts. good repeat looks duplicate. Prevent it by modeling attempt and final disposition.
Closing before late events. healthy records appear missing. Prevent it by using a defined watermark.
Netting orphans against missing units. two faults cancel numerically. Prevent it by reporting exception classes separately.
Overwriting corrections. history becomes unverifiable. Prevent it by appending linked correction records.
Validate under production conditions
Create batches with known missing, duplicate, delayed, orphaned, corrected, bypassed, reworked, scrapped, and counter-reset events. Close around shift and clock boundaries. Verify equations, affected identity lists, hold behavior, authorized exceptions, immutable summaries, reopening controls, and reconciliation against physical reject evidence.
Use representative acceptable parts, confirmed defects, boundary samples, and nuisance variation. Repeat complete part presentations rather than processing one stored image many times. Include start-up, warm-up, maximum speed, changeover, maintenance, environmental limits, communication faults, and long-duration operation where relevant.
Define acceptance criteria before reviewing final results. Preserve raw counts and denominators for false accepts, false rejects, invalid acquisitions, timing overruns, and manually reviewed cases. After release, trend leading indicators and conduct labelled audits so deterioration is detected before a customer escape.
Key takeaways
Derive the expected population independently.
Use governed identities and attempt semantics.
Report missing, duplicate, and orphan records separately.
Wait for a defined arrival watermark before closure.
Hold or explicitly approve batches that do not reconcile.
Follow this Hashnode blog for more practical industrial machine-vision engineering, and connect with Kivanc Ekici on LinkedIn. To explore relevant technology information, visit Algomedi.
Frequently asked questions
Can equal PLC and database counts prove completeness?
No. A duplicate and a missing record can cancel; identity-level reconciliation is required.
What is a control total?
An independently derived summary used to verify the population and processing outcome of another data set.
How should reinspections be counted?
Store each attempt while defining exactly one governed final disposition per unit and station requirement.
When should a batch close?
After the production boundary, retry queues, and defined late-arrival watermark have been evaluated.
Can an incomplete batch be released?
Only under a documented, authorized exception policy that preserves the unresolved IDs and rationale.