旧ごみためのページ：ラダーマンの部屋
ラダーマンの部屋は，ラダーマンblogへ移動しました。
ラダーマンの部屋
ラダー(LADDER)マンは、ラダープログラミング、リレーシーケンス制御、についての情報を収集する心やさしいエンジニアです。
第6回（２００４．０２．１０）：ソフトPLCについて考える準備をする
いっちょライセンスフリーなソフトPLCエンジンでも書いてみようかと思い立ちました。←いえ，実は何年も前から妄想を続けているのですが，最近プログラミングスキルに自信がついてきたもので。
さて，PLC実行エンジンを書くのはそんなにたいしたことではありません。特にインタプリタ型であれば，エンジンのコアは1時間もあれば書けてしまいます。そしてコンパイラ型について検討していて以下のようなことが頭を巡りました。
コンパイラ型エンジンを作るには，ターゲットマシンのCPUの機械語をラダーから生成しなければなりません。ラダー図から機械語を生成するのは骨ですが，ふと考えるとニモニック表現というものがあります。
例えば，X00オンでY00に自己保持かけて，X01オンで自己保持を解除するラダーネットワークを考えますと，
TODO:ここに図を入れる。
ニモニック表現では，
LOAD X00
OR Y0
ANDNOT X01
STORE Y00
END
という風になりますね。（ここで使うニモニック定義は擬似ニモニックです。実在しません。）
少しここで飛躍がさせて，これをマイコンのアセンブラのソースコードだと思い込んで見てみるとどうでしょうか。ここでは私のネイティブランゲージであるZ80のザイログニーモニックで書き下ろしてみます。Aレジスタの省略は避けて，擬似ニーモニックを使います。
LD A, (ADR_X00)
LD HL, ADR_Y00
OR A, (HL)
XOR A, &HFF
LD HL, ADR_X01
AND A, (HL)
ST (ADR_Y00), A
HALT
なんということでしょう（ビフォーアフター風・声はサザエさん）。ラダーニモニックがザイログニーモニックに（ほぼ）1対1で対応するではありませんか！これなら，数千ステップくらいまでのラダーなら，鼻歌交じりでZ80に移植できそうです。
さらに，最近はやりのH8やSH,いわんやPentiumなどでは，HLレジスタによる間接アドレッシングなんて不要ですから，もっと楽チンに1対1対応できます。（いわゆる直交性が良い命令セット。したがってZ80においても，アセンブラマクロで擬似的に直交性を向上させれば楽になります）しかもしかもですよ，Z80のように命令ごとに必要クロック数が変化することすら考慮しなくて良いのです。＞今時のマイコン
つまりこれは，コンパイラ型のエンジンはラダーニモニックと機械語の対応表だけで作れてしまう（つまりエンジンコアに必要なプログラミング量は限りなくゼロに近い）ということなのです。
ところがどうでしょうか。世の中には馬鹿というか，間抜けな人がたくさんいます。例えば海外には，PLC2CなるラダーをCのソースに変換するというちょ～間抜けなツールが実在します。一所懸命ラダーをグラフ理論で解析して，Cのソースを吐き出しているようです。うがー。ばっかじゃーん。
あるいは，既存ラダーをマイコンのプログラムに置き換える，上記議論を知っていればぼったくりとしか思えない金額設定の設計サービスが実在します。彼らはラダーをニモニクに変換し（時にはメーカー製ツールで一発変換し）それをマイコンのアセンブラに変換しているだけなのです。手数がかかりそうですが，そんなもんはMELSECならラダーヘルパーのニモニク出力機能と，Perlスクリプトで仕組みさえ作ってしまえば，瞬殺ですがな。そりゃ特殊命令とかCPU間通信とか使ってるのは一発では移せないでしょうから，見積もり段階で蹴ってるんでしょ？うがー。汚ねー。楽な仕事だけでぼったくってやがる。それなら古いPLCを新しいPLCでリプレースするだけにしとけよなー。どうせ一番コストがかかるのは現状把握と再配線なんだからよー。
さて，大昔のPLCを知っている人なら上記の話はただの昔話です。休憩時間の喫煙所でぼそぼそ話すネタ話に過ぎません。なぜならば，そもそもラダーニモニクとはマイコンのアセンブラニーモニクだったからです。当時の作業--->ラダーを書くときはまずラダー図を紙やCADで描いてから，ニモニクに落とし，ROMに焼いてPLCに挿します。おや？これはマイコンのソフト開発とほとんど同じですねぇ。もちろん今時はROMに焼いたり，紫外線で消したりする作業なぞ忘れ去られていますが，基本は同じことです。
その後の進化の過程で，ROMをPLC機上で編集できるようになったり（ROMライタ機能），ラダー図で編集するツールが用意されたり，いつのまにかPLCの中のマイコンのニーモニクとラダーニモニクが同じものでなくなったりしただけのことなんです。
そんなことすら知らずに，調べずに，気づかずに，「やったーSH/H8マイコンでPLCエンジンでけたよー」とか喜んでる企業/人に対してここでこっそり後ろ指差しておきます。中には確信犯もいて，しらじらしくあたかも新しい技術のように売り込んでいる会社もあり，少々腹立たしくもあります。（あえて名前は伏せますが，業界ではちょ～有名な所です。）
技術者たるものケンカをふっかけるなら技で勝負したいです。まずはWindowsベースのPLCエンジンとその開発環境です。目標は「ラダーで書くHello, World!」こうご期待←いったいいつになることやら
第５回（２００３．７．１２）：PSD理論て何すか？
ネタ整理しているあいだにPSD理論自体がフェードアウトした模様なので没。
第４回（２００３．２．１）：状態遷移の表現いろいろ
ごりさんが、掲示板に書いておられましたが、
シーケンスの定石で、状態が次々送られてゆく（この言い方はおかしいか）のがありますね。・ある条件で仕事１が始まり
＃こに再起動防止がつくことが多い
・終わるきっかけで次ぎの仕事２が始まり
・どんどん進んで最後の仕事が終わると、最初にもどったり、次の仕事群にわたったり
てなやつで、普通、自己保持で書きますね。
これについてつらつら書き留めておきます。
私が把握しているパターン分類
- ラダーで書くパターン
- 自己保持で書く
- セット/リセットで書く
- レジスタで書く
- SFCで書くパターン
- そのまんま
- C言語で書くパターン
- switchで書く
- タスクで書く
細かい説明の前に、言葉を決めておきます。ごりさんがわかりやすく説明してくださっているので、それに対応させて私の言葉を定義します。←そのまま書けよ・・・
動作←ごりさんの言うところの「仕事」
ある状態では、バルブAとモータBをON、みたいな。
状態←ある動作をしつづける状態（もはや禅問答）
～動作をし続けていることを「これは～動作をしている状態だ」と思い込むことが味噌かも。
現在の状態←現在実行中の動作に対応する状態
コンベアを5sec間作動中、とか（次はコンベア減速）
状態遷移←ある状態Aから状態Bへ移ること。歩進と呼ばれたり。
コンベア5sec回ったので、次どうぞー、みたいな。
遷移条件←ごりさんの言うところの「条件、きっかけ」
5sec経った、光電AがONした、近接BがOFFした、あるいはその組み合わせ、みたいな。
１．ラダーで書くパターン
自己保持で書くか、セット・リセットで書くかは、「セット・リセット使うべき/使わないべき/使っても良い」の論議があろうかと思いますが、さして違いはありません。
レジスタで書く場合もさほど違いはありません。カウンタで書く場合もあるかも。
特徴的なのは、レジスタで書く場合は、現在の状態を、レジスタに入っている数字で表すことです。つまり、レジスタ方式（勝手に命名）では一連の動作（あるいはそれに対応した状態のかたまり）を表すのに１個のレジスタで済ませることでしょうか。自己保持やセット・リセットでは、状態１個にコイル１個が必要ですね。
（わかりにくいから、図で例示すべきなのかも）
動作状況のモニタでは、状態を表すコイルのON/OFFでどこで止まっているか一目瞭然ですね。あとはそのコイルをサーチして、次の状態へ遷移するラダーの条件を見ればイッパツ！
２．SFCで書くパターン
SFCはStateFlowChartですから、状態遷移図と一般的には訳されると思います。←単なる思い込みかも←ほんとに思い込みでした。正しくは、シーケンシャルファンクションチャートらしいです。
ですんで、どの状態で、どんな動作をし、どういう遷移条件で状態遷移するか、をスマートに記述できる（ことを目指している）のです。
私自身は使ったこと無いので、いまいちコメントしづらいです。
３．C言語で書くパターン
switchで書くのがほとんどだと思っています。規模が小さかったり、状態遷移が複雑でない（ほとんど一筆書き）場合はラダー同様、カウンタなどで済む場合もあり。switchの実行が遅いと盲信している方々はifに展開したりするようですが。
switchでの実装は、ラダーのレジスタで書くパターンと全く同じと言って良いです。変数１個で１連の動作１まとまりを表します。
タスクで書くパターンは、説明難しいです。ぶっちゃけて書くと、状態１個にタスク１個が理想です。OSとかじゃなくて、マルチタスクモニタとか言われてた頃は多用されていたはず。←今もか？
状態遷移は現在タスクが寝て、次のタスクを起こすように実装します。あるいは、タスクが変化したりする実装もあり。
タスクの切り替えオーバーヘッドが味噌になってくるので、Windowsとかのスレッドで真似をしても使いものにならないことだけ、書き添えておきます。
問題は動作状況のモニタですが、switchのパターンは変数を見れば、現在の状態はわかります。どの条件待ちかも見れるようにしておくのがベストです。
タスクの場合は、タスクの動作状況をモニタできる仕組みがないと辛いです。
ここでは「動作」に限定しましたが、これが「処理」になっても同じ理屈です。ですので、パソコン、マイコンや汎用機のソフトを作っている方々も、「状態遷移図」を使います。UMLでも書けます。呼び名や、表現方法が違うので、お互いあまり知らないのかもしれません。また、ガッコでは、有限状態機械（FSM）と読んだりもするので、ソフト屋さんにはこっちの方が通じやすいかもしれません。
ちなみに私は以下のようなマンガと、表を書いてから状態遷移を実装します。（ラダー、C問わず）
こいうものは、ラダーかSFCかC言語かは無関係に使えます。しかも再利用・流用ができます。
実装する前に、この図からタイミングチャートを書いて、要求仕様のタイムチャート（あるいはメカ屋さんのサイクル線図）と比べて検証したり、必要な異常処理を洗い出ししたりします。特にタイムアウトの種類などの洗い出しには効果テキメンですね。
状態名
状態の説明
動作
コイル
S0
初期状態
なにもしない。
M100
S1
お湯出し中状態
お湯を出す。Y01オン。 タイマーで時間を計る
M110
S2
上下動作中状態
上下に動かす Y02オン、オフを６回繰り返す。
M120
S3
前に出し中状態
カップを前に出す。 Y03オン。
m130
S3
終了状態
なにもしない
M140
図・表を書いておくと、状態遷移が入れ子になったり、複数パラレルに走ったりする場合は特に強力です。
C++や、「オブジェクト指向」の考え方に染まっている方の中はswitchでの状態遷移の実装をボロカスにおっしゃる方がおられるので、お気をつけください。
また、通信プロトコルの設計などに用いられる状態遷移表や、ロジック回路の論理圧縮に用いるカルノー図、なども同類だと思っています。根っこは同じかと。
書き足りないこと、たくさんありますが、この辺にしておきます。
お勧め検索キーワード：状態遷移、状態遷移表
第３回（２００２．１２．１４）：シーケンス制御におけるインターフェイス
PLC1台で、シーケンスを制御する場合、制御装置内で必要なI/Fは、全てラダー内に収まってしまいます。
それでも、いわゆるステッパなどの状態遷移機構を持つ高度なラダーの場合は、複数の状態遷移の間の関連があるために、暗黙的なI/Fが存在します。
複数台のPLCをIOなどで通信する場合は、明示的にI/Fが設けられます。
特に設備に搬送装置などがからむ場合、I/Fはトラブルメーカです。さらに、担当者や施工業者が異なると、事前にいくら細かい協議をしておいてもなかなかうまくいきません。
それは、他装置とのI/Fというものが、その重要性の割に、軽視されているからだと、考えます。
もっと言えば、装置間のI/Fについて、深く掘り下げた研究結果などをラダーマンは見たことがありません。
比較にはならないかもしれませんが、インターネット技術を支えるプロトコルは多くの技術者によって議論され、鍛え上げられて今日に至っていますが、装置間のI/Fのプロトコルというものが存在しないことが問題なのかもしれません。
IOを1本つなぐだけでも立派なI/Fですが、それをどういうときに、どう使うべきかについてもっと考えなければならないでしょう。
ちなみに、大きな工場を持つ会社や、設備の保守・保全コストを真剣に考えているユーザは自前のI/Fについての規定を持っていることがあります。しかしながら実際は、よく出入りする納入業者によって、その精神や時には規定そのものが捻じ曲げられていることがあります。あるいは、規定にかかれている内容に穴がありすぎ、解釈によってどうとでも取れてしまい、納入業者間の協議の結果、落しどころが決められてしまうような実情もあるのではないでしょうか。多くの規定は、すでにメンテされておらず作成者がいなくなってからは見直されれることもないのです。大きな組織ではもっと確りと規定がメンテされていますが、現場で必要なものが漏れなく含まれていないのもこれ現実でしょう。
手始めに今回は、シーケンスでよく見られる（とラダーマンが勝手に思い込んだ）IFの代表例を列挙してみます。書きにくいので、装置を擬人化して書きます。
・受け渡し系
半製品などを、次の装置に受け渡しする場合
・インターロック系
動かないで！
・情報やりとり系
半製品に関する情報をやりとりする
装置の稼動状況を上位システムに報告する／上位システムから指示を受け取る
第２回（２００２．０５．０４）：EZSocket
三菱電機さんは、数年前から、EZSocketを展開し、MELSECを取り巻く開発・設計・保守をからめたサードパーティ網を構築しようとしているようです。2000年のJIMTOFくらいで見かけたようにラダーマンは記憶しています。制御機器関係の展示会などではもっと早くから取り組んでおられたと思いますが。
ラダーマンはこういう方向づけは良いと思います。まだまだ契約したパートナーにしか情報を公開しないようですが。
いろんな、プラットフォーム、ＯＳに対応することをメーカの責任だけでもって実施するのは大変でしょうし、どうしても対応が遅くなります。
三菱電機さんだけではないのですが、どこのＰＬＣメーカさんも、ラダー編集ツール(MELSECならGPP!)で作成したデータを２次加工できるようにしていただきたいものです。
例えば、社内規定でレジスタの割付方が決まっていたとして、そのチェックをしようにも、GPP上でディスプレイとにらめっこするしかありません。
EZSocketはそういう環境を整えてくれるはずなのでラダーマンは大いに期待しておりました。
が、悲しいことに、現場のラダーメン達は保守的で、ただひたすらＧＰＰを叩き、画面上のラダーをにらみ、印刷したラダーを追いかけつづけるのです。
確かに歴戦のラダーメンはラダーの設計～立上までに関して恐ろしいほどの生産性を持っています。そこらにころがっているような、ＰＣベースの「なんちゃって」コントローラベースのシステムに比べて、ものすごい安定性と実績を持ったシステムを構築できます。ですが、「人の書いたラダーは触れない」「メーカの違うＰＬＣは触りたくない」「ラダーの標準化などできない」…ないないづくしです。それでいいのでしょうか。
先人に教わったノウハウだけでこの２１世紀を生き残れると本気で考えているのでしょうか。
ラダーマンは、自分の将来が心配です。最近のＰＣベースのコントローラなどの氾濫を見ていても、「シーケンス制御」の魂が感じられません。
先人が築き上げた「シーケンス制御とはなんぞや」を今後も引き継いでいくには、ラダーメン達も積極的に新しい技術に触れて、
・これまでのＰＬＣによる制御システムの良いところ
・２１世紀に求められている制御システムとは
に少しでも知恵をひねって欲しいところです。
そうでないと、世代の断絶により、見かけだけ「ＰＬＣよりも高速・高性能・高信頼性」のコントローラが現れた時に、それを利用する技術者達はまたゼロから「シーケンス制御とはなんぞや」を（数々の失敗を繰り返した上で）積み上げていくはめになってしまいます。こう言ってはなんですが、「ソフト屋さん」の書く「シーケンス制御」はとんでもないものです。
リレー盤からＰＬＣへの移行では断絶はなかったようです。しかしそれは、リレー盤でシーケンスを設計していた先人が、必死になってＰＬＣに彼らの魂を吹き込んだからではないでしょうか。
今まさに、新しい移行（パラダイムシフト）が起こりつつあるとラダーマンは考えています。
第1回（２００２．０１．２７）：リンク集め
PLCの歴史については、
ISA-JTechnical Keynote(ＰＬＣ制御の歴史)
を見つけました。「ＧＭがＰＬＣの要求仕様をまとめた」云々についての記述が対立しているような気がしますが、あまり気にしないことにしましょう。
プログラミングについては、
などを見つけました。
ラダーマン個人は、使用しているＰＬＣのメーカによって得意・不得意があると思うので、あまり汎用化された設計手法などはまとめにくいと考えています。
どちらかというと、「人を殺すな」「機械を壊すな」「電源を焼くな」というような現場の実学の鉄則を元にプログラミングできることの方が重要かもしれません。
ちょっと見つけたツール類としては、
などがありました。
「連枝」はトラ技の広告でご存知の諸兄もおられるかと存じます。
第0回（２００２．０１．２７）：独り言
シーケンス制御をなめてはいけません。被害妄想かも知れませんが、ＰＣ系ソフト屋さんはラダーを原始的なもの、古臭いものと考えているような気がします。
マイコン系ソフト屋さんは、これまたＲＴＯＳがどうとか、古くはリアルタイムモニタがどうとか、タスクコントロールブロックがどうとか、小難しいことを並べ立てて、シーケンスのバグの原因の言い逃れをしているように見えます。
ラダープログラミング、ＰＬＣは決して古臭いものでも原始的なものでもありません。正しく設計さえすれば、保守性、可読性に著しく富んだ制御システムを構築することができます。
ラダーマンはシーケンス制御屋さんの味方ではありませんが…
シーケンス制御屋さんも、昔は先進的な制御ハードやソフトに意欲的に取り組み、そして自動化設備/装置の進化に大きく貢献していましたが、最近は「保守的になりすぎている」と言わざるを得ません。
ラダーマンは、シーケンス制御屋さんと他のソフト屋さんが仲良くなれる掛け橋になりたい…
そして自動化設備/装置の制御の、進むべき道について皆さんと語らって行きたい…
ラダーマンの部屋は，ラダーマンblogへ移動しました。
ラダーマンにご意見のある方はごみためまん宛にメールをいただくか、掲示板にお書きくださいませ。
