Defect Detection: From a Camera Image to a Reliable Production Decision

Watch the on-demand resource

The official Cognex page identifies this resource as an on-demand webinar. It is a recording, not an upcoming live event. Follow the original link for access and any current provider requirements. We have not assigned a broadcast date, presenter, duration, price or registration deadline that the landing page does not establish.

1. Agree on the quality decision before choosing the camera

Start with the defect that matters to the process. A scratch, a missing feature and an incorrect assembly are different inspection problems. Define what is acceptable, what must be rejected and what requires a person to review the result. Use representative physical samples and agreed reference images so production, quality and controls teams share the same decision boundary.

Include normal variation in the discussion: material finish, harmless marks, orientation, supplier lots and expected changes between products. A small selection of unusually clean samples can make a demonstration look better than the future operating conditions. Record the consequences of false acceptance and false rejection separately; a single headline accuracy number can hide a commercially important weakness.

2. Make the image repeatable before making the algorithm sophisticated

Define the viewing geometry, inspection area, smallest relevant feature, working distance and part presentation. Evaluate how reflections, shadows, movement and ambient light affect visibility. Where a defect is not consistently visible in the image, changing software alone is unlikely to establish a dependable inspection method. Lighting, optics and mechanical stability belong in the scope and budget.

Consider whether the important feature is a surface appearance, an edge deviation or a height-related condition. As one concrete example, Cognex's documented Edge Defect Detection Tool evaluates deviations from a fitted line or circle; its reported measurement units depend on image calibration. This illustrates why the tool and measurement assumptions must match the requirement. It is not a specification for every Cognex camera or software release.

3. Choose the inspection approach through evidence

Compare candidate methods against the actual sample set rather than selecting a product because it carries an AI label. Ask what the method detects, what examples it needs, which operating variations are allowed and how an engineer can explain a failed result. A stable geometric check and a highly variable appearance problem may need different approaches or a combination of methods.

Separate samples used for configuration or training from those reserved for acceptance testing. Keep the origin and labels of the test set traceable. Include difficult borderline examples and challenge the proposed setup under expected operating conditions. Agree on acceptance criteria with the customer before tuning; otherwise the team risks repeatedly adjusting the system until it fits only the examples already seen.

4. Design the PLC handshake and the physical reject path

An inspection result needs context. Define how the PLC triggers inspection, identifies the part or cycle, receives a completed result and acknowledges it. Specify result validity, communication-loss behaviour and timeouts. A previous good result must not be reused for a new part, and a missing or late result must not silently become a pass.

The exact handshake depends on the equipment and protocol; confirm it against the selected manufacturer's documentation. Quality inspection logic is not automatically a personnel-safety function. Changes to machine behaviour, guarding or safety-related controls require the appropriate risk review and authorized implementation.

• Distinguish ready, busy, inspection complete, result valid and fault states where supported by the selected equipment.
• Associate the decision with the correct part through transport delays, buffering and restart conditions.
• Verify the reject action and the applicable feedback, not only the command from the PLC.
• Define the approved hold, stop or segregation response when inspection or rejection cannot be confirmed.

5. Test production conditions and recovery, not just good and bad samples

Build an acceptance plan covering the agreed defect classes, normal product variation, expected line speeds and relevant environmental conditions. Observe the full sequence from trigger to final disposition. Deliberately test permitted fault scenarios such as a missing trigger, delayed result, interrupted communications and a controlled restart. Document what happened and whether it matches the approved response.

Keep the result categories distinct: a correct rejection, an incorrect rejection, a missed defect and an uninspected part are not interchangeable. Report the sample count and conditions with any performance result. Do not turn a limited factory trial into a universal accuracy or return-on-investment claim. Site acceptance should confirm the installed system against the customer's agreed criteria.

6. Decide what evidence must survive the inspection

Agree with quality and IT on the required record: time, part or batch reference, inspection recipe or revision, result, fault state and any retained image. Define retention, access, backup and retrieval responsibilities. Saving a file is only one step; the team must be able to find the relevant record and understand which configuration produced it.

Not every application needs a full SCADA platform, and not every application can be adequately served by an uncontrolled spreadsheet. Select the recording approach from the customer's operational, audit and retention requirements. Include a restore test and a practical retrieval demonstration in the handover where records are part of acceptance.

Turn the webinar into a focused project discussion

Our suggested next step is a short requirements review supported by sample parts, images, cycle information and the current controls architecture. The output should be a defined inspection boundary, unresolved feasibility questions, an acceptance outline and a budget basis. That makes a supplier demonstration more useful and prevents camera selection from getting ahead of the production requirement.

At AranVision, the emphasis is the complete controls workflow: clear requirements, dependable sequencing, usable diagnostics and documented handover. Bring the production and quality owners into the conversation early, and involve IT when results will leave the machine. Any proposed changes remain subject to site authorization and application-specific verification.