はじめに

実態はよく分かりませんが、参考文献などがほとんど発売されていない以上、GX WORKS3でのPOU（プログラム構成ユニット）を組み合わせてプログラムを行う「いわゆる構造化プログラミング」が普及していないていで記事を書きます。

実践的なプログラミングテクニックを記載している訳では無いので、そういったものを求めている方は立ち去っていただければ幸いです。

GX WORKS3が出始めの頃、カタログで
「部品を貼り付けるだけの簡単プログラミング」
との記述を目にし、
「そんな訳ないじゃ無い」
と冷ややかな目で見ていました。
ですが、ここ最近の自作ファンクションブロック（FB）を活用したプログラミングを行っている際、
「あれ、いまのこれって部品（FB）を貼り付けてグローバルラベル結びつけてるだけ？」
ということで、気が付いてみると昔冷ややかに見ていた謳い文句に近いプログラミングを行っていました。

PLCでの「いわゆる構造化プログラミング」とはどういうプログラミングなのかを自分なりの経験で記事にしたいとおもいます。

IEC61131-3に関しては
「IEC61131-3を用いたPLCプログラミング-PLC言語の国際規格の解説と応用」第9刷を参照しました。
解釈の間違いやその後の規格の改定で変更になった部分もあろうかと思いますので、すべて鵜呑みにせず読んでいただけると幸いです。

IEC61131-3を用いたPLCプログラミングの要点

FBなどを組み合わせてPLCプログラミングを行うソフトはIEC61131-3という国際規格に則っているということになっています。
ところで、この国際規格ですが、「IEC61131-3を用いたPLCプログラミング　PLC言語の国際規格の解説と応用」という解説書の中には「構造化プログラミング」という用語はほとんど出てきません。
要点としては

プロジェクトを構成する要素をPOU（Program Organisation Unit,プログラム構成単位,プログラム構成ユニット）と呼ぶブロックに標準化した
- POUの種別は下記の3種類とした
  - ファンクション(FUN)
    - 入力が同じなら、常に同じ結果を返す、関数のようなプログラム部品
  - ファンクションブロック(FB)
    - 変数を持つ事ができるので、処理状態を記憶することができる
    - 入力に対していつも同じ結果を返すとは限らない
    - タイマ、カウンタ、等を使用した処理が行える
  - プログラム（PROG:メインプログラム）
    - プログラムの呼び出しはPLCのタスクに割り付けられる
      - 「スキャン」「定周期」など
    - 物理的I/Oアドレスにアクセスするための直接表現変数（D0、M0などのデバイス）の使用が許されている
    - 独自のプログラムを行ったり、FUNやFBを呼び出してプログラムを行う
変数、データ型の標準化を行った
プログラミング言語の標準化を行った
PLCの機能の標準化を行った

実装に関しては全てを求めるものでは無く、実装の程度を明示するという要求です。
PLC OPEN JAPANのサイトや資料に記載されているような構造化手法に関しての記述は無く、こういう単位でプログラムを行えばプログラムを構造化することもできるし、しないことも出来るというという提案として読み取りました。

※物理アドレスの使用についてはコーディングガイドラインでは機種間の移植性などの理由で禁止になっています

諸悪の根源はGX WORKS2以前

GX WORKS2では構造化プログラム編として別冊でマニュアルが用意されています。
そして、プログラムの種別を下記の3種類に分けており、プロジェクトを新規作成する際にどれでプロジェクトを作成するか選択させていました。

シンプルプロジェクト（ラベルを使用しない）　
- ラベルを使用しない従来型プログラム
- 使用できる言語　ラダー、SFC
シンプルプロジェクト（ラベルを使用する）
- ラベルを使用する従来型プログラム
- 使用できる言語　ラダー、（SFC、STはFXでは不可）
- 使用できるプログラム要素　ラベル、構造体、FB
構造化プロジェクト
- プログラムを部品を作成し、その部品を組み合わせてプログラムを完成させる
- 使用できる言語　FBD、ST、（ラダー、SFCはFXでは不可）
- 使用できるプログラム要素　ラベル、構造体、FB、FUN、ライブラリ

この構造化プロジェクトに対するマニュアルが構造化プログラム編でした。
なので、FXで構造化プログラム編を参照してプログラミングを始めようとすると非常にハードルが高いものでした。
しかし、当時は気が付かなかったのですが、シンプルプロジェクトもラベルを使用すればFB（ファンクションブロック）を使用することはできていました。

IEC61131-3で一番基本的なプログラム要素とされているFBが使用できる訳ですから、シンプルプロジェクト（ラベルを使用する）でもIEC的プログラムの構造化は可能な訳です。
なのにこのWORKS2のメニュー構成とマニュアル構成は悪魔の所業のように思えてしまいます。

実は、GX WORKS3では構造化プログラミングという記載はほぼ無い

WORKS2で「構造化プログラム編」というマニュアルまで別冊でまとめたのにかかわらず、実はWORKS3では構造化プログラムという記載はほぼありません。
カタログやマニュアルのPDFで「構造化」を検索した結果が以下です

GX WORS3のカタログにて「部品化・構造化プログラミングに対応」と1文のみ記載あり
iQ-FのマニュアルではWORKS2との互換性の説明で「構造化ラダー」との記載あり
ST言語の説明で「構造化テキスト」との記載あり
昔ながらのループ、コールの命令を分類する「構造化命令」との記載あり

というわけで、WORKS2であれだけ提唱していた構造化プログラミングというのはGX WORKS3のカタログに1文記載されているだけです。
WORKS2で構造化プログラミングを活用されていた方向けの説明文でしょうか。

「構造化プログラミング」という幻を追いかけていたのだろうか

IEC61131-3はそれ以前にもあったPOUに類似するようなプログラムの分け方を標準化したり、言語の種類を標準化したりという提案で「構造化しなさい」というものではありません。
トップダウン的にプログラムの構成を定めても良いし、部品を積み上げてプログラムを構築しても良いというガイドラインでした。

まだまだGX WORKS2も現役なので「構造化プログラミング」という幻が目の前にチラチラしていますが、GX WORKS3はそんな事は一言も言っていません。

まずは気持ちを落ち着けて、
「POUって？プログラム分けられるの？だったら通信と制御で分けておくか」
とか
「サーモスタットくらいFBで組んでおく？」
位の感じで始められたらと考えています。

構造化といっても、部品が無ければ構造しようが無いじゃないですか。

機能の分解と構築
プロセスの分解と構築
データの分解と構築

これらの要素によって組み上げられたプログラムが構造を持つのであり、色々な分野によって、それぞれの構造化が存在すると私は考えています。

というわけで、「いわゆる構造化プログラミング」という一歩引いた表現を使用しています。

なかやすみ

長くなってきたのでこの辺で区切ります。
次は部品化（モジュール化）について記事を書いたら丁度良い長さになると思ってます。

過去記事一覧

過去記事一覧