Pass and fail records
Store the inspection decision, timestamp, active recipe and relevant measured values.
Turn a pass/fail decision into useful production evidence by defining what is recorded, how products are identified and where inspection data must go.
Application-led design Proved against the real product, defect and production conditions.A specified system can record time, recipe, product identifier, inspection result, measured values, decoded text or codes, reject event and selected images. Useful traceability starts with a clear data model and product identity; simply saving every camera image does not establish a reliable production record.
Each requirement is tested against representative products, normal variation, line speed and the agreed production response.
Store the inspection decision, timestamp, active recipe and relevant measured values.
Retain failed, sampled or all images according to storage capacity, risk and the agreed retention policy.
Associate OCR, barcode, Data Matrix, serial or batch data with the inspected product where reliable tracking is available.
Record the inspection result and the confirmed line response as separate events when the control strategy requires it.
Expose counts, defect classes, measurements and reject trends so teams can investigate drift and recurring faults.
Exchange agreed recipes, identifiers, results or alarms with compatible PLC, SCADA, MES or database systems.
The system needs a dependable way to associate an inspection with the intended product, batch or serial number through the line.
Image rate, resolution and retention period drive storage, network and backup requirements; retaining everything is not always useful.
User access, recipe changes, time synchronisation, backups, review responsibilities and interface recovery must be part of the operational design.
The useful result is a repeatable decision that operators can understand and the production line can act on.
Agree what production, quality and engineering teams need the record to answer.
Document triggers, codes, product tracking, inspection and reject-confirmation points.
Set result fields, image policy, retention, users, network routes and recovery behaviour.
Challenge lost communications, recipe changes, rework, clock synchronisation and reject events.
Traceability depends on identity and sequence. The record must show which product was inspected, which recipe and limits were active, what result was produced and what happened next. Image storage is valuable evidence, but only when it is linked to the right event and can be found when needed.
Yes. Failed-image retention is common, subject to the selected platform, image size, production rate, storage capacity and agreed retention period.
Yes, when the identifier is read reliably and product tracking preserves the association from identification through inspection and rejection.
Often, through an agreed industrial or database interface. The exact data fields, protocol, ownership, security and behaviour during lost communications must be defined with the site controls team.
Not necessarily. All-image storage can create large data volumes without improving decisions. Failed images, statistical samples and measured result data may provide a better balance, depending on risk and review needs.
No. The vision result and physical reject confirmation are separate events. A higher-assurance design tracks the intended product to rejection and monitors the reject mechanism and collection route.
Send samples, images, line-speed information and the defects you need to detect. We’ll recommend the right next step.