PCBの改訂管理：試作版の変更が誤った量産ロットに反映されないようにする

2つ目のプロトタイプを作成する際の難しい点は、最初のプロトタイプ以降に何が変更されたのかを正確に把握することです。配線の修復、部品の交換、ファームウェアの回避策などは、それぞれ異なる箇所に存在する可能性があります。シンプルなリリースプロセスを採用することで、これらの発見を明確な次のビルドへと繋げることができます。.

それぞれの建築物に明確なアイデンティティを与える

読みやすい基板リビジョンを選択し、設計記録とリリースパッケージ名で一貫して使用してください。ハードウェアリビジョンは、ファームウェアバージョンおよびアセンブリバリアントとは別に管理してください。1枚の基板には複数の実装オプションがサポートされる可能性があるため、基板ラベルだけでは搭載されているすべての部品を説明できない場合があります。.

観察結果と承認された変更を分けて表示する

変更履歴には、確認された問題、提案された修正、および修正を受け入れる根拠となる証拠を記載してください。「コネクタの問題」では対応が困難です。「コネクタの向きが筐体の開口部と干渉する」であれば、次のレビュー担当者が具体的に確認すべき事項が明確になります。未解決の問題は、最終版のアーカイブに隠すのではなく、未解決として記録してください。.

ファイルセットをまとめてリリースする

変更が承認されたら、予定されている改訂版に基づいて製造および組立の出力を生成します。見積もりまたは製造のために送付したパッケージのコピーを保管してください。「final.zip」という名前のアーカイブの内容を繰り返し置き換えながら、ファイル名を変更しないことは避けてください。.

• 基板の改訂版および組み立て版。.
• 製造および組み立てファイル名。.
• 前回のビルドからの変更点の簡単なリストです。.
• 保持されている例外または未入力のコンポーネント。.
• 関連するファームウェアおよびテストドキュメントのバージョン。.

具体的な変更通知を使用する

例えば、リリースノートには「リビジョンBでは、コネクタJ2を筐体に合わせて移動します。アセンブリのバリエーションは変更ありません。新しい基板と配置のエクスポートを一緒に使用してください。」と記載されているかもしれません。これは「最新ファイルを添付しました」よりもずっと役立ちます。受信者に対して、以前の情報のうちどれが置き換えられ、どの決定事項が引き続き適用されるかを明確に伝えることができるからです。.

注文変更は別のリクエストとして処理してください。

新しいデザインリリースは、既に処理中の注文のファイルを自動的に置き換えるものではありません。注文番号、旧リビジョン、および提案する置き換え内容を添えて、DIYIPCBまでお問い合わせください。新しいパッケージが使用可能だと判断する前に、必ず確認を依頼してください。その回答はリリース記録と一緒に保管してください。.

次のビルド後にループを閉じる

テスト結果を、実際にテストしたリビジョンおよびアセンブリバリアントに紐付けてください。基板を手作業で変更した場合は、変更内容を記録してから、未変更のサンプルと比較してください。これにより、次回の設計レビューがより効率的になり、以前にベンチテストでのみ修正された問題が再発するのを防ぐことができます。.

これはオリジナルのDIYIPCBワークフローガイドです。リリース識別子と変更履歴の例はあくまで参考用です。有効な注文に対する変更は、必ずサポートチームにご確認ください。.