ツールの作り方 – 画面編

前回まではPLCとの通信に関連することを説明してきましたが、今回は画面＝ユーザインターフェースの部分をサクッと説明していきます。

通信について

PLC用のツールなので、まずは通信に関する部分が必須です。

• 通信設定
• 通信の開始／終了

通信設定は画面から操作できるようにするのが基本です。また通信設定はファイル保存・読込みできるようにしておくのが一般的でしょう。(ファイルは独自フォーマットでもCSVでもINIでもXMLでも何でも構わないと思います)
場合によっては最初にファイル読込みだけを実装しておき、後で編集・保存機能を追加するもの有効だと思います。重要なのは通信設定を変更する手段を用意しておくことです。間違っても通信設定をソースコードに直書きするのは止めましょう。愚の骨頂です。許されるのはサンプルコードか初心者だけです。

開始/終了はユーザが任意タイミングで切り替えられるほうが何かと都合が良いことが多いです。何かしら通信プログラムにバグがあったときに通信回線切断→再接続という動作が出来るほうが便利ですし。。

どんなツールを作るにしても通信部分は必須かつほぼ似通った作りとなるので最初に作って後は使いまわす形にすることが圧倒的に多いです。

必要な機能を決める

数値の扱い

ツールの目的によって必要機能は当然異なるわけですが、、
PLCのデバイスを読み書きするものなのでビット・ワードを扱えなければ話になりません。
これは画面のインターフェースとは直接関係ありませんが内部処理としては必須となります。(通信処理側に機能を持たせることも可能です。仕様と設計次第。)

ビットは0/1、OFF/ONなのでシンプルに分かりやすいですが、ワードデータには注意が必要です。

• 符号付き16Bit (-32768～+32767)
• 符号無し16Bit (0～65535)
• BCD16Bit (0～9999)
• 符号付き32Bit (-2147483648～+2147483647)
• 符号無し32Bit (0～4294967295)
• BCD32Bit (0～99999999)
• 単精度浮動少数(32Bit)
• 倍精度浮動少数(64Bit)
• ASCII文字列

基本的にワードデータを扱う場合は上記しかありません。(三菱PLCの場合は”符号無し”は扱えませんが。。)
通信データはワード単位(16Bit)で扱うのが基本なので、符号の有無や16/32Bitの変換処理が必要になります。

必要な変換処理だけ実装すればOKですが、、
全部実装してもそれほどたいしたことは無いでしょう。もし”ちょっとあやしいかもな～”的な部分があれば復習も兼ねて実装したほうが良いと思います。(時間の許すかぎり。)
たまにこのあたりの変換に関して”話が通じないソフト屋さん”もいますので。

表示方法

ビットやワード状態を何かしらの文字列にする、色を変える、などが基本になります。
単純にラベルやテキストボックスを使うことが多いと思いますが、場合によってはステータスに応じた画像を準備してデバイス値に合わせた表示をさせることも有効な手段です。

アナログ値などの数値を表示する場合はそのまま表示することもあれば、物理量(電圧、電流、温度、圧力など)に換算して表示することもあるでしょう。
PLC的に良くあるのは0.1や0.001単位のものは10倍・1000倍して整数として扱うパターンですかね。(可能なかぎり浮動少数で数値を扱うのを避ける)

Excelの表のように数字や文字を並べて表示・編集したい場合は”グリッド”を使うことになります。(Visual StudioであればDataGridViewですね)
便利な部品ではありますが使い方が分かりにくかったりするので慣れが必要です。下手な書き方をするとやたら処理が遅くなったりとか。。

やる気があれば自前の描画処理で図形を描くことも可能です。敷居が高いかもしれませんがコツをつかめば意外と簡単に出来ます。(多角形や円、線などを組み合わせるとか。)
描画処理が出来れば折れ線グラフなどが作れます。

ちなみに色を変えて表示する場合、、
赤＝Alarm、異常、危険を表す
黄＝Warning、警告/注意喚起を表す
青・緑系＝通常/正常動作状態を表す
装置は一般的に上記の色使いをします。特に赤・黄は日本国内に限らず海外でも同様なのでツールといえども赤・黄系統の色を使うときは注意しましょう。

書込について

ツールの目的によっては書込も必要になります。書込はボタンを使うことが多いと思います。
ビット(SET or RST)か固定値を書き込むような処理は比較的簡単ですが、任意値の書込処理には注意が必要です。

任意の値＝ユーザからの入力操作が入るので文字列→数値変換が必要になります。問題なのは(といより面倒くさいのは)想定したデータ型に変換できないパターンを考えておくことです。空の文字列とか数値認識できない文字とか範囲外とかが良くあるパターンだと思います。それなりに例外処理を考えておかないと使い勝手が悪くなるので最初から考慮しておくのが基本です。

数値入力したいシチュエーションは良くあるパターンなので自作のテンキー入力フォームを作ってしまうのも1つの方法です。(結局のところ数値入力としてみれば例外処理はほぼ似たようなものになり、入力部分にすべて例外処理を記述するのは苦痛以外の何者でもない。。というよりムダな労力。)

連続したデータ書込が必要な場合はグリッドを使うパターンが多いです。100～200点程度のデータ(装置パラメータ的なものとか)ならばボタン操作でPLC読出/書込を実行することが多いですが数1000点を超えるようなデータ(レシピデータとか)であればファイルを使うことが一般的です。

通信のタイミングついて

読出はタイマー(フォームに貼り付けるヤツ)のイベントで実行し、書込はボタンのイベントで実行、というごくごく普通の作り方で通常は問題ないです。
(通信処理自体のつくりと使い方次第で問題になることもありますが。。そのときは作った本人に頑張ってデバッグしてもらいましょう！)

タイミングというよりも通信回数のほうが問題になることが多いので注意してください。
たとえばD100～の50点とD500～の100点の計150点のデータを読み出したい場合。素直に考えれば①D100～50点の読出、②D500～100点の読出、と2回実行となります。
が、これは避けるべきやり方です。通信負荷(というより通信オーバーヘッド？)を考えるとD100～500点の読出を1回で実行するのがやり方として正解です。ムダに見えるかもしれませんが実際後者のほうが通信時間が短くて済みます。

極端な例を考えればもっと分かりやすいです。
ワードデータを100点を読出する場合、、
1点ずつ100回読出と100点を1回読出。
どちらが速いか？と考えるのと同じことです。
当然答えは後者が速いですが、どれだけ違うかも認識しておくほうが良いでしょう。
もちろん環境によっても異なりますがEthernet通信ならおそらく前者は1～2秒、後者は1～20ミリ秒くらいの通信時間になるハズです。(桁が違う。。)

なのでツールでデバイスを読み書きする範囲はまとめておくほうが無難です。
(PLCのデバイス割付は用途別にまとめておく場合が一般的ですが。)
そうはいっても”ツール都合のため”にPLC側のデバイス割付を変えられない場合もあると思いますのでそのときはブロック読出ではなくランダム読出を使う、など工夫の余地はあります。

まとめ？

“画面編”とうたった記事のくせにたいして画面に触れてないですね(笑)
見せ方や操作性は千差万別で一概にコレが良い・悪いとはいかないのでいろいろ試して経験を積むしかないのがホントのところです。。
PLCを相手にするツールとなれば通信が必須なのでそのあたりが少しでも伝われば良いのですが。。