PLCと上位機の通信喪失の詳細に関する議論
Thread Content
一般的なPLCのスキャン時間は非常に短く、ほとんどがms単位です（通常は10～100ms）。一方、上位機のデータ収集時間は一般的にs単位です（通常は0.5秒または1秒）。では、スイッチが20ms間オンの状態になると、上位機がその信号を取得できなくなるのでしょうか。しかし、PLCは既に対応するロジックを実行しましたか？
この投稿は最後にbudaoweng123によって2015-9-30 14:22に編集されました。ふふ、もし収集できたとしても、何の意味があるのでしょうか？論理が機能すればいいのだ。
この説明は間違っていますよ。通信である以上、DCSに関しても単にこの問題だけではありません。例えば485通信やMODBUSプロトコル、ボーレートなどを適切に設定すれば、PLCとDCSの品質や性能が良好であれば、データの損失という問題はほとんど起こりません。投稿者が言っているPLCのデータ収集のミリ秒単位というのは、通信とは必ずしも関連しないんですよね。また、スイッチ信号が20ミリ秒間オンの状態になると、DCSはそれをスイッチの誤動作と判断することが多い。でなければ、DCSはなぜわざわざ遅延処理を行うのだろうか？
私が言っているのはPLC+HMIで、DCSではありません。以前、あるポイントを素早くオンオフさせる実験を行ったのですが、HMI上にはすべてのオンオフが記録されませんでした。
このような状況では、現場で実際に動作が起こるものの、上位機のアラームは作動せず、しかし1秒か数秒後に上位機で正常なフィードバックが表示されるようだ~~
正常に動くかはわからない。とにかく、私がその時実験していたとき、素早い動作をした回数と最終的にアラームが鳴った回数が一致しなかったのです。 また、実際の駐車時にもこの問題が現れました。ある機械が理由もなく停止した際、最終的に急停止ボタンが緩んでいたことが原因であることが判明しましたが、タッチスクリーン上にはその警報が表示されませんでした。
ですから、これもPLCの欠点の一つと言え、そのアラームはHMI層で検出されてトリガーされるのです；一方、DCSはCPUレベルでトリガーを検出します。
安全性の要求が低いシステムには一般的な上位機ソフトウェアを、要求が高いものには海外の大手メーカー製の上位機ソフトウェアを使用し、より高度な圧縮機ユニットにはPLCと上位機のセットを使用する。これもプログラミングのレベルに関係しており、ソフトウェアではMS級のアラーム記録が実現できない場合は、PLCに遅延出力を追加することができます。。。
このようなアラーム信号には、RS保持とリセットがあるべきですよね？RS保持があれば、HMIは必ず反映される
このような状況は以前にもありました。外部のスイッチ信号が瞬時に動作し、PLCのロジック動作は確認できます（エンジニアリングファイルをオフラインで確認する場合）、しかし操作アラーム画面には関連するアラームが表示されません。
すべてのインターロックをトリガーするフラグビットは、必ず保持信号でなければなりません :)