Take three paper slips and write 41, 42 and 43 on them. Move them along the machine drawing. Give 42 a failed inspection and 43 a pass. Before either reaches the rejector, ask which record the output decision will read. If your answer is “the latest camera result”, you have found the bug before writing the queue. The record needs identity, result, position or progress, and validity.
A correct result can belong to the wrong part
The camera says Fail. The reject cylinder extends. A part drops into the reject bin. Every individual action looks correct, yet the rejected part passed inspection and the failed part continues downstream.
This failure is about identity and timing, not the Boolean meaning of Pass. Our training inspection cell moves parts past a camera and then past a reject gate. The controller must keep a result attached to its part until that part leaves the system.
The model uses a belt encoder and a queue of part records. It teaches transaction ownership and position-based scheduling. A real implementation requires appropriate sensing, motion behavior, safeguarding, and target-specific engineering beyond this browser exercise.
Write the part's contract
Each detected part receives a locally unique identifier for its period of ownership. The controller requests an inspection with that identifier. The camera interface returns the same identifier, a result, and a validity indication. A result is accepted once, only for a pending part, and only within its declared deadline.
Do not reduce the interface to Trigger, Busy, and Pass without defining how their transitions identify a transaction. Some devices provide counters or result numbers rather than an arbitrary identifier. Adapt the contract to the documented device interface while preserving the ability to reject stale or duplicate results.
For this model, missing, invalid, and late results cause the affected part to be marked for rejection, with an explanatory reason. If reject confirmation fails, the model stops accepting new parts and reports uncertain disposition. This is a training quality policy, not a universal product-release rule.
Store a record, not a row of unrelated bits
A part record contains:
PartId
EntryEncoderCount
InspectionRequestId
ResultState: Pending / Pass / Reject / Unavailable
ResultReason
RejectStartCount
RejectEndCount
Disposition: InFlight / GoodReleased / RejectConfirmed / UncertainBound the queue size. If it is full, inhibit new admission or enter the defined overflow response. Silently overwriting the oldest record loses physical ownership. The plant may still contain the part even though the array no longer remembers it.
Define minimum part spacing and the maximum number simultaneously in flight. Those mechanical and process assumptions determine whether a single reject actuator can serve consecutive parts. Software cannot solve a spacing problem by issuing two mutually overlapping commands to one mechanism.
Use distance when distance is the requirement
The gate is 800 mm downstream of the inspection reference. The encoder provides ten counts per millimetre, so the nominal travel distance is 8,000 counts. If belt speed changes, a fixed one-second delay no longer locates the same part. Position tracking follows accumulated movement instead.
Define where the measurement begins: leading edge at the trigger sensor, part centre, or another reference. Include mechanical and actuator response allowances in the reviewed gate window. In the model, show the part rectangle and the gate's effective action zone so learners can see whether the command acts on the intended part.
Real conveyors may slip, reverse, or lose encoder information. A motor encoder does not automatically measure part position perfectly. The design must specify which movements are permitted and how uncertainty is detected or reconciled. Our first model allows forward travel only and faults on loss of tracking validity.
Handle counter wrap deliberately
An encoder count has a finite representation. Comparing CurrentCount >= TargetCount naively can fail across wraparound. Choose and document a wrap-aware distance calculation or use a suitable accumulated position representation maintained by an owner that handles hardware rollover.
For teaching, the model uses a bounded forward-distance function whose valid horizon is shorter than half its counter range. That bound makes ordering unambiguous. Test a part entering just before rollover and reaching the gate just afterward. The animation should continue normally, with its identifier unchanged.
Do not copy a wrap formula into a target with different signed arithmetic, overflow behavior, or permitted reverse movement. Verify the data types and runtime behavior explicitly.
Make the camera exchange idempotent
Suppose result 417 arrives twice because the interface retries delivery. The first valid result updates pending part 417. The second should be recognized as a duplicate, not assigned to the next pending part.
Likewise, result 416 arriving after part 417's request is not “the latest result” for part 417. Match by identity, check state, and record the reason for ignoring an out-of-window message. Acknowledgement should refer to the received result transaction rather than a generic pulse whose meaning depends on perfect timing.
On a result message:
find the matching active transaction;
verify that it is awaiting a result;
verify validity and deadline;
store the decision once;
acknowledge that message identity;
record duplicate, unknown, or late messages separately.This is also why a counter of inspected parts should increment on accepted new results, not while a ResultReady bit remains true.
Reject is a process with feedback
At the scheduled position, a Reject part requests the gate action. The model then distinguishes gate command, physical gate movement, and reject confirmation. A command alone does not prove that the part reached the bin.
Define the confirmation window and its identity assumptions. If one sensor watches the reject chute, explain how it can be associated with the scheduled part under the allowed spacing. Consecutive rejects may require a different window or tracking rule from isolated rejects.
For Pass parts, confirm normal release using the available downstream evidence. If the process lacks that instrumentation, name the result honestly: “released according to tracking model” is different from “physically confirmed at destination.”
Test the failures an attractive animation hides
Run two parts with opposite results and vary camera latency so replies arrive out of order. Duplicate a result. Lose one result. Change belt speed between camera and gate. Hold the gate physically closed while its command is true. Start a part near counter rollover. Fill the tracking queue.
For each test, inspect both the visible part and its record. Good software should retain an explanation when a part becomes uncertain. Clearing the queue to remove an alarm is not a product-disposition policy.
Try it
Part 81 is waiting for its result. Part 82 has just triggered the camera. A Pass result for 81 arrives, followed by a duplicate Pass for 81, then a Fail for 82. The current program assigns each incoming result to the oldest pending part. Predict the failure and propose the smallest correct interface change.
Work through the answer
The first result correctly marks 81 Pass. The duplicate can then mark 82 Pass because 82 is now oldest pending. The real Fail for 82 may be discarded, assigned to another part, or cause an unexplained error. Message order has replaced identity.
Carry the result identifier through the interface and match it to the active part transaction. Accept the first valid result for 81, recognize its duplicate without consuming another pending record, and apply Fail to 82. Test this exact sequence and an out-of-order sequence.
The principle extends beyond cameras. The two-station line uses ownership to prevent two controllers from each assuming that the other owns a transferred part.