00:00
で、この専用設計というのを話し合うと、ちょっとIPCを話したいなぁと思ったんです。
先回ちょっと話したんですけど、この間、ネットビューのコメントを見ていて、昨日ツイッターで話したんですけど、
IPC、最近結構推奨されているんですね。PEKOさんとか、メーカーもIPC使いましょうと、使った方がメリット多いんですよ、と言っているんですよ。
で、私はよく聞いた根拠は、IPC使ったらSQLサーバーも建てるよ、自分のパソコン1市内で。
MQTTプログラムも建てるよ、ビジョンもできるよとか、あとPLCもできるよ、C++プログラムもPython7に書けるよって言ったら、これからIPCの時代ですって言ってたんですね。
で、それを持ってちょっと考えたんですよ。確かにそうかもしれないね、できることが多くなるんですけど、
で、実際ほんのそこまでやる、そんな1市内で全部やるのかということはずっと疑問ってたんですね。
そもそもオーバースペックだと思ったんですよ、ちょっと。で、そもそもオーバースペックのものを使う、本当に例えばIO制御だけ、サーブいちいちいくらいそこまでハイスペックのものを使う必要があるかとかもあったし、
多分先回高田さんの話でIOあるかどうかの話だけじゃないですか。もしIPCでIOが指されるんだったら、PLC何で違うの?という話ができて。
で、1つのこの人の議論をすると面白いのはセーフティですね。あの人は多分ロックウェアを使っているから、今IPCってチップセーフティってどうすればいいんですか?って言ったんですよ。
実装すればいいんじゃないですか。実装するにはTubeとかの印象どうなってるんですか?という質問になったんですね。
まあ多分、彼の話はリソースが多いと実際運用するの話がずれちゃったんですけど、でも結局そんな簡単にIPC採用できないかなという。
採用できないというか、採用するというか、根拠、お互いの根拠が足りない。
また感じちゃったなと思ったんですね。そういう議論をよく見てるんですよ。どっちのほうが良い。
高橋さんをIPCを使います、PLCを使いますという根拠が出てるか、ちょっと見たら探せるんですね。なかなか出てこなくて。
まずさ、オーバースペックじゃダメなの。
オーバースペックじゃダメなの。
そう、オーバースペックじゃダメなの。
オーバースペックはその分のお金が、いわくお金で別所使いたい。ギリスペック、スペックどこまで余裕持つかの話ですね。
03:09
そこまでオーバースペック分のお金を節約したいとか、コスト下げたいとか、彼らの考え方かもしれないですね。
まあ、なんていうんかな。ちょっとIPCの定義があやふやですよね。
そう、たぶん世界初のIPCが何ですか?パソコン?ただのパソコンですか?みたいな。
でも違うんだけど、じゃあIPCは何ですか?って言ったら、高橋さんのこれをちゃんと答えてるところは今どころはないかなという感じ。
僕の答えとしては、ハイエンド、ミドルエンド、ローエンドという分け方をしたときに、それぞれの領域でIPCとPLCはほぼ同一化するというのが僕の見立てなんですよね。
つまりローエンド。
そう、だから結局ベッコフやコデシスのローエンドってWindowsじゃないんですよ。
ですよね。
だからWindows上で動いてないんですよね、あのランタイムが。
できたらあれでPLCも違う。
そう、じゃあそこはMQTTでも当然動かないし。
で、なる。
で、あれ採用すればPLCはあまり変わらないんじゃないかと。
で、ミドルエンドやハイエンドがどうかっていうと、ちょっと以前のFAラジオでも話しましたけど、ほとんど同一化してくる。
なるほどね。
みんなが8割使いたい機能っていうのは、どちらも実装するからほとんど同一化してくる。
だからMQTTが使えますっていうことがメリットなのかっていうと、みんなが使うんだったら同性質標準実装されるんだからあんまり変わらない。
そうだね、でもPHPを頑張ってやるから。
だからどこから追いつくわけですよね。
そうだね。
だからあの機能がない、この機能がないっていうのはあんまり議論にする意味がないと思ってて。
そうですね、そこじゃないと。
そうですね、だから議論ポイントとしてはWindowsやLinuxが入っているから、それでできることはとりあえずアドオンインストールがすぐ可能なわけです、IPCに関しては。
そこをどう取るかだと思ってますね。
結果、どう運用するか、運用するのかどうかですよね。
そうですね。
でもPLCも別にPLC部だけPLC使ってエッジパソコンつければいいじゃんっていう議論に対してどうですかって話もあるじゃないですか。
ホラー通信やればいいじゃん。
ホラー通信やればいいじゃん。専用APIがあるんでしょってあるじゃないですか。
ありますね。どっち取るかだね。
そこに何か違いがあるのかっていう話ですよね。
てか、菅谷さんが言っているのは、昔IPCとPLC通信はすごい面倒くさい。だからIP使う方が都合がいいんじゃないという話ですよね。
そうですね。だから僕らがやるべき話はIPCにすべきだったんじゃなくて、将来どうなるかなんですよ。
何したいか。
コンピューターが。コンピューターというかコントローラーが将来どういう機能があってどうなりたいかということをまず定義することが必要で。
06:01
でもこれ定義するのはエンドユーザー?でも定義できないよね。
定義というかこうなるだろうと見立てをまず立てるのは我々ですよねっていう。
そこにおそらくほとんど同一化するんで、PLCもIPCも。
どんどん近づいている。お互いの宝のことを。
そうですね。あとはその道筋を辿るのにどっちの方が都合がいいか。
あとお値段とか。
値段もあるし、拡張性もありますよね。
だからWindowsという環境があってそこに自前のアプリをバカバカ入れるんですっていう思想があるんだったら、それは当然IPCの方がいいだろうし。
決められた通信がワンパッケージ入っていればいいというだけだったら別にPLCでも使えるし。
もしくはそんなハイエンドをやるのでローエンドでいくんだって言うんであれば、そもそもそのローエンドのPLCをどう生かすかっていう話のことになるんですね。
なるほど。
だからそこの議論なんだと思うんですよ。
なるほど。もう何使いたいとかじゃなくて、そもそも何が結局ゴールどころなのかね。
だからIPCがいいっていうか、もうどうせ全部IPCっぽくなります。
みんなどんどん近づいている。
それは間違いない。
なるほど。
IPCっぽいやつとすげえローエンドなPLCの2極化するんです。
なるほど。で話が何かというと、これIPCとPLCどんどん近づくと、IT知識はどこまでやるのか、どの方法によればいいのか。
だからこれがプログラムの統制。
別にIPCに別にIT知識はいらないですよね。
でもだからね。
だってツインキャット立ち上げるのはIT知識いらないでしょ。
まあそうだね。
必要なのはそのWindows部分に入っているアプリケーションの知識が必要ですけど。
なるほど。
Linuxソーサーとかそこまで。
でもそれってPLCじゃないじゃないですか。
そう考えるともうPLC扱い方じゃない。
そうそう。だってそれは普通にPLCを使ったとしても、そばにHPCがあってその中にLinuxが入っているんでしょっていう。
なるほど。
関係ないですよ。多分どっちも必要なの。
なるほどね。
それはIPCだから必要なんじゃなくて、生産設備として多分必要なの。
そこのPLCとIPCの論争にそれが入ってくるのはちょっと説明がつかないなって。
なるほど。どれもうまい説明が出てこない。
うまい説明っていうよりは、それが決定的な主張にはならないと思います。
これだからこれ使う。
どういう結論になれない。
あとはもうなんというか、自分たちのやりたい方針にどっちが合うかなんですね。
Linux自分のゲームパワーがある。
だからいくらIPCがこうだって言っても、PLCでIPCっぽいことができる以上は、じゃあPLC使ったらそれはできないんですかって言われたら、できるって書いてなっちゃう。
面白い。確かにね。
09:01
どっちの方がシンプルでかっこいいかみたいな議論はあるかもしれないですけど、機能としてはできるから。
なるほど。多分どんどん近づいたらな、お互いに戦うと。
あとはその、もうその、各々のポリシーに基づいて、どちらでいくのかっていう原宿森を決めなきゃいけない気がするね。
なるほど。
そうだね。
なるほど。
ただいろんな話はあります。今で言ったらIPCとPLCの大きな差があるけど。
あと5年後。
10年後っていうのはほぼ統一化するんじゃないっていう。
IPCとPLCのコラボもなかなかないかもしれないな。新しいコラボまで全部統一するかもしれないですね。
なるほど。
IPCはWindowsが入ってるから、自分の開発環境で動かせていいですよねみたいな話があった時に、PLCメーカーがそれ同等のシミュレーションソフトを出したら一緒じゃんみたいな。
ニーズがあったら開発するから、基本的に。
ニーズがまだ足りてないってこと?メーカーの。
そうですね。
見えてないというか。
今はもともとニーズがなかったところにIPCっていうものが自分の利点を生かした商売をしてるからそういうふうに見えてる。
面白い。なるほど。面白いですね。なるほど。
だからどっちもやっておいたら。
動画までやったら?
そうですね。だから僕は今は現時点で言うと、開発側の意見をするとIPCを使っていることに多大なメリットは感じている。
将来ある時期の変更だったらどうなるかわからないですね。
そうですね。ただこれからPLCがなくなってもIPCになるかっていうと、別にPLC側も対策するやろうから。
PLCメーカーが頑張ってやるから。
それは技術的な不可能なことでは全然ないし。
ミキマネって言うんですね。どっちか。
そうですね。
なるほど。
だからIPCかPLCかっていうよりはツインキャットかGXワークスかスマックスツーディオかみたいな話になってくる。
どれを使うの?
どのメーカーのアプリケーションやソフトが一番いいのかみたいな。結局そこですよね。
それで選ぶよね。
だからPLC、IPCっていうよりはメーカー…
メーカーが出しているツールやソリューションがどれだけ完璧なのか。
結局そこに戻ってくると思いますね。
だからPLCとIPCでほぼ構造的な違いがなくなると。
なるほど。やっぱりビツビツさんのものがいいからGXワークス使おうみたいな。
結局そういう勝負になるんじゃないかと。
勝負つかないかと。
だからハードにほとんど出ないだろうね。
安いしなんとも安くないよね。ハードメーカーのソフトで。
ソフトの話になると、これから日本の制度研判の話ですけど、
12:08
ソフトウェアのモジュール化がどんどん必要じゃないかなと思ったんですよ。
例えばライブラリカーとか。
ライブラリカーとかちゃんと資産として残らなきゃいけない。
簡単に運用できるようにならないとダメだなと思ったんですね。
今やり方は多分わからないですね。
今大変なやり方はこのLINE3プロジェクトを渡すから、
これを見ながらやっといてというのが流れだったんですね。
例えば完全にサーボモーターのライブラリを渡しますから、
これを使ってライブラリを実装してというのが、
今セーメンとかペックオフとか全部やり方ですよね。
ライブラリライブラリして、
これをライブで使って簡単に実装するのが、
今の欧州のやり方。
日本もそうするべき。
欧州みたいに全部ライブ、
多分そうなわけじゃないかなってわからないですけど、
ファンクションブロッカーして、
ファンクションブロックを使わなきゃいけないんですか?
という話だったんですけど、
ファンクションブロックとかライブラリとか、
高谷さん的にはファンクションブロック、ライブラリ…
いわゆるライブラリは別に今までの日本の中で大量に使われてきている話だから、
パッケージックされているかされていないかだけなんです。
パッケージングされるべきかどうか。
でもいいと思うなあ。
PoUではされても別にファンクションブロックではされても、
動くものは一緒なの。
動くでしょうけど、
そのまま引っ張ったら使えるかどうか。
と彼らは考えています。
引っ張っているかどうか。
ワンクリックボタンでインストールされているだけで、
もう使えるかですよね。
どこまでかですよね。
全部ファンクションブロックで真っ赤になるのは絶対無理だと思って、
それは結局改造しないといけないから。
中身書いちゃったらもう意味ないんじゃない?ライブラリ。
そうそう。
ライブラリのコンセプトを一番奥のと変えずに、
これを上に運用するんですよね。
そこにいわゆるオーバーロードとか継承の場合に入れてくるかって話もあるけど。
OBのコンセプトですよね。
15:00
あるけどなあ、っていうのは思いながら、
モジュール化を進めるべきなら間違いないですけど。
どこまで進むべきかどうかですか?
というよりは、
シーメンスのやり方が完璧かってそうじゃないじゃないですか。
ごめんね、そうじゃないです。
結局人が書いている部分はまだ残っているわけですよね。
残っていますよね。
だから結局そこでミスが出たり、不具合が出たり。
ライブラリが100%無いでも、無いでも、人間がライブラリを使ってやっているから、
そこで結局エラーが出るかと。
そうですね。
質問の問いからは外れるかもしれないですけど、
そっちの方が大事だと思う。
人間をミスをいかにも減らすか。
そうですね。
その中の一つの選択肢というライブラリや文字の拡充点は当然あるんですけど、
それはやりながら、人が書く部分、
人が決めている部分をどう品質を担保していくか、
どう早く作るかっていうところの議論の方が多分大事なんじゃないですか。
なるほどね。
だってもうライブラリを作らなあかんとかもう自明ですよね。
絶対やらなあかんじゃないですか。
やらない理由ないじゃないですか。
だから議論にならない気がしてて。
ああ、ライブラリ使わないとダメですという結論。
ダメですというか、
使う…
否定する理由あります?
そう、これを持って、
私今までCMSをトレンドにやったんですけど、
ファンクションブロックを何で使わないといけないんですか?
よく聞かれるんですよ。
ファンクションブロックを何で使わないといけないんですか?
で、私の答えはファンクションブロックを使ったら、
コードがもうライブラリ化、カプセル化されて、
カプセル化に余裕があっているかどうかわからないですけど。
なんていうんですかね、
ファンクションブロックやファンクションが使わないといけないんじゃなくて、
品質拡充されたものがあるんやからとりあえず使えよ、
に近いじゃないですか。
じゃあ全部自分で書くときに、
ファンクションブロックを必ずしも使わないといけないかって、
それはそうじゃないんですかね。
そうじゃないですよね。
だからそれは既に配布されているっていうものが、
ファンクションブロックという形で来ているだけ。
あればもうこれを使ってくださいと。
これは別にソースコードのそのまま来たら、
そのまま使ってくださいということ。
だから新たに新規設計するときに、
まずファンクションブロックの仕様を決めて、
みたいなやり方は今多分されていないと思って。
そうそう、あそこからダメって言ってくれる。
だからその議論をするんだったら、
仕事のやり方としてまずファンクションブロックを作るところから始めてください、
という仕事に対する言い方をするかどうかというところをまず議論するんですね。
そういう質問をするくらいだったら、
それぞれファンクションブロックを使わない、
当ててはない。
まずどのファンクションブロックを使って、
何やったらこのファンクションを作って、
ということから始めるのかですよね。
スタートポイントがどこなのか。
18:01
じゃあファンクションブロックがあるやつはどうやって使って、
っていう話になったらそれはもう使う そろそろそうでしょっていう
標準的なものがあるんだからそれを使う その当たり前の話じゃないですか
そうだと思ったんですけどね でもそういうこれがバラせんバラせくださいと言われるんですよ
まあそれはわからんだよ 現場でいじりにくいから
そうそう これは現場でいじりにくいからなんで使わなきゃいけないんですか
またマニュアルの原点もあるけど設計者からの 視点と現場の人の視点が見ると全然違う
いやだからそれはファンクションブロックが全部一緒だからです ファンクションにしたらそれを一個だけ変えるってことはできないから
結局はそれは別に継承できれば問題ないわけですよね それができるシステムになってないことが問題なんです
そこか そこで例外的な問題だよ
別にそうじゃなかったらだってコピーしてそれを変えて終わりじゃないですか アカビオで
それができないシステムだからそういう要望が出てくるんですよ バラしてくださいって
そういう例外がたくさんあるからそうしないでくださいと
だからそこは完全にシステム面の問題だと思いますよ
なるほど ファンクションブロックって悪ではない 悪で言うかそういう問題はないと
ただシステムがそれが向いていないというか
だから今のあるPLCではできないよねっていう回答なんでしょうね
なるほど
でもそれは別に技術的に解決できないわけではないよね
もうちょっとシステム上の設計かもしれないし
なるほど
それはそうじゃないですか全部が同じ仕様なわけないし
でこれを上にどうやってやるのか
という設計論も当然必要でしょうね
なるほど なるほど
長押し押しの方法
なるほど
僕はとりあえず今そう思いますよ
ファンクションブロックの件に関して
ファンクションブロックの運用も必要ですよね
日本国内はファンクションブロックというよりは
もう少し大きめのアキテクチャを決める必要がある
ついでにファンクションブロックを使いましょうとか
ファンクションブロックを何で使わなきゃいけないのか
理解しなきゃいけない
ファンクションブロックというか
まずそもそもどういう機能単位でまとめて
どういうインターフェースを作ってというのが
圧倒的に大事だと思いますね
ファンクションブロックはその先だろうと思いますけど
そうですね
みんな手をつけやすいからそこから始めているだけであって
本当はそこじゃないと思うな
そもそもシステムをどういうふうに設計するのか
上にファンクションブロックは
設計システムを実装するためのツールだけ
21:01
基本的には品質の担保と設計効率の向上が
バランス的だから
なるほど
そのためのツールだしな
逃げちゃったな
逃げちゃったってことですか
逃げちゃったわけではないですけど
まずそこから始めるのはあるんでしょうけど
なるほどね
やっぱりそこばっかりやっても
あるところで詰まるだろうな
なるほど
結局ファンクションブロックを組み合わせたり
そういうところに人が書くわけだから
そこの品質が担保できなかったらもう終わりです
設計の思想を持っていたら
そもそもアウトじゃないと
まあそうだと思います
なるほど
だからテストだとか
テスト系の話だとか
シミュレーションの話だとか
いろんなものが足りてないね
だからメーカーがファンクションを用意して
提供してくれるのは
素直に使って
ありがたいことだけど
そうですね
ただ日本のポジションとして
ただ生産すればいいわけじゃないから
どっちかというと
より良い生産を目指さなければいけない
80点じゃダメなんですね
僕は
95点くらい狙わないといけない
なるほど
狙う目的は点数は違う
点数は高い
そうなった時に配られたものだけを使って
95点を狙うことは難しい
難しいよね
どうか改造が入る
もしくは新規のMAXIMUMを作る必要がある
ということを念頭に置いた時に
構成を組むべきか
なるほど
そうするとどう考えるか
そうですね
その時にファンクションボックスを改造する
一応その話もあるだろうし
便利になりますね
高谷さんの話を聞いて
これは話は終わっても
どこまで飛んだか分からないですけど
この話はこれで終わりです
