Link inspection records, images and part identifiers

Problem and prerequisites

Saving a folder of failed images does not establish traceability. A useful record links each part decision to its image status, recipe and acquisition generation, even when the image cannot be saved.

Prepare the test

Assume two 2000 × 1500 Mono8 cameras at 10 frames/s: 2 × 3 MB × 10 = 60 MB/s and 216 GB/hour of raw images. Retaining exactly 1% yields 2.16 GB/hour of image payload, but all frames still pass through acquisition and processing. Use decimal units.

Define why images are retained before sizing storage. Troubleshooting may require failure images and neighboring context, while a process audit may require a specified sample set and immutable event records. Record the project’s retention rule and who may place an investigation hold. Identify all cameras, actual formats, frame rates and whether saved files are raw, encoded or cropped. Use SDK-reported payload and measured saved-file sizes for the real budget; dimensions alone can omit padding or metadata. The example assumes ordinary Mono8 pixel data without those additions. Do not assume a compression ratio from the file extension. Measure representative difficult images and bursts, because storage demand changes when more rejects are selected than during normal operation.

Procedure

1. Create an event identifier before capture and record camera, part, recipe, calibration and generation.
2. Store the decision immediately with image status pending; transfer an owned image to a bounded writer queue.
3. After a successful image write, update its reference and saved status; record failures rather than inventing a path.
4. Set retention by event age and disposition; do not delete images still referenced by an investigation hold.
5. Simulate full disk, restart and interrupted writes; reconcile pending records and preserve the original inspection result.

Create the event record before asynchronous saving and copy or retain each image under documented buffer rules. A writer must not access a driver buffer that has already returned to acquisition. Bound the writer queue and log its depth, oldest pending age and terminal save result. Associate camera identity and acquisition generation with the event so that multiple images cannot be attached to the wrong part. Write to an identified temporary object, finish the write using the storage method’s documented semantics, then publish the completed location or integrity reference. Keep a failed or pending save distinct from the inspection decision. Decide the containment response when mandatory evidence cannot be saved before production release.

Illustrative test record

Illustrative assumptions, not measured Deyi performance. Replace these values with your own signed test records.

Use decimal MB and GB in this example: each raw frame is 3,000,000 bytes and twenty frames per second produce 60,000,000 bytes/s. Retaining exactly 1% gives 2.16 GB/h only if that selection is actually achieved; a burst of rejects can exceed it. Measure the writer queue at peak reject load, reserve investigation holds outside routine deletion and distinguish image-save failure from the part’s inspection decision.

Separate three rates in the capacity worksheet: camera acquisition, selected image traffic and sustained storage writing. Selecting 1% after acquisition does not reduce the full image stream from the cameras or the memory needed to inspect it. Add event records, configuration snapshots, filesystem overhead and reserve space to the saved-image estimate. Track backlog during peak reject conditions instead of extrapolating from an average read rate. Express capacity and retention duration using the same decimal or binary units. Account for investigation holds that are exempt from routine deletion. A disk showing enough free space at startup can still exhaust capacity if deletion is blocked, rejects increase or the writer becomes slower than incoming selected images.

Two views of the workflow

Troubleshooting

• A decoded value alone is not a unique key when batch codes repeat.
• A slow writer must not expand memory indefinitely or block the station without an explicit policy.
• A record claiming an image exists must be checked against the actual readable file.

Acceptance and handover

Verify lookup from part to decision and from decision to image or explicit save fault. Measure sustained write speed and capacity with real formats. The 216 GB/hour example excludes metadata, filesystem overhead and reserve; compression savings are not assumed.

Set acceptance limits before testing and retain the original evidence. The examples here do not establish a supplied model’s capabilities.

Validate disk-full, writer interruption, restart and investigation-hold behavior with controlled test data. Confirm that every planned event ends with a visible save status and that completed files correspond to the recorded event and camera. Verify recovery without attaching an earlier pending image to a new part. Exercise the normal deletion rule and confirm that protected investigation records remain retrievable. Measure sustained writing and peak queue size with the actual format and selection policy before setting the capacity alarm. Handover includes assumptions, measured file-size range, raw-versus-selected rates, queue policy, retention ownership and failure disposition. The example’s 216 GB/h and 2.16 GB/h are arithmetic for stated assumptions, not measured compression, recommended retention duration or a performance guarantee for a particular storage product.

Related reading

Read the related selection and application guides before choosing equipment. For an engineering review, provide sample images, the required result, operating conditions and the completed test record.