つづきを始める前に
「いわゆる構造化プログラミング」への道 3回目の記事
からのつづきになります。
前回はデータの構造化としてリンクリフレッシュデバイスを構造体によってマッピングする手法を紹介しました。
この呼び方自体合っているのかというのは他に出典が無いので微妙なのですが、イメージを掴んでいただけたら幸いです。
今回はファンクションブロック（FB）の大まかな分類と、FBへの入出力データの構造を簡単に考察して、前回の手法がどう結びつくのかといった話を展開します。
説明というよりはこうやったらこうなったという結果論的な話にはなります。
FBを規模によって分類する
FBの規模感について共通理解が無いと話が通じないと思うので、ここではFBを規模によって3つに分けます。
1. ミニマルFB
汎用ファンクションブロックのように入出力が片手で足りる程度の単機能FBをここではミニマルFBと名付けます
2. モジュールFB
ミニマルFBを複数個含むFBをモジュールFBと名付けます
警報付きのサーモスタットとかそんなイメージになります
3. コントローラFB
下記の特徴を持つFBをコントローラFBと名付けます
- 多数の設定値を入力する
- 構造体で引き渡す
- 他のコントローラFBとの連携を取る
- 外部のI/Oを制御する
- 多数の状態値を返す
- 構造体で引き渡す
- 基本的には内部にミニマルFBやモジュールFBを持ちます
コントローラFBは制御プログラムを機器毎や工程毎にまとめ、情報を外部I/O側とHMI（GOT）やフィールドネットワーク側に切り分ける役割を持ったファンクションブロックといえるでしょう。
コントローラFBのデータ構造について
フィールドネットワークのローカル局側にコントローラFBを配置することを考えます。
そのとき、コントローラFBに入出力するデータについて下記の3種類に分けて取り扱うと整理が簡単になりました。
1. 下位データ
- 主に外部I/OをコントローラFBに接続する
- 汎用性を考えると外部I/Oはグローバルラベルに割り付ける
2. 同位データ
- フィールドネットワークのローカル局内で発生した情報をコントローラFBへ入力する
- コントローラFBからの信号はローカルプログラム内であれば公開ラベルなども使用して行う
- コントローラFB同士のインターロックを行う信号やローカル通信で取得したデータを入力する
- コントローラFB内で保持したい長時間タイマーなどをIN-OUT型でデバイスと結びつける
3. 上位データ
- フィールドネットワークやHMI（GOT）の表示データ
- フィールドネットワークから流れてきたデータをコントローラFBへ構造体で入力する
- コントローラFBからのアンサーを上位ネットワークへ構造体で返送する
- 同位データ、下位データのうち、上位返送するものをここに乗せて返送する
要するに、コントローラFBはフィールドネットワークやHMI（GOT）との入出力を行ために専用のデータ列を用意するという部分が重要になります。
これだけ書くとコントローラFB内でデータを分類して取り扱うメリットが分かりにくいですが、例えばこのようなデータ処理をしなかったらどうなるか。
そうすると、下位データにあたる外部I/Oの状態をフィールドネットワークに返そうと思うとコントローラFBの外でリンクデバイスへの転送処理を行うプログラムが必要になり、プログラムもリンクデバイスのデータ構造も複雑になってきます。
データ構造を図示する
前回と今回の記事で扱ったデータ構造を図示すると下図のように示せます。
注）マスター局部のマスター局内で扱う部分はリンクリフレッシュには乗らないのですが、実際のプログラムではリンクリフレッシュ部とセットでデバイス範囲をマッピングしました。
- HMI(GOT)部について
- FXでのプログラムだとこの部分ではデバイスを扱う事になると思います
- この部分で扱うデバイスは構造体型ラベルに割付られているのでPLC内ではラベルで取り扱うことができます
- マスター局部について
- マスターの中にもフィールドネットワーク全体を取り持つマスター制御部とマスター局でのローカルI/O制御が存在する場合が多いと思われます
- 通信全体の構造体データからローカル制御用の構造体データへ転送を行う事により、ローカルI/O制御部は他のローカル局と同じプログラムを使用できるようになります
- ローカル局部について
- 通信全体の構造体データからローカル制御用の構造体データへ転送を行う事により、遠方-手元の切替に対応したり、他局とプログラムの共通化が行えるようになります
- ローカル局間のデータ転送について
- マスター範囲構造体型グローバルラベル間で行う事になります
ファンクションブロックを規模毎に分類し、コントローラFBという概念を導入することによりデータとプログラムを構造化することが可能になりました。
そしてリンクリフレッシュデバイスを構造体でマッピングしている事により、HMI(GOT）でのデータの割付も比較的整ったデータ列で行う事ができました。
おわりに
デバイスプログラムでもXやYを一旦補助リレーで受ける等の規則を設けてプログラミングをすることもあったのですが、現場で改修を行うと段々とその辺がグチャグチャになったという経験が何度かありました。
同様の経験をお持ちの方もいらっしゃるのではないでしょうか。
その点、構造体型ラベルを用いたプログラミングはその辺りが崩れにくいというメリットを大いに感じました。
いわゆる構造化プログラミングへの道として雑多に書いてきましたが、要点を書き出すと下記になります。
- まずは部品化
- データの構造化
- コントローラFBという概念の導入と構造化したデータの結びつけ
あまり上手く書けたとは思いませんが、プログラムを構造化するならデータも構造化する必要があるんじゃない？
ということを書かせていただきました。
そして、データを構造化するから構造体という訳では無いですが、こういった用途に構造体型ラベルが非常に強力な武器になることが伝わればと思います。
ちなみに今回の手法は4階建て冷凍倉庫で各階ごと分散制御、事務所にてHMI(GOT）で集中管理というシステムを構築するのに用いました。
あと1回、オマケとしてテクニカルな面やトラブルシュートを記事にしたいと考えています。