構造体の基本概念
明日のファクトリーオートメーションへようこそ。メンバーソナリティの高橋です。
クリスです。
よろしくお願いします。
よろしくお願いします。
ラジオネーム、たこ焼さんから頂いております。
PLC制御の構造体について活用法などを伺って頂きたいです、ということです。
ちょっとこの前のラジオで、もう一つ取り直しなんですけど、構造体というものがまずありますよね、PLCには。
構造体というのはどういうものかというと、通常は変数は1個ずつ宣言するというのが基本的な変数になります。
例えば、ブール型の変数を1つ宣言すると、ブール型の例えばAという変数が1個できます。
そうですね。
もう1個、配列というものもありますよね。変数を宣言して、これを100個宣言するよと。
この100個というのは変数の後ろに括弧がついていて、1番というのは1番だし、2番というのは2番という変数で括弧を用意できますというのが変数ですね。
変数というのは配列ですね。
これは1個の変数を複数作るということなので、型が全部同じになります。
例えばブールの配列だとブール型しか100個できるし、エルリアルの変数、配列を作るとエルリアルが100個できますと。
そうですね。
配列というのは、まず1個配列という型を作って、その中に変数をいくつか宣言することができるのを一般的には構造体と言います。
例えば、ストラクトという構造体を作って、このストラクトの中にメンバーというんですけど、メンバーの変数というのを宣言できます。
なので、ストラクトの中に例えばABCDという変数を宣言したときに、このストラクトというものにひも付いたABCDというのが宣言できるわけですね。
そうですね。
このABCDというのは、基本的には別の型で宣言することができます。
例えば、Aはブール、Bはワードみたいな、そういうことが変数できるわけですね。
これを書くとき、呼び出すときは、今回ストラクトの中のAという変数があるので、呼び出すときはストラクト.Aという形で、
ストラクトとこのABCDというのは、いわゆるシステム的にグルーピングできるというふうなものになります。
これが構造体ですね。
構造体の利点と利用法
先ほどクリーさんと、何で構造体を使うんですかというときに、構造体のメリットって何ですかというときに、
僕が考えている一番のメリットというのは、システム的に変数同士のひも付けができるというのが一番の利点かなというふうに思います。
システム同士に変数をひも付けるという。
システム的にね。システム的に変数のひも付けで。
例えば、AとBが同じ、似た辺。
例えばレシピを書いたときに、レシピ1,レシピ2,レシピ3というのを作ったときに、
レシピ1とレシピ2のレシピ3が一つのグループのレシピだというふうにひも付けるために、
例えば変数名にレシピ氏アンダーバーこにゃららみたいに書くこともできるじゃないですか。
アンダースコア1,アンダーバー2で10個作るんですね。
でもこれはコンピューターは識別できないわけです。
これがグループだということが。
確かに。
人間が勝手につけたルールなんで、このルールをどこかに入れない限りはコンピューターは識別することができません。
そうですね。
人間はレシピ1こにゃらら、レシピ1こにゃららって書いてたら、
これはなんとなくグルーピングなんだなということを認識するんですけど、
コンピューターはそれを識別することができない。
ただの変数が、独立した変数が3つあるみたいな。
そういうふうに見えちゃうわけですね。
そうですね。
これがストラクト型を使うと、コンピューターが理解できる形でグルーピングされます。
ストラクトの中にA,B,Cっていうのがあると、
これはストラクトっていうグループなんだなっていうことをシステム的に紐付けることができるっていうのが、
構造体の一つ大きな利点というか特徴ですね。
この特徴を生かして何がいいのか。
そういう意味で手間ってかからなくなる?
時間がかからない。
ボロム作る時間が減らせるかな。減らせるのがいいんじゃないか。
そうですね。これの利点としては、
まずシステム側がこれがグルーピングだよっていうのが最初から理解できてるわけなので、
例えば複製するときはそれを丸ごと複製することができます。
例えばストラクトっていう型があったときに、
じゃあこれを3つ宣言しますっていうときに、
このストラクトの中に入ってるA,B,C,Dも含めて3つ、
このストラクト宣言するだけで宣言することができますよと。
これはコンピューターがこれはグループだって理解してるんで、
それごと丸ごとまとめて宣言することができますよねっていう。
なので非常に決まってること、これはこういう塊ですよっていう決まってることですね。
例えばレシピだったりだとかパラメーターだったりだとか、
基本的に変えませんよっていうことの複製バージョンを作りたいときっていうのは、
すでにまとまってるものがあるのでそれをそのままコピーしていくと、
宣言し忘れとかスペルミスとかこういうものは基本的になくなっていくよと。
これはシステム的にストラクトっていうグルーピングができてるからですよね。
また宣言だけじゃなくて転送っていうのも同様に非常に楽にすることができます。
これはグルーピングされてるんで一番上にストラクトっていうのを転送すると、
その下も含めて全部一括で転送されると。
確かにそうですね。
こういう利点があるっていうので、
基本的にストラクト型の利点っていうのはグルーピングされてるってことが、
一番根っこにある技術的な良さなんだとは思いますね。
構造体の課題と未来
でも一個ちょっといつも気になるのは、
例えば構造台の中のメンバーを変えるときは多分全部飛んじゃうでしょ、データが。
そうですね。
多分これをちょっとずらして、これパラメータとして使うのが本当にいいのかどうかちょっと今でもすぐなんですね。
それは場所によるでしょうね。
いわゆる全部変わるっていうことですね。
大元がいるんで、メンバーの途中で、
例えばストラクトをストラクトでABCっていう形で宣言したときに、
これでもストラクトBだけもう一個メンバー欲しいなみたいになったときに、
いじるとAもBも増えるっていう、そういう面倒くささっていうのがあるよねっていうのは当然ストラクト型の構造的な話に。
でもこれが本当にいいのかどうかちょっと私も、今も構造台と配列でプルンってアレンガで組んでるんですけど、
でもこれも果たして本当にいいのか私もわからなくて、今もちょっとこれ行き帰りとかをずっとしてますね。
高谷さん的にはどう思いますか、こういうところ。
あとはファンクションブロックで構造台としてパラメータ入れるのが本当にいいのかどうか、今も悩んでるんですけどね。
そうですね。
基本的には関数型のプログラミングとかだと、基本的にはインターフェースは固定されるっていうのは基本的な考え方になると思うんですよね。
今持ってるデータセットを渡しますっていうよりは渡される先のデータセットがもともと決まってて、それを作りますっていう方がどっちかというと正しいんで、
どっちかというとライブラリーに依存する話になりますよね、基本的には。
なるほどね。
基本は渡されるか関数何を求めるか、これをストラクトを求めてるから、ただこの変数、ストラクト変数を定義しますみたいな感じですね。逆ですね。
そうですね。そういう形になるんじゃないかなっていうふうに思いますね。
なるほどね。
昔1回、FBとFCで構造体パラメータといった時期があったんですけど、たぶん2回くらいのお客さんに言われて、こんなのやめてくれって言われたんですよ。
クロースウェーブンスに引っかかる、中身の引っかかる。
引っかかんない予定なんですね。
検索も効かなくなっちゃうからやめてくれって言われたんですよ。
全く悩んでるところで、確かにそうだなと思ってたんですね。
なんていうんですかね、それはある種正しくてある種間違ってるっていうのはあるんじゃないですか。
そうですね。今、ケガチブには作ってるFBも全部また構造体として入ってるんですけど、たまにもこれが本当にいいのかちょっと悩んだりはしてますね。
例えば、なんで検索するかっていう話ですよね。要は検索できないからっていうのは、なんで検索するかっていうと不具合があるから検索するんですよ。
そうですね。
だからやっぱ品質保証が甘いんですよね、そういう意味で言うと。
なるほど。
それは人の問題じゃなくて、システム的にシステムの仕組み上ですね、設計のシステム仕組み上を品質保証するのがまだまだ難しいようなシステムになってっていうのがやっぱあると思います。
もう一回いいですか。
要は例えばですけど、じゃあシミュレーションが何ですか、事前に全部検証できるシミュレーションが発達してますかっていうとしてないですよね。
してないですね。
自動テストのツールありますかってしてないですよね。
どうなったときに出たプログラムを。
変更点の管理できるようにGitって整ってますか?バージョン管理してると整ってますか?整ってないですよね。
ないですね。
じゃあ不具合が起きるのって、まあそれは起きますよねって。
当然結果になるんですよね。
となったら、じゃあ検索いりますよねっていうロジックなんだと思うんですよね。
いろいろの積み重ねが甘かったからこういう結果になっちゃったってこと?
そうですね。これは誰が悪いとかじゃなくて、今のシステムだとそこまでしかできないっていうことなんだと思います。
なるほど。
だからそういう可能性があるから検索できるようにしてくださいっていうのがおそらく先方の言いたいことだと思うんですね。
まあそこまで深くやってるかわかんないですけど。
でも逆に言うと不具合がないんだったら調べる必要ないじゃないですか。
まあそうだね。
そうですよね。
そうなってくると現場よりは設計が楽になった方がいいですよね、構造で。
シンプルにパパッと書いてっていう。
まあどちらかというとシングルですぐ書けた方が楽ですよね、楽しい。
ですよね。
いわゆる現場の使いやすさと設計のエリアのやりやすさっていうのをどっちを取りますかっていうトレードオフをどっちに寄せていくかっていう話になるじゃないですか。
なりますね。
ということなんだと思うんですよ。
だから現時点のシステムでは構造体転送したときにおっしゃるような検索の問題とかがまだまだ残ってるよっていう。
そうですね。
でもそれそもそもいるんだっけとか。
そもそも検索しなきゃいけないんですかみたいな。
でも現状はしなきゃいけないよねって。
誰がせいに置いといてはそういう現状になってますねということですね。
でもしなくてよくなったらそれは別にそういうのが構造体全部揃えるっていう未来もあるんじゃないですかって僕はそう思います。
なるほど。
だからどっちがいいどっちが悪いかっていうよりは今まだ時期じゃないっていうことなんじゃないですか。
そういう時期じゃない、整ってないんじゃないですかっていう。
まあこのインフラをとどめるのを待ってるというかそういうことですね。
そうですね。
まあそれかもう少し別の解釈もあるかもしれません。
例えばそれはだって検索できないのは転送してるから検索できない、一括転送してるから検索できないだけじゃないですか。
そうですね。
だから結局全部のメンバーを転送してるから検索できないっていうことなんじゃないですか。
そうですね。
だから結局全部のメンバーを転送すれば別にそれは解決するじゃないですか検索も。
つまり検索もそれ引っかかるようにすればいいっていうことですね。
そうそうそう全部struct.aイコールstruct.aみたいな感じで。
引っかかるように文を組んでもいいしって感じですね。
そうだから別に構造体が悪いわけじゃなくて構造体の一括転送に検索が引っかかんないことが問題なわけですよねその場合って。
これがメインだねメインの問題だね。
ですよね。
だからそこはもう技術の進歩に期待するしかないところではあると思いますね。
なるほどね。どっちが先だろうね。さっきの引っかかるようにして待ってる間に
そもそも検索せなくてもいいというソフトまで作り上げるまでを待つですねこのインフラを。
なるほど。
構造体の基本とその限界
という過渡期待法はまだまだアピールし、特にICは特に強くあると思います。そういうのが。
なるほど。
ICの構造体は結構不便です普通に。普通に不便です。
不便っていうのは?不便ってもうちょっとおかしすっきりですか?
構造体に対する機能が全然他の高級言語のプライベートって持ってないですよねっていう。
これ確かにそうだね。これそうです。
そうですね。ただPOEの中で構造体を宣言したりとか絶対できないじゃないですか。
基本的に最初に宣言するものであって宣言する。
一時的使い捨てなの?
もうできないですよね。例えば言うとですけど。
だから今までIT系が構造体でそういう使いづらさを改善してきたものが実装されてない、まだ実装されてないっていうのは大いにあるんじゃないかなとは思います。
凄い商売的なものしか定義されてないんですね、ICの方で。
そっか。
やっぱり多数的では使った方がいいと思ってるんですか?構造体は。
アドレスプログラミングとの比較
どうするかっていうと、アドレスプログラミングとの比較をした方がいいと思うんですよ、僕、こういう時って。
そもそも変数でやるか、アドレスでやるか。
アドレスでやってた時って構造体と似たようなこと基本的にやってるんですよね。
一括転送。
一括転送っていう、要はアドレスのこのアドレスから二重ワードは一括で転送しますよとか、この二重ワードはこういう意味がありますよってコメントでつけるみたいな。
さっきコンピューターは理解できないって言ったけど、人間は理解できますよみたいなことやってますよね。
で、このブロック転送っていうのは構造体転送でしか再現できないんですよ、実際。
そうだね、基本同じ。
ですよね。
だからブロック転送なしにやろうと思ったら、いわゆる変数を例えば100個あったら100個全部転送メールで書くみたいなことが発生するわけですね。
これを握るためには構造体を配列で使うしかないんですよね。
でも村田さんが前に出たアドレスでプログラムする人が今まで困ってないことが結局変数になったから困ってるから、今できたことができなくなったら困るんですよね、これも。
そうですね。
だから変数プログラミングの時に、変数じゃなくてアドレスプログラミングした時に、やってたやり方を踏襲していくんであれば構造体は使わざるを得ないと思ってますね。
だからInter-POUとか関数のインターフェースに構造体を使うっていうのはやむを得ないかなっていう。
その一括転送の中心ですね、結局。
なるほどね。
そうですね、はい。
わかりました。
あとはパラメーター書いたりとかね、そういう。
運用面ですね、これ実際どうなんだか。
そうですね、意味を持たしたりとか、そういう構造化したプログラム構造にしていく上で、やっぱりその構造体っていうのは切って切れない関係にはちょっとあるんじゃないかなっていうのは思ってますが、
僕の周りでもやっぱりクリスさんの言うように構造体の評判はめちゃくちゃ悪いです、現場から。
うん、めちゃくちゃ悪い。やめてほしいって言われたんですよね。
そうですね。
ただ、使わなかったら設計の手間がめちゃめちゃ増えるわけですよ、これは。
すごい単純に打つの関数が増える。
そうそう、単純に倍とかになるじゃないですか。
で、それを解決するような仕組みになってないんですよね、いろんなのが。
なってないね、基本は頑張ってやるしかないね、地味地味で書く。
そうそう、例えばSTとかで書くんやったらまだいいですよ。
ラダのブロックの宣言なんてもう地獄ですよね、普通にやるのは。
もう地獄です、あれはもう。
なるほどね、なるほどね。
で、それやったらもう別に良くね、みたいな。アドレスで良くね、みたいな。何かでない。
なるほどね。
皆さんこれで結局困っていることが困っているから、できたことができなかったから、
結局みんな不満になったよね、構造だけじゃなくて。
いろいろ変数とか配列とかそういえば文句言ってるんですよね、文句じゃないから使わないですよね。
そうですね、僕は基本的には配列にするべきだとは、構造にするべきだとは思ってます。
なるほど。
インターフェースっていうものの定義をそこで作ってしまうのが多分良いと思います。
現場での課題と解決策
普通にアドレス、アドレスじゃない、1個ずつの変数にすると、別のドキュメントを書かないと絶対に分からないんで、
やっぱり効率化されないよなっていうのが心の中でずっと思ってることですね。
だからさ、今の仕事が最終的には標準化ですからね、標準化。
手間かかないような、リードタイムを1秒でもいいから短くしたいと、ですよね。
品質を保持した上でね。
品質を保持した上で、リードタイムをできるだけ少なくする、そういうディスタンスもね。
基本ですからね、これは。
まあでも構造体は基本どんなPUCでも対応してますっけ、大体の。
まあしてるはしてますけど、ものによります、やっぱり。
どこまで対応するかですよね、みんなも若干違うと思う。
そうですね、はい。
例えば、構造体のNESTができるかどうかとかね。
NESTは何ですか?
NESTっていうのは構造体の中に構造体を宣言するってことです。
これはできないところもあるか、一応あるか。
できないところもあるし、深さに制限があるところもあります。
NESTの中のNESTの中のNESTの中のNESTみたいなのがどこまでできるかって。
3回、3回回っていうのが。
そうですね、ありますよね。
で、あとは構造体の配列が作れるかっていうのもありますよね。
あれね、意外と制限が多いね、みんな。
構造体の配列が宣言できないメーカーは実は意外とあります。
そうなんですか?
普通に欧州メーカーでもあります。
ちょっと記憶があやふやですけど、確かPLCnextもできなかったと思います。
さっきPLCnextがいいんじゃない?開いてやってみますね。
そっか。
結構あの辺は普通に。
お互いもちょっとずつ違うんですよね。
自分だけのスタンダードみたいなものを持ってますよね。
そうですね、それはそうかと思います。
ただ自分のハードウェアの方が都合で、ランダムに都合で。
なるほど。分かれました。
そうですね。で、あとはアクションブロックに渡すときにやったら、
基本的にMultidiskを渡して、
そうですね。で、あとはアクションブロックに渡すときに、例えば100個の変数渡すんかって言ったら、渡せんすよねっていう。
ブロックもめっちゃなくなっちゃうからな。
そうそう。
そう考えると、そうね、やっぱり構想で使おうさるを得ないですよね。
大量のデータを渡すときに、1000倍とかデータを渡すときに、やっぱり構想されてないと思う。
構想されてないと無理やな、数多く無理やな、と同じものですよね。
そうですね、はい。
現実的にはもう基本的にデータの受け渡しっていうのが、コード体制には基本的に使わざるを得ないし、
使っていくべきであるとは思いながらも、まだまだ課題は多いねっていうところなんだと思いますね。
それをどう解決するべきか、解決するか、無理か。
と私たち佐藤さんが言った通りに1個1個移すかって感じですよね。
そうですね。ただ100個じゃあ移したときにスペルミスないかって言ったらスペルミスあるんですよね、1個ぐらい。
2個ぐらいありますね。
じゃあ絶対もう10個ぐらいある、8個破壊書いた。
そうですね。あまりにもそういう話をしていくと、変数使いづらいなっていうことになりかねえんですね。
やっぱりちょっと使い物ならん。と思ったりしてアドレスが落ちちゃうとか、そういうのも怖いですね。
そうですね。そういうところも下げたいので、
これいいところをアップデートしかないんだ。原板とちゃんと使いますよ。
変数のほうが見やすいですよというぐらいかな。
っていう感じじゃないかなと僕は思っています。
そうですね。
今日は途中では何故か汽車で入らなかったんですけど。
というわけで構造材の話はここまでにしたいと思います。
高木さんありがとうございました。
ありがとうございました。
