00:00
明日のファクトリーオートメーションへようこそ、メインパーソリエンティの高橋です。
クリスです。
よろしくお願いします。
ラジオネームイヌハさんからいただきました。ありがとうございます。
ありがとうございます。
現場で設備が制御不能になり、そのことを上司に報告するべきかどうか判断する経験をいく度となくお持ちのお二方に質問します。
あえてこの言語からいきますが、IEC61131-3の5言語において、ST言語に追加してほしい言語仕様についてご意見あれば教えてくださいと。
待ってね。制御不能どういうことですか。ちょっと聞きたいんですけど、ここから。
現場で制御不能になり、これは何の制御不能。チームが制御不能なんだ。それも装置が。
現場で設備が制御不能になり、これは多分どうでもよくて。
ちょうどいいですよ。これ結構大成はマイク切られるんですか。
いやいや、これは関係ないですよ。そういう経験を持っているクリスさんが、IEC61131-3の5言語において、ST言語に追加してほしい言語仕様があれば教えてくださいってことですね。
なので、クリスさんはもうST言語に追加してほしい言語仕様を教えてくれということだと思います。
そうだね。ST言語について、まず何が仕様を追加してほしい。
これは企画は全て満たしているという前提のもとで追加仕様がどうかって話なのかな。
そうだね。言語自体は各社がもうちょっと頑張って装置したいなと思う気持ちですね。
STでもSTでも企画は切ってるんですけど、各社の違いがあるんですか。
ここは仕様欲しい仕様というか、みんなちゃんと同じ仕様に整えてほしいなと思うんですね。
たまに、例えばマシンを見たら、私が心を持ったのはST言語を使うPoCって大体一種類分かれてるね。
コーチス系、コーチスペックオフ系とそれじゃない系が分かれてるんですね。
コーチス系はもともとはST言語だけじゃなくて、OOPのコンセプトが入ってるから、これプラスSTで結構そういうプレーンのワークとかも出てるんですけど、
そうじゃない派は、例えばSiemensとかMejibishiとか、
今までのFPと同じフォーナー、フォーニーの動きになってるOOPコンセプト、
メソッドがプロパティとかエクスターミントができないとか、それが分かれてて、
多分この分かれ方をいずれ合流する気がないと思うんですね、私。
03:01
そう思ってるんですね、ずっと。いずれ合流することはない、どんどん分かれてるとずっと思ってたんですね。
新しいハードウェア、アクティクチャー、ソフトウェア、新しいツールを出せない限りは、
多分そんなに合流する気がないかなと思ってたんですけど、この2つの枠が。
そうですね。
何て言うのかな、何て言うのかな。
こいつが作った、
いいですか、話して。
作ったプログラムが、MejibishiGatorが別の、みなさんSTでアイスとクサイシさんの一ノ理書けば、
みんな教授の仕様を使ってるから、よく言うのは別の機器でも乗り換えでも簡単ですよ、と言うんですね。
でも結局そうじゃなかったんです。
ST原稿とか大きな枠の仕様はそもそも違う。
さっき言った通りのコジツ系、コジツペックオフ系、あとはそうじゃない系は一緒にならないですね。
OBB作ったものが、たぶんMejibishiとかで直接変換できないですね。
でもMejibishi、シーメンスとか作ったSTプログラムとかは、おそらくだいたいはコジツとかツインケーターで走れるんですね。
それ言い方いいかな。
まずはどこかのタイミングで交流してほしいんですね、このST原稿のみなさんが。
ST原稿じゃなくて、このアイスとクサイシさんのラーターとかもそうだし、
この辺のどこかのタイミングでみんな交流してほしいなと思ったら、
ちゃんと同じ基準になりたいなと、まず私はいつも思っていることをですね。
どう思いますか、これが。
したほうがいいのは間違いないじゃないですか。
でも実際難しい、たぶん何か壁があるかなと思いますね。
難しいというか、メーカー側から見たときに交流する大きなメリットなんてないじゃないですか。
ないですね。
そのときに、いわゆるユーザー側もしくは第三者のサードパーティーが、
その交流するメリットをいかに打ち出せるかということに今かかってるんじゃないですかね。
そうですね。
なのでたぶんこれ別にエッチだけじゃなくて、他の言語、4つの言語でも同じ状況じゃないかなと思ってますね。
そうですね。だからその、交流してほしいけど、
僕らユーザーがじゃあ交流するために何か活動しますかっていうと別にしてないんですよね。
してないです。残念ながらお久しぶり。
っていうやっぱり難しさとか、そこがたぶん問題な、問題というかウィークポイントなんだと思いますね。
06:03
揃ってたほうがいいじゃないですか。
でも、じゃあ専用命令出さなくていいんですかって言ったらみんな出してほしいって言いますよね。
専用命令、そうだね。
じゃあ相反することを言うわけですよ、そこで。
統一してほしいけど、そのメーカーの特色は出してほしいってことを言うわけじゃないですか、ユーザーとしては。
統一したいんですけど、それでもこの入社特性の異論も立ててほしい。
そうですね。
それは矛盾ですね。
矛盾を言いますよね。だからやっぱりそこのバランスをどうやって取るかっていうことのことをやっぱり提示しないといけないんでしょうね、誰かが。
その活動には確実にユーザーは参加しないといけないんだと思います。
実際使ってるとか、まさにこういう要望がありますと、強く打たないといけないということですね。
そうですね。それはメーカーに言うんじゃないですよね。もっと別の概念が多分必要なんでしょうね。
メーカーが言うじゃなくて。
世論に近いですかね。世論というか、世の中のニーズって言われるバクッとした概念に対して言っていく必要があるんでしょうね。
これメーカーで今世論もこの風に流れてるから、そろそろ合わせようかみたいなことですか。
合わせたら何が嬉しいかっていうことをユーザーとメーカーでデザインしていかないといけないんだと思いますね。
なるほど。
今はそういうことを考える枠組みがないんですよね、世の中に。
そうですね。
ユーザーはユーザーでまとまってないし、メーカーはメーカーでまとまってないし。
全然バラバラ状態。
そうそう。っていうので、規模の力でシーメンスがご利用してるっていうのが今の現状なんじゃないかなっていう。
あと問題なのは、これ別にどこまで詰まってないし、どういうこともあって。
そうですね。
問題はまだね、バラバラの日はそこまで詰まってない。
だからそこに入る必要もないんじゃないということもあるんじゃないかな。
でもこれが統一してないからやれないこともたくさんあるわけじゃないですか。
ありますね。
やれないことがすごくメリットを生み出すかどうかっていうのがセットギアなわけですよね。
なるほど。
困ってないっていうのは、ある種でいうとその先の利益が見えてないっていう言い方もできるわけです。
プロセッション。
それは改善するよってこんなに利益があるか。
今のやり方で言ってもいいですけど、その隣の会社が、
別のやり方でものすごい利益出してたら困るじゃないですか。
それは困りごとですよね。今のやり方だと他社に勝てないっていう。
だから明確な上にいっているものがないと困らない。
09:02
なるほど。
今STとかそういう言語が統一されてないことによる何かできないことがあって、
それが今のやり方で言ってもいいですけど、
言語が統一されてないことによる何かできないことがあって、
それがすごく嬉しいことなんですよっていうことがやっぱり見えてない。
あるかどうかは分からないけど。
あるかどうかはないかは分からないけど、今のところ見えてない。
見えてない。なるほど。
それを何らか可視化しないといけないんだろうねっていうのはやっぱりちょっと思っていることですね。
はいはい。
だからね、難しいですよね。世の中のニーズってどうやって作るんだろうって。
これリードするのが誰でいいかですよね。
誰でいいかと、ニーズってやっぱりどうやって生まれるんですかね。
やっぱり大きなところか、例えば大きな自動車工場とかというニーズがあるから、
これを合わせる、作るのメーカーが結構多いじゃないですか。
やっぱり一番大きいユーザーからリードしないとダメなんじゃないですかね。
ダメというか、やらないとうまくいかないんじゃないですかね。
それはまあやっぱりいろいろあると思いますね。
普及っていう面に関してはそういう面はあるでしょうし、
クリティカルなこと。
例えばその機嫌、ドライブレコーダーなんていうとそうじゃないですか。
あれ誰かが言い始めたわけじゃなくて、
ユーザーが潜在的に考えているクリティカルなことを解決するための一つの技術なわけですよね、あれって。
そうですね。
なるほど。
ただユーザー同士の困りごとというか、クリティカルな共有っていうのもありますし、
ユーザーの今の一番の問題っていうのは、何に困ってるかいまいちユーザーも分かってないってことだと思うんですよ。
何が困ってあるかよく分かんない。
そうですね。
例えば福井さん、プログラム書くのに1週間かけてたとするじゃないですか。
その1週間問題ですかって聞かれたときに分かんないですよね。
そう言われても、そんなこと聞かれてもいい感じですよね。
ですよね。でも理想はゼロじゃないですか。
そうだね。理想はなくてもゼロにしてもいいよね。
理想はゼロじゃないですか。でも理想に比べたら1週間もかかってるわけですよね。
そうですね。
これはいいんですか悪いんですかっていうことを分析できてない。
判断も良くもないですね。
当たり前すぎてね。
12:01
だからユーザー自身も何に困ってるかとか今後何が必要かっていうのは多分あんまり分かってない。
多分判断基準がないんですよね。何が求められるのかな。判断基準が分からないですよね。
そうですね。ただ漠然と感じてるんですよ。
これじゃないって試してみたら。
ソフトがもっと早くなったらいいなとか感じてるわけですね。ソフトが遅れた経験とかがあったりだとか。
それはみんな国足とか遅れてるクリティカルな原因に対してちょっと違った見方とかちょっと違うことを言うんですよ。
ちょっと違うことを言うっていうの。
例えばですけど。よくあるのはチェックシートがないかなとかね。
不具合がないのがベストだけど人が間違ったのが悪いからこれはその人が間違ったのがもう一人でチェックが必要でしょうとか。
本質じゃないちょっと本質がいいことに着目しちゃったりとか。
これはその人の能力が低いというのはそういう話じゃなくてそういうものなんですよ。
健在化しない潜在的な問題みたいなのはやっぱりたくさんあって。
これをいかにいろんな人と話した結果、こういうものができるかどうかっていうのが一番大事だと思うんですよ。
これをいかにいろんな人と話した結果、こういうことがクリティカルな要素なんだねっていうのをうまくまとめるっていう作業が必要で。
うまくまとめる。
それをマーケティングって言うんですけど。
これは今のところこのマーケティングっていうものをやっぱりメーカーに丸投げしてるっていうのが今のユーザーなんだと思いますね。
ユーザー修道じゃないって言うんですよね。
ユーザーが欲しいものはメーカーが考えてるんですよね今。
ユーザーが欲しいのとメーカーが考えてる。
いいポイント言いましたね。ユーザーが欲しいものをメーカーが代わりに考えてる。
そうですね。
あたしリスナーさんのものはそれじゃないって言ったら文句を言う。
文句を言うというか、ユーザーは自分たちの今思いついたことをいっぱいとりあえず言うけど、
自分たちの横並びで言ってることをまとめてこういうことが問題なんですよみたいなまとめをして、
自分たちの横並びで言ってることをまとめてこういうことが問題なんですよみたいなまとめたりはしないわけです。
自分の経験ばんばん言うだけなんですね、基本的に。
15:01
本質見てないで、本質は自分も分かってないし、みんなも分からない。
本質見てないとちょっと悪口ぐねになっちゃうけど。
すみません、すみません。
ただいっぱい言って、いろんなユーザーの意見を集約して、
本質のところ何かっていうのを考えるのは今のところメーカーの役目やみたいな、そういう分担になってる。
となった時にさっき言ったユーザーがこうやったらST言語はいいんですよみたいな、
メーカーが引きついたとしてもやりにくいことっていうものがユーザー側で提示できないわけですね。
やってないから。ユーザー側のユーザー側の回っていくマーケティングってことはやってないから。
吉田さん今困ってることを言うだけで、今困ってることを言うのが。
言うことが多い。僕も言う。
言うことが多い、すごいですね。
とりあえず自分の思っていることをとりあえず言うっていうのはやる。
でもこれは別に悪いことじゃなくて、そう言わんと始まらんからって言うんですけど。
っていう構造的な課題っていうのはすごい歩きはしてますね。
これを解決するには、ユーザーが頑張る。
私から頑張ってレベルを上げるしかない。
そうですね。ユーザー側があるビジョンを描いていくっていうのは必要なんだと思います。
ユーザーが頑張らなきゃいけない。ユーザーチームのクオリティーを上げなきゃいけないんです。
クオリティーいいからいいのか悪いんですけど。
難しいですね。ユーザー側も自分の会社だけを考えたりしますから。難しいですけど。
ユーザーがユーザーをまたいだそういうことを考えていくっていうのは、もしかしたら必要かもしれないなっていうのは思いますね、最近。
いろんなユーザー、いろんなメーカーと話してて。
こういうものを作ったほうが、ユーザー君に合わせて作ったものだからそうなるんだろうなという感じ。
これは極端簡単な例だと、海外製のもののラーダーのエディターと異品製のデジタルでもわかりますよね、この特徴が。さっきのネタ話が。
それはあるけど、それはフードの話とかもありますからね。どっちがいいどっちが悪いっていうのはそういうフードなんでしょうね。
そうですね。日本人の考え方とドイツ人とアメリカ人の話し方も違うし、スタートポイントも違いますよね。
そうですね。やっぱり日本のものづくり哲学っていう本にも書いてますけど、
やっぱり各国の環境だとか歴史だとか、知性学的な話だとかいろいろ踏まえた上で、各国の得意なものづくりっていうのは確かにあって、それにやっぱり追従する形でこういうものが進化していくんですよ。
18:18
やっぱり開発者がそういう頭にあるからですね。
なるほど。
だからなんというか、欧州のものが日本にそのまま合うかっていうとやっぱり難しいところがあると思いますね。
いいのか悪いのかじゃなくて、ただ合わないだけですね。違わない。
でも、じゃあ日本のやり方にとっては勝てるんかっていうと、またそれは違うっていう。だからそんな単純な話じゃないんだろうなっていう。
ヨーロッパが最中したり、ヨーロッパが最先端やって言えば、別に解決する話でも多分ない。
ヨーロッパが最先端ですというだけで問題解決、追従するだけで問題解決なるわけではない。
そうですね。
なるほどね。
たぶん彼もメインする現場も違いますよね。日本の生産現場とドイツの生産現場、たぶんその環境もちょっと違うかもしれないですね。
そうですね。ただ共通する部分もあるわけじゃないですか。
日本の問題とヨーロッパの問題、中国の問題って別に全部が全部違うわけじゃなくて、働いてる以上は大枠一緒なはずなんですよ。
はい。
だからお互いにしっかりと見ていくっていうのは当然大事ですよ。
あれはヨーロッパのやり方やからなんて言っとったら置いてかれるよっていうのはそれはもう間違いなくて。
はいはい。
なるほど。
特に中国やアメリカなんて自国の市場がでかいから、自国のやり方をやっとったってある程度結果出るわけですからね。
そうですね。
だからそういう辺は当然入ってこないですね、日本も。
だからやっぱり日本には日本のやり方があるだろうし、日本には日本の戦略があるかなって思っておかないと足元救われちゃうかなって最近思ってますね。
自分のウシラちゃんを。
そうですね。話を戻ってきてST言語の追加をしつつ言語仕様はっていう話ですね。
たしかに日本のエディターはブレックポイントとか作れますだっけ、ブレックポイントをST言語。
21:08
作れますよ。
作れますか。知らなかった話。そうか、じゃあ大丈夫だね、これは。
あとはバイトアクセスとかもできるようにしたいなと思ってたこいつで。
そうですね。
例えば64ビットのデータで最初にE-Worldだけアクセスして、アンドで終わるはずですけど、ちょっと可能に考えられると嬉しいなと思ったんですね。
それもだいたいこのビットアクセスとかもそうだじゃないですか。
分かる分かる。
これは編集のこのことなのでそうですけど、そういうとこもあるかなと思ったんですね。
ビットアクセスとか、もうちょっと細かくアクセスできるようにするとか。
そうですね。くりさんの言うとおりで、やっぱり追加仕様でするんだったら、やっぱりもう少しローエンドに適応させてほしいなっていうのはやっぱりたしかにやっぱりありますね。
そう、今までできたことはできなかったらちょっと困りますね。
少なくともC言語レベルにはしてほしいですね、ローエンドを触るのは。
でも、二方もそういう意味ではないですよ。もうC言語まだ落としてたから、C言語を使えばいいやんと最後にアイテムを言いましたっていう。
それはまたこの話で別かなと思いますね。
そうですね。
これはだってC言語をどう書いたらいいかって話なんで、Cでこれがいいって思ってもたらそのC言語の仕様を今言えばいいんだろうなと思うんですけど。
あと欲しいのは、今みんなSTで剥ぎ出してるのはもうIC6社立の中央に順次してXMLを出してるんですか?
いや、全然そんなことはないですよ。
剥ぎ出しとかも統一したいなと。
STにおいては別にあんまりどうでもいいですよね。
そう思ったんですけど、剥ぎ出すとやっぱりちょいちょい違うんですよ。剥ぎ出しても飽きなくなったってもうコピペになったんですよ。
特にコピペがほうが早い剥ぎ出すよりは。
そうですね。
なんていうんですか、XMLで吐かなくていいんですよ、ST言語だったら。
コピペでほうが。
要はバーインプット、バーアウトプットで変数のところを括って、あとはメイン関数のところ、PoEのところを書いてっていう。
そういうST言語だけ言うんだったら別にわざわざXMLにする必要って多分ないんですよね。
これはグラフィック言語だから必要かもしれないという。
あれをうまくまとめるのにXMLなんですよ、あれって。
だからSTに限って言うんだったら別にそこまで重要じゃないですね、XMLは。
なるほどね。
24:01
あとはライブラリ。
ライブラリ管理。
でもこれも各メーカー違うから統一仕様にならないでもうすぐね、これは。
ツール依存。
まあでもそうでもないからツール依存しちゃおうか、これも。
ライブラリ管理すると。
ST言語だったら文字ベースだから、そういうライブラリ管理とか前の単純な言葉とかの称号論がすごいやりやすいんじゃないかなと思ったんですよね。
まあぶっちゃけライブラリ管理は仕様の管理に近いんで。
例えばですけど、アイコンの命令が動作仕様まで完全に合わさってるかって別にそうじゃないですよね。
だからあれってハードウェアメーカーの各社がやっぱり用意してるんですよ。
ただ大体こういう機能があればいいよねっていうのは統一されててるっていうのがやっぱり大きなところで。
大体機能があればいい。
そうですね。
なるほど。
要はユーザーからしたら実装はどうでもいいんですよね。別に動きはいいから同じインターフェースで。
そうやって動くかどうかですよね。正しく動くかどうかですね。
それが保証されてるかどうかのほうが圧倒的に大事なんで。
どうやって実装するのか別にどうでもいいんじゃなくて、そんな大事じゃない。
こんなにこの結果が出ればどうか正しくが大事ですよね。
そうですね。結局世の中にSTのオープンソースライブラリーっていうのもありますけど、
それもやっぱり仕様だけ統一して結局各社仕様のライブラリを出してるっていう現状もあるから、
それで運用できるだけで構わないわけですよね。
その管理が大変だという話はあるんですけど。
はい。そうだね。なるほど。
大枠だけ決めて各社各作で合わせて作るって感じですね。
そうですね。統一してほしいっていうのは統一してる気持ちはありますけどね。
この間センが言ってたパケメルも一番いい例かもしれないですね。
仕様だけを出して各社と合わせてチームのPFC、コンドローラーにIPを作るみたいな。
多分そういう形のほうがいいかもしれないです。今のところは多分いいかもしれないですね。
あとはそれをどうやって意見を取りまとめるかというか、
メジャーな意見にしていくかっていうほうが大事かなっていう。
例えばユーザーの声をキャッチアップする?
そうですね。単的に言うと勝たないといけないってことですね。
はい。なるほど。
これはどんなに素晴らしいシステムでも、これは100点ですというシステムでも、
27:00
広く普及した80点のシステムには圧倒的に負けちゃうんで。
はい。もう一回言ってもいいですか?分からなくて。もう一回言ってもいいですか?
例えば100点のシステムがあったとしますよね。
はい。
これ100点の仕様ですっていうのが、じゃあ世界の20%で使ってますっていうものと、
これは80点なんだけど、80%使われてますっていうものだと、
世界の80点が圧倒的に勝っちゃいますよね。
そういうことですね。
だって残りの2割はどうとでも挽回できる分はそのシェアがあれば。
そういうことですね。挽回できました。
だからやっぱり勝たないといけないんですよね、この手のやつって。
なるほど、なるほど。
その勝ち方っていうのは多分いろいろあるんだと思います。
日本語くらいで統一、そういうメーカー、言葉のメーカー一緒に座って、
何ですか、チャンスとか。メーカーだけで、何て言うかな。
参加、日本のPLCメーカーで一緒にプロジェクトを作ろうとか、今まであった、ありますか?
別にいろいろあるじゃないですか。例えばエッジクロスとかもありましたよね。
あれは言語の話じゃないけど。
やっぱりメーカーが集まって評価を作ってって話はいっぱいあるんですけど、
なかなかうまくいかないですよね。
それは多分勝てなかったからっていうのが一番でかいことだと思います。
勝てなかった。
勝てなかった。それは主流にならなかったってことですね。
なるほどね。難しい。
例えばで言うと、OPC UAとオラインだったらOPC UAが発祥したっていうのもあるじゃないですか。
そうですね。
別にオラインは悪い仕様じゃないです。全然悪い仕様じゃないですよ。
OPCも全然良くない仕様もいっぱいあるけど、結果勝ったのはOPCが世界で勝った。
勝ったんですね、今。主流になっちゃいましたよね。
いいのか悪いのかちょっと置いといて。
なるほど。この話は何でか使用。
使用でかはもうちょっとSD言語以外のことか。
別にSD言語でいいと思ってますし、SD言語を拡張したり普及したりするっていうことなんだと思うんですよね。
はい。
SD言語。
そうですね。何でみんなSD言語を使わないんですかっていうことに対するクリティカルなことは何なんでしょうねっていう。
30:02
いや、別に使わなくてもそこまで困ってないと、最近私はここら辺の漏れた答えかなと思ったんです。
そうですね。だからぶっちゃけた話で言うと、そんな好機能なくてもええやんっていうのはありますよね。
そんな好機能じゃなくてもええやん。
要は何かというと、例えば何でもできるPLCと1個しかできないPLCがあったとするじゃないですか。
ありますね、はい。
でも必ずしも何でもできるほうがいいとは限らないんですよね。
はい。
例えばですけど、1個しかできないPLCっていうのは何も迷わないんですよ。それしかできないから。
なるほど。
でも何でもできるPLCは1つのことをやろうと思ってる無限のやり方があるんですよね。
ということは何でもできるPLCっていうのは扱う人にすごい決断力を要求するんですよ。
なるほど。
機能制限されてもうこれしかできないから。
そう。となったら決断力のある人って全体の例えば20%しかいないとするじゃないですか。
はい。
じゃあさっきの100点の20%と80点の80%の話になるわけですよ。
圧倒的にこっちは大きいって言うんですよね。圧倒的にはいかないですから。
例えばですけどね。
はい。
これいいですね、確かに。
今終了というか、OBの終了、何でもできるのかコンセプトがどんどん盛り上がってるイメージがあるんですよね。
この間僕らSPTフレームワークの話したじゃないですか。
しましたね、はい。
ああいうのは一つの会議だと思うんです。
何でもできるけどその上にフレームワークを載せてやり方を固定化していくっていう。
できることも決めるというかやり方を決める。
そうそう。だからこのPLCっていうのはすごくいろんなことができます。
でもその上にこういうフレームワークを置いてこれは便利です。
この便利さっていうのはある制約を課してるから便利なんですよっていう。
便利だった。
やっぱりこうするべきっていういわゆる設計論をPLCの中の上に載せることによって便利にしていると。
不便にすることで便利にしてるわけです。
でもね、このSPTフレームワークの話ですけど。
33:01
で、わし一回だけ動画とブログ書いたんですね。
で、アリー内にたぶんこの23日でもたぶん6人くらいがわしのメールとかに届いてきて、
もうちょっと説明してよ、ちょっと自理大にするってやんな。
いろいろと来たんですよ。
たぶんやっぱりできることが多すぎて、ちょっと迷って。
話したらもう自分書くのめんどくさいし、どう書くのかわかんないし。
フレームワークがあったらこっちで使ったほうが便利そうだな、ちょっと教えてよみたいな。
問い合わせも何回も来たんですね。
高畑さんの。
ちょっと似てることで似てるかもしれないですけど。
制限かけて100%動くのが今の一部の人が求めてるんじゃないかなと思うんですね。
難しいですよね。
全部できなくてもいいんじゃないと、できる程度そこまで求めてないというのが多いんですね。
でも人ってワガママで、簡単なことだけだったら競争に負けるんですよ。
競争に負けるんですよね。
だから簡単でありながら難しいことをしたいわけです。
なるほど。簡単で難しいことをできるようにしたい。
そうですね。
それはどういうふうにできるかねっていうことを我々はやっていかなあかんと。
その一つの回はフレームワーク系はそれで実現しようとしてるわけですね。
基本的にはこれできると。
気に入らんところがあるんやったら自分で拡張せってことです。
その自由度はまだ残ってますね。
その拡張できるところに関しては非常にICの凄く準拠率の高いものを用意しておきましたっていうのが、
おそらくベックオフとかCodesysの主張なんだと思ってるんですね。
日本のPLCの主張はそれでもまだ難しいっていうのが日本のPLCの主張なんだと思います。
それでも難しい。
もっと簡単にした方がいいやろ、これだけでいいやろっていうのが日本のPLCの主張なんだと思いますね。
別に難しいことやらなくても、そんな拡張とかエキスタンドがもういらなくてもいいんじゃないということ。
そうですね。
でもこれまた正解と違いとかはないですもんね。ただ考えた違いだけですよね。
そうですね。
ただ、それぞれについてできることの差っていうのは確実にあるので、
それがあるイノベーションがバーンと起きたときに決定的な差になる可能性っていうのは別に頭痛にはらんでるわけですね。
なるほど。
例えばフレームワークを載せましたらこれ全部自動設計できますみたいになったら、
もう日本のPLC勝ち目ないですよ。
そうだ。
だってそれを真似することはできないわけですけどね。
日本のPLCは全然機能面で劣ってるわけだから。
36:03
機能面で劣ってるって言ったらちょっとあれですけど、
ICの準拠率とかそういうもので圧倒的に劣ってるので、
その準拠率がすごいPLCではこういうことができますっていうキラーアプリが出たときに追従できないわけですよっていうリスクはありますよね。
ただそういうのがなかったら簡単なほうが楽で早くて確率じゃんとも言えるわけですから。
なるほどね。
ここはバランスだと思いますね。
バランスですね。
なるほど。
各メーカーのユーザーはどっちにベッドするかっていうのを今多分思い悩んでるんだと思います。
みんなも悩んでますね。
試しながらどれが一番いいのか。
だからこれは結構深いテーマだとは思いますね。
これからも考え続けなきゃいけない。
だからST言語に追加してほしい言語仕様。
そもそもST言語。
ST言語どういう立ち位置するか。
他の言語と。
もっと深い話ですねこれ。
ただST言語どういう仕様追加しなきゃいけないんじゃなくて。
そうですね。
ST言語どこまで。
基本的に設備のプログラム全部ST言語で組み合わせて前提のもとでだと思うんですけど。
どういう上にアプリケーションやフレームワークを積むかっていう話ですよね。
これSTの言語仕様っていうよりはICの仕様としても多分入ってくると思うんですよ。
例えばですけど、今のICって並列系の処理とかは特に規定してないわけですよね。
いわゆるマルチスレッドとかはないわけですよ。
そういうのがいるんかとか、そういうのがあったら何ができるんやみたいな話は多分あると思います。
これをやるんだったら、ICでやる言語じゃなくて別言語でいいんじゃないとかいう議論もあるしね。
っていうのもあるし、ただICで行くんだったらそういうのがあったらその上に何か詰めるんかって話もあるし。
はい。
なるほど。
ただ僕らがあまり他の言語仕様について詳しくないんですけど、
もっと言うんだったら、例えばSTでアサート文を入れられるべきかとか、
エラーハンドですか、すみません。
アサート、いわゆるエラーハンドリングができるんですよね。
いろいろな話があるんですけど、
エラーハンドリングもできるところもできないメーカーもあるので、
もう分かれちゃったんですね、僕らも。
39:00
なるほど。
っていう話かな。
そうですね。
別にSTで書くことにはそんなに問題ないと思うし、
ST、本気でやるんだったらSTでやれるような周りを整えれば別にいいんじゃないかと思うんですよね。
そうですね。
はい。
そうだね。
でも、どうなんだろう、多分私も軽減で、日本のメーカーって、かつてST描いてるメーカーも結構いるんですけどね、
昔の染色でもそういうプロームも結構見舞ったし、
そういうプロームが見舞うというか、
みんなの言うほどエクストとか、みんな言うほどやってないわけじゃないと思うんですよ、コロナで。
いや、まあ究極品質でやるんやっていいんですよ。
そうやってますよ、みんなちゃんと真面目に頑張って。
順次して平成も切り、定位してやってるんですよ。
だからそこまでひどくないんですよ。
なんでみんなそんなひどく言われるんだろうと、自分自身は思うんですけど。
STひどく言ってる人は別にいないと思うけどな。
そうだね、だからちゃんとやってますよ、STでも。
ただ要は何て言うんですか、
ST言語で生産設備をやりきるのは、
まだちょっと難しいんじゃないとは思ってますけどね。
アーキテクチャ的に。
なるほど。
適切適正ですね、やっぱり最終的には。
まだ手でやっていいんじゃないという感じかもしれないですね。
それは別にSTでかける設備なんていっぱいありますし、
STでかけない設備もいっぱいありますよ。
ただ、実装する権利も違うだけですもんね。
そうですね。
この話意外と深いですね。
そうですね、だからなんていうか、
ラダーにしがみついてるから遅れてるとか、そういうことを言う人もいっぱいいますし、
そういう人たちもいっぱいいますし、
なんていうんですか、ラダーにしがみついてるから遅れてるとか、
そういうことを言う人も僕は微妙だと思いますし、
ST言語をひたすら嫌うような発言をする人も別にちょっとと思いますし、
そこじゃないとは思いますね。
もうちょっと本数があるんですよね、ここじゃなくて。
そうですね。
言語は言語じゃないとできることだと思いますね。
42:02
言語は言語じゃないとどういうことですか。
言語はあくまでプログラミングツールでしかないじゃないですか。
表記のほうですね、この動作の表現する。
別にみんなプログラミングをしたいんじゃなくて、結果が欲しいわけであって。
装置をきれいにちゃんと受ける。
だったらすぐ止まれる、原因が分かる。
ゴールが間違ってる、間違ってるかゴールがちょっとぼやっといっちゃったかもしれないですね。
そうですね。
ST言語を使うのは。
あとはビジネス的にやれるかっていう話もありますし、
保守運用って話もありますし、
いっぱいありますという話でございました。
はい、ありがとうございました。犬旗のすごいいい質問でした。ちょっとまた書き換えました。
はい、じゃあ犬旗ありがとうございました。失礼します。
はい、ありがとうございました。
