はじめに：ラダーとSTの変換に関する質問
明日のファクトリーオートメーションへようこそ。 メインパーソナリティの高橋です。
クリスです。
はい、よろしくお願いします。
よろしくお願いします。
ラジオネームは、生産技術の実装により いただいております。ありがとうございます。
ありがとうございます。
こんにちは。いつもためになるお話、 ありがとうございます。
ラダー言語とST言語の変換について ご意見をお聞かせください。
ラダー言語は活性化していないラングに ついているコイルはオフになりますが、
STのイコールは全てセット命令でなされます。
ラダー名プログラムをSTプログラムに 変換する場合、
明示的にコイルのイコールトゥルーの場合と コイルのファルスの場合を書かないといけなくなりますが、
面倒だったり、森が出たご経験はないですか ということでございます。
ラダーのコイルとSTの代入命令の挙動
えっと、ちょっと待って、まずイコールですよね。
イコールはセット、でもこのサイクルは 修理になることだけだと思うんですけど、
別セットかなってなることは思いませんけどね。
いやイコールは基本セットですよ。
セットは、まあマチュアの意見はセットは、 もう気を使っているのは初めて。
セットは、一回チューになったら、 一回この値を書き込んだら、
次のループ、これからのループの中でもう一回上書きされないと、 ずっとこの値になると私は思っているんですね。
でもイコールは、今このイコールの後の条件が、 AND、ORがたくさんあって、
毎種サイクルにこのAND、ORの条件によって、 この値が演算結果が変わるというのがイコールですよね。
ここでイコールっていうのは、ラダーのコイルと同じようになりますか っていうことを言っている話なんですね。
イコールじゃないか。
イコールってこれ代入っていう意味のイコールですね。
STの代入っていうのはセット命令をイにしますよね っていうことを言っています。
でも代入って…
例えばラダーっていうのは、いわゆる、 トゥルーとフォルスが一つの命令で実現されているわけですよね、コイルっていうのは。
ああ、そうですね。
だから一回通ったら、絶対にトゥルーかフォルスになります っていうものじゃないですか。
でもSTっていうのは、トゥルーとフォルスっていうのは 別の命令を書かないと実行できないですよね。
はあ、はいはいはい。
え、でもさ、例えばね。
例えばY1がイコールX1&X2のプログラムあるとして。
例えばこれも結局、一つの回路、一つのステイマンで トゥルーとフォルス同時実験実装されているんじゃないですか。
それは2文書かないといけないですよね、F文で。
いやでも、直接Y2イコールX1&X2書けるじゃないですか。
え、なりますか。
えっとちょっと待って、今収録チャンネル書いておきまして。
私はこれ書き方してるんですけど、セット中でY2はX1&。
ちょっと僕今YouTube入れてるから見れないっす。
ツイッターで送りますね、ツイッターで。
こういう構文はどうですか。
これはY2がフォルスには。
これだったら一つ構文で。
なるのはなるね、はい。
でもこれだと問題はたぶんめっちゃ長くなるので。
上下によってはたぶんかなり見にくいんですね、これ。
上下なくなると。あとたくさんカッコとか入れなきゃいけない。
そうですね、確かにこの書き方だったら毎回トゥルーかフォルスになりますね。
STでの記述の複雑さとテストの課題
話戻るんですけど。
ただ、これをSTで書くかっていったら書かないですよね。
書かないですよ、めっちゃ書くんですけど。
これ短いから言ってるだけでしょ。
めっちゃ長いんだったらやらないな。
めっちゃ長かったらやらないですよね。
中でオワとか入れ子になりまくったら書かないですよね。
20個だったらオワだったらもうちょっと別の方法やるね。
やりますよね。例えばアンドとオワが3個ぐらいのグループ、5個とかあったらもう書けないじゃないですか。
たぶん中間で、中間変数挟んじゃうんですね、STやっちゃうと。
ですよね、そうなったら分割したりとか、まあたぶん。
まあでもクリスさんの意見わかる。まあコースで書けるよっていうのは確かにそれはそう。
まあちょっと話戻るんですけど、チューとフォースは結構漏れました、今でも。
やっぱり一回チューしてとしたら絶対フォースしなきゃいけないじゃないですか。
またリセット忘れたとかね、たまに出ますね今でも。
これたぶん、なんか一個一個チェックするんですけど、
まあでも結局なんでかな。何言えばいいんだろう。
今たぶん私たち人間でチェックするのはしょうがないんですけど、
たとえば今のユニットテストのフレームワークが回ってて、
そういうのが自動テストもできるので、こういう自然テスト、自然漏れテストとかもできるんじゃないかなと私たちの意見ですね。
うーん、でもそれテストが漏れるでしょそれ。
そうです。
いや正直、要はテストでそこを認識できてるんだったら苦労しないよねっていう。
そもそもこれテストのケースも漏れてるということは考えなくないなと思ってます。
いや全然あるんじゃないっていう話ですよね。
ラダーとSTの根本的な違いの再確認
とりあえずさっきのクリスさんの話を一旦わかるように話をすると、
今まずこのセンサー技術の虫さんが言ってるのは、
コイルでラダーを書いた時っていうのは毎回実行された時に絶対にトゥルーかフォースになりますよねっていう。
それに対してSTの代入だとイコールトゥルー、イコールフォースっていうセットをした時に、
これはセット命令がイコールでその関係が維持されると。
維持っていうのは保持されることになるよねっていうことを言ってると。
それに対してクリスさんは、いやいやこれはSTのイコールの右をトゥルーかフォースに固定するからそういう風になるんだっていうことを言っていて、
そこに例えばブルー台数みたいな、例えばA and Bみたいな。
いわゆるラダーの左の条件みたいな条件の代入式を書くと、
例えばコイル、コロンイコール、その右側は毎回トゥルーかフォースに判定されるような計算式をブルー台数で書いちゃえば、
ラダーと同じようにどっちかに収束するよっていう、私はそういう書き方をしてますよっていうことをクリスさんが述べていて、
僕もそれは確かにそうだなって思いましたっていう話がまず最初ですね。
でも条件が長くなるとこれは無理があるということもタカさんが言いましたね。
そうですね。ただ異常処理とか簡単な異常処理はそういうことで書いていったり、あとは切り方ですよね。
何かをNGというか、例えば非常停止状態とかある状態になったときにこの辺の命令はすべてオフになってほしいみたいな。
そういうときにはそういう書き方っていうのが一つテクニックとしてはあるんだなと。
クリスさんに今日めっちゃ勉強になったなって思ったんですけど。
設計思想の違い：ボトムアップとトップダウン
ただ僕の意見としてですけど、まず設計の仕方がちょっと違うんだろうなっていうのは思ってます。
ラダーとSTですね。
多分状態遷移の書き方とか設備状態の考え方っていうのはちょっと異なる気がしますね。
ラダーとST書いたときっていうのは。
ラダーでいうと、状態遷移の書いたら結構大雑把な感じがしますね。
結構自律分散的にやっていく書き方をすることは非常に多いような気がするんですけど、
STの場合は結構状態管理っていうのをトップに持ってきて、
集中管理的に書いていくっていう方が多いんじゃないかな。
従順的に管理が入る。
ちょっとここピンの2件、あんまりイメージ動かないんですけど。
なんていうのかな。
ラダーってどっちかというとカッコ動作をすごく意識した書き方をするような気がする。
あとはこのコイルをどこの直接直結しているか。
どのシリンダ直結するかを。
そうですね。
中心で考えているということですね。
そうですね。まずそのあるユニット単位のまとまりを記述して、
それをどの順番でやっていくかみたいなそういう書き方をすると思うんですけど、
どっちかっていうとSTの場合は先に状態から設計して、
例えば状態遷移でこういう順番でフローが走りますっていうと、
まずそれを設計して、その後にその状態のところに書く命令を書いていくみたいな。
今の下から書いていくか上から書いていくか全然違うような設計をしている気が僕はするんですよね。
確かに今まで見たペコフさんとかコディスさん、コディスのサンプルフログラムも
例えばK7でやっちゃうと、だいたいみんなK7の中で挟んじゃうんですよ、動作全部。
でもラーダーは多分そんなことしない、直接しないんですよね。
ですよね。
だから一番最初にSTのプログラムをゴリゴリ書く人のプログラムを見たときに、
全然思想がわからなかったんですよね。
同じ動作する命令を何回も何回も使い回しをせずにベタ書きで書いたりするんですよ。
何回も若き若きするんですね。
若き若きって。
フォース、チュー、フォース、チュー、フォース、チュー、フォース、チュー、何回も繰り返すんですよね、同じの変数を。
そう、これどうやって不具合があったときに、どこが何をしたかどうやって判別するんだろうってずっと思ってたんです。
そう。
で、これからで終わってしまう。
タンボって言うんですね。最初全部リセットする。
そう。
その後に真ん中で管理するみたいなイメージですね、彼ら。
難しいと思ったのはやっぱあって。
で、それもよくよくそこから5年ぐらい、そのSTを我々やる人たちとか含めて付き合っていったときに、
なるほどなという出発点が違うのかということになんとなく気づき始めた。
って自分の中では思ってますね。
インスタンスの概念とPLC設計論の欠如
自分に言ってるかけがわからないです。最初に全部状態をまとめてから、管理してから進めるんですよね、だいたい。
そうですね。僕はだから装置考えるときってもう状態のこと全く考えないですからね。一番最初とりあえずまず全部確保処理から全部書いていきますからね。
で、それ全部書き終わった後に初めて状態どうするかっていう話をその上にくっつけていきます。
でも見たとき、STだと全部状態、動作、ワンセットになっちゃったんですよ、みんな。ワンセットになってる。
そうですね。なので僕はね、命令は分離できるなっていう意見を持ってるんで。
なんかその状態のところにここに絡むものが複数書かれているっていうのは違和感、めっちゃ違和感がある。
そう言われると確かにそうだね。
それから彼のフォースチューも何回繰り返すを使うのも理由の一つかもしれないですね。繰り返し買い回してるとかもそうだかもしれないですね。
そうですね。いわゆる状態遷移がきちんと正しく設計できているんであれば、その下が間違ってたとしても終えるでしょっていう。
そうですね。
そういうことなんだと思う。
STの書き取りとかタイマーも使い回してるからね、彼らも。こういうの全部使い回してる。一個でいいでしょうとか聞かないし。
なんでなんでなんでなんでなんで状態ごとにタイマーつけなきゃいけないのとかそういうのもめんどくさくないんですかって言われて、え、あ、そうですねとかしか言えなかったんだよ。
だからやっぱりね、ラダウェって言ったらインスタンスの概念とか全然理解できないんですよ。
もう何これ、やっぱ何これと思ってましたね一番最初は。
そういうことか。だから僕が。
多分考え方のスタートポイントが違うんですよね。ポルム設計の考え方のスタートポイントが違うんですよね。
そうですね。その複製をする意味っていうのはあんまりなかったんですね。
そしたら配列のインスタンスが直されてなんで。
多分ラダウェっていう人にいまだにインスタンスってものにピンときてない人たぶんいっぱいいるんじゃないかなって思いますよ僕。
多分ファンクションブロック使ってるんですけど、でもこのインスタンスを普通に使ってるんですけど、
でもこのインスタンスってどういう意味持ってるかを、まあ僕は考えなくてもいいですけどね、そのまま使えるし、多分ね。
そうですね。まあまあなんか慣れたら不運って感じですけど。
でもたまに見たのは、普通ファンクションブロックで同じインスタンス使ったらなんでうまくいかないんだろう、これうまくいかないんだろうとちょっと何回これポルムを
私にお客さん送ってもらって、私のFPがなんでうまくいかないんですかって言って、
それは同じのFPを、違うFPを同じインスタンス使うから必ずうまくいかないでしょうって言って、
え、なんでですかというところで、まあそういうことかとちょっとたまもってたんですね。
インスタンスそこまで、このインスタンスは何のために制限されてるのかとかですね。
そうだと思うなあ。
なんかだから、何て言うんですかね、その違いは設備以外のプログラムを書いたときに何か始めて、ああなるほどなっていうのは思ったかもしれませんね。
なるほど。
一時、ゲーム作ってたことがあって、ゲーム作ってたときに、ああなるほどな、こういうやり方はまあ確かにそれがいいかもしれないっていうのは何か思ったなあっていう。
だから今、例えば今ラーダー描いたら、もうラーダーの描き方でずっと水槽で切り替えて、STだったらもうSTで水槽で切り替えてやってるんですか今の考え方というか。
どうでしょうね。
そういう意味で言うと、僕はSTっぽいSTを描けないですね。
描く技術を持っていないっていう方が正しいかもしれません。
なるほど。
やっぱり、そもそも一番最初の装置設計のスケジュールがあるじゃないですか、こういう順番で作っていきましょうみたいな。
それがもう完全にラーダー寄りの考え方をしてしまうので、まずSTでやる場合ももうそこから基本的に入っちゃいますね。
なるほど。
でもそれも私たちは高さがある。
高さがある。
高さがある。高さ前も言ったんですよね。
そもそもPICのプログラム、正しい設計論を持っていない、今でも持ってはいない、ではいないというか、
正しい設計論がまだできていないと前も言ったんですよね。
公開されたものがないっていう意味で言いましたね。
ないですよね。公開されていないので、たぶん個人的にはもうすごい自由な描き方になっていて、
それも原因の一つじゃないかなと思ったりは。
ガイドラインみたいな、ガイドラインの言い方とは変ですけど、何言えばいいんだろう。
プログラム原稿って動けば、それ以外はないんですけど、動けばもう正義じゃないですか、ある意味では。
ちゃんと動けば。
高田さんからそういう考え方、こういう思想でプログラムを設計しましょうというのがないんですよね、今。
フレームワークはない時点でないでしょうね。それがあったらもうフレームワークはできていると思うので、とても便利だね。
そう、これもないので、もう自由自体でやっているので、だからそういう、なんていうかな、いろいろ流派というか、
みなさんも自分の描き方できているかもしれないですね。
そうですね。
はい、なるほど。
プログラムの品質と言語の特性
まあ、としみじじゃないですか、ファイシャリー作りすぎよ。
フォースでなら絶対、注射なら絶対フォースで戻してねというしか言えないでしょう。
いやまあ、結局は品質の高いプログラムをどうやって描きますかって話に収束すると思うんですよね。
はい、そうですね。
じゃあ、STで描いている人たちは品質の高いプログラムを描けていないのかというと、全然そんなことはないわけですよ、ヨーロッパも含めてね。
きちんとST下で描いている人たちはちゃんと書いているし、ラダー下で描いている人はちゃんとラダーを下で描いているし。
だから品質がいいプログラムソフトは何ですかね。
それはちゃんと動くことでしょう。
ちゃんと動くのわかるんですけど、でもそれ、動くプログラムもぐちゃぐちゃのプログラムと、
ぐちゃぐちゃじゃないっていうか、ぐちゃぐちゃの言い方たち、どういう言葉で言っていいのかな。
で、動くは正義だと前提だとして、その中で品質が良くないのは何ですかね。
いや、まず仕様通り動くか動かないかということが最重要じゃないですか。
そうですよね、これ動けばもう品質が良いプログラムと言えばいいですよね。
動くという意味ではね。品質が良いというのは、全てにおいて品質が良いという一まとめにしているというのは、いくつかに分類はされると思いますよ。
僕の意味から見るかもしれないですね。
僕からの意味の品質が良いのかもしれないですね。
まずは納品物という意味では、その仕様通りの動作をきちんと実行できることということですよね。
そうですね。
これがまず納品品質なわけじゃないですか、機能品質ですね。
それに対してメンテナンスの品質とか、プログラムをかける時間はどうなのかという構成品質みたいなものも当然あるじゃないですか。
それはどれを重視化するかというのは当然案件によりますよね。
そうですね。
なるほど。
グラインダーでは納品品質だとメンテナンスの品質もそうですし、拡張性とか。
いろいろな面に関してトータルでどれくらいの質を決め、判断する、評価するという意味ですね。
言えるんですかね。評価する。
ケースによりますよ、どれをどう評価するかというのは。
そうですね。
そうだと思います。
なるほど。わかりました。
動けばいいと言っているわけではないです。
でも僕は最適な条件ですね。動きてバグないのは最適な条件ですね。
そうですね。それがやっぱり一番大事なことですよね。
それを実現するためにはさっきのメンテナンス性であったりだとか、過読性であったりとか、こういうものが必要になってきますよねっていうのも当然あるでしょうし。
わかりました。
結局、動くんだったら見なくていいですからね。中身、プログラム。
そうですね。正しく動いていないからみんな中身見ちゃうんですよね。
そうですね。正しく動くことが保証できているようになったら別にプログラムの中身見る必要なんて何にもないんで。
正しく動いていないから中身見ちゃうから。
そっか。品質いいプログラムだったら中身見なくていいので、ちゃんと動いていたら中身見なくていいので、ですよね。
じゃないですか。
わかりました。了解しました。
ちょっとまた最初の話がかなりずれたような気がしますけど。
いつもずれますから話が。
まあね、ラダーとST、どっちもめんどくさいんですよ。
どっちもめんどくさいです。
どっちもめんどくさいですね。
ラダーはラダーで書き方みたいなのはシンプルですけど、とにかく量が多いのと、キーボードの制約が多い。
ひたすらに矢印を連打して、コイルの変数やコメントを打ってみたいな。
これをキーボードだけでやれる人っていうのはすごく高度なスキルを持っている人で、どうしてもラダーは書く速度が出ないんですよね。
ホットキー覚えてないもん。
Aセッティングは何のキーボードか覚えてないですよ、今でも。
そうですね。
STに関しては全部文字で書くので、キーボードで書いたら速度は出るんですけど、構造的に書くっていう、ガイドする機能があんまりないので。
構造的にガイドする機能?
構造的に書くこと。
こういう書き方をすれば大丈夫ですよみたいな。
そういう構造的に書く、ガイドする機能っていうのが、ラダーに比べては少し薄いので、ちょっと品質悪くなりがちだとは思います。
人寄りますね、これまた人寄りますね。
で、ラダーだとだいたいこういう書き方が見やすいとか。でも標準回路決めやすいですよね。
そうですね。
標準プルーも決めやすいんですよ、STより。
そうですね。STは結構書き方変わっちゃいますからね。ラダーだったら例えばインターロック信号みたいなところがすごい量になったとしても、別に書き方変えないじゃないですか。ひたすら同じところにひたすらものが増えていく感じになりますけど。
全部文信号で、プルー信号で並べるだけですね。
そうですね。でもSTはそうなったら多分書き方変えると思うんですよね。
例えば、十半生で挟んだりとか。
それが増えすぎたらまた見にくいからちょっとやり方変えてみたいな。
多分あんまスケーラブルじゃないんですよね、そこが。
これ結構難しいところだなって思いますね。
PLC言語の現状と未来
なるほどね。
ネストがすごく深くなったら本当に見にくくなるとか、ラダーは割とスケーラブルな気がしますね、そういう意味で言うと。
なるほど、なるほど。
だるいんですけど、2倍に増えたら2倍だるいなみたいな。
でもSTはもう何倍だるいか分からないですね。
そうですね、5倍に増えたら10倍だるい気がしますね。
それでまた変な発想で変な書き方をし始めて、それでまたラダーは素直ですよ。
素直ですね、ひたすら多いだけですね。
そう、素直。
多いなって思うけど。
高谷さんおかしな脳筋のことを思い出したよ。
脳筋?
ラダーの脳筋のことを思い出した。
でも難しいカードもできるんですけど、ST比べるとやっぱりシンプルはいいなと思ってます、ラダーは。
結局STは経験値が足りないっていうのは非常にほぼほぼのところを占めてるような気はせんではないですけどね。
でもST書かなくても困ることもあんまりないじゃないですか、多分ね。
いやどうなんでしょうね。
だって今のラダーに問題ないかって言ったら問題ありまくりじゃないですか。
ありますね、あれもあるよ。
そのラダーに問題がなかったらみんなラダーはクソだみたいなあんなXのポストが出ないですからね。
そうですね。
だからやっぱりラダーにはそれなりに不安があってっていうのは間違いないと思いますよ。
なるほどね。
STもSTだからSTはシフトしてみたい人も多いんですよね、STより。
要はラダーじゃない何かに変える必要があるんじゃないかと思ってる人たちたくさんいて、その候補の一つにSTは上がっていてっていう段階だとは思いますね。
なるほどね。
でSTがじゃあ、いやもうこれからSTですよ、ST価値覚ですわとまではまだ言ってないと思います。
まずまだ探せる方ですね、ラダーじゃない何かを探せるという。
探してるってのは間違いないんじゃないですか、多分ラダーに見切りつけてる人いっぱいいると思いますよ。
なるほど、これからもう増えないかな言語、もう増えないですよね、PFCは。
いやわかんないですよそれは。
もう思いつかないね、ほかにどんな言語が増えるんだろうって思いつかないね。
いやでも直近で言うとNode-REDみたいなの出てきたじゃないですか。
こっちか。
ICに取り込まれるかっていうのは別ですけど、新しい言語形態が出ないかどうかって言うと出るんじゃないですか。
そうだね、あ、そうか、Node-REDでもいいですね、でも立派な言語ですからね、ロード式も。
そっか。
そう。
出てるかもしれないですね。
例えば安全PFCとかだと、PILSみたいな、ちょっとよくわからない、いろんなものを貼り付けていくような。
ごめんね、そうですけど、ごめんね。
いや、よくわからないってのは否定趣味じゃなくて、表現できない、言葉にできなかっただけです。
そう、まとめてそうですよ。
あれも新しい形態じゃないですか。だから言語フォーマットは増えるんじゃないですか、これから。
増えないですね。
提案はあると思いますよ。
今後新しいIC言語が増えるかどうかちょっとまた楽しみにしてます。
ICは増えないと思うけど。
だって次の議論だって10年後じゃないですか。
じゃないな。
次2035年ですよ、議論があるの。
ほい。
改定が、5thね。
もう2035年はまだPFCやってるかもわからないしな。
そこまで入らないってことですかね。
まあ、ですね。
そうか、そうか。
でも配置はあったんですよ、ILとかも配置したんですよね。
確かに配置しましたっけ、ILは。
いや、非推奨だと思うんですよ、まだ。
まだやめてないですけど、もう使わないでねということですね。
非推奨にあってると思います。
まあ、って感じですね、IL。
使いたくない。もういいです、あれは。
もうCMASYもだんだん使ったからもういいです。
そうですね、はい。
というところでですね、コイルとST、NADAとSTについて少しお話をしたというところで、
これから頑張っていければいいと思いますね。
はい、皆さんありがとうございました。
