IEC61131-3の普及
明日のファクトリーオートメーションにようこそ、メンバーソニックの高橋です。
クリスです。
よろしくお願いします。
よろしくお願いします。
お便り来ています。
ラジオネーム、ゆうゆさんに頂きました。ありがとうございます。
ありがとうございます。
おはようございます。
おはようございます。
おはよういただきます。
早速ですが、質問です。
最近、国内でもIEC61131-3の対応のPLCが各社で出してきており、普及が進んでいるのかなと思っています。
この流れは今後も続くと思いますか。
それとも、1131の語言語がなくなり、新しい言語やIT系の言語がスタンダードになる時代もあり得ると思いますか。
お二人の意見を聞いてみたく質問しました。よろしくお願いします。
ソフトウェア構成の重要性
ということです。クリスさん。
まず、どこから始めようかな。
まずは、今の国内でもIEC61131-3の対応のPLCは各社で出てきており、この流れは今後も続くんですか。
もう続くしかないな、まずはこれ。
そうだね。
離れることはもうノーセンスだな。ほぼありえないかなと思ったんですね。
さっき、1個前のラジオを話したんですけど、仕事の楽数とか標準化の話が出てきて、
これが出てくると、同じルールを守りましょうということが共通なんじゃないですか。
今このIEC61131-3はちょうどいい、1個の守るルールじゃないかなと思っていますね。
このルール自体は多分もうこれから、聞けることは聞けること?
どんどん追求していくんじゃないかなと思いますね。
このラジオから聞いている方は知っているんですけど、
IEC61131-3の中に、ユウさんが言った言語を入れるというのは、
メザウスラターとSBD、ファンションブロックチャートと、
あとはSP、攻撃言語っぽいやつと、あるSFC、フローチャークみたいなやつ。
あともう1個はIL、インソフィニスト、アセームリ言語ですね。
そうやっても、アセーム言語は今もう使わないという傾向になっていますので、
語言語も今段階はあるんですけれども、
今、ファンションチャーク、インソフィニストはもう使わない方法はしています。
ついつい言ってはないですけど、形上ではもう1個は使わなくなっちゃったんですね、皆さんが。
そういう理解であってます?まずは。
聞かれてることはそうじゃないと思ってて。
そう?
結局、IECがどこっていう話っていうか、
たぶん後半のほうが聞きたい話だと思うんですよね、この話って。
そうですね。
要は、端的に言うと、PLCがんばって、
もうその後、他の言語にまくられるとかあるんじゃないですか、みたいなことをたぶん聞いてきてると思うんですよ、この場合。
そうですね。
ここちょっと僕の意見を言うと、
IEC61131-3の大事なところって、言語っていうよりは、
PLCの中のソフトウェア構成だと思うんですよね。
ソフトウェア構成というのは?
いうのは、例えばPOUと概念は、この61131-3で出てきてるんですよ。
POUっていう概念ね。
あとタスクっていう概念も61131-3で出てきてるんですよ。
これは結構この1131の企画の結構大きな特徴だと思うんですよね。
はい。
ちょっとこの辺分からない人に説明をすると、POUっていうのはプログラムを書く単位ですね。
そうだね、はい。
プログラムオブユニットかな、略称としては。
本当に、はい。
プログラムは一つのPOUという単位で書きましょうっていうものがまず一つ決まってるっていうのと、
あとそのPOUっていうのをタスクというものに割り付けましょうと。
このタスクっていうのは定期的な周期で呼び出されるタスクですね。
そのタスクに割り付けたPOUが、例えば100ミリだったら100ミリ周期に1回呼び出されて、
それが上から下まで全部実行されますよっていう。
これが設備制御っていう面に非常にマッチした書き方、もしくはアーキテクチャーなわけですよね。
こういうことが結局C言語とかその辺り決まってないんですよね。
確かに。
結局その語言語が大事っていうよりはこの構成が大事なんですよ。
POUっていう単位で割りますよとか。
プログラムを呼び出すとか。
それをPOUをどうやって呼び出しますかっていう話だとか、それがハードウェアどういうふうに実装されてますかとか。
これが設備制御において非常に重要なことなんです。
言語の未来と変化
よく考えたら、今まで結構、FunctionブロックとかOOPとかコンセプトより前先あるんですよね。
多い単位でプログラムを組むよ、タスクでちゃんとこの周期で動きましょうという。
これが一番コアのところって理解でいいですかね。
その中をラダーでやってるかSTでやってるかは結構些細な算面ですね、ここの場合で言うと。
でもぶっちゃけて言うと、この中が別にC言語で書かれてもそんな問題じゃないし、実際、CodexやPincatはC++で書かれてるわけですね。
そうですね。
一部ね。
なるほど。
書くことができるわけじゃないですか。
なるほど。
そこにSTとC++で差がありますかってほぼないわけです、実際にね。
でも言語はそもそも大事じゃないわけですね。
今は基本的にこの規格が6133で統一されてるんで、その語言語で多分進んでいくと思いますし、これは今後の流れも多分進むでしょうと。
これをIT系の言語に入れ替えたときに統一を取ることができるのかって言うと、多分なかなか難しいだろうなっていうふうに思っています。
統一できるだろうと難しい。
要は結局今せっかくこの6133で大体こう書けばみんな一緒だよねっていうことが決まってきているのに、
これをじゃあ一回全部捨てて、じゃあ全部Cにしますっていう話をしたときにまとまると思いますかっていう各ベンダーが。
そうC書けないとか。
Cが書けることとCの書き方はまた別なわけですよね。
どういうふうにプログラム組むのっていうのがまた一からなったときに、みんなそのC言語が書けるっていうこと以外にこう書いたらいいですよみたいなサポート機能いっぱい付けるわけですよ。
なるほどね。
それはもう収集つかなくなると思います、僕はそういうことを始めるとね。
だって実際どういう例があるかっていうと、製品でいうとHoloのPMACっていうのがあるわけですね、C言語コントローラーでいうと。
これは何かデファクトスタンダードな書き方になっているかっていうと、別に全然そうじゃないんですよ。
自由自体の自由を。
そう、かなり自由に書けるんですね。
実際そのPMACユーザーは結構独自に、かなり独自にやってるんですね。
おさほの書き方みたいなのがないんですよ、そこに。
そうか、そういうことか。
だから本当に大事なのはこのPOUっていう括りと、そのPOU間の通信みたいなところをどういうふうにアーキテクチャ組んでいくかっていうことが圧倒的に大事で、
これを多分今後崩すっていうことは多分なかなか起きないなと僕は思ってます。
なるほど、なるほど。
そう、だから別に言語が変わることは全然あると思います。
言語は別に。
言語はなかなか変わるものあるだろうし、例えばそれがCやCプラファレなっていくことっていうのも僕は全然あると思いますけど、
このPOUとかそのタスク性っていうのは多分この6.1.1.3.3を今後も生産するべきなのは踏襲していくと思う。
そう考えると、ずっと見てたこのFCとかFPとかOPとかが違うのはまずそこだね。
プログラム単位で設置名を書きましょう。タスクで割り付けましょう。ここが一番怖いものはやっぱり。
そうですね。
そっか、言語は意味が悪いけど、どうでもいいというか、もうどういう意味でも言えられないですけど。
まあどうでもいいっていうよりは。
そこまで気にすることよりはもっと大事な部分があるよっていうんですよね。
多分、だからこの6.1.3っていうものを突然なくすんじゃなくて、これを継承した形で多分何か変わっていくんでしょうね。
だから僕は言語のリプレイスが多分どこかで入ると思いますよ。
今の言語に置き換えられる新しいものが出てくる。
そうそう、STやめてこういうのにしましょうって。
それはもしかしたら既存の言語を入れてくる可能性だってあります。
STやめてシープラフトにしよう、STやめてラストにしようみたいなことは全然起こり得ると思うし、今後ね。
それはSTのライブラリ全然ないんで、もっとライブラリオフなやつに移しましょうとか、全然あると思いますそれは。
あり得るね、あり得るな。
ただこの構成は崩さんと思う、今の。
このタスクとこういうタイミングの組み合わせでセルセピを組むという構成は難しい。崩すのは。
なんでこういうことを言うかというと、フィールドネットワークが低周期で物が上がってくるっていうのが基本的なハード構成になってるんで、
PLCプログラムの現状と課題
情報が上がってきてそれを次の周期までに処理するっていうことが確定的にやらなければいけないことなんですね、ハード面で言うと。
これは今のタスクやPO優先っていうのは非常にマッチしてるから、おそらくこれはこのままいくだろうと僕は思います。
ちょっと質問ですけど、この構成を一回崩そうとしてるのは多分あったんですよね、シュナイダーさんとかの499とか。
499は別に崩してないですよ。499も実際は別にこのアーキテクチャー内で動いてますからね。
基本はイベントトリブンでやってるから、これをちょっと崩せようかなと思ってたんですね、さっき。
別にイベントトリブンも別にPO優があるあるであるイベントトリガーで叩かれるだけなんで、別に崩れてないですよ。
崩れてないというか、このアーキテクチャーの上にさえ乗せてるって感じですね、崩すじゃなくて。
じゃあ真中で一緒か。
考えるとこの構成を崩すの難しいな。
この上に乗せるだけじゃないかな、多分このタスクとPO優の組み合わせは。
そうですね、だからこういうふうになるんじゃないですかっていうのと、
ただじゃあ別のことで書くっていうことがないかっていうと別にあると思いますよ。
全部Pythonで設備組みましょうとか全然あると思いますよ。
あるね、あり得るなこれ。
例えばROSとかもそうだし、これ以外設備制御してるかっていうと別に知ってる設備は全然ありますよね。
例えば半導体のケア設備なんてCで組まれたりするんで、全然あるじゃんっていう。
あるね、別に全部この語言語でやるわけなくても成り立てるね。
そうですね、はい。
ただそれは高度なことをやりたいからそっちに行ってるっていうのがかなり強いですよね。
言ってくるにはこの語言語が限界あるんですよね、限界で言うか。
だから非常に高度なことをやろうとするとこれはしんどいと、ラダンってしんどいと。
だからもっと適した言語を使いましょうねっていう形で済んでるので、
汎用的な部分でこういう置き換えが行われるっていうことはあまりないんじゃないかなっていうふうに思ってます。
言語選択の理由
なるほどね、これも難しいわけじゃないと多分そもそも語言語が跳ねることもないし、
この構成が跳ねることもない。
っていうふうに思ってますけどね。
そこは入れ替わる、少なくとも向こう10年は多分ないと思うな。
なるほどね。
この語言語も何年の歴史があるんでしたっけ?結構歴史長いですよね、この語言語も。
語言語自体も90年ぐらいに生まれてなかったかな?覚えてないですけど。
覚えてないです。
結構歴史長いよね、それでも今この時代でも新しい言語をこれを入れようと思ってなかったな、なかったな、今でも2025年が現時点では。
まあただ不満ないんかって言ったら全然不満ありますけどね。
言えそうな不満だけでもういちがいしゃべるでしょ。
とりあえずこの1131の3番の言語仕様に不満がないかって言ったら別に全然そんなことはなくて。
めっちゃあるよね。
できないことは山のようにあるし、じゃあOOPに対応しますって言いながら全然対応しないやっけみたいな話も当然あるわけですからね。
ただ拡張するっていうのは今後もしかしたらあるかもしれませんが、もうただ10年後なんですよね、次の改定って。
そう、もう1131の4番はほぼ仕様が確定してしまったので、次の改定って10年後なんですよ。
じゃあ最低限10年後ですね。
少なくとも10年は変わんないってことですね。
10年か。
10年です。
高須さん誘惑は別に、やっぱり功労じゃない限りはこれ以外の言語を選ぶこともほぼないし、だろうしっていう感じですよね。
なるほど。
というよりコストが高いと思いますね。
学習のコスト?
デバッグだとか、いろんなことに対するコストが高いので、なんで今高度なことをやろうとしたときに別の言語が使われるかっていうと、リターンが高いからなんですね。
多少そこに投資とか学習コストかけても十分なリターンを得られるからそういう行動が起こってると思っているんです、僕。
とりあえず今ね、我々これを言語で書いたの、掃除の単価はそこまで高くないってこと?
そうそう。だから汎用機とか、いわゆるあんまり効果が見込みにくいもの、いわゆるその結構薄利多倍なことをやってるところに、そういうことをやるあんまりモチベーションはないんじゃないかなっていうふうに思いますね。
結局は掃除が安いから。
掃除が安いから。
安い掃除はそれをやらない、そんなことをやらない。
そう、だから高い掃除は全然そういうこと、発生してる可能性ってのは全然ありますよ。
だから半導体とかの辺は、そもそも全然高いから、投資する価値あるよね。
ここか、こうする価値があるかどうかだね、結局。
例えば半導体とかだと、その位置制度をバシバシに出すみたいなことが、本当に売れ気全然関わるわけですよね。
で、それ1億、2億、3億、4億っていう話なんで、その世界って。
なるほど。
本当にズレましたね、私も。
俺もこの話聞くと。
語言口を増やせるか、そもそも意外使おうかどうか、その掃除の見込みのリターン、どれがあるかよって決めるよね、大体。
そう。そっか。
なるほどな。
別に全然世の中の装置で、別にPLCで動いてない装置っていっぱいあるじゃないですか。
ありますね。
例えば、映像の演出装置とかもそうだし、いろんな舞台装置とか、シャッターとか、公共のものだとか、自動販売機だとか、別にPLCで動いてないものは山のようにあるわけですよ。
そうだね。別にPLCになっても、行けるところは行けるよね、考えたら。
そういうときも、ああ、なるほど。もうちょい短く見たらそうだな。
だから別にPLCじゃないとダメってことは全然ないけど、あんまりこれを置き換えるっていうモチベーションが湧くような美味しい仕事自体はあんまないんじゃないか?って思ってます。
始まってぐるぐるって戻ったな、結局。安いんじゃない?安いから。
そう、急遽的にはもう設備安すぎるから。
言語の置き換えについて
安いから、投資する理由もないし。
投資する理由はあんまないんじゃないかなって思いますね。
こうやって制御機器が削り始めるから。削り始めるからいろいろ。
なのとね、トータルの結論が言うと、設備は安い。安いから無理。無理というか、投資しにくいですね。
なるほど、そういうことか。
まあそうだな、ラストぐらいになる可能性っていうのは全然ある気してますけどね、僕。
うんなんですか?
いや、だから言語が置き換わる可能性っていうのは全然あると思いますよ。
このタスクの範囲内で言語が変わるなんて可能性は僕は全然あると思いますね。
そう、結局多分このPOIの仕様とこのタスクの仕様さえ守れればですよね。守れればですよね。
ただ、それをしたらなんかめっちゃよくなるかって多分そうではないと思いますね。
つまり?だからこの高級、他の言語で切り替えたらめっちゃよくなるということですか?
要は結局10ミリセックだと10ミリセック内処理完了させないといけないんで、この時点でPythonとか無理なんですよね。
無理だよね。
使えたとしても、基本公文が使えるだけであって、メソッドとかをフル活用には絶対無理なんですよ。
無理だよね。
準備って終わんないからね、そんなことをしていたら。
はい。
となると、IT系の言語っていうものが、いっぱいライブラリーがあったりとか、そういうのがほぼ活かせなくなると。
その、何ミリセック2回に1回を終わらせるというリミットの中で。
そうですね。
そうなんだ、ほんと。
となったら、結局C++ぐらいに落ち着くんですよ、ラストとかね。
うんうん。
狭いんですか。
むずいな。
うん。
むずいな、無理やな。
もしかしたら、もう少し別の言語もあるかもしれないですけどね。
あとは、本当に完全にイベントトリガー型でやるっていう決断をするからですけど。
ただイベントトリガー型はめっちゃ管理が難しいから。
そう、これで、ちょっとやったことないですけど、きっとイベントトリブンはどう思うかというか、どう思うかという言い方がちょっとおかしいな。
どう感じましたか。使いましたか、高橋さんは。使ったことあります?
ないです。ないというか、ひたすらにデバッグが難しいと思ってます。
今どこ言うか分かんないんだけど、今このプログラムどこまで走ってるの。
そうですね。
トリガー。
なるほど。
事件のトリガー。
そうですね。ちなみにでも別にぶっちゃけた話で言うと、ラダー回路はイベントトリガー型の回路ですよ。
まあ、そうだろうな。これ起こる中でジャンプ、これ入る中で全部ジャンプだもんな。ジャンプだらけだよね、あれも。
イベントトリガーの課題
だってさ、異常とかって特にそうじゃないですか。別に常時監視でポーリングして異常見てて異常があったらなんか動き出すわけでしょ?
これはそのうちイベントトリガーってことですよ。
だってイベントトリガーなんですか?
エースワークで言ったら、じゃあ結局、なんか今、IC-6499って言ったらイベントトリガーなんですか、あれは。
でもイベントトリガーじゃないよね。
それはだからイベントトリガーのタスクの起動を誰がやるか、システムがやるか、ユーザープログラムがやるかっていう違いだけしかないと思います。
これだけだよ。結構ハイライトされたんですけど、あれはイベントトリガーですよっていう。
イベントトリガーをラダーで書いたときのめんどくささとしては、イベントトリガー起動しないときもプログラムが一回実行されるっていうめんどくささがあるってことです。
リソースは若干無駄に使っちゃったっていう。
あるし、セットリセットっていうのがなかなか難しいっていうのはありますよね。
難しいな、セットリセット。
逆に言うとイベントトリガーをシステムでやると、セットリセットの管理がめっちゃ難しい。どこでリセットするの?ってなるじゃないですか。
リセットのセットプログラム、回路もちゃんと書かないといけないんだ、いろいろ言うんで。
そうですね。
長時間ポーリングじゃないから。
っていうと、イベントトリガーを入れてるPOU内で処理が完結しないんですよ。それとは別のイベントトリガーもしくは何らかのタスクにそこをリセットする回路を書かないといけない。
ポーリングになっちゃうな、多分。
そう。ってなったら、そのイベント1000個とかになったらもう管理しきれんすよね、多分。
だってその中で完結しないんだから。
そっか。
そういうことか。
うん。
っていうのがイベントトリガーをシステムにする難しさだと思います。
常時監視の戦略
うーん。
でも向いてるところあるんですよね、そういう風に。今ここで打ってるところあるんだったら。
いや、例えばシーケンスなんてめっちゃやりやすいですよ。
例えばこのイベントが発生したらこれを順番にやりますみたいな、そういう処理はめっちゃ楽ですよね。
楽だな、楽、楽。
あー。
だからその、混ざるんですよね、基本的に。設備って常時監視したい処理がいっぱいあるんですよ。例えばインタールックの処理なんかそうですけど。
そう、インタールックとかアラームの常時監視がポーリングで。
で、じゃあそのポーリングとイベントトリガーどうやって切り分けるんですか、どういう風に設計分けるんですかっていうものは今のところ確立されてない、説明の世界では。
そっか、イベントトリガーそういうことか。
うん。いやだから別にやる手段はありますけど、要はなんかいつも言うことですけど、
まあ誰かが本気でやらんとあかんってだけだと思いますけどね、その要は一丁紙じゃできないっていうだけだと思います。
誰かが本気でやらんとあかん。
うーん。
最後は責任持ってやる、ですよね。
そうそう。要は一番最初、道をちゃんと敷設するまでは結構な努力がかかりますよね、今やったことないからねっていう。
うんうんうん。
特効薬ではないということですね。
特効薬ではない。
そう、イベントトリガーっていうものを使えば全てがうまくいくっていう特効薬ではないってことですね。
なるほど。
的際のものを使って別に、イベントトリガーを使ったら体が良くなるというわけでも。
まあ別になんとかいう、要は今より良くなる可能性ってありますけど、やっぱり一回沈んだりするんで絶対。
焦げた、焦げたねその後。
そうそうそうそう。だからなんかちょっとやってうまくいかねえなやめるみたいなことが世の中には多発してるってことです。
あれ終わるか。もう私と会社とは合わないというわけですよね、これは。
まあ合わないというかその先までちゃんとやれば上向く可能性ってありますけど、それにはそれなりの投資と労力をかけないと多分そこまではいけないだろうなっていう。
まあいいかね、メーカーの協力もいるし、そうかなんじゃないよなこれ。
それを誰がやって誰が世の中に公開するかっていうだけの話かなと思います。
なるほど。
なるほど。
という話ですね。という話で今回の11.31について、私とKeiさんの感想ですね。
Keiさんがコースの中でPUとタスクがもうこのPU中の中のコアのコアだと強調しました。
というわけでですね、またいろいろコメントご意見あればぜひお願いしますということで今日はおしまいにしたいと思います。
ありがとうございました。
ありがとうございました。
