ogochan
以前とある輸送機の仕事をした時(これはいずれまた)、PLCというものに触れました。
触れたと言っても直接PLCをいじったとかではなくて、PLCで構成されている制御系を、マイコンで構成しなおすというお仕事です。
その時に初めて、ラダー図を見ることとなりました。それ以前にいわゆる教養としてラダー図というものは知っていたのですが、実際に動いている実物を見るのは初めてです。第一印象は、
よくこんなものでプログラム書けるな
でした。ちなみに、ラダー図というのは、こんな感じです。
詳しく知りたい方はこちらの方が「講座」的なことを書いておられるのでそちらでも。
件のお仕事は「1号機」を作ることで、「零号機」は既に存在していたのですが、電装系のドキュメントはマトモなものがありません(これについてはいずれ)。もちろん制御系も同じです。しょうがないので、ヒアリングとコード解析という、まぁありがちの方法になるわけです。「コード解析」と言っても、CとかRubyとかのおなじみのものではなくて、例のラダー図だけです。しょうがないので、ラダー図についてお勉強しながら解析するわけです。
ラダー図そのものは、いくつかの記述ルールを覚えれしまえば、電気屋にとっては特に難しいものではありません。ただ、モジュール化という考えに乏しく、ダラダラと連鎖した回路図みたいなもの(実際回路図とも読める)が描いてあるだけで、大変イタリアン(婉曲表現)風味になりやすいものです。
ただ、そのついでに、他のIEC-61131-3関係(PLCの制御言語の規格)のドキュメントとか見ていると、実に面白いことに気がつきます。
第一に「PLCのプログラム」というのは、STとILと呼ばれるものを除けば、
ビジュアル
です。プロジェクトで見たのは「ラダー図」と呼ばれる図ですし、その他のFBDと呼ばれる表現形式も図です。
つまり、実に本物のビジュアルプログミングです。いわゆるIT屋が知っているビジュアルプログラミング言語は、「文が図になっている」とか「キーワードがアイコン化されている」だけだったりするわけですが、IEC-61131-3にあるものはまさに図。回路図とかブロック図とかと同じような図なのです。
第二に「PLCのプログラム」というのは、本質的に
並列処理
です。
プログラムに書かれた「図」がステップ実行されるのではなくて、イベントや値が「光の速度」で伝播して結果が出るものとして処理されます。途中にある制御要素や演算は瞬時に完了するものと見ますし、イベントや値が分岐すれば、分岐先には公平に届いて処理されます。イベントやデータが分岐すると、そこで並列処理が始まってしまいます。
もちろん実装の都合がありますから、必ずしもそうなってはくれないのですが、1つのタイムスライスが終われば全ての処理が完了しています。
これら2つの特徴は、それまで「IT屋の言語」しか深くいじった経験のない者にとっては、なかなかのショックです。コードのビジュアル化なんてのは、それこそ何10年も前からの課題でありながらマトモなものは何一つないと言っても過言ではないことは、皆さん御存知だと思います。さらに並列処理をそれと意識しないで本質的に扱うというのがなかなかに難しいものであることも、皆さん常識だと思います。ところが、PLCの世界では、それが当り前なわけです。
そんなわけで、今まで半ば「コンピュータモドキ」みたいな目で見ていたPLCなる機器の世界はなかなかに新鮮なショックを与えてくれました。
PLCなる機器の世界の面白さは、これだけではありません。また、現代に於いてこのような機器が必要とされる背景も、なかなか面白いものがあります。
たとえば、PLCのインターフェイスは、直接制御対象の機器を操作出来るくらいの「パワー」があります。もちろん大電力の機器とか動かすためにはリレーとかを介する必要はありますが、そのリレーが直接ドライブ出来るくらいの電流が流せます。また、リレーを動かすと電気的にはいろいろな不愉快な現象(リレーコイルの逆起電力とか)が起きるのですが、基本的にはそういったものの存在は無視出来る回路になっています。
プログラムを書く時も、既に書いているようにビジュアル言語ですし、割と即物的と言いますか、「そういった装置を並べてつないで作る」みたいな感じで出来ます。割込み応答がどうだとかスレッドの同期がどうだとかという問題も、直接考える必要はありません。つまり、ハード的にもソフト的にも、
やりたいことに集中してシステム構築出来る
ようになっています。
もちろんそれでは不足することがあって、その場合はいろいろ対応があるのではありますが、基本的には上記のような感じでシステム構築されるわけです。
さて、次回以降は、このPLCを弊社としてはどう取り組んで行くかという話となります。