検査記録、画像、部品識別子を関連付けて保存する

課題と前提条件

NG画像のフォルダーだけでは追跡は成立しません。各部品の判定を画像保存状態、レシピ、取得世代に結び、画像を保存できない場合も記録を残します。

試験の準備

仮に2000×1500のMono8カメラ二台、10枚/sなら2×3MB×10 = 60MB/s、非圧縮で216GB/時です。厳密に1%保存なら2.16GB/時ですが、取得・処理は全画像を扱います。単位は十進です。

容量計算前に保存目的を決めます。原因調査には失敗画像と周辺状況、工程監査には指定サンプルと不変イベントが必要になる場合があります。保存規則と調査保留責任を記録します。全カメラ、実形式、速度、原・符号化・切出し画像を確認します。実予算はSDKのペイロードと保存ファイル実測を使います。寸法だけでは余白やメタデータを省きます。例のMono8は追加分を含みません。拡張子から圧縮率を仮定せず、難画像と不良集中を測ります。

作業手順

1. 撮像前にイベント識別子を作り、カメラ、部品、レシピ、校正、世代を記録します。
2. 判定を画像保存待ち状態で記録し、所有する画像を有限の保存待ち行列へ渡します。
3. 書込み成功後だけ画像参照と保存済みに更新し、失敗は異常として記録します。
4. 保存期限を経過時間と処置で定め、調査保持中の画像は削除しません。
5. 容量不足、再始動、途中書込みを試し、待ち状態を照合して元判定を保持します。

非同期保存前にイベントを作り、規定所有で画像をコピーまたは保持します。返却済みドライバーバッファを書込側で参照しません。キュー上限、深さ、最古待機時間、最終状態を記録します。カメラ識別と世代で複数画像を正しい部品へ付けます。識別した一時対象へ書き、保存方式の完了規定に従ってから場所や整合性参照を公開します。保存失敗・待機と検査判定を分け、必須証拠が解放前に保存できない時の保留を決めます。

仮定に基づく試験記録

以下は説明用の仮定であり、Deyiの実測結果ではありません。実際に承認した試験記録に置き換えてください。

本例では十進のMBとGBを使い、原画像一枚は3,000,000バイト、毎秒二十枚で60,000,000バイト/秒です。保存割合が実際にちょうど1%になった場合だけ2.16 GB/時となり、不良が集中すれば超えることがあります。不良集中時の書込キューを測り、調査保留データを通常削除から保護します。画像保存失敗と部品の検査判定は分けてください。

取得、選択画像、継続書込の三速度を分けます。取得後1%選択でもカメラの全転送や検査メモリは減りません。イベント、設定、ファイルシステム、予備を保存見積に足します。平均ではなく不良集中で滞留を見ます。容量と期間は同じ十進または二進単位で表します。通常削除しない調査保留も考えます。起動時の空きが十分でも、削除停止、不良増加、書込低下で尽きます。

工程を示す二つの図

トラブルの切り分け

• 重複するロット文字列だけを一意キーにしません。
• 遅い保存でメモリが無制限に増えない方針を定めます。
• 保存済み画像は実ファイルの可読性を確認します。

受入確認と引き継ぎ

部品から判定、画像または保存異常を検索できることを確認します。実形式で速度と容量を測り、216GB/時にメタデータ、ファイル管理、余裕は含まれないと明記します。

試験前に受入基準を定め、元の証拠を保存してください。本例は供給対象モデルの機能を保証するものではありません。

管理データで容量不足、書込中断、再起動、調査保護を検証します。全予定イベントに見える最終状態があり、ファイルが記録したカメラと一致することを確認します。復旧で旧待機画像を新部品に付けません。通常削除と保護記録の取得を試します。実形式と選択で継続性能・最大キューを測って警報を決めます。仮定、サイズ範囲、原・選択速度、キュー、責任、異常処置を渡します。216と2.16 GB/時は仮定計算で、実圧縮、推奨期間、製品保証ではありません。

関連資料

機器を選定する前に、関連する選定・用途別ガイドを参照してください。技術検討には、サンプル画像、必要な判定、運転条件、試験記録を用意してください。