時々バグですが、優先度が高い

私は、レーザーの助けを借りて形状を金属にカットするCNC（コンピューター数値制御）プロジェクトに取り組んでいます。

現在、私の問題はたまに（20日間で1〜2回）カットがうまくいかないか、設定された内容に従っていないことです。

しかし、これは損失を引き起こすため、クライアントはそれについてあまり満足していません。

私はその原因を見つけようとしました

1. ログファイルを含める
2. デバッグ
3. 同じ環境を繰り返します。

しかし、それは繰り返されません。

一時停止して続行操作を行うと、再びバグが再現することなくスムーズに実行されます。

この問題にどのように取り組むのですか？ハードウェアの問題として述べる必要がありますか？

回避策

以下のようChrisFは示唆して、実用的な短期的な解決策を使用することであり、一時停止と再開のトリックを、しかし、あなたはあなたの優先順位はどうあるべきかを知るためにあなたの顧客に話をする必要があります。例えば：

• 障害により£1000の部品が廃棄されるか、週に1回4時間のダウンタイムが発生し、一時停止再開修正により生産が1％減少する場合、おそらく今すぐ修正を好むでしょう。

• 障害により1ポンドの部品が廃棄されるか、週に1回4分のダウンタイムが発生するが、一時停止と再開の修正により生産が1％減少する場合、おそらく生産率に影響しない修正を待つことを好みます。

レーザーマイクロマシニング業界で長年働いてきたので、プロセスを最適化し、機械で可能な限り1時間あたりの部品を生産するためにどれだけの圧力をかけるかを知っています。問題を適切に修正する圧力。

ロギング

私の経験では、ハイゼンバグを効果的に追跡する唯一の方法は、大量のロギングです。エラーの原因となっている可能性のあるコードの部分とその周辺のすべてを記録します。ログファイルを効果的に読み取る方法を学び、モーターの次のエラーを監視していることを確認します（ステージは必要なときに必要な場所に移動していますか？）。マシンのメモリ使用量を確認してください。メモリリークが原因で重要なプロセスが枯渇していますか？

ユーザーのアクションも記録していることを確認してください。オペレーターが緊急停止に当たっていないので、修正中にシガレットのたばこの休憩のために飛び出すことができますか？私はこれが起こるのを見ました！

静的解析

また、特定のパターンのスクライビングと、多かれ少なかれ引き起こされるバグとの相関関係を探します。問題をより頻繁にトリガーする（またはトリガーしない）パターンを見つけることができる場合、これらは問題を指している可能性があります。

問題をより頻繁に引き起こすパターンを作成してみてください。問題を確実にトリガーする方法を見つけることができれば、解決策の半分になります。

他のオプション

最後に、ハードウェアをすぐに非難しないでください。しかし、それが完璧だと思い込まないでください。多くの場合、私は本質的に電気的または機械的であることが判明した問題を非難してきたので、あなたは常にそれを心の奥に持っていなければなりません。

通常はマシンにアクセスできない場合でも、一部の問題はマシンでのみ効率的に解決できることに注意してください。場合によっては、オンサイトで数日間はリモートデスクトップ経由で数週間、オフラインでは数か月の価値があります。オフラインのオプションを使い果たした場合、サイト訪問を提案することを恐れないでください。彼らはノーとしか言えません。

また、ヘイゼンバグで何をしますか？の質問と回答もご覧ください。と再現しないバグをどうするか？しかし、これらはあなたの状況にとってそれほど有用ではないかもしれません。

私は壁から外れた提案をするつもりです。

工場のマネージャーに行き、誤動作が発生した時間について、そのツールまたはそのエリアの電力線モニターの記録を確認するよう依頼します。また、その頃に溶接や他の異常な活動があったかどうかも尋ねます。

数十年前、私の父はまったく理由もなくクラッシュしていたミニコンピューターで、地獄に落ちていました。彼らはメーカーの顧客担当者に電話をかけました。

担当者は工場エリアのオフィスに来て、電圧計をミニの隣の壁に差し込み、「これを見て」と言いました。

数分後、電圧計は突然大幅に低下し、その後戻ってきました。担当者は、「それは彼が彼のテストアークを打つことでした。ちょっと待ってください。」と言いました。その後まもなく、電圧計は再びたるみ、そして今回はたるんだままでした。

担当者は、「それがあなたの問題です。あなたは工場の床で溶接している男がいます。彼はあなたと同じパワーレッグにいます。私が歩いているときに彼がセットアップしているのを見ました。」

彼らはオフィスへの完全に独立した給電を実行する必要がありました。

問題は、ユーザーにとって実際の結果を伴う実際の問題です。つまり、台無しになった作業などであるため、修正が必要です。ただし、「適切に」修正する必要はありません。あなたの状態：

一時停止して続行操作を行うと、バグが再現されて再びスムーズに実行されます。

その場合は、これを行うだけです。お客様は、通常の実行に数秒かかる場合でも、欠陥のある実行で材料を無駄にしないことを喜んでいます。

明らかに、長期的には「適切に」これを修正する必要があるかもしれませんが、当分の間、損失を削減するために、回避策を取り、何か他のものに取り掛かります。

私は、10億に1回しか発生しなかったゲームにバグがありました。幸いなことに、これは15〜30分ごとに表示されることを意味していましたが、debugggerのコードをステップ実行しても機能しませんでした。デバッグメッセージを入れてしまった。問題が発生したときだけ何かが欲しかったので、彼らは派手なif文を使用する必要がありました。ほとんどの場合、デバッグコードは通常のコードで計算を繰り返していましたが、異なる手法を使用していました。繰り返しは正確である必要はありませんでした。数値が常に10,000未満であることがわかっていて、150,000に達することがあるようであれば、100,000を超える値をチェックするだけです。バグが発生するたびに、結果を調査し、より詳細なデバッグメッセージ（より正確には、メッセージを表示するかどうかを確認するためのより詳細なチェック）を考案し、問題が再び発生するのを待ちます。

あなたのサイクルは私のサイクルよりもずっと長くなりますが、最終的には問題に迫ります。他のより高速な方法で解決策を見つけることができることを願っていますが、他に何もしなければ最終的にそれをキャッチし、より良いアイデアを思い付くまであなたが何かをしているという感覚を与えます。

（役に立つ場合は、問題として最終的に特定した数行のコードをクリーンアップすることで、問題を解決しました。問題は何もないと誓いますが、オプティマイザーとCPUの両方が命令を並べ替えていたと思いますパフォーマンスが向上し、たまに少し速度を上げるチャンスが得られると思います。最近ではシングルコアでもマルチプロセスを実行しています。私は、「インスタンスフィールド」の値が右の開始時にローカル変数に移動されました。ローカル変数で動作するようにすべての計算を切り替えて、ローカル値は、同期ブロック内で、バックだけで非常に最後に移動されました。そして、私は使用ローカルの値を「インスタンスフィールド」ではなくメソッドの戻り値私は使っていました。）

デバッグにおけるルール1ナンバーワン：再現可能なシナリオが必要です。

持っていない場合は、最初に作業する必要があります。実際に金属が切断されていない、ある種の「シミュレーションモード」でそのバグを再現できますか？これはここで理にかなっているようです。数分で20日間のプロセスをシミュレートして、いくつかの異なる切断プログラムを迅速かつ自動的に実行できますか？これにより、問題が発生する可能性が高くなります。

次に、このようなシナリオが発生した場合、次のステップはできるだけ多くの情報を収集し、実際にデバッグを開始することです。

これがどの言語で実行されているかはわかりませんが、コード（C ++）で不安定なバグが発生した場合は、valgrindやcppcheckなどのツールを使用して、メモリ単位で何も実行されないようにします。

RalphChapinの答えの拡張：

長年にわたって、ハードウェアが接続されているため複製できなかったシステムでしか見られなかったかなりの数のバグを捜さなければなりませんでした。

気が狂ったようにログを記録することに加えて、コードがどこにあるかを示す情報を画面に表示し、関連する変数の値を表示することも有用でした。問題が発生すると、工場の作業員でさえ情報を読むことができました。

通常、正確に特定するには数ラウンドの改良が必要でしたが、非常に効果的でした。