デバイスプログラムとの一括処理の違いについて

構造体型ラベルと機器毎のコントローラFBを使用すると、いままでアドレスの連続性を利用してZRST命令の1文で済んでいたアラームリセットやデバイスの桁指定を使用したアラーム発報判定が1文では済まなくなる場合が生じます。

アラーム処理やアラームリセット受付を機器毎のコントローラFBで行うか、アラームについては別処理で行うかというプログラム設計の部分で違ってきますが、保護動作もコントローラFBで行った方がシンプルかと考えます。

そうなると、

これらは、ST言語でループ処理を使用して1点1点の処理を記述するということになります。

記述自体はコピペなどを使用し簡単に行えるのですが、1文で済んでいたものとは比較にならないステップを費やす事になります。
分野によってはこれが受け入れられないかもしれませんが、私の場合は問題ありませんでした。

アラーム点数カウントの例

ビットをBOOL_TO_INTで数値に変換して加算しました。
これをループなどを使用して行いました。

ローカルラベルで重故障の設定を行います。

アラームビットと重故障設定ビットのANDを取り重故障発報点数に加算しました。

アラーム点数と重故障点数の差分を取れば軽故障点数となります。

各コントローラFBにアラームリセットスイッチ入力を設けた場合の例です。
アラームリセットスイッチは構造体として他のビット設定とまとめてコントローラFBへ入力される形になっているのでこのような処理が必要となっています。

タッチパネルの一括異常リセットスイッチを押すと「G_b_異常リセットボタン」をモーメンタリでON-OFFします。

押した瞬間にb_flagをTRUE、離した瞬間にb_flagをfalseで異常一括リセットスイッチの転送処理を行います。

今回の話は最初に書いたようにプログラム設計次第の話ではあります。

K8M0などの桁指定を使用した異常点数のカウントやWANDを使用した重故障の判定と比較して面倒にはなりますが、ST言語でループなどを使用して1点1点処理するというのも一つの手として紹介しました。

ステップ数と処理速度については構造体の転送と同様、許容できる範囲かどうか見積る必要があります。

今回組んだシステムは集中リモコン的なシステムだったので、各コントローラFBとの入出力はシンプルにした方がHMI（GOT)画面作成などにも都合が良かったので、一回組んでしまえばほとんど見ない一括処理に関しては今回の扱いで正解だったと考えています。