つづきを始める前に

「いわゆる構造化プログラミング」への道　最初の記事
からのつづきになります。

GX WORKS2では
「よし、これから構造化プログラミングをするぞ」
と心構えをさせられたけど
GX WORK3では構造化プログラミングなんてマニュアルでは一言も記載が無い。

じゃあ、どうしよう。
という話です。

「いわゆる構造化プログラミング」というのは、IEC61131-3に準拠した形でGX WORKS3行えるプログラム手法を指しているつもりです。
IEC61131-3はプログラムの標準化についての提案はしていますが、必ずプログラムを構造化しなさいというものではありません。
IEC61131-3を活用するとプログラムを構造化できるというスタンスに読み取っています。

構造化というよりは、まずは部品化

構造化プログラムというのはBASICでパソコンプログラムを始めた頃に初めて耳にした言葉ですが、元々はGOTO命令を使わずにGOSUBなどでサブルーチンを呼び出す形のプログラミングを意味していました。
シーケンス命令にも「構造化命令」としてその手の命令が用意されています。

「いわゆる構造化プログラミング」で部品化手法として代表的なファンクションブロック（FB）はインスタンスを生成するという部分ではオブジェクト指向に近いのですが、継承などの重要な概念は導入されていないので（GX WORKS3では）オブジェクト指向とも呼べません。
（しかし、解説書の方では機能は足りていないが「FBはオブジェクト指向」と記述されていました）

CHAT GPTと相談して
「中途半端なオブジェクト指向」とか色々な呼び方を評価してもらいましたが、
「部品化」というのが実態をよく表していて適切とのお褒めをいただきました。

制御盤設計ではすでに普及している部品構築化設計

制御盤を設計する際、特定の機能を組み込む際にはそういう機能を持つ部品を組み込むのが普通です。
・フロートレスレベルスイッチとか
・調節計とか
・週間タイマーとか
・比較変換器とか
どちらかと言えばマグネットやリレーやタイマーで設計者が構成し実装することが多いと思われるスターデルタ回路もスターデルタユニットとして販売されています。

これと同じように、そういった何らかの機能をFB化して貼り付けてプログラミングするというのがPLCでの「いわゆる構造化プログラミング」の実際であると考えています。

こういった部品には動作モードを切り替えるための入力などが設けられているため、こういった仕様が自作FB部品を作る上でのヒントになりました。

「よく使う回路をFB化する」のでは無い

そもそも再利用性が低いというのが問題視されているPLCプログラムなので定型の処理以外は似ているんだけど微妙に違う回路の集合になっているのでは無いでしょうか。

なので、「よく使う回路をそのままFB化」というのは演算や信号処理など決まり切った流れの処理に限られて来ます。

私の分野では冷凍、空調制御などが主なので、有接点シーケンスで制御盤を組む場合は下記のような部品を盤内に組み込む事になります。

サーモスタット
デフロストタイマー
1時間以上遅延のオンディレイタイマー
送風機間欠タイマー
空気状態計算機
温度警報発生器（調節計機能の一部）
ハイセレクタ

このような実際にも部品として存在するものからFB化してFBというもののイメージを掴みました。

その他のイメージとして、空調機相手に制御する場合は空調機側が外部入力と外部出力を持っていて、それとPLCで連携を取るプログラムを今まで組んできたわけです。
なので、送風機制御などのFBを組むときは空調機をまねて、送風機制御器にはどのような入力と出力が必要か検討しました。

データの構造化の問題もクリアしないといけないのですが、入出力を持つ装置をFB化する所まで見えてくれば、三菱の冷凍機制御で言えばクールマルチコントローラとかそういった役割を持つ比較的大規模なものもFB化出来るようになります。

ファンクションブロックFBとファンクションFUNの違い

ファンクションブロック（FB)
- タイマーやカウンターなど、内部で値を記憶する処理が可能
- したがってFUNとの比較として言えば、入力に対して同じ結果を返すとは限らない
ファンクション（FUN)
- 内部で値を記憶できない
- 入力に対して必ず同じ結果を返す

GX WORKS3以外の場合はファンクションの戻り値は1つだけというのが多いのですが、GX WORKS3は複数の戻り値を設定できます。
したがって、ファンクションで使用出来ない変数の型を使用しなければ、内部で値を記録する必要が無ければファンクションブロックからファンクションへの移植も簡単です。

FBをプログラム中に並べる＝盤図に部品を並べて書く

FBをラダープログラム中で使用するのは、まるで盤図に部品を並べて書いているのと同じ感覚です。
まさに「部品を貼り付けるだけの簡単プログラミング」です。
それでいてサブルーチン型のFBであればサブルーチンとしてプログラムが呼び出されるのでロジックに関しては回数分のプログラムステップを消費しません。
（引数引き渡しと呼び出し処理にいくらかステップを消費します）

同様の処理を複数回繰り返す場合を比較する

ラダーベタ書きで処理数分の回路を書いた場合
1つのロジックでデバイスをインデックスで切り替えて必要回数処理した場合
サブルーチン型のファンクションブロックを使用した場合
ファンクションを使用した場合（内部に値を保持する処理は不可）

項目	ラダーベタ書き	ラダーインデックス	FB	FUN
ステップ数	大	小	中	中
データメモリ	回数分	組み方次第	回数分	1回分
内部モニタ	可能	不可	可能	不可
用途範囲	広い	狭い	広い	狭い
回路変更	大変	楽？	楽	楽

※ラダーインデックスの回路変更はインデックスに絡む変更は難しい場合があるので？を追記しています

引数引き渡しと呼び出し処理にステップ数を消費することに目をつぶれるならモニタも出来るし回路変更も楽というFBの優位性が分かると思います。

なかやすみ

私だけかも知れませんが、「よく使う回路」と思っている間は、ホントFBって何を作って良いか思い浮かばなかったんですよ。

下手に作ろうとしても、いきなり大がかりな処理をFB化しようとするものだからFBの中でグローバルラベル配列を使って、添え字部分を引数で引き渡して切り替えるとかトンチンカンなFBを組んでみたりしてました。

最近見た海外のPLC OPENの資料では発酵機を例に挙げて説明してあったのでFB化する部分についても非常に分かりやすかったし、私と考え方が近かったです。

次はデータの構造化について書いてみようと思います。

過去記事一覧

過去記事一覧