00:01
皆さん、こんにちは。ファクトリー オートメーションラジオです。本日
は第8回ですね。クリスさん、本日も よろしくお願いします。
クリス よろしくお願いします。
おだしょー というわけで、ジムトフも始まりました
ね、クリスさん。
クリス そうですね。一応、金曜日
行く予定ですけど、高橋さんはいつ 行くんですか?金曜日ですか?
おだしょー 私も金曜日ですね。金曜日
と土曜日の午前中、ジムトフには 向かう予定ですね。
日曜日まででしたっけ、あれは?
おだしょー 日曜日までですね。
クリス 日曜日は息子と行こうかとか、
ちょっと考え中ですね。
おだしょー 3日間ですか?
クリス そう、最後にはもう子供と
一緒に行こうかなと思ってますね。
子供を許すかどうか、ちょっと金曜日に、
子供がいるかどうかによって、ちょっと 判断しようかなと思ってます。
おだしょー なるほど、なるほど。
クリス はい、そうだね。
おだしょー さあ、じゃあ、今日も
それからいきましょうかね。
クリス そうですね。
おだしょー 本日はたくさんお便りいただいたんですけど、
クリスさん、どれか気になるものありますか?
クリス 私からでいいですか?
おだしょー はい、どうぞ。
クリス じゃあ、そうですね。
簡単な話から始めようかな。
どうしようかな。
じゃあ、ちょっと真面目な話しようかなと思いますね。
ちょっとモンアップして。
ラジオネームぞうそうさまからのお便りになります。
いつも聞いてくれてありがとうございます。
ラジオネームぞうそうさんからの質問です。
ラウダー言語だけでカプセル化する方法について、
ちょっと話してほしいということなんですけれども、
いきなり真面目な話なんですけれども、
まずラウダー、私から話してもいいですか?
おだしょー どうぞ。
ラウダー言語だけでカプセル化する方法というトピックですけれども、
おそらくまずはカプセル化から入れようかなと思ったんですね。
カプセル化というのは、
多分彼らは曰くちょっとライブラリからで言う方がいいかな。
もうちょっとこれ日本語何て言うんだっけ。
上昇化。
どう言うんでしたっけ、日本語は。
上昇化?
上昇化をしたいんじゃないかなと思ったんですね。
例えばサーボドライブを制御するプログラムなんですけれども、
これを中に必要な要素だけを収集して、
そしてカプセル化して、
他の人も作ったプログラムも使い回せるようにしたいんじゃないかなと私は思っていますね。
この理解で合ってるんですかね。
03:00
まずカプセル化ってどういうことなんですかね。
これはちょっと場合によってはソフトウェアのOOPのコンセプトのカプセル化の話ですよね。
今はカプセル化についてGoogleに調べたんですけど、
初めにカプセル化って何ですかというと、
カプセル化はコンピュータープログラム用の概念であり、
特定のデータ構想とアルゴリズムに何とまとめたソフトウェア複合体の内側の総裁を
その側からインベースすることを定義されている。
隠された方法は計算技科学者デビットさんが推奨したものですね。
データをまとめることをカプセル化と呼ぶと言うんですけれども、
高橋さんはカプセル化ということはこんなことじゃないかという解釈はあるんですか。
そうですね。カプセル化自体にはすごくいろんな論点があると思うんですけど、
実際にはいかに最小のコースでソフトウェアを作り上げていくかということですよね。
いかにも早くソフトを作り上げる、使い回せるというイメージですか。
あまり使い回すという言葉は適切じゃないなと思うんですけど、
基本的にはやりたいソフト、作り上げたいソフトウェアをいかに早く、いかに品質よく作り上げるかということが主眼に置かれていて、
使い回すというのは毎回作った品質のいいソフトウェアをそのままいじらず使えば次も品質がいいよねっていう、
そういう観点に基づいて使い回しているものが用いられやすいというのが、こういう話にあるのかなというふうに思います。
はい。
なので別に、じゃあ一から全プログラム書きます。でも5秒で書けます。であれば別にそれは5秒で書いてしまっても別に構わないんじゃないですかね。
そう。カプセル化する必要性はどこ?それのメリットをまず考えない。何でカプセル化しなきゃいけないということですよね。
そうですね。何で今カプセル化をしないといけないということがよく言われているのかということはひも解いたほうがいいんだろうなというふうに思います。
例えばアルゴリズムは実際にプログラム機器を制御する場合はアルゴリズムを隠して、この辺全部隠して、それでメソッドとプロパティだけ出して、
06:08
例えばこのget、サーブモードの場合はモーターの中のプログラムの複合体の中でこのメソッドコールだけ呼び出せばサーブモーターが維持決めできるとか、
リセットできるのかできるのかできるみたいな感じで、プロパティだったらこのプログラムだけアクセスすれば今のサーブドライブの状態をまるごと取れるとか、そういうことをカプセル化しているんじゃないかなと今さっき思いついたんですね。
カプセル化っていう言葉だけ言うとそうなるかもしれませんね。
これがなぜこんなことをするかですよね。
なぜこのカプセル化をして、ソフトウェア設計者にとって何がメリットあるのか、現場の人にとって何がメリットあるのか、これをちゃんと伝えて理解しないと、
たぶん一回作ったソフトでも結局時間かけて作ったのに誰も使わないずに後戻した、前のやり方を戻したということになると思うんですね。
カプセル化すると何がメリット、どんなメリットあるのか私もまだソフト人間じゃないので、そんなにカプセル化のメリットをちょっと理解できなかったんですね。
どういう流れでそうなるかっていう話ですよね。
いかにもうすでにITはカプセル化したりだとか、そういうことが当たり前になってきた世界線なので、そこから見ていくとちょっとよくわからないかもしれないですけど、
ラダーは今まさにそうなろうと、ラダーっていうのはPLC系ですね。産業ソフトっていうのは今まさにそういう方向に進もうとしているところなので、今産業PLCの世界観で見ていくとそこでわかりやすいかもしれません。
例えばですけど、本当に単純なプログラムですよね。
例えばエアーシリンダーがシュッシュッシュッと4回順番にシーケンスで動きますっていうのはやっぱり見た目も簡単だし、誰が見ても構造っていうのはパッとわかると。
書いてあることも少し勉強すればだいたい理解できるような、そういう感覚の回路っていう時期が昔あって、
そこから3軸あったとして、それが100軸になりますと。
じゃあめっちゃ簡単だけど、それが100個あるっていうのはとてもコピーしたりするの大変だし、手打ちのミスがあったりして大変だよねって。
09:03
じゃあ一番簡単な1軸だけの回路を標準として作って、それをコピーして、品質の保たれてる部分がそのまま使えるようになれば確認するところは一部で済むよねっていうような形ですよね。
それがまずコピーをしていくっていう考え方になってくるわけですけど。
そこから次はコピーしても結局上の部分は書かないといけないわけですよね。同一にどういう順番で何をっていう。
そうですね。
そういうところがやっぱり非常に複雑になってきたので、そういうところを決め事をしましょうと。
なるほど。
中のプログラム何書いてるか全くわからなくても、一番外側のインターフェースだけ、動作指示方法だけ知っていればそれが要は扱えるようになりますよね。
こうやりたい方法を作れるプログラムの作り方はどうなんですか。こういう形で少なくとも産業プログラムは今のところちょっとずつ拡張しているような形になります。
でもそういう考えだと、産業プログラムと私たちまで使っているPoCの関数でもそうじゃないかなと思ったんですね。
そうですね。
関数が中にどうやってこの関数が何だったかわからないじゃないですか、私たちも。
はい。
とりあえずこのパラメータさえ渡せばこの結果もらえる。私たちはもう常にずっと使っているんじゃないかなと思ったんですね。
例えば高橋さんの話聞いたら。
結局はそうですよ。
そうですよね。
たぶんいわゆるこのITからカプセルカードという言葉が出てきて、じゃあどうやってカプセルカードを話したのか。
今まで私たちもたぶんずっと知らない知らない間でずっとこのコンセプトを使っているかもしれないんですね。
そうですね。だからなんて言うんですかね。
結局的にはある機能を呼び出してきてそれを組み合わせて何かを作りましょうっていうのが基本的に根本にある考え方なんだと思います。
なるほど。
ただそれをやるにも普通にやるとめちゃくちゃ大変っていうのがやっぱりいろんな問題が出てきて。
はい。
例えば関数Aっていうものと関数Bっていうものがあって、実はBっていうのはAをちょっとだけ改造したものです。
はい。
っていう風になった時に、じゃあそれはBっていうのを1から全部書くんですかって関数をいちいち。
今先ほど議論してたのはもう既に完成されたライブラリーがあるという前提に立った時にそれでいいよねっていう考え方ですよね。
なるほど。
そういうところを新しいものを作っていくときに既にあるライブラリーではちょっと心もとないとかちょっと足りないみたいなのがたくさんあるわけです。
でも関数の中身ってブラックボックスだから分からないわけですよね、外から。
12:01
分かんないですよね。
分かんないですよね。でもそれをちょっと付け足したいとか、じゃあそれを1から全部書くんですかみたいな。
そういうライブラリーを構成する部品っていうものを作っていくのが結構大変だよねっていう風にこういうのが進んでくるとなってくる。
なるほど。
そうなってくると、じゃあそれをもとに何か改造できる関数を作れるようにしましょうだとか、こういうのがクラスの概念であったりだとか継承の概念っていうものに繋がってくる。
なるほど。今の関数をオーバーライトしたりとかできるようにした方が、こういうコンセプトを使うんだったらこういうことまでできないとダメだよねということですよね。
そうですね。なのでソフトウェアを作るときの考え方として既に用意されたものを全部組み合わせるだけでやれるんだったらこういう概念は基本的に必要ないです。
なるほど。
ただソフトウェアを進化させていく上で、やっぱりそれだと物足りないし自分たちのやりたいこともできないので、それに少し加えた何かを作らないといけないと。
なるほど。
で、既に用意されたライブラリ群だけを使っていくようなものでは、そういうソフトウェア的な柔軟性っていうのは多分生まれないので、そこに今のものに少し付け加えてとか、今のものをベースとしてどういうふうにものを作っていくか。こういう概念が多分あるんだと思いますね。
ここ僕専門じゃないので、間違ったこと言ってるのがすごいしますけど、僕の理解はそういう理解です。
そうですね。これをここまでできるというか、さっきの対応データでは、このラーダー言語だけでカプセル化する方法ですよね。
で、次に注目するのは、このラーダー言語だけというのは、これも方法でいうか、これまず対応できるメーカーがどこあるかですよね。
もちろんラーダー言語だけでカプセル化したい。
基本的にはIECに対応していればできると思いますけどね。
そうですね。各メーカー、ちょっとだけ特性のことを除いたら、基本はできるはできますね。
例えば、オーバーライトとか、メソッドとか、プロバティとか、インターフェイス使うんだ、一部のPIC今しか欠けてるんですけれども、基本型はできると理解でいいんですよね。
基本的に必要なことは、ローカル変数、グローバル変数の概念があるっていうことと、あとはそれを、ある塊を呼び出せるっていうことですよね。
そう、呼び出せる大事ですね。
これだけあれば、基本的にはカプセル化っていう概念自体は成立するので、PLCでいうとPOUの区分とファンクションブロックの区分があれば、一旦成立すると思います。
15:09
なるほど。さっきの話まとめると、PLC側がローカル変数とグローバル変数をしっかり切り分けれるというのが大先手で、その後にこのPLCメーカー、このPLCのソフトウェアが、
ちゃんと自分が作ったソフトウェアの塊を、別のどんなタイミングで呼び出せるようにしておけば、それでもカプセル化ができるという考えですね。
ただ、それだけだとやはり先ほど言ったみたいに、ちょっと改変したもの、いわゆる例えば位置決め制御っていうのが8軸分ありますっていうときに、全部同じ位置決め制御だと不都合ですっていうときに困るわけですよね。
そうですね、はい。
となると、それをちょっと改造したときに、もう管理ができなくなるわけです。部品のライブラリの管理ができなくなってきたりするわけです。
そうですね、はい。
なので運用面だとか、そういう面も考えていくと、PLC各社の使い勝手の差っていうのが多分出てくるんだと思います。
ここですね。実際に自分のやりたい制御のときにどんだけ融通効いてくれるか、融通できないですよね。
この中で高橋さんに持っているのは国産は多分、この方が聞いている質問は多分国産はたくさん触っているんじゃないかなと思ったんですね。
多分ですけど、ちょっと偏見は持ちたいですけど。
この中に高橋さんがこれをできそうなところはあるんですか?
基本的に今のPLCメーカーでできないメーカーはないと思います。
そうですね。基本的にはある程度の枠はできるんですね。あとはどんだけ使い勝手ですよね。
そうですね。
どんだけ使い勝手。これの使い勝手が自分が今のソフトウェアの開発の思想っていう言い方?いいかな。
AOKAとかですよね。
そうですね。あとなんていうんですかね。
基本的にはさっき言った最低限のところっていうのは、カプセル化の考え方だとかOOPの基本的な考え方。
OOPってあれですけど、いわゆるオブジェクト思考の考え方。
基本的な考え方ができている人が集まってやったらやれるよっていう話なので。
そういう考えが概念としてあまり持ってない人でも使うようなシステムを組んだり表情を組んだりするっていう場合には、
もう少し高度な機能っていうものが必要になってくるだろうなっていうふうに感じます。
じゃあ例えばそういうソフトウェアの方でOOPとかをやってみたいと思ったら何かアドバイスはあるんですか。
18:01
ここから始めた方がいいですよとか、どういう始まり方がいいのかなんかあるんですか。
まずラダーでやらないことじゃないですか。
まずラダーを。
諦めるというか、ラダーでOOPを学ぼうっていうのはなかなか難しいと思いますね。
なぜならラダーでOOPで書くっていう設計論が世の中に全然ないからです。
こうしてくださいねっていう一般的なお作法っていうのが確立されてないのでまだ。
だから最初にラダーでカプセル化をしたときにそのできたものが正解なのか不正解なのかっていうのはなかなかわからないと思います。
なので本当にやりたいんだったらまずテキスト言語の方でOOPプログラムっていうものに触れて、
大体こんな感じなんだねっていうのを理解した上で、
じゃあそれをラダーに落とし込むんだったらどうだろうねっていう方が多分いいと思いますね。
なるほど、テキスト言語は別に本当に例えばPS言語じゃなくてもPythonとか何でもいいので、
こうやって一回OOPがどういうコンセプトなのかちょっとある程度をサラッと理解した上で、
じゃあこの考え方がどうやって私たち今使っているPLCシステムの中に取り込めるかを考えたほうがいいんじゃないかという感じですよね。
いいと思いますね。
なるほど。
ラダー言語だけじゃなくて、PLCの語言語もそうですけど、基本的には全然機能的には十分じゃないので、いきなりそこでやったとしてもやっぱ苦労すると思います。
参考的に総数も少ないですよね。リソースもそこまで多くはないかもしれないですね。
そうですね。
なるほど。そう考えると普通の一般のITのテキスト言語を触った上で、それをやったほうがこれが正解だなというある程度の概念があるかもしれないですね。
そうだと思いますね。僕は多分そうだと思いますね。
ラダーだけを一生やってこの概念を確立していくっていうのは結構大変だと思います。
大変ですね。大変。
これは別にテキスト言語にみんなしましょうねっていう話ではないですね。
単純にラダーの歴史にそういう歴史がないっていうだけなので、
それを今からどう組んでいくかっていうのが今我々の少し瀬戸際になっているところ。
なるほど。ということで各メーカーとかこれからどうやってやるかを考えでいろいろシリーズを出しているんですね。
21:01
やっぱりあんま勘違いしない方がいいのは別にOPが全てに勝る正義が正しいわけではないですよね。
特に小規模プログラムを書くときなんてOPの概念むしろ邪魔になることありますからね。
わかります。わかる。
こんな小さな機械のためにこんな大げさなことまでやるんですかみたいな。
普通に書いたほうが早いっていうか場合もあるしですよね。
そうですね。なので、OPが活躍するようなことが全体の5パーとか5パーの中に入っているのかどうかっていうのがちょっと分かるかもしれないですね。
全体の5パーとか1パーしかないっていうような場合にじゃあOPの概念に入った方がいいんですかっていうのはやっぱりちょっと考えるところはあるでしょうね。
ただ今世の中の流れとしては生産設備のソフトウェアっていうのもどんどんどんどん大きくなっている現状があるので、
いずれそういうものが活躍する場っていうのも近くくる可能性があるっていうことだと思います。
勉強しては損が絶対ないんで。
そうですね。当然それが来ない職場もあるし、来る職場もあるでしょう。
でもいるかいらんかはやってみないと分からないので。
やったら多分好きかもしれないですね、本人が。
そうですね。
やったらやっぱりこれハマるとかあるかもしれないですね。
なので触れておくっていうのはいいんじゃないですか。
そうですね。社内のチームの会社のソフトウェアのチームの文化を受け入れるかどうかですね。
どういうフル音も組んでいるか、この振り方が本当に納得するかどうかですね。
一緒にチームやってる人が。
そうですね。
POCプロミューの結構一匹狼で言われること多いんですけど、これからもそうですかね。
一匹狼っていうのは。
POCプロミューを作るにはもう一人でやるのが結構イメージ多いんです。
まあそんなことないと思いますけどね、別に複数で書いてる例ってたくさんあると思いますけど。
なるほど。
そうですね。
でも本当に一人しか書いてないんだったら、いわゆるチェックイン、チェックアウトのシステムなんてないですし、世の中に。
世の中に対応しないし、Gitもいらないじゃないですか。
いらないですね。一人だけだったら別に。
そうですよね。
そうですよね。
そうですよね。
そうですね。
でも現実そういう製品が多数世の中に出てきてるっていうことは、他人数で開発してるPLCプログラマーもたくさんいるということだと思います。
で、そこで高谷さんすごくオススメ作のソフトウェア、
ソフトウェアの製品が多いんですよね。
24:01
そうですよね。
そうですよね。
そうですね。
それはちょっとカプセル目の人はずれますけどね。
だいぶずれましたけど、いろいろあるんですね。
管理とか、
そういうのがあるんですね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですよね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
そうですね。
本当にね、
本当にね、
本当にね、
本当にね、
本当にね、
Лuting как хорошо
Т bow
なるほど、確かに。
なるほど、確かに、
そういうぐらいですね、
確かにそうですね。
そうですね。
そうですね。
でも、仮に
でも、仮に
對
決まったことをずっと繰り返します
2つを繰り返す
よう
動画
とか
filmed
動画
でした
続まない
そうですね 新しいことや難しいことが 極力排除されてるほうが 新人が来たときもしやすいし ミスも少なくなるし いわゆる選択がないからですね
絶対これしかできないってやったら それしかしないから 間違わないし
こっちは合律的ですね 場合によっては 合律的ですね
はい だからそういう見方もやっぱ あるっていうことです
なるほど なるほど
ケースバイケースですね
ケースバイケースっていうと ちょっとあれですけど 要は世の中の流れやビジネス的な観点から
どっちのほうが都合がいいかとか 世の中の流れがあるかっていうことが重要であると
なるほど
我々はソフトウェアでこれから ガンガン価値を上げていくんだよっていうほうに
僕とクリスさんはベッドしてるってことですね
そうですね 頑張りたいと思います 新しいことをどんどん
はい まあちょっと
テストさんの答えがどうか分からない なんか分からないですけど まとめ言うと
まず最初は カプセル化する方法という前には テキスト言語で Pythonでも何でもいいので
そして 私たちはこのOBのコンセプトを さらっと分かった上で
これをどうやってラッター言語に落とし込むか やり方のほうがいいかもしれない
あとは 自分に今使ってる PLCのIDEとか こういうプログラムツールが
27:06
ローカル変数やグローバル変数とか ちゃんと分けてるか
あとはプログラムの塊をどこでも呼び出せるかどうか
それによっては作り方もとか 使えるかどうかも変わるというところ
あとはケースバイケースですね 最後の高田さんがすごい言ってた大事なのは
今までずっと同じことしか繰り返してたり やってないと
だったら逆に合理的に考えると そういうカプセル化も いらないかもしれない場合もあるので
そういうときはケースバイケース
ケースバイケースっていうよりは 何を主軸とするかですよね
そうですね 何を目指したいという 言い方のほうですよね
それにのっとったやり方があると思います という話ですね
そうですね
ちなみにクリスさんに聞きたいことがあるんですけど
どうぞ
仮にラッターでカプセル化するとして
POUで括っていく方法とファンクションや ファンクションブロックで括っていく方法
2パターン今のところあるような気がしてるんですけど
ファンクションブロックです
ファンクションブロック派ですか
絶対ファンクションブロック
僕逆なんですよね 僕ファンクションブロック 反対派なんですよ 実は
僕POUで括るタイプなんですよね 現状で言うと
なんでですか
書かなあかんから
え ということ
ファンクションブロックにすると ファンクションブロック並べなあかんっていうのと
ファンクションブロックをちょっと改造する っていう術が今のPLCに薄いんで
ちょっと改造という
いわゆる継承の概念とかが基本的にないっていう前提を持ったときに
ファンクションブロックバージョン1.1 1.2っていうのが乱立するっていう
これはないです
そうですね それがあるんで
今のところ自分はPOUで括るべき 現状で言うと
っていうちょっと考え方を今持ってるんですよね
なるほどね なるほど
結構PLCメーカーとはちょっと 意見が割れるところなんですけど
そうですね あと結局ファンクションブロックが
バッチリJustSiemens使ったんですね
JustSiemensはファンクションブロック 非常によくできたので
最初の世界メーカーで1番目 最初にファンクションブロック
コンセプトを推奨したメーカーと思うんですね
何て言うかな
インとインナウトとか
そういう使い方もちゃんと切り分けてるんですね
本当にドキュメントもあって ファンクションブロックを使うときに
いつイン使うか いつアウト使うか いつインナウト使うか
もう全部書いてるんですよ
こういう場合はインナウト使うほうが 法律的にいいんですよとか
中身の変数をどうやって並べばいいのか
30:02
ファンクションブロックの中にまた ファンクションブロックを呼び出すときは
何が注意点必要なのか 全部ドキュメントしてるんですね
これはSiemensのところに Siemensのプログラムガイドラインを
Google検索したら出てくるんですよ
大体60 70ページの英語のPDFが
あれ見たらいろいろ納得できるんですね
セーフティーバージョンもあるので
セーフティープログラムガイド
そういうところでどうやってファンクションブロックを
組むのか 法律的なのか もう全部書いてるんですよ
これを見ながらやったので やっぱりコケるんですね
例えば 中の変数をちょっといじったら
組織化しちゃったりとかあるんですね Siemensの場合は
領域と配列の長さを変更したら
中では全部組織化しちゃうとか
そういう場合もあるので
どうやって避けるのか
ノウハウが書いてるんですよ Siemensで公開してるんですね
そういうノウハウが
彼のPFCの考え方
これを読んだ上でファンクションブロックを
組んだんですね
だからファンクションブロックよく使う
あとはメーカーのせいですけど
Siemensで基本はPOUは
基本の基本は1個しかないんですね
分かれるのもあるんですけど
基本1個しかないので
皆さんはこの中にファンクションブロックを
たくさん読んでるっていうイメージ
よくやるんですよ
多分これはPFCメーカーの都合のせい
だからこうなっちゃったということもあるんです
今まで例えば
自分で使ったのはSiemensなので
ライブラリをダウンロードするときは
ファンクションブロックとしてダウンロードするので
もう使うしかないんですね
ある意味でいうと
彼らのサーボを制御したときは
彼らのサーボのファンクションブロックが
ライブラリに出てるので
ファンクションブロックを使うしかない
という現状です
僕はそれ嫌なんですよね
しかもバージョン変わるので
前のバージョンなくなっちゃったとかあるんですよ
紹介像が大量に入るようなことを考えたときに
やっぱりファンクションブロック都合悪いな
って思うんですよね
ファンクションブロック都合悪い
都合悪いときある
やっぱり結局我々すごく不具合を出すんで
トレースが取れないんですよね
ファンクションブロックって
これ結構言われるのが
例えば10個のインスタンスがあって
中の1個目だけモニターしたいのか
33:03
今は多分良くできたんですけど
多分5,6年前まだできてないんですね
そういうのは結構致命的
そうですね
だからやっぱりちょっと機能が追いついてないと思ってて
今のところ
考え方すごい先端入ってるんですけど
ソフトウェアはそこまでついていけないという感じがしますね
そうですね
そういう意味でちょっとまだPoUぐくりっていうのが
今のところベターなのかなっていうのが
今の自分の意見ですね
なるほど
今日はコーティストのプログラムちょっと見てるんですけど
久しぶりに本格の
あれを全部PoU書いたので
PoU書いてもアリだなと思い始めましたね
本当に
意外と分かりやすいなと思ったんですよ
PoU書くともアリだなと
トレースブロックとまた
なぜか1いったら中に処置がしちゃうか
しちゃったら処置がされるときの処理が見えなきゃいけないんですね
メモリが何かの
全部消えるときの処理の
組織関数もあるので
これも全部定義しなきゃいけないところはちょっと面倒
こういうとこまだ面倒見切れないかなと思ったんですよ
今PoCのメーカーが
パンチョンブロック不具合でいうか
何か変更加えたときの面倒見るのが
まだ見切れないというところが
今の現状かなと思ったますね
どのメーカーでも
そうですね
最低限ちょっとメソッドぐらいは
実装しないとしんどいんじゃないかなと思ってます
メソッドね
今はメソッドはできるのは
コティス系とツインケット系
あとPoC Nextはメソッドできるんですね
そうですね
やっぱりそういうソフトPLC系はできるけど
ってとこじゃないですか
でもできるけど
ゲットって感じですね
まだ足りないという
そこもやっぱまだ足りないですよね
足りないというところですね
これをどうやって解決するのか
そもそもこの合憲法委員会で
また新しいものになるのか
どこか分からないですね
例えばSiemensの場合は
なんかまたAX出たんですね
もうVSコードでプログラムを書いて
それで今のCPUにダウンロードするという
ソフトウェアは今作ってるんですね
来年がリリースするんですかね
でもまあまあ高いんだけど
結構ヨーロッパ側は結構好きみたいですね
彼らは何故かこういうやり方すごい好きですね
別に全然アリだと思いますけどね
いわゆるその何て言うんですか
ラダ言語って何て言うんですかね
簡単な代わりに書くのめっちゃ時間かかるんで
36:01
それがラダさんのセンターで大事ですね
これは結局この負担が設計者なので
ゲーマーとはやっぱり楽
すごい楽ですけど
でも全部の負担は設計者の方に入っちゃうんですよね
そうですね
だから設計者目線で言うんであれば
テキスト言語に注力してやるっていうのは
全然アリだと思いますね
理想では現場では
ラダ見なくてもこの装置でどんなエラーが
どんな問題で詰まったのか分かれば一番いいですよね
多分究極的には
そうですね
そこの今何て言うんですか
ソフトウェアが大規模化してること
プラスそういうことが全然釣り合ってない
プログラムだけはすごい膨大して
これに対して開発者と現場の人に
お互いも優しい環境を整えてないっていうんですよね
そうですね
何て言うんですか
ST言語で書ける人は書いたらいいと思うんですけど
それで100軸200軸ある設備をやったときに
多分困りますよ
またそれじゃないと
多分困ると思う
なんか詰まる
詰まるというか
ゲイン解析が難しい
そうですね
だから別にそれは課題なんで
クリアすれば全然問題ないと思いますけど
今それがクリアできる状況になってないと思います
どのメーカーでもこれをセンダリングするで提供できるところ
まだないです
まだできてないってことですね
テキスト言語でやろうと思ったら
もう少しシミュレーション環境が充実しないと厳しいでしょうね
要は設計保証するっていうことがとても大事なんで
シミュレーション
そうですね
今設計側で保証するっていうのはなかなか難しいと思います
一応設計側が終わって
これを作って現場でデバッグして
最初使うのは現場の人
このギャップも大きいし
その自分が作ったソフトが
どこまで正常保証なのかわからないということですよね
正常保証
そうですね
そういう言い方ですよね
これからのプログラムも
作るところまでは将来できる
この間話また変わるんですけど
最近すごく流行っている生成AIとか
全部そういうところである程度ベースを作ってくれる
のが正解なんですよということですね
これもここも保証誰がやるんですかということですね
別に人がやればいいと思いますけど
そうね私やるよ
私は受け止めずに本に書いてくるんですよね
よく人がやればいいと思いますけど
39:01
本に書いてくるんですね
なるほど
そうですね
人がやればいいと思いますけど
別にスキルのない人がやれるわけじゃないんで
生成AIで誰でも簡単にプログラムが書けて
設計者いらなくなりますわってならないですね
それだと
ならないですね
誰が後ろで苦しんでるんですよね
結局生成AIで書いたプログラムを判断する人が
必要になるんで結局人減ってないですね
それだと
むしろ苦しんでるが増えるかもしれないですね
ある意味で後ろで
なるほど
だから生成AIが仕事を奪っていくっていうよりは
やっぱり生成AIはどちらかというと支援の特性が
すごく強いんでしょうね
現状だと
今の皆さんの使い方だと
皆さんの仕事のアシステントとしては
すごい役に立っちゃうんですよね
言い方いいかな
そうですね
皆さん
なるほど
じゃあちょっと話がすごいずれたんですけど
それは園野さんのつもみ
こうやってあるかどうかなんですけど
私たち2人の考え方です
またこれについて
アドバイスがございましたら
コメントとかお便りいただければと思いますので
よろしくお願いします
よろしくお願いします
はい