「ソフテックだより」では、ソフトウェア開発に関する情報や開発現場における社員の取り組みなどを定期的にお知らせしています。
さまざまなテーマを取り上げていますので、他のソフテックだよりも、ぜひご覧下さい。
ソフテックだより(発行日順)のページへ
ソフテックだより 技術レポート(技術分野別)のページへ
ソフテックだより 現場の声(シーン別)のページへ
近年の制御システムでは、PLC(Programmable Logic Controller)の高性能化のおかげで、対応できる事が格段に増え、中〜大規模のプログラムも珍しくなくなりました。
それに伴い、PLCソフト開発における、プログラム標準化・開発高効率化・品質向上を目的とする構造化プログラミング(※1)が注目されています。
国内でも、ある程度構造化プログラミングを目にする機会が増えてきましたが、まだまだシンプルラダーでのプログラミングが主流だと言わざるをえません。
ところが、国外では既にIEC言語による構造化プログラミングが主流となっております。
構造化プログラミングが気になる、または取り組みたいけれども、実際どうなのか?と足踏みをされている方も多いのではないでしょうか?
そこで本メルマガでは、三菱電機製PLCエンジニアリングツール『GX Works2(※2)』を使用した場合の、構造化プログラミングについてご紹介してみたいと思います。今後、構造化プログラミングに取り組む事を考えている方にとって、少しでも参考にしていただく事ができればと思います。
構造化プログラミングのポイントとして、『プログラムの部品化/階層化』『ラベルプログラミング』の2つがあげられますが、『プログラムの部品化/階層化』は、シンプルラダーによるプログラミングでもある程度実現する事は可能ですので、ここでの説明は省略します。
デバイス直接指定ではなく、ラベルプログラミングについて紹介します。
ラベルプログラミングとは、プログラムで使用する信号/データを、ラベル(変数)として定義し、そのメモリ割付(ラベルとデバイスの紐付け)は、エンジニアリングツールにより自動割付される事になります。
ラベルには、グローバルラベルとローカルラベルがあります。
[グローバルラベル]
[ローカルラベル]
ラベルは、ビット長、処理方法、扱うデータの範囲によって、データ型に分類されます。
[データ型] | [値の範囲] | ||
---|---|---|---|
1.ビット型 | 0(false)/1(true) | ||
2.符号付ワード型 | -32768 〜 32767 | ||
3.符号付ダブルワード型 | -2147483648 〜 2147483647 | ||
4.符号無ワード型 | 0 〜 65535 | ||
5.符号無ダブルワード型 | 0 〜 4294967295 | ||
6.単精度実数型 | -2128 〜 -2-126/0/2-126 〜 2128 | ||
7.倍精度実数型 | -21024 〜 -2-1022/0/2-1022 〜 21024 | ||
8.文字列 | 最大255文字(可変) | ||
9.時間 | -24d20h31m23s648ms 〜 24d20h31m23s647ms |
ラベルを使えばどういうメリットがあるかについてまとめます。
[プログラムの流用が容易]
[デバイスミス/デバイス重複使用の防止]
[変数名の共有が可能]
いずれも、PLC固有のデバイスでの開発時には『今回はどう対処しようか?』などと頭を悩ませるところではないでしょうか?
ラベルを使えばどういうデメリットがあるかについてまとめます。
[コンパイル時に注意]
[ラベルに慣れるまで]
プログラム言語ですが、IEC言語の一つであるFB(Function Block)が比較的使いやすいと思います。
FBは、入力パラメータと出力パラメータを持つ、関数のようなものです。シンプルラダーで言うと、シーケンス命令を除く、基本/応用命令はすべてFBとして使用できます。
また、複数の機能を組み合わせた制御(処理)をFB化する事で、1つの命令のように簡略化する事ができます。
FBを使えばどういうメリットがあるかについてまとめます。
[プログラムが見やすい/分かりやすい]
シーケンス回路記号とFBを組み合わせる事で、一つ一つの機能・処理がシンプルラダーよりも分かりやすくなると思います。入力と出力が明確になっている標準的なFBを見れば、そこで何をしているかは容易に想像がつきます。
※下記は、加算FB使用例です。
図1. FB使用例
FBにおける”EN”は実行条件、”ENO”は実行結果です。
いずれもビット型ラベルを指定します。”ENO”は指定しなくても良いです。
ラダープログラムしか作成した事の無い方でも、FBであれば抵抗なく入っていけるものと思います。
[複雑な処理はFB化]
複雑な処理は、ラダーでダラダラ書くよりもFBとして部品化してしまい、必要に応じてプログラム内で使う事ができます。FBの中身をデバッグする必要はありませんし、複数の案件で使用可能な複雑処理・便利処理をFBとして登録しておけば、入力と出力を指定してFBを使うだけで、簡単に結果を得る事ができます。
[流用性の高さ]
複雑処理・便利処理をFBとして登録しておけば、必要なときにそのFBを流用し、用途に応じて入力と出力のみを変更するだけなので、使い勝手が良いです。
ポイント①とポイント②では、ラベル及びファンクションブロックFBを利用したプログラミングに触れてきましたが、実際にはいろいろな事ができます。
FB及びLD(Ladder Logic)の他、IL(Instruction List)/ST(Structured Text)/SFC(Sequential Function Chart)と5種類の言語があります。
それぞれメリット/デメリットはありますが、得意なところを組み合わせて使うのが良いです。
全面的に切り替えるのはまだ先になるかもしれませんが、私はLDとFBの組み合わせがしっくりときました。
他にも、ST言語を取り入れていきたい考えもありますので、この話はまた次回触れてみたいと思います。
シンプルラダーの場合は、登録したプログラムブロック順に、実行タイプ(待機/スキャン/初期/定周期)に従って実行していくのみですが、構造化プログラムでは、タスクという考え方を持つことができます。
具体的には、小さなプログラムを部品として複数組み合わせてプログラムブロックとする事ができ、しかもその中で部品毎に実行条件(常時実行/イベント起動/周期起動)を指定する事ができます。
条件次第では、複数の部品が同時に実行される可能性もありますが、この場合は部品毎に優先順位を決めて、どちらが先に実行するか?など自由度の高い処理の組み合わせが可能です。
プログラム部品は、たとえばAのプログラムブロックとBのプログラムブロックに登録する事も可能です。部品という単位で1スキャン中に何度も実行する事が可能ですので、こういう点でも自由度が高いです。
(最上位のプログラムブロックは、2重登録して2回実行するという事は出来ません)
構造化プログラミングという視点で、今回は初歩的な部分に触れてみました。
実際には、細かい制約がいくつもあり、スペシャリストになるには多数の経験を積んでいく必要がありますが、PLCの世界でもラベルプログラミング、FBを使ったプログラミングがどんどん増えていますので、興味がある方は、簡単なところからでも取り組んでいただければと思います。
弊社もIEC言語には積極的に取り組んでいく予定ですので、もしご質問などございましたら、お気軽にお問い合わせいただければと思います。
(Y.S.)
関連ページへのリンク
関連するソフテックだより