Does Product Reconciliation Require a Machine Fault?

The panel shows good, bad, reject-request, and verified-reject counts, but the totals do not always match while product is moving. Start here: product reconciliation is an accounting test across a defined machine boundary. For a completed run, every unit admitted to that boundary must have one final disposition.

Do not turn an ordinary in-process difference into an immediate machine fault. Products between the infeed, two eject stations, and discharge remain work in process. Compare final totals only after the machine is empty, or include work in process in the live calculation.

Define What Must Be Reconciled

Read the approved machine specification and batch requirement first. The term can describe three different functions:

• Product quantity reconciliation: units entering equal good units leaving plus verified rejects and other controlled dispositions.
• Label reconciliation: labels issued equal labels applied plus labels remaining, rejected, damaged, sampled, or otherwise removed.
• Material or recipe verification: the container, label, lot code, and date code match the selected product recipe.

The described machine already verifies lot and date code with a Cognex camera before label application and checks for label presence with a UV sensor afterward. Those inspections answer identity and quality questions. They do not, by themselves, reconcile product quantity.

Ask the customer to approve the boundary, counted events, permitted dispositions, rerun treatment, response to a variance, batch-close conditions, and required records. If the requirement means product quantity, continue with the infeed boundary check. If it means label inventory or recipe identity, write a separate calculation and acceptance test; one total cannot represent all three functions.

Check the Infeed Boundary First

Take the reading at the event where the machine accepts ownership of a product. A hopper command is not enough. Count a physical unit once, after it has entered a roller pocket and cannot leave upstream without a recorded intervention.

Use the CompactLogix L306 to create one product record for each accepted occupied pocket. Advance that record with the physical conveyor movement. Inspection results then attach to the same record instead of creating new products.

• If one physical product creates one accepted record, proceed to the pocket-tracking check.
• If an empty pocket increments the count, fix occupancy qualification.
• If one product can trigger the entry event more than once, add edge detection or position gating.
• If a product can be removed between the count point and first inspection, record that removal or move the boundary.

Camera triggers, image acquisitions, and inspection totals are poor substitutes for the infeed count. A camera can retry, reject an image, or receive multiple triggers for one unit. The reconciliation count must follow physical product, not processing attempts.

Track Each Pocket Through Every Branch

Read one pocket record at each inspection and eject position. The record needs a current disposition such as pending, good, reject requested, reject verified, or held for investigation. A failed camera or UV inspection changes the disposition; it does not increment the product total again.

Multiple inspections and eject stations do not prevent accurate reconciliation. Accuracy comes from assigning exactly one terminal disposition to each admitted product. The basic conservation equation is:

Infeed = Good discharge + Verified rejects + Work in process + Controlled removals
Variance = Infeed - Accounted product

At a completed, empty batch, work in process must be zero. If the process allows no manual removals, controlled removals must also be zero. A 1,000-unit example closes when good discharge plus all verified reject destinations equals 1,000.

• If the live variance equals the number of occupied pockets still inside the machine, continue running; that is not the fault.
• If a record reaches the discharge as good, increment the good total once and close that record.
• If a reject is physically verified, increment the corresponding verified-reject total once and close that record.
• If a record disappears without either event, stop product flow and investigate the last confirmed position.

Separate Requests From Physical Rejects

Compare reject requests with verified reject events at each eject station. A request is a control decision. A verified reject is the physical disposition needed for reconciliation.

Panel symptom	Likely cause and next check
Reject requests exceed verified rejects	An eject did not occur, reject confirmation was missed, or the unit remains in transit. Check the affected pocket and reject-verification device.
Verified rejects exceed reject requests	A product was counted twice, the verification event bounced, or an uncommanded unit entered the reject path. Check one-shot logic and physical routing.
Good plus rejects trails infeed during production	Products remain between the entry and terminal count points. Compare the difference with tracked work in process.
Good plus rejects trails infeed after the conveyor is empty	A unit was removed, lost, jammed, or passed a terminal point without a valid count. Review the product record history and intervention log.
Good plus rejects exceeds infeed	A terminal event was counted more than once, or a rerun was counted without a matching re-entry rule. Check event edges and rerun handling.

The existing fail-safe—raising a major fault and shutting down when a reject request is not verified—protects against passing a rejected unit. Keep that logic separate from batch reconciliation. The immediate fault responds to one failed physical action; reconciliation detects an accounting variance across the run.

Decide How Reruns Affect the Totals

Read the state of the reject bin and the operator-intervention record before allowing a rejected unit back into normal production. Reruns are the fastest way to double-count a batch.

Choose one approved rule and make it visible on the PanelView HMI:

• New entry rule: a rerun increments infeed again and retains its earlier reject disposition. This reconciles machine passes, not unique physical units.
• Return rule: remove the unit from its prior reject disposition before returning it to work in process. This reconciles unique physical units, but requires controlled identity and custody.
• End-of-run rule: record normal-run totals, then execute reruns as a separate controlled phase or batch segment.

The end-of-run rule is usually easiest to audit when serialization is not part of the project. This machine verifies lot and date codes but does not serialize individual units, so it cannot infer that a returning unit is the same physical unit previously rejected. An SOP can control the rerun phase, or an interlock can prevent removal from the reject bin until the authorized phase begins.

The requirement that an operator be logged in before conveyor start supports attribution, but login alone does not account for product. Record the intervention type, time, affected quantity, reason, and resulting disposition whenever an operator opens, clears, removes, or reloads product within the reconciliation boundary.

Classify the Variance Before Faulting

Read the variance together with machine state. Do not alarm on the raw difference alone.

• Running with occupied pockets: a nonzero difference can be normal work in process.
• Stopped with known occupied pockets: hold the batch open and show the pending count.
• Empty after a controlled flush: any nonzero variance is an unresolved reconciliation discrepancy.
• Reject requested but not verified: use the existing major-fault path immediately; do not wait for batch closure.
• Count channel unhealthy: inhibit batch completion because the accounting basis is no longer valid.

A reconciliation discrepancy does not automatically require an immediate conveyor fault. The customer must decide whether the response is a warning, batch hold, prevented batch close, or machine stop. Product-safety events such as an unverified eject can remain immediate stops while an end-of-run numerical variance becomes a quality hold requiring investigation.

Implement the Resolving Branch

1. Define the physical infeed and discharge boundaries and every permitted exit between them.
2. Create one product record when an occupied pocket crosses the accepted infeed event.
3. Advance that record with conveyor position and attach defect, code, and label-presence results to it.
4. Generate an eject request from the record state, then wait for physical reject verification before closing the record as rejected.
5. Close a good record only when the product crosses the good-discharge count point.
6. Track occupied pending records as work in process. Display that value beside infeed, good, reject requests, verified rejects, and variance.
7. Require an authenticated, recorded action for manual removals, reject-bin access, and rerun mode.
8. At batch end, block new infeed, flush or clear all tracked pockets, confirm zero work in process, and calculate the final variance.
9. Allow batch completion only under the customer-approved variance rule. Preserve the final totals and intervention records in the required batch record.

Do not reset counters at an ordinary stop, recipe-screen change, HMI restart, or recovery from a jam. Reset them only through the approved batch-start transition after the previous batch has been closed or formally held.

Verify the Result With Forced Outcomes

Run an acceptance test that proves every branch, not just normal production.

1. Pass known products through with no rejects. Confirm one infeed event and one good-discharge event per product.
2. Force a defect-camera failure and verify ejection at the first station. Confirm one reject request and one verified reject, with no good count.
3. Force a failed lot/date result or missing-label result and verify the second eject path in the same way.
4. Prevent one commanded eject from being verified. Confirm the major fault and shutdown occur, and confirm the unresolved record remains visible.
5. Stop with products inside. Confirm the live variance equals tracked work in process and batch close remains unavailable.
6. Remove a product under the approved intervention procedure. Confirm the event is recorded and the final equation uses the approved disposition.
7. Rerun a reject according to the selected rule. Confirm that totals represent either passes or unique units exactly as specified.
8. Empty the machine and close the batch. Confirm work in process is zero and good product plus verified rejects and approved removals equals infeed.

Also challenge duplicate entry signals, duplicate reject verification, HMI restart, controller recovery, and a stop between reject request and verification. The counters and product records must neither disappear nor increment again after recovery.

FAQ