ツールマスターへの道

デバッグの効率化を考える

PLCのプログラムを作成してデバッグをするときにPC側からPLCにアクセスしてデバイスの読み書きが出来ると便利で効率的です。(そもそも何かしらの手段でデバイス値がモニタ出来なければデバッグになりませんが。。)

PLCの開発環境上でデバッグをすると分かりますがラダーをモニタして画面を切り替えて上下スクロールを繰り返し、最初に見ていた場所はどこだっけ？と彷徨うことがわりと頻繁に発生します。デバッグに開発環境は必須ですが効率的に出来るかどうかは別問題となります。ウォッチウィンドウのように指定デバイスをまとめてモニタできる機能もありますが使い勝手が良いとは思えません。(個人的にはほとんど使ったことが無い。)

PLCは画面を持っていない(ユーザインタフェースが無い)のでPLCを使った制御システムには必然的にタッチパネルやPCが付きますが、ある程度の規模になればPLC/PC/タッチパネルで分業するのが基本です。そうなると、、PLCのデバッグ時に欲しい画面≒通常は不要な画面を搭載するのは厳しくなります。

そこでデバッグを効率的に進めるための方法の1つが“PCからPLCのデバイス値を読み書き出来るツールを作る”です。別にPCツールでなくともハンディタイプのタッチパネルでもソフトGOTのようなものでもデバイスが読み書き出来れば何でもOKなのですが、PCツールにする理由がいくつかあります。

まずはタッチパネル系のものを使いたくない(＝独断と偏見による”当社比”的なもの)理由から(笑)

• タッチパネルを使う場合
  別途電源(DC24V)と配線(電源＋通信)が面倒
  持ち運びがかったるい
  あえて購入するには高価(?)
• タッチパネルのシミュレータ機能を使う場合
  PCの動作が極端に重くなる
• ソフトGOTを使う場合
  ハードウェアライセンスが邪魔(見た目がUSBメモリっぽいヤツ)

PCツールを選択する理由としては、、

• 技術力の向上、蓄積
  PCツールを作成するとPLCが得意な処理とPCが得意な処理とが自然と理解できる
  ⇒合理的・効率的な設計の思考力が養える
  さらにレベルアップすると通信制御する機器のエミュレータも作れる
• 気分転換
  人間ひとつのことをやり続けたら飽きるので”いつもと違う技術”に触れることも重要
  ⇒結果的に技術の幅が広がる
• 自己満足
  モチベーション大事
  ⇒楽しくなければ仕事じゃない！

ちなみに、PCツールを薦めておきながら言うのもアレですが。。
上記に挙げた内容がたいしたデメリットでなければタッチパネル等は積極的に使うべきです。なぜならPCツールは便利な反面、作るには結構な技術力(センスも含む)とそれなりのスピードが要求されます。優秀なツールであったとしてもタイミングが合わなければ価値半減どころかゼロになるので状況に合わせて選択すれば良いと思います。(私も10年以上前はちょいちょい使ってました。)

そもそも、、、
この手のツールはあれば便利と理解されても現実的には時間とコストをかけられない場合が多いので作るチャンスがあるかどうかは企業・組織の風土によると思います。私の場合、普段の仕事ではPCツールを作成してデバッグしていますが、ツール導入前を思い返すとデバッグ時間の短縮とプログラム完成度の向上に役立っているのは実感します。

効率的なデバッグ

PLCであれPCであれプログラムのデバッグは当たり前のことですが、デバッグをするためには対象のプログラムを動かさなければ始まりません。(当然ですね。プログラムは動かしてナンボです。)
PCプログラムの場合は開発環境からボタン1つでデバッグが可能となり対象プログラムを実行させる操作やテストコード作成が容易にできますが、PLCの場合はPCほど容易にデバッグというわけにはいきません。

PLCのプログラムはいってみればIF文が連続した先に本当の制御プログラムがあるので①IF文をとおす＝条件を整える、②トリガ≒コマンドを与えて実行する、大きくこの2つを揃えて本当のデバッグが始まります。(条件やコマンドが合っているかも大事なデバッグ要素ですが。)

ざっくりと大雑把に言えばデバッグを効率的に進めるにはこの2つを容易にクリアできる環境を準備すればOK、と考えることが出来ます。ツールを作るならこの視点を重視＋実行状態のモニタを考えればおのずと必要な形が見えるハズです。このようなツールと机上シミュレーションを組み合わせるとデバッグの効率が上がります。

ツールを作る

おおよそデバッグに必要な内容が分かればツールを作れば良いだけなのですが、ここからハードルが上がります。(個人のスキルによって感じる高さに大きな違いがあると思いますが。。)
タッチパネルを使うのであれば通信経路(シリアル(RS-232/422/485)やEthernet)を決めれば自動的に通信処理をしてくれるためデザインしてデバイスを割り付ければおおよそOKなのですが、PCツールの場合は通信処理そのものも作らなければなりませんのでよりハードルがあがります。

ちなみにPLCとの通信に関しては専用の通信ライブラリやミドルウェアといったものが販売されているのでそれらを使う方法とソケット通信等(APIや言語特有のライブラリ)を使って自作する方法とがあります。

通信ライブラリを使う場合はPLCメーカーが販売しているもの(三菱ならMX Component、OMRONならCX-Compolet)かサードパーティ製(使ったことはないけどロボティクスウェアとか)があります。当然ラクな反面、必要なライセンス数だけお金がかかりますしライブラリがインストールされていないPCではアプリケーションが動作しません。

通信処理を自作するなら制約がない反面、手間がかかります。三菱ならMCプロトコル、OMRONならFINS、KEYENCEなら上位リンク/MCプロトコルを調べてみれば分かります。いわゆる難しくはないけど面倒くさいヤツです。通信でデバイスの読み書きが出来ればOKですが、ゼロから調べてそれなりの自作ライブラリにまとめるには1～2週間程度はかかるでしょうし、センスが無ければ1ヶ月どころか半年かけても作れないでしょう。。
個人のスキル次第なのでなんとも言えませんが向き・不向きがありますし、通信ライブラリが市販されている＝その処理をイチから作るのは面倒だと言えます。やる気があって学習方法(もしくは教わる人)を間違えなければたいていは作れるハズですが。。(かかる時間はやる気とセンス次第)

PLCとの通信が出来ればボタンやラベルやなどを配置して一定時間毎にデバイス値を読み込んで表示を更新するとか、ボタンクリックで何かしらの値を書き込むといったプログラムを作れば立派なツールとなります。このあたりのコントロールやらイベントやらについての情報はグーグル先生に聞けばいろいろなサイトを教えてくれます。(C#やVBなどVisual Studio系の情報は腐るほどあるかと)
ツールに必要な必須機能、あれば便利な機能、その他オプション的なもの、状況と作る人の好みで大きく変わると思いますが何度か繰り返し作ることでセンスが磨かれます。継続は力なり、です。

参考までに経験談。

私がツールを作るときにはVBを使ってます。ごく稀にもしくはC#。(内容と気分次第)
本格的にPLCの仕事をする前はVBでPC側のプログラムを作っていたので慣れているVBを選んだだけのことですが、VB自体にイラつくことも多々あります(笑)

PLCとの通信処理に関する部分ですが昔は三菱PLCしか使用していない環境かつMX Componentが社内に転がっていたので使っていましたが、ツールを作って別の人が使う・別のPCで使うとなると面倒なことに気付きました。(便利なんですけどね～、ライブラリのインストールが手間だったり、ライセンスの問題だったり。)

途中からはOMRONやKEYENCEを相手にすることも増え、三菱含めて通信処理を自作しました。このときにMX Componentを使った経験をふまえて自作通信ライブラリのインターフェースはコレをパクり、、いや参考にさせて頂きました。ツールを作っては改良を重ねてそこそこの形にするまで3～4年かかった気がします。(本業はPLCでラダーを作るほうなので、ツールは空き時間でなんとかした感じ)

そもそもツールを作るきっかけは”ヒマ”だったから。(こう言うと語弊がありますが)
PC+PLCで構成するものを仕事としていますが自分の担当分がそこそこ作り終えても結合テストレベルのデバッグが出来ない状況があったり、工程の見直しで実機を使える予定が遅れたりすることがままあります。
するとムダに待ちを強いられるので時間の有効活用を考えることになるわけです。最終的なシステムに必要なハードとソフトが欠けた状態でデバッグするにはどうすれば良いか？⇒考えた結果がツールを作ることでした。ツールを作ればなんでもかんでも効率よくデバッグ出来るわけではありませんが、場合によって有効な手段となるのは間違いありません。

でも本当の理由は単に”プログラムを作るのが好きだから・面白いから”というのは内緒です(笑)