はじめに
かなり頻繁に文献で私はエラーの説明に出くわし、タイプ別にエラーを分類しました。
認めざるを得ないが、特定のエラーがどのタイプに属しているかを知るのに役立つ単一のケースを思い出すことはできない。 他の人に説明する理由を明確にした後を除きます。
しかし、人々がどのように場所を計算し、エラーの底に到達したかは、私にとって常に興味深いものでした。
システム情報とエラー
デバイスへの設定（時間、モードフラグ）およびコマンドは、コンピューターからPLCに送信されます。
デバイスのステータスと、このデバイスのコマンドの終了までの時間の信号が、PLCからコンピューターに発行されます。 受信と送信の量を最小限にするために、信号はワードにパックされます。
コマンドは、PLCからデバイスに発行されます。
デバイスは、そのステータスをPLCに発行します。
当初はすべてが機能していましたが、コマンドを与えるとしばらくすると、SCADAのコンピューターのステータスが点滅し始め、一般的に非常に不親切になります。 そして、1つの場所で、1つのオブジェクトでのみ。
しかし、各チームで「セイバーダンス」が安定して登場し、とても楽しかったです。
検索する
カッコ内の数字は、下図の数字に対応するチェックの場所を示しています。
まばたきの原理と依存関係はすぐには理解されません。 おそらく疲労のため、おそらくその不足のため。
エラーはSCADA （1） （実際に検出された場所）だけでなく、OPCサーバー（2）にも存在することがわかりました。
さらなる分析により、少なくともコンピューター用に作成された単語にはエラーがPLCにも存在することが示されました（3） 。
デバイスからのステータスのエラーを確認します-問題の原因としてデバイスをマークします。
デバイスから手動でステータスを変更しても、何も変わりません。 強制的に（常に、強制的に）デバイスのステータスを変更しても、エラーは保存されます。
したがって、これらはモニタリング中に見えない衝動ではありません（4） 。
このエラーが存在しない他のオブジェクトのコードと比較しても、違いは生じません。 完全なアイデンティティ。 PLCプログラムのエラーの可能性が減少します（5） 。
エラーの原因としてコンピュータはシャットダウンし、このメモリ領域に何かを記録します。 エラーが保存されます。 コンピューターによるエラーの確率はゼロになる傾向があります。 したがって、どのような場合でも、問題はまだPLCにあります（6） 。
注：PLCを無効にして、OPCのステータスを手動で変更することもできました。 しかし、このオプションは技術的に難しく、一般に、これら2つのチェックはほぼ同等です。
PLCからコンピュータに転送されたステータスワードをPLCメモリの別の領域に転送しても何も起こりません。 エラーが保存されます。
エラーのあるコードを別のブロック（条件付きで関数）に転送しても、エラーには影響しません。 したがって、他の外部のチームが独自の何かをそこに書くことにより、これが影響を受ける可能性は無視できます。 ポイントはこの作品です。
コードは徐々に削除され、エラーが保存される最小値がほぼ残っています（7）
- コマンドの送信（それなしでは、確認方法は明確ではありません）。
- コマンドがリセットされる前に時間が取られるタイマー。
- コマンドをリセットするためのステータスと時間からのコンピューター上の単語の形成。
タイマーが削除されます。 コマンドはリセットされませんが、エラーは消え、ステータスはジャンプしなくなります。
代わりに、新しいタイマーが挿入されます。 不条理を注意深く検査します。 タイマーは最も普通のもので、異常なものはありません。 プログラムにはさらに200個ありますが、エラーが表示されます（8）
PLCからの信号の形成は、エラーソースの最も可能性の高い候補と見なされます。 信号はコンパクト化のために1ワードでパックされ、ステータスビットは上位バイトで、時間は下位バイトです。 3つのチーム：
- ワードの下位バイトへのデバイスステータスの書き込み。
- 上位バイトと下位バイトをSWAP_WORDコマンドの場所に置き換える（ステータスは上位バイトに転送されます）
- ANDによって、単語の最下位バイトに時間を書き込みます
それは珍しいことではないようで、完全に同一のシステムは、数十の同一のデバイスで動作します。 脳はきしみ、助けを拒否します。
単語ごとのパッキング命令のシーケンスは、同じように機能するが、他の演算子で構成されるものに置き換えられます（9）：
- ワードの最下位バイトへのデバイス時間の書き込み。
- 中間変数では、ステータスが256倍され、ワードの上位バイトにシフトします。
- ORにより、ステータスはワードの上位バイトに記録されます。
すべてがうまくいきました。
分析後-状況は完全に明らかになります。
エラーの理由：
オペレーターは、標準のタイムアウト時間を1.5分から10分に増やしました。
1.5分が90秒の場合、10分は600秒です。
600秒は下位バイト（最大256）に収まらず、一部の時刻は上位バイトに書き込まれました。
最後のチェックの本質：
最初に時間を記録し、次にステータスを記録するとき-ステータスは時間値からのオーバーフロービットによって記録されました。 そして、コマンドの逆シーケンスでは、時間とは逆に、ビットでステータスを記録しました。
解決策：
時間とステータスは2つの単語に分けられました。 現地のエンジニアは、メンテナンスを実行するか、標準時間を5回以上超えるタイムアウトでデバイスを交換するように求められました。
結論
記載されているエラーは特に複雑ではありませんが、私の意見では、指示の点ではかなりいいです。
実際、正確にエラーを探す場所はそれほど重要ではありません-電子機器、PLC、コンピューター、その他の場所です。 一般原則は常にほぼ同じです：
- 最大限、問題に関する情報を収集します-どこでどのように表示されます。 オシロスコープ、スニファー、Rusinovichのユーティリティ、ログ、温度計、一般に、この場合に使用できるすべてのもの。 それは、時期、掃除婦の到着、または気圧に依存しますか。
- 可能な限り疑いから脱出してください。 プリント基板上のトラックを切断し、タグを無効にし、システムから個々のコンピューターを削除します。 フィードバックやその他の握手がある場合はさらに悪い。 次に、システムの一部の不足を考慮してテストを整理するか、フィードバック入力に人為的に信号を供給するなど、一部をエミュレートしてみます。 一般的に考えてください。
- 可能であれば、突然「思考！」が表示されても、各テストを終了します。 「思考」は機能しない可能性があります（多くの場合、攻撃的に機能しない）が、チェックの結果は失われます。
- 残りの部分では-疑念を引き起こすすべてを変更します。 このソフトウェアの場合-再インストールするか、類似のソフトウェアと交換してください。 原則として、この時点から開始するオプションがあります。 私は個人的に、エンジニアがK155シリーズの40〜50チップでボードを修理し、それらすべてを噛み、新しいものをはんだ付けするのを見ました。 しかし、これは、私の意見では、むしろそれをしない方法の例です。 たとえすべてが機能していても、詳細は得られないからです。 さらに、記載されているケースでは、このオプションはパスせず、誤動作が続きました。 一般的に-私はそれを言わなかった。
もちろん、ある状況のレシピは他の状況に比べてまったく役に立たない場合があります。
しかし、すべてのエラーには特定の理由があり、この理由はいつでも明確にすることができます。
たとえば、ケーブルの上を運転するハローを持つトラクターの運転手が何らかの理由でした。 そして、それを排除するのに困難はありませんでしたが、繰り返しを避けるための推奨事項を書くプロセスでは十分でした...
読みにくいと思われることをおizeびします。
このトピックはあまり芸術的ではありません。さらに、PLCでのプログラムの周期的な実行とタイマーの存在により、BreakPointsの強制放棄など、あまり重要ではないポイントをスキップすることで、このトピックを減らしました。