CODESYS言語の使い分けに関する質問
アッシャーのファクトリーオートメーションへようこそ、メインパーソニティの高橋です。
クリスです。
はい、よろしくお願いします。
よろしくお願いします。
はい、ラジオネーム RemoteIOさんからいただいております。ありがとうございます。
ありがとうございます。
お世話になっております。
軽装機器メーカーに勤めるものです。
自社が、初 PLC 確保レストをリリースしました。
使い方をCFCで勉強し、最近はAIに頼りながら、STでお遊び程度の反則用プログラムを書いています。
質問です。
CODESYSの各言語の使い分けや好きな言語のアピールポイントを伺いたいです。よろしくお願いします。ということで。
最近流行ってますね、CODESYS PLC を。
いろんなメーカーが。
そうですね、おめでとうございます。
リリースしましたね、おめでとうございます。
どこかちょっと分からないですけど。
いや、僕なんとなく分かりましたよ、これ。
マジか。
見ちゃダメですよ。
いや、多分MGだと思う、僕これ。
見ちゃダメですよ、これ。
いや、当たってるかどうか分からないけどね。
IFSでCODESYSのPLCを発表されたところが多分あそこだと思うので、多分そこじゃないかと。
そこで、使い方をCFCで勉強して、AIでちょっと頼りながらでSTを書いていると。
で、この書く原稿の使い分けやお好みの原稿のアピールのポイント次第ですということですね。
CFCとFBDの使い分けとグラフィック言語の限界
どうですか?
マジ珍しいね、CFCで。珍しいね、マジ。
使っております?CFC、高谷さん。
ありますよ。ありますというか、FBDを使うよりはSCFCを使うほうが多いです。
だから1枚の紙でブロックをたくさん置いて、それで線を自由につなげるイメージですよね、あれは。
あれは便利ですよね。
便利ですね。だからテストをするぐらいだったらCFCのほうがFBDより楽かなというので、僕はCFCを使うケースは結構あります。
なるほど。でもね、CODESYS、言い方悪いけど、やっぱりグラフ言語、弱いというか、あんま近い入れたいですよね、イメージ的にはまずは。
どうですかね、FBDとか不満あります?
FBDは、まあ高谷さんのほうにFBD使うんだったらCFC使いますね。
いやいや、それはそうですけど、なんていうんですか、FBDとCFCはほぼ同じようなもんだと僕は思ってるんですけど。
系統的にはね。
系統的には同じ、似てるもんですね。
そうそう、だからなんていうんですか、FBDよりはCFC使えますっていうのは別にそれはそれでいいわけじゃないですか、代替案があるから。
でも似てるものは似てるもんですね。
ラダーは正直さ、あのちょっと開発が足りないなっていう感じはするじゃないですか、CODESYSっていうのは。
そうね、去年だっけ、お年、ラダー2出たんですけど、あれはまだまだですよね。
ただそれはでもラダーが弱いだけであって、グラフィック言語が弱いかはちょっとまた違う話なのね。
それやったらそのFBDとかSFCどうなんでしたっけって話をちゃんとした方がいいと思う。
CFC。
CFCも含めて。
CFCは普通ですよね、普通使えますっていうイメージですよね。
ダクリスさんが、いや仮になんか微妙って言うんだったら、なんかありより使いやすいFBDとかCFCのエディターってあるんですか?
私はSteemance使ってないですけど、結局あんまり変わんないですね。
変わんないっすよね。
変わんないですね、だからなんか。
FBDは操作感的にはSteemanceはまあまあ良かったんですよ、ラダーも。操作感良かった。
でも操作感の問題ですね、結局多分。
いやだからなんかFBDがダメ、FBD、グラフィック言語が弱いっていうよりは、それはなんかFBDの限界なんじゃないですかっていう。
もうそこまで、もうそれ以上は多分無理ですということですか。
そうそう、いやなんかクリスさんがなんかめっちゃ改善点思いついてるんだったらそうですけど、まあなんかそれはダメなんだろうなって感じですけど、
多分なんかもう本質的な問題なんじゃないか疑惑が僕はちょっと思いましたけどね、クリスさんとさっき話聞いてて。
それ以上多分もうFBD限界ですということですよね、なるほど。
クリスさんがそう感じてるんだったらですけどね、だからまあクリスグラフィックが弱いとはなんか僕はあんま思ってないですけどね。
グラフィック言語の限界ですかもしれないってこと?
限界っていうか、いや単純にそのラダーが弱いことに引っ張られすぎじゃないって思っただけ。
もう、あ、コディスをダダ弱いところがどんどん解かれすぎるっていう。
っていうよりはクリスさんがそうそれに引っ張られてるんじゃないっていう、だからじゃあラダーなしで考えたときってどうですかっていうときに僕そんなコディスで不満ないですけどね。
CODESYSラダーIIの進化とAI連携
なるほど、そうなんですね。
でもラダーⅡを使ってる唯一いいところは、コディスのウェーブライセンションが見るんですね、ラダーⅡが。回路。
あれー。
そのまま貼り付けて。
どうだろうな、まあなんかその、ちょっとどうですか。
微妙なところなんだよね。
いや微妙というか。
あれね、まず1個目は更新できないですね。
更新というかその、あれってさ、まあ多分聞いてる人分かんないと思うんですけど、そのコディスってラダーⅠとラダーⅡがあるんですよ。
なんかそのプログラムが最初選べるんですよね。
ラダー、FBD、SFC、IL、STって選べるんですけど、そこにラダーⅠとラダーⅡがあるんですよ。
で、ラダーⅡが最近入ったんですよね。
ラダーⅡが最近入って、で主なアップデートとしてはその、一番大きいのは、スクリプトが書けるようになりましたと。
いわゆるインラインSTというやつが書けるようになりました。
あ、なんかSTがある。
そう、インラインSTというのが書けるようになりました。
これが一番大きなアップデートで。
で、プラスでその、コディスってHMIがあるんですよね。
ウェブサーバーでHMIを何回か付けかけるんですけど、その中にラダーエディターとかそういうものが表示できるようになりましたというアップデートがあったってことですね。
で、それがラダーⅡしか使えないよって話で。
ただあれさ、普通になんか全部は無理じゃないですか。
ここだけみたいな。
そう、ここ、しかも貼り付けないと、なんか一回あの辺のラダーの部分更新しちゃったら、もう一回生成し直してまだ貼り付けないと更新しないのかなと思ったりしてますね。
だからその、なんていうんですかね、中の技術的な要件で言うと、そのラダーエディターを呼び出してラダーを表示してるんじゃなくて、そのラダーっていう画像を切り取って、もうなんかそこにはめ込んでるみたいな。
だからそのスクロールとかもできなければ、そのプログラムに通常して勝手に変わるわけでもないみたいな。
そういうちょっとなんていうか。
日本がね、やっぱり入れてるやつに比べるとちょっと機能不足だなっていうのは正直感じるとこではありますね。
最初はチェイテックみたいなもんだと期待してたんですけど、やっぱり違うかと思ったりしましたね。
そうですね、いやでもなんか僕あれをやったこと自体になんかすげえ驚きがありましたけどね。
最初は思って、あ、こうです、ちょっとラダーの力入れ始めてるんじゃないとちょっと思いましたけど。
でもあれ以外も更新してないですからね。
でもああいうのがあったっていうことは、おそらくそういうニーズがあったってことですね、向こうで。
そうですね。やっぱり向こうそういうラダーモニターが欲しいかもしれないですね。
どこの大喜利ユーザーとか、どこの声援が拾ったかもしれないですね。
かもしれんですね。
あとインナーSTかける機能大事ですけど、でもインナーSTがモニタリングできないのはまたちょっと痛いなと思ったりしてますね。
あー、それ知らんかったな。あんま使ってないから全然知らんかった。
そう。インナーSTの中の変数は現代人に見えないですよ。
あ、そうなんすか。えー、知らんかった。
これはちょっと痛いなと思ったりしてます。
まあまあね、発展途上だから、多分発展途上だからね。
そうそうそう、もうちょっと頑張ってほしい。もう、あいつからSP21ですけど、SP22も出てたっけ?
SP22はもうすぐ出るんじゃない?多分。だってもう2月でしょ今。
まだSP21やな。
だいたいさ、3月か4月くらいに出るじゃないですか。
だからAHAの場に合わせて出てるってこと?
そうですね、まあその辺にアップデートされるのがいつもですけどね。
なるほど、一応ねSP22はAIAプログラミングが対応してるみたいね、SP22。
そうなんですか。へー。
えーと、STだけどな。
SPSでそんなこと言ってるの?
あとCODIS-GOも、ST-GOもSP22で実装するようでですね。
なるほど。
CODIS-GO。
あとCODIS-MCPサーバーもSP22でやるみたいですね。
へー。
結構AI、AIで言ってるんですね、CODISは。
まあそれは世の中の流れですからね、もうそういうのは。
あと、AIベースでSiemensのコードからCODISのSTに変換するとか、まあそんな難しくないんだよな、それは。
いろいろ工事あるんですけど、AIサポートエンジニアリングのところちょっと見えてて、SP22はたぶんまた面白い工事やるんじゃないかなと思いますね。
今それ出たらね、また試してやりましょうね。
ST言語の利便性とパラメータ管理の難しさ
ST、でもみなさんST使います?使うしかないんですけど、STも若干ビブラート、なんか最近辛い感じが出たかなと思いましたね、ST。
STは今CODISもST使ってるんですけど、私、ラダーボルンスめんどくさいから、操作がめんどくさすぎてもうSTやってるんですけど、
なんで言うかな、まあ仕方ないかなと思って使ってるというイメージが多いんですね。他のセナクシーもないし、私のスキルの中では。
どうでしょうね、STはSTでめんどくさいじゃないですか、正直なところ。
めんどくさいところがあります。
めんどくさいっていうのは何がめんどくさいかっていうと、IC言語でファンクションとかファンクションブロックを叩くときに引数が多すぎる問題があるじゃないですか。
これはね、たぶんどこのメーカーでも同じですよね。
そう、だってモーションのファンクションブロックなんて普通に引数8個ぐらいあるわけじゃないですか。
そうですよ、それは少ない方ですよね。
しかも覚えてないじゃん、そんな引数8個も覚えてないし、普通に。
覚えてない、覚えてない。
正直ね、かけにラーダーとかが多いから引っ張ったら全部出てくるから、ブロック一気に必要な変数。
あれでもまだ楽よ。
だから僕、小規模テストはFBDでやるんですよ。
なるほど、全部見えるから、パラメーター。
なるほどね。
そう、高谷さん、この間パナソニックのPOC試したときもあれもFBDでラーダーって言ってたんですもんね。
別にラーダーでもいいんですけど、コレスだったからFBにしましたけどね。
なるほど、あとさ、STって省略できないじゃないですか、パラメーター。
使わないパラメーターもできるというか、何がすればいいんだろう。
書かなくても見えないですか、使わないパラメーター、インプットとかアウトプットとか。
書かなくてもエラー引っかかないじゃないですか。
あれもまた、標準パンクブロックはいいんですけどね。
他の人が書いたパンクブロックとか見たら、これすごい困る。
そうですね、でも引数省略するのって別にSTに限って話じゃないじゃないですか。
まあじゃないんですけどね。
だってPythonだってCだって引数省略するじゃないですか、Cはちょっと忘れました。
まあ省略できますけど、でもラーダー、STさんはラーダーでFPとか呼び出すから、基本はあんな省略できないですね。
何があるのか全部言えるので。
STは省略できるのは初めて省略して、でも下から見たコード記は省略したのに、下はFPの出力直線で叩くとか、FPの有力な直線で入れるとか、
多分FP1とどんみたいな感じで直線で入れるとかもきっと見えたので、すごいややこしいなったのかなと思ったんですね。
だからそれはSTだからめんどくさいっていうよりはテキスト言語がそういう性質で。
FA分野におけるOOPの適用と標準化の壁
そういう特徴あるんですよね。
あと何あるんですか?やっぱりOOP使わないとダメですかね、CODISとか使うと。
メソッドとかプロパティとか。
どうだろうね。
クラスまで使いこなしているサンプルプロジェクトを僕はあんまり見たことがなくて、CODISのプロジェクトをいろんな平本を開いたとしても、ギリメソッドじゃないぐらいのイメージがあります。
欲しいですね、そういうちゃんと使いこなせてるクラスのプロジェクト、見たことないですよ、一回も。
でも結構ちゃんと検討したことがあるんですよ。
ICをフルでやったときに、どういうプログラムの標準化とか、いい仕組みが構築できるかっていうのを結構1年ぐらい考えてた時期があって、仕事外のところで。
なるほど。
結局結論としては足りないっていう結論になって。
CODISのこの…
CODISというか、そのIECの機能自体がそういうことを、OOPを完全にやっていくにはちょっと足りないねっていう。
なるほど。何が足りないんですか?
何が足りない?変数周りとか特にしんどいですよね。宣言が必要とか、プログラム中で変数作れないとか。
なるほどね。
最初から宣言しないといけない、姿勢的なものなので。
そうか。姿勢向いてないというか、まだ足りないってことですね、それは。
そうですね。あとデータの受け渡しとか結構難しかったりだとか。結構しんどいなっていう。だからクラスを使ってできることたくさんあるんですけど、
ただ何かそれをしたときに、プログラムがややこしくなる以上の何かメリットあるんかっていうと、何かやりきれへんなみたいなところが結構感じてるところですね。
自分も一時的にクラスを使ってみたんですけど、何か使えば使うほど自分何書いてるのかわからなくて。
多分私は設計論がないから、何か使えば使うほど、もうちょっと諦めようかなとやったんですね、自分も。
そうですね。
ちょっと分かんない。本も読んないんですよ、そういう何かオプティック思考とか、どういう時にメソッドでどういう、何だっけ、オーバーライト、オーバーライトじゃなきゃいけない、何だっけ、
エクスタントとか。
まあ継承とか。
どこで使えばいいのか全然何か把握できないというか、分かんない。今でも分かんない、そこまで。
何ですか、あんまり自由度がないじゃないですか、OPって呼ばれる子供ね。
例えば、モーターっていうクラスがあって、その中によそから正転とか逆転とかジョグとかが引っ張ってこれたらいいけど、そういうふうにはなってなくて、あくまで元のクラスを拡張するっていうことしかできなくて。
そうですよね。
やっぱり何かを組み合わせるっていうほど組み合わせられへんなっていう。
接着がこのブログコピーして、だから学びを改装するというのが多分長くなっちゃうかなと思います。
そうですね。で、何かそういうことをしても何かいたずらに依存関係だけが膨れ上がっていって、あんまり何かいい未来が見えんかったなっていうのがその当時の検討の結果かなっていう僕の。
なるほど。でも今はそこまで変わってないんですよね。
でもね、だからヨーロッパ界隈はもうOOPをこれからのコンセプトですとかすごい流れがあってみたいですけどね。
いやOOPは別にいいですけど、別にそれが要はICフル活用でやりますっていうこととは全然違うことをオーションは言ってるわけですよね。
なるほどね。
なるほどね。
だからOOPイコールースのここですかって言うと、まあ別にそうではないっていう。
そうでもない。
でもOOPだっていうこと自体は別にそれはそうでしょっていう、今のソフトウェアの流れから言うと。
我々もやってるFA協会もそういうコンセプトになるんだろうと。
いやーそれはわからんよ。
だからさっきよりなんか、いやーわからんかって言うんですけど。
いやだって、OOPにして何が嬉しいんでしたっけっていう話が本当に議論されてるのかなっていうのは思いますけどね。
わかんないですよ。クラス使ってるとは何がメリットあるんですかと。
何か誰もちゃんと答えててくれなかったなと。
気のせいかな。
何て言うんですか。
何て言うのかな。
OOPって基本的に最終的に再利用されるっていうことが大前提にあるわけですよね。
そうですね。
再利用されないOOPはOOPじゃないですよね。
基本的には一回作ったもしくは標準的に作ったものが再利用されるっていう前提があるじゃないですか。
OOPってね。
あるですね。
でも日本というかそのFAの難しいところっていうのはハードに紐づくっていう問題があって、
ハードに紐づいた瞬間に再利用性はものすごく減るんですよ。
今日はこのデバイス使うからなんかこのOOPがついてるというイメージですね。
だからPLCopenのファンクションブロックとかは再利用性がかなり高く作れると思いますけど、
実際に標準化されてない通信機器なんて山ほどあるわけじゃないですか。
例えばセンサー一つ通ってもそうですよね。
IOリンク通信っていう標準的な通信がありますけど、中のプロトコルは何一つ違うわけじゃないですか。
同じもの多分いかないレベルで全部違いますよね。
センサー何千種類とある中でこれ全部割り付けが違うわけですよ。
全部OOPにするかみたいな。
ですよね。
そういうものを果たしてパッケージ化できるんだろうかっていう話ですよね。
パッケージって時間だけ消費されて、自分でも一回使ったらもう次いつ使うかもわからないという状態。
そうですね。
ただ当然だからドライバーに近くないところ、いわゆるIOに近くないところは梱包できるわけですよ。
それがうまくいったらPAC-MLですよね。
なるほど。PAC-MLですね。
ベックオフとかで言うとジョブフレームワークっていうOSSとかをベックオフジャパンの中で作ってたりしますけど、そこはもうクラフトフル活用してやってたりします。
でもそれはドライバーソンに近くないから。
近いとか意図的に外してるところはありますよね。
ハードウェア使い付くとどうしてもこの辺が標準、毎回も違うというか標準化が難しいですよね。
その結果何が起こるかっていうとドライバーは毎回みんな頑張って書いてねってなるんですよ。
何回も味わってます、こういうのは。
でしょ。でもソフトウェアの中小化に期待することでドライバーを書かないことのはずじゃないですか。
基本は同じようなドライバーはインストールして終わるものですよね。
基本的には。
USBとかドライバーとか。
要は自分たちはその末端のことはあんまり意識せずに、上だけのちゃんと価値のあるところだけ書きたいんですよっていうのがそういう思想のはずなのに、
なんか上の方だけOPになってて、その下で苦しむ人たちが結構な割合いるっていう。
それがやっぱり流行りきらん理由なんじゃないかなっていう。
これは何というか他の組み込み系でも見られるんですよ。
例えばロスですね、ロボットOS。
ロボットOSも似たようなところがあって、
ロスっていうものの中でノードをいっぱい書いていけばドライバーとかメーカーが使えるんですってなってるんですけど、
ただ現実にはハードウェアメーカーが好き勝手にハードウェアを出してるんで、
それに対するドライバーって絶対あるわけではないんで、結構ドライバー書いてるケースって多いんですよ、開発で。
ドライバーはやっぱりロールかけて書いてて、
その上の層が表示ができても、みなさんがロールをかけて、あそこ全部使ってるっていうことですね、ドライバーのほうで。
ドライバーを書いてるっていう。
っていうのがやっぱりハードウェアのソフトウェア抽象化っていうところの難しさではあると思う。
だからFAだけじゃなくて、ハードに近いものっていうのは大体あんまりうまくいってないと思いますよ。
そのOOPっていう概念が。
すごい勧誘されてるところ。
なるほどね。
でも行ききれずですよね。最後まで一貫できないですよね、そういうところは。
そうですね、だから結局スキルいらないよまでは行けてないよねっていう。
まあ楽になってるかもしらんけど、結局その必要なスキルは下がってないよっていう。
楽になるかもしれないですけど苦しい部分もあるんですよ、残ってて。
高橋のラダー言語へのこだわりとイベント駆動の危険性
そうですね、だからITの偉いところはちゃんと全部標準化したってことがITの偉いところです。
我々FAがまだちゃんと標準化も頑張ってやってるんですけど、そこまで回ってきてない。
そうそう、だから要はIEEEが偉いんですよ、とにかく。
もう一回何プレイですか。
IEEEがめちゃめちゃ偉いの、標準化団体が。
なるほど。我々の団体がそんなに偉くないですか。
エンドユーさんも偉いな、偉い。
だってさ、TCPIPとTCPIPドライバーがどれだけこの世の中に貢献してるかって話ですよ。
なるほどね、確かにね。
だってあれで世界中のワールドワイトレブ全部動いてるわけですからね。
で、そこには一切の外れたものはないわけですよ。
偉い、偉いです。レベル違うね。
そう考えると我々はイーザネとIPとかイーザキャットとかそういうのが本当に比べるものにならないですね、これ。全然。
あの辺はまだいいですけど、結局アレス・ファンチボーだってそうだし、ハイオー系だってそうだし、やっぱ無くならないですよね。無くせないです。
なるほどね、なるほど。なんか悪口になっちゃったね。
いやいや、悪口じゃないです。
OPが難しいっていう話ですよ、OPがね。
そうですね、なるほど。別に悪口ではないですよ。好きな言語のアピールポイントを伺ったりして、別に悪口では言ってないです。
じゃあ質問終わりますけど、個人中で、たかやさん好きな言語は何ですか?というか好きな言語はありますか?
コレスの中で。
たぶん今リモートアイオーさんが聞いてるのがコレスの中ですね。
いやもうラダーラダーです、僕は。
ラダー、なるほどね。
いくら使いにくくてもラダーです。
気持ちは分かるんですね。
やっぱり他のところ比べればラダーのほうが、何でですか?可視化とかの関係ですか?やっぱり見えるっていうところですか?
やっぱり可視化が一番しやすいっていうのと、何て言うんですか。
STでやるときにSTじゃなくてもいいなって思っちゃうから。
ST格だったら他の言語でもありんじゃないという考え方って理解でいいですか?
そうだし、何て言うんだろうな、選択肢として複雑なSTを書こうっていう気持ちにあんまりならないですね。
複雑なことをSTで書くのがちょっと違うなと。
慣れてないっていうのは一番ですよ。慣れてないのは一番ですけど、何て言うんですかね。
STで書いてる人のコードとか、結構増えてた関係もあるんで、いっぱい見たことあるんですけど、
イベントトリガー的に書くんですよね、みんな。イベント駆動的に。
何かが発生したらこの中のコードを一回実行するみたいなイメージですよね。
僕、リアルタイム処理のフローとあんまり合ってない気がしてて。
常に毎回ロジックをスキャンするじゃなくて、コードイベントあったからこの部分のロジックだけ実行するのがあんまり好みではないってこと?
好みではないというか、それだったらそういう駆動方式のほうが綺麗じゃないですか。
駆動方式、そういうイベントトリガーの式のプラットフォームでやったほうがいいんじゃないという気がする。
擬似的なイベントトリガーみたいなことをやる必要があるんでしたっけみたいな。
なるほどね。
いや、それで駆けるし、それが効果あることも全然あるっていうのは理解してるんですけど、
本質的にそういうために作られたものではない中でそういう使い方をするっていうことにあんまり綺麗さを見出せないって感じですね、僕は自分に。
高田さん、高田さんの美学ですよ、今話してるの。ここと美学の話してます。
そうですね。だからやっぱりリアルタイムで低周期駆動してる以上、ラダーが一番合ってるなっていうので、ラダー一番好きだなと思ってますよ、PLCの上で書く上では。
それは多分どのPLCメーカーでもどんなソフトウェアのランダムでもやっぱりPLC、ラダーが多分一番、高田さんのこの中で合うんじゃないかなという理由ですよね。
そうですね。STも別に書きますよ。FCも楽というか、リアルタイムの中で使える範囲のSTを僕は書きますって。
そのSTをめちゃめちゃ使っていくと、どうしてもイベントとトリガー的な書き方になっちゃうから、その方向に行くよりはもうラダーのほうがいいなと思ってます。
でもね、わかるよね。ST書いたらちょいちょいこのイベントを見て、これをやる。このトリガーのビットを見て、これをやる。
そうするとイベントトリガーになっちゃうんですよね、全部。
確かにそうですね。
僕はやっぱりイベントトリガーはバグをめっちゃ読むなって思ってて。
見つかりにくいですよ。
言いながら入っちゃったらね、見えないんですよ。
そうですし、やっぱり立てたビットをどっかで消さなあかんっていう。
一回注意しちゃったら、どっかでフォース戻さないと。
そうそう、それが忘れてみたいな。
そうやってます。
だからそれをすごい人に依存するじゃないですか、それって。
でもそんなのララいいですよね。このスキャンダでロジックを追跡したから中的にフォースになっちゃうんですよね。
そうなんですよ。やっぱり自己保持とそれを遮断するBセッティングを1個入れとけば、何かがあったときに全部自動で消えるっていう。
これはいいですね。
なんか安全な書き方ができるなっていうのはちょっと思ってます。
確かにST書くときにも、一回注意しちゃったものが、オンしちゃったものをどっかで絶対脅さないといけないのは自分の心の中で思ってるんですよ。
じゃないって、それでたまにも忘れちゃう。リセットすると忘れるとか。
で、そのメモリマップを網羅的に見る手段ないじゃないですか。
バックを見ると、あったときしかわからないですよね。
これ消し忘れてるなみたいなのを見る手段が結構少ないなと思ってて。
っていうので、大規模ST苦手だなって思ってます。
しかも見つかるまではすごい大変。
ボールプとか入っちゃったらもう無理や。もう見つからないほうがわかる。
だから僕はSTを否定するわけではないんですよ。別にSTはSTの良いところは絶対あるし、STフルで書くっていう方法も全然あるし、
今の時流的にSTの方がAI連携とかもしやすいよねっていうのは十分にわかった上で、
今のところRudderの方がまだいいかなっていうか、いいかなって思ってます。
なるほど。
だからやっぱり非同期なプログラムを別で書くっていう手段が融合的にいるんじゃないかっていうふうに思ってますね。
もう一回でいいですか?すみませんこれ。
非同期なプログラムを。
オープンをリアルタイムから外したところで合わせて書くんだったらフルテキスト言語でも別にいいかなって思います。
でもその時にSTじゃなくてもいいんじゃないとか高須さんも出てきたというところもあるんですよね。
STじゃなくてもいい。
PNGなんかのランタンじゃなくても外でもいいんじゃないということになっちゃうんですよね。
でもそれは別にSTでもSTじゃなくてもいいっていうだけで別にST以外の選択肢なんてダメだよねなんて言われないですよ。
別にSTでもいいじゃないですか。
そうですね。
そうですね。
なるほど。
そうか。
でもそう言われて確かに自分のSTプログラムを作った時の僕は大体そんなもんだなと。
ぶつかりにくいなとちょっと思い出しました。
そうですね。
まあなんですか。
これはどういうポジションでどういう見方をしてるかによって全然変わるんで。
僕のやってきたことと今考えてることと大事にしてることからするとやっぱりランタンが好きだなっていうふうに思ってるっていうことです。
なるほどね。
クリスのCFC推奨と実行順序の管理
なるほどね。
なるほど。
わかりました。
そうだね。
私だったら。
私いいですか次は。
いいですよ。
私だったら多分CFCかなと思ったんですね。
理由は。
CFC。
CFCはやっぱり一枚の紙の中で全部ロジック見えるのが好きは好きですね私。
でもね私がCFC書いてもらって分からないと言われて全部ランタンに置き換えられたこともあったので私が。
やっぱり私CFC結構好きですけどね。
あの一つの紙の中で全部書いてて今ロジックどこまで流れてるか線で分かるの結構好きだけど。
一番結構はまったのはCFCの各ブロックの実行の順番が決めるんですよ自分で。
こいつで一個オプションつけて各ブロックで今の順番が見えるんですよ。
1,2,3,4,5,6,7,8。
あれをちゃんと並び直さないとロジックがおかしくなる場合があるんですね。
実行の順番が間違えると。
ここは最初は結構ハマっててこれさえちゃんと分かれればCFCは結構便利だなと思って私は思っていますね。
CFCが。
線のパラメータも見えるし線につなげられるしネットワーク1,2,3,4これ気にしなくてもいいし。
例えばラタとか観測観測を作って観測出力をわざわざもう一個何かビットとか割り付けないとダメじゃないですか。
後日の場合は。
使えないですがあれはでもCFCが使えるんじゃないですかあれを。
比較したときの出力が。
5,1,1ってヒーズはちょっとめんどくさいなと思ってるだけです。
CFCだから直接この結果使えるからわざわざCFCで作っていくのがいいかなと思いますね。
なるほどね。
どうですかこの私の気になるポイントでしても使っていいんですけど。
いいんじゃないですか好きな言語って話ですからね別にいい言語じゃなくて好きな言語だから別に全然いいと思いますよ。
何でもいいです。
できればCFCが初めてやる人でも正義CFCを一回試してほしいです。
シーメンスもスケーターでデカいプランドでやる時はみんなCFC使ってるのでほぼ。
CFCを使ってみてほしいです皆さん。
CFCってここで吸っただけじゃないですか。
はい。
ここで吸っただけじゃないですかCFCって。
違う。シーメンスがシーメンスです。
シーメンスなんですかあれは。
シーメンスから始めるかどうかですけど最初触ったのはシーメンスですね多分十何年前から。
シーメンスがステップセブンのステップセブンクラシックいわゆるS7300とか400の古いCPUでプロモークツールの中でCFCで付いてて
最近Tiポータル新しい最近の多分2年前3年前のやつもCFCがかけるようになったんです。
CFCはシーメンスもかけます。
なるほどね。
まあ正直IC言語じゃないからな。
IC言語じゃないからな。
IC外れてるんですけど使ってますね皆さんがCFC。
そうですね。
IC言語じゃないんですけどICの表示の関数が呼び出せるし大きなメガシーメンスとかコーチスとかツインケットもそうですけど操作感もすごい似てるから皆さんも何らか使ってるんじゃないかなと思ってると思うんです。
そうですねまあそんなもんですよね。
IL言語の現状とSFCによるシーケンス制御の安全性
まああとは各言語の使い分けみたいなところはもう好きにやってくださいというところではありますけどまあただなんかもう普通に一般的に言われてる感じだと思いますけどね。
まあその要はそれぞれの得意なところがあって。
はい。
ああいうところで得意な言語を書かせるみたいなイメージですね。
まあだからラダーはその可視化性がすごく優れてますよっていう話だし、ラダーというかエフィリウムフェイス含めた話はそうだし、STに関しては複雑な計算式で書けますよっていう話だし。
計算とか。
そうですね。
ILももう廃字でしたっけ。
ILは廃字です。
廃字というか推奨ではない。
廃字ですね。
推奨ではない。
あれは使うべきじゃないかなと思うんですけどねもう。
まああれはもう高速化以外にはまあそんなもうあまり気をしないと思いますけどね普通。
そうですね。
なぜかとねまあちょっと告示じゃないですけど、
シーメンスのPOCってブルーのやつを吸い出してされたら原はIL、全部ILですよ。
ラダーじゃないので。
ラダー書いてももし吸い出してて、もしこの吸い出したときにこの回路がラダーで成立できなかったら全部ILに変換されちゃうんですよなんかライフで。
もともとILなんて書いてあるシーメンスのプログラムは全部。
例えばSTで書いた原稿のブロックがPOCが入っちゃって、でもこのソースファイルを持ってないんだったら吸い出したときはもう全部ILなんですよ。
インダクショニスト。
でも何書いてるかさっぱりわからない。
という。
まあね。
ことがあります。
まあでもさあキーエンスでも書けるじゃないですか、そのILチックなメールってあるじゃないですか。
今でも書く、ありますね。
使ってる人いるってことですよね。案内サポートされてるってことは。
いるんですか。
でも使おう、ごめんね、私も300、昔シーメンスPOC使ってたらずっと使うんですよ。
例えばオワカイロでランチュ語を書くときに私IL使いましたね。
よかった、やっぱ便利です。
便利というか手間かかないという点があるんですね。
すごい簡単なロジックカイロだったらいますね、ILで。
そうですね、あと今まで話に出てないけどSFC。
あった、SFCとかあったね。
SFCはもっと使われるべきだと思ってる不思議ですけどね、どっちかっていうと。
これはなんでですか、もっと使ったほうがいいってことですか。
安全。
なるほど。
分岐も決められるから。
分岐というか、フローをシーケンス制御で1個ずつステップごとに進めていくわけじゃないですか。
あれってラダーで書いてもSTで書いてもバグを生みやすいんですよね、シーケンスって。
だってラダーのステップ回路ってめっちゃめんどくさいわけですよ、普通に考えて。
めんどくさい。
STのステップ回路もめんどくさいわけですよ。
ケース分だから。
ケース分だし、普通はテキスト言語って何週もするようなものじゃないから、1個ずつ進んでいくわけですよね。
リアルタイムなPLCのST公文って何回も通るわけですよ。
次のステップに行くまで100回ぐらいフロー通るわけですよね、ケース分を。
そうですね、ずっとずっとループしてるからね。
ループして通ってるわけじゃないですか。
それって別にそういう用途じゃないんだけどってちょっとあるじゃないですか。
はい、なるほど、なるほど。
それを全てSFCはシステム側がちゃんと保護してくれるわけですよね。
今はただST止まってて、ステップコードでやらなきゃいけない動作を書いてあげて、見なきゃいけないインターロープ全部見てるということは安全って言うんですよね。
SFCにはすごく難しいことがいっぱいあるんですよ。
ただ、順番にこれを1個ずつ進んでいって、分岐もして、1つのフローをやればいいっていう環境においては、非常に安全に書くことができるなっていうふうに思ってます。
ただ、途中から始めたりとか1個飛ばしたりとか、そういうちょっとエレギュラーなことはSFCの公文上はちょっと難しいところがあるから、なかなか使われないんだろうなっていうふうには思ってます。
なるほど。SFCあんまり使わないですね、自分も。
使ったことはある? 使ってます? 高橋さん、検証用以外に。
僕は実務ではあんまり使ってないですけど、基本的には使うべきだっていう立場です。
いろんなIC言語を検討して、いろんな標準回路みたいなものを検討した上で、SFCは使うべきだっていう判断、僕は。
なるほど、使えるもんだったら使う。
なぜなら、可視化ができるから。
一番分かりやすいよね、今どうステップ止まってるかが一番分かりやすいよね、もう。
あと書くステップも見るしね。
今、だからシーケンス回路の可視化をする術っていうのはあんまりないです。
あんまりない? っていうのは? あんまりないっていうのは?
なんていうんですか、今どこのステップにいるかっていうことは別にRudderでもSTMで示すことはできるわけですけど、
それを分かりやすく伝える、要は設計者以外が分かりやすく伝える方法って画面を作る以外なんとか多分ないと思ってるんですよ、僕。
一発分かるのはRudderはもう画面作るしかないですよね。
作った人は分かりますよ、Rudder書いた人はそりゃ分かりますよ、どこで止まってるかここ見ればいいんだなと。
ただ受け取る側は多分難しいと、慣れないと。
でもSFCだったらもうこのランプステップもランプをつけてるから、だから分かるんですね。
だからRudderって例えば異常回路とかは誰が書いても分かるじゃないですか。
今何が原因でこのランプがついてないんだなっていうのは設計者を見て分かるわけですけど、
シーケンス回路は分かんないですし、STも正直分かんないですし。
もっと分かんない、もっと分かんない。
って考えた時にやっぱりシーケンスっていう分野に対してはSFCっていうのはRudderの異常回路分かりやすいよねみたいな性質を持っているっていう言語だと思ってて僕は。
なるほど。
だからやっぱり活用した方がいいんじゃないか。
活用っていうのはそれを前提にいろんな設計論っていうのを組んだ方がいいんじゃないかってここ5年ぐらいやってたって感じですね。
まさかタカさんはFSCそんなに愛あると思わなかった。
ただやっぱりSFCは日本の海外も含めてPLCメーカーの実装率が悪いんですよ。
作ったり作れなかったり、あとはバラつきが多いとか。
そうですね。
例えばオムロンとKeyenceはないんですよ、SFCが。
ないんですね。
ないでしょ。
で、三菱とJtechとはあるんですよね。
ただ実装は最低限、最低限です。
なるほど。
そう、仲の人の話を聞いてもやっぱり特定のお客さん向けっていう話をなんかよく聞く。
だからその力は入れてませんみたいな。
これ難しいね、活用は。
そっか。
だからやっぱり。
海外だったらSeamenさん。
コレスとかがやっぱり一番SFCの実装は進んでる。
今まで更新してますからね、今ずっとやってるからね、SFCが。
だからこう実装したらSFCを皆さんもぜひ体験してほしいということですね、タカさんも。
いい意見ですね。
ただ小回りは効かんすよ。
僕は検討したから分かるから全然小回り効かんすよ。
やりたいことの6割ぐらいしかできないのが。
IC企画上のやっぱり難しいところ。
言語上の問題ですか?言語の構造上の問題にも。
文法上の問題。
お客さんのブインキーとかは多分合わないとかあるんですね。
ブインキーというかステップを飛ばしたりとか、特定のステップから始めたりとか、そういう活性化を制御する術っていうのがない。
今どうなってる?例えば道中ステップ1が始まるんじゃなくて、ステップ5が始まるんだったら7が特定のDM書くしかないんですよ、レジスターに。
DMというかもう飛ばすしかないです。
全部のステップにスキップスキップするような線を入れるしかないです。
これは小回り効かないというか、もう線効かないね。
それで飛ばしてもいいんですけど、そうしたらこのグラフィカルのところがもう線だらけになるんですよね。
逆にグラフィック活性化を満たすためのSFCだけど逆に見えにくくなったということですね。
っていうのはやっぱり望んでることではないじゃないですか。
そうだね、そうですよね。
そういうところがありました。
まとめと今後の展望
でも皆さんね、やっぱり使ってほしいのは高さの1回、この言語を使ってほしいというのが高さの規模です。
というわけで今日はクエストなししてきましたというところで、皆さんも好きな言語があればぜひコメントに残していただければと思います。
それではありがとうございました。
