A reject lands late on the conveyor at 03:47, the operator escalates, and the shift ends with three different theories — the model is wrong, the PLC is slow, or the buffer is drifting. Before changing the line rule, prove which clock is actually off. iFactory AI overlays your MES, QMS, historian, and vision stack with a timing-contract layer that preserves every timestamp — trigger, capture, inference, publish, PLC receive, actuator, physical reject arrival — so late verdicts get diagnosed with evidence, not intuition. Book a 30-minute walkthrough of one reject event end to end.
A reject that lands late is not automatically a bad inspection. It may be a timing contract problem hiding across six timestamps.
At a Glance
Why Seconds Change the Loss Bucket
In OEE, a few seconds can shift a stop across a shift boundary, reclassify a micro-stop as downtime, or move an event into a different reason bucket. The PLC may see the physical state change first, the MES may receive the stop after buffering, and the historian may record the tag transition on its own ingest cycle. If each system is treated as an independent source of truth, disagreement replaces traceability. The answer is not to hope the clocks match. The answer is to define an event contract that says what each system owns and how to reconcile small differences.
For a controls engineer, that distinction matters more than the tools. Time alignment is necessary but event agreement is what makes the record defensible. In edge vision inspection, the plant rarely sees just a defect — it sees a chain of events that can drift apart. The photoeye triggers, the camera captures, the model classifies, the verdict is published, the PLC scans, the reject fires, and the part physically leaves the line. When any of those steps drifts, the reject can land late without the model being wrong.
Where Latency Accumulates
Edge vision latency is not one number. It is a stack. Each layer adds a small delay that becomes an operational problem only when the chain crosses the line-speed budget.
Trigger may be immediate, but exposure time, shutter behavior, or trigger alignment can shift the effective capture moment.
Inference time depends on model, edge hardware, and preprocessing. Line-speed changes make the same compute acceptable or unacceptable.
A few buffered frames may be harmless at low speed and disastrous during acceleration or product changeover. Buffer depth must be known, not assumed.
Publishing the verdict to PLC, MES, or historian can add delay, especially if messages are retried or the system is not event-aligned.
A PLC does not respond continuously — it scans. If the verdict arrives just after a scan window, the reject waits until the next cycle.
The solenoid, air blast, or diverter needs time to move. That delay must be measured and mapped to conveyor distance.
The part keeps moving. If line speed changes, the same reject command lands at a different physical position.
What iFactory Delivers
iFactory reads the timestamps your vision, PLC and MES already produce and turns one late reject into a timing story your controls team can act on.
Trigger, capture, inference, publish, PLC receive and reject laid out on one timeline per event.
Which segment of the chain grew when a reject arrived late, in plain language.
Where latency shows up as rejects, rework or speed loss in your OEE record.
Ask how long inference took this hour and hear it from the headset or tablet.
Runs at your facility on NVIDIA-based systems sized with you, near the lines.
Before-and-after timing comparison once your controls team makes an adjustment.
Bring one line and one late-reject example. We walk through trigger, capture, inference, publish, PLC receive, actuator, and physical arrival — all beside your existing MES.
The Timing Contract That Keeps OEE Honest
A timing contract defines the relationship between line speed, inspect-to-reject distance, maximum allowable latency, and fallback behavior. Without one, OEE events can become misleading — the line may continue to count good parts while a delayed reject is in flight, so the plant records the wrong scrap lot or misses a containment boundary.
- What is the maximum line speed for this inspection setup?
- How far is the camera from the reject point?
- What is the maximum total latency from trigger to actuation?
- How much queue depth is acceptable?
- What happens when latency exceeds the threshold?
- Which parts become suspect if the decision arrives late?
Validate Before You Change the PLC Rule
The right workflow is evidence-first. Measure trigger and capture on a known part, record inference completion and publish time, compare PLC receive against scan cycle boundaries, and verify actual reject arrival at the physical release point. This separates physics from software timing and prevents unnecessary rule changes when the problem is really buffering, line-speed drift, or scan alignment.
Frequently Asked Questions
It depends on the business rule. OEE should use the timestamp that matches the definition of the event, but the system should preserve the full chain so you can audit the decision.
Compare inference completion, publish time, PLC receive time, and PLC scan boundaries. If the decision arrives before the scan but the reject still lands late, actuation or conveyor timing is likely involved.
There is no universal answer. The buffer must be evaluated against line speed, part spacing, inspect-to-reject distance, and the maximum allowed end-to-end latency.
Mark the time window and genealogy range as suspect, hold the affected product in MES or QMS, and review the event timeline before release.
Yes. An overlay can align events, write validated quality records, and flag containment needs while leaving PLC control intact.
Late rejects are not just a model problem — they are a timestamp problem, a timing-contract problem, and a governance problem. iFactory AI aligns every event so the OEE record and the containment boundary reflect what actually happened.
.png)
.png)
