インラインSTの概要
明日のファクトリーオートメーションにようこそ。メインパーソナリティの高橋です。
クリスです。
よろしくお願いします。
ラジオネーム、たこ焼さんから頂いております。ありがとうございます。
ありがとうございます。
インラインST便利じゃないですか。
計算とかコンパクトに表現できて、プログラムが見やすくなりますよね。
ということです。
このインラインSTね、まずインラインSTは何かっていう話なんですけど、一般的にラダープログラムを書くじゃないですか。
でもラダープログラム、例えば、AたすBはCみたいなことを書くのめっちゃ大変なんですよね。
それだけ4行くらい使うみたいな。
読みづらい。
というので、日本のPLCの特殊な機能なんですけど、
ラダーの中に一部テキスト言語で計算式を書けますよっていう機能があります。日本のPLCだけ。
いや、だけじゃないな。今、CORESとかも実装されましたけど、インラインST。
ありますけど。
これね、みんな便利だからよく使ってるよねというお話になります。
そうですね、まず私から言うと、インラインSTは私はあまり使ってないんですね。
ラダーの中にグッデークのファンクションを呼び出して、この中でST書いてるみたいな感じですね。
インラインは使わないですね。
何故か言うと、インラインST、GX Works2だっけな。
使ったんですけど、機能がちょっと足りなくて。
配列使っちゃダメとか制約があったんですね、あの時は確かに色々。
あの時に使いこじが良くなくて、結局はインラインSTは諦めたんですよ。
インラインSTの利点と制約
なるほど。
ファンクションの中にファンクションを書いて、ファンクションの中にSTを書くみたいな。
その中にラダーの中にファンクションを呼び出すみたいな形になっちゃったんですね、私が。
どう思いますか、このインラインSTは。
それは単純に古いですよ、福井さん。
今そうでもない。
そうでもない、そっか今。
今のSTはもう普通に基本的に変わらないので。
ファンクションブロックの中に書けるSTとインラインSTの中に書けるSTはほぼ一緒なんで。
単純に福井さんはそれはあれですね、使ってたPIDが古かったっていうだけの話ちゃうかな。
なるほど、それだったら使うかもしれないですね。
あとインラインSTってラダーのエディターの中で表示されるので、
バイオではちょっと見づらい時あるんじゃないかなと思うくらいかな。
ちょっと私使っているものは古いんだったらまた使おうかなと思いますけどね。
便利は便利だと思いますけど。
基本的にはガンガン使っていくような話だと思いますけどね。
今のコサンピエルCを前提するんだったらこれは外せない機能の一つでしょうね。
ただちょっとこれ残念ながらICの中で定義されていない機能なので。
共通化っていう面では外れていくんですけど。
でもやっぱりインラインSTは便利ですよ。
何が便利かって、if文、for文が使えるのも便利ですね。
それね、ラダーでfor文書くとめっちゃ大変ですよね。
かなりfor文を書いて、forの関数を呼び出して最後またnextを出して、
真ん中の中で自分で足さないといけないところを出なきゃいけないんですよね、確かにラダーを書くと。
そうですね。というかラダーでfor文を書くと、ラダーのいいところが消えちゃうわけですよね。
見やすさ。
いわゆる現在の状態がわかるということが消えちゃうわけですよ。
for文でラダーを回すと一番最後の状態しか見えないから。
例えばfor文で30回マスターすると1から29の結果っていうのはもうわかんないわけですよね。
なるほど。
どれだったらラダー、インラインSTでほうがいいんじゃないという話ですね。
いいケースが増えるだろうなっていう。
なるほど。
そうですね。
ちなみに僕はラダーでfor文を書くケースかなり多いですけどね、実際の業務では。
もう一回言っていいですか。すみません。
実際の業務ではラダーでfor文を書くケースはすごく多いですよ。
そうなんですか。
多いです。ifも多いです。
これは何かの原因が、STは使わないようにするんですか、ICで標準されてないかとか、でもないか。
単純にSTで条件を書きたくないからですね。
STで条件を書きたくない。
こういう条件のときはこれをしますっていうシーケンス文を書きたくないからですね、STでは。
条件で全部ラダーで要件できるようにしたい、ロジック部分が。
他の部分はそうしてるんだからその部分だけ変えるっていうのはやりたくないです。
それは読み手に対してやっぱりそれは不親切だと思ってる。
急にST出てきて、わけがわからないけど、ペザ処理したらこれまた読み手はちょっとよくない、読みの人はちょっとよくないってことですよね。
なるほど。
なのであんまり乱発はしないでおこうかなって思ってるので、ラダーで書くケースが多いですね。
書けるものはラダーで書く。
普通にラダーじゃないと、インラインSTじゃないとできないことはないんですけど、
書く人の趣味と、本当に高谷さんの通りのルールというか、どういう考え方ですね、このインラインSTを使うかどうか。
インラインSTのほうがいいことはやっぱりありますよ。計算式なんて絶対インラインSTのほうがいいですからね。
ほうがわかりやすいですよね。
設計ルールの重要性
わかりやすいっていうか、ラダーにできないことっていうのは連続計算ができない。
1回とかパフォーマンス1内に移さないといけないですよね。
そうですね。これどういうことかっていうと、例えばAという変数にAたすBたすCたすDっていう計算をしたいとするじゃないですか。
しますね。
これはSTで書けば、AイコールAAたすBたすCたすDなんですけど、それで1回ずつで計算できると。
このラダーでこうすると、まずAたすBをA'っていうのに入れて、A'たすCっていうのをB'っていうのに入れて、
DにC'たすDっていう計算のブロックに分割ってのはあかん。
そうですね。
これが非常にだるい。
あるいはだるい。
見にくい。
で、そういうときはinline-stは使わないといけない。
そうですね。
inline-stで1回ずつで計算したほうがいいでしょうねっていうケースは使えるでしょうね。
なるほど。
高さの業務的な基本はinline-stより書けるものは全部ラダーでやるという感じですか。
やっぱり見るって。
inline-stで可視化ができない問題があるんで、可視化が必要なものは書かないです。
なるほど。
なのでこういう演算は多分もうinline-stでやろうと。
そうですね。
全く書かないわけじゃないですけどね演算も。
ただ基本的には統一すると考え方、設計デザインルールは統一するっていうのが基本原則だと思ってますね。
ここですね、設計ルールの統一ですね。
なるほど。
どういうときにinline-stを使うか、そういうルールも決めないといけないですよね。
決まってないですよね。決めきれないですよね。
決めきれないですよね。計算しますっていうのやりますとか、for loopやりますとか、それだけじゃないじゃないですよね。
なるほど。
じゃあ計算全部stで書けますかって言うと別に1たす1みたいなのを別に書く必要ないじゃないですか。
そうですね。別にそのままラダでもいいですし。
そうか。
むしろラダの方が見やすいまでありますよ。その計算を走らせる条件っていうのが絶対あるはずなんで。
なるほど。
やっぱり私もね、一回この古いPOCでinline-st使ってちょっとあったから、あれ以来もうこれは下げちゃったんですね、私もinline-st使うのは。
そうですね。
なるほど。
ファンクションを作ってその中に書くっていうのはやっぱりやりたくないですね。
これはあれですか、やっぱり足利の面から見るとよくないっていうことですか。
そうだし書き捨てのものにファンクションを一時作るっていうのは多分設計の概念からしてあんまり気持ちよくない気はしてますね。
なるほどね。
これは再利用性のないものにどんどんファンクションを作っていくってことになるじゃないですか。
そうだね、そういう面もあるですね。
そうですね。だからinline-stはもう書き捨てるものに対してはそれにすればいいと思うんで。
だから再利用の必要なものはファンクションにしていく。
なるほど、なるほど。
そうですね、ちょっとそう考えると私も今後の考え方も見合わさないといけないな。
実は結構ファンクションブロックの数制限されたりしますからね。
ファンクションとかファンクションブロックを無限に作れるっていうことでもないんですよ。
制限があるからしょうもないことでファンクションブロックを使っておったら制限に引っかかる可能性ってやっぱり出てくると思うんですよ。
小規模プログラムだったら問題にならないけど、やっぱり大規模プログラムで問題になるようなことはスケーラビリティの観点からあんまりやりたくないですよね。
そうですね。
そっか、多分ね、これもずっとSiemens使ったので、Siemensの基本は1個しかないんですよね。
基本はみんなOB1というメインのプログラムで書いてて、その中で今FPを呼び出して、
ファンクションブロックをずっと1台ずつ呼び出して、その中で今FCとかFPとかそういうコンセプトを、こういうコンセプトだってプログラムを組んでるので皆さんが、
昔もそう教えられたので、多分この考え方でまだ残ってるかもしれないですね、私も。
ずっとそのやり方でプログラムを組んだんですね、私も。
そっか、これをちょっと見直すチャンスかもしれないですね、私も。
そうですね。まあまあ、というかSiemensの考え方も今変わってくると思いますけど、結局そのYCの考え方ともタスクにPoEを割り付けるという考え方なんで、
メインのやつが1個走ってっていう考え方はもうやっぱないですよね。
そうですね、多分PoEという、PoEというコンセプトなんですよね、多分将来的には。
作れないことはないんですけど、私が教えた時もメインの中でだけ全部書いてということ多かったですね。
そういうプログラムも参考にしながら見たので、ちょっとこの辺も見直していきます。
すみません、ちょっとペン切られました。
という感じかな、ちょっと私もこれを見て自分のプログラムを見直していきます。
はい、いやまあガンガン使えばいいとは思いますけどね、昔ほどInlineSTに危機感秘密というのもだいぶ減ってきたんで、
Inline STの基本的な使用について
InlineSTに関われていること自体はそんなに今後は増えていくとは思いますね。
あとはそれはどこまでやるかですよね。
やろうと思ったらラダープログラムの中にInlineSTだけで全部記述するってできるじゃないですか。
はい。
それはやっぱりちょっとやりすぎだと思うんですよね。
なるほど。
いくら可能やといっても。
それだったら他にSTですればいいんじゃないですか、どのプログラム全部って感じですよね。
InlineSTで諦めちゃったら。
なるほど。
そうだね、ルール決めるとか、ルールというかある程度の使い方を決めた方がいいですね、これはこのInlineSTどこまで。
決めるとか普通に信念を持ってやるというか、コンセプトを大事にした方がいいですよってだけの話だと思います。
InlineSTもデバッグ見えるんですか、現在の最後の数値が。
基本は最後に入っている値は見れますよ。
見れるか、ありがとうございます。
じゃあこれをちょっと試してみます。
あとコメント書きやすいのはいいですね。
シャプシャプ、フレッシュフレッシュで。
そうですね、コメント文使えるっていうのは。
そっか、コメント文は使えない、ラダーちょっと難しいですねコメント文は。
そうですね、やっぱりラダーの難しさってコメントアウトできないってことだと思うんで。
そうだね、最新のCODISのラダー2という、やっとできたんですけど、でもラダー2の使い方もちょっとイマイチで、
そもそもCODISのラダーの使い心地もちょっとイマイチなので、そういうところかな。
コメントアウトできれば嬉しいですよね、よく考えたら。
そうですね、ラダーコメントアウトできる機能もあるんですけど、あるには。
あるんですか?
ありますね、ラダーのある業からある業まで無効化するっていう機能があるメーカーもあるんですけど。
これ知らなかった、ちょっとメンボしようこれ。
ただコメントアウトを検索する機能がないんで、コメントアウトがそういう無効になっていることを検索する機能がないんで。
コメントアウトされたものは検索書かないってことでしょ?
書かないです。そこはコメントアウトされていることを検知するのはできない。
なるほど、いわゆる1000文字検索しかないんですよね、これだとまたすごい膨大になりますよね。
検索しても出ないです。
出ないんですか?
出ないです。
POLの中にそもそも存在していないと思ってるんですけど。
存在しないんで、機能としてある業を殺すっていう。
だから全部目視でチェックしないとわかんないんですよね。
そんなものが紛れ込んでると品質悪くなるじゃないですか。
これを無効にしたことを後から検索できないって。
でも検索できないのは結構でっかい大きい問題ですね、これ。
何に書いたかわかんないし、前の人は何に書いたかわかんない。
あー、俺わからなかった。
これどういうところがあるんだ、このコメントアウトララーは。
だからララーをやってきた文化の中で、
一つすごく象徴的な機能っていうかやり方って、
調整用コイルだと思うんですよね、僕。
調整用コイル?
調整用コイル。
わかります?調整用コイルって。
わかんないです。調整用コイルって何ですか?
要は現場で何か無効化したりするじゃないですか。
何かを消したり足したりした時。
その時に調整用コイルっていうビットを1個作っておいて、
それを入れとくんですよ。
言ってることわかります?
自分変更したところを全部別に?
そう、変更したところにオアをかけたりとか、
例えば何か追加したものに対してはオアでかけるんですよね、
その調整用の接点を。
その調整用の接点をオンにしたら、
その変えたところは全部無効化されるっていう。
なるほど、これは調整用コイルですね、この名前。
なるほど。
で、一番最後にその調整用コイルの接点を全部検索していくと、
変えたところは全部わかるんです。
これが便利ですね、これは必要ですね、これ。
っていうのを、今のラダーの進化の運用の中で、
ある種一つ編み出した?
手法?使い方?
使い方。
これが今STの中だと、コメントアウトしたとしてもそれが、
今回やったのか前やったのかもやっぱりわかんないし、
それをうまく運用するやり方がまだ出てない。
わからないですね。
基本的に今はもう、バージョン管理システムでそれはやりましょうっていう流れだと思いますけどね。
でもこれ現場でやるときはバージョン管理システムまでたどり着けるかどうかですね、現場でやらなきゃいけないときとか。
ただそれが別にパソコンがネットで繋がっていれば別に構わないわけなんで、
それができるかどうか置いといて、そういう流れなんでしょうね。
なるほど、なるほど。
調整用コイルの概念
自分STで書いたときのこのコメントアウトされたものをどうやってわかるか。
とりあえず日付を書くしかないんですよ。書くと簡単に何書いたか書くしかないんですよ、私も今も。
それ以外のいい方法がないんですね、この日付だけ書いて。
そうですね。
原作的にね、この文字列引っかかるようにして。
そう、それがどんな人がやってもそれにならないといけないんですよ。
これは多分私はこう書いたんですけど、向こうの人はこんなやり方しないかもしれないですね、これは。
ないかもしれないですね。
だからラダーはそういう面で言うとすごくシンプルなんですよ。
情勢コイルのやり方をみんな覚えれば、同じことをやれば大体同じことを追いかけるからっていうことですね。
そうですね、このアドレスのやつを入れとけっていう非常にシンプルなルール。
ルールはそこまで決めなくてもいいんですよね、そのルールと。
そうですね。
なのでコメントする際に何をコメントするか知るとか、いつゲーム入れて何書いたか入れてなくて、情勢コイルいくだけオーバーすればもう完結。
それに代わるような何かを多分ST側も作っていかないといけないのか、それかシステム的に対応するのか、もしくは現場調整というのがありえないという話をするのか、そういう話はあるんだとは思います。
なるほど、いやまだないか、そこまで。
そうですね。
だからいろんな手法が過去の歴史の中で編み出されているものをどう織り込んでいくかっていう視点は持っとかないといけないんですよね、とは常々思ってますね。
これはラーダーでもそうだし、STとか、今のICの語源語でもそれなりの対応をどうするか考えなきゃいけないですよね。
そうですね。
なるほど、わかりました。
ということを考えたときに、今のラーダーのやり方をまるっと何かで置き換えるのは多分難しいんだと思います。
はい。
おそらくそれ専用のやり方をきっちり考えていかないと、STを前提とした、ST化学に対して前提とした設備の作り方、設備のデバッグの仕方、設備の確認の方法の仕方、これは多分考えないといけないですね。
そうですね。
この常勢コイルの考え方、なるほど。
今のはあくまでも例ですけどね。
語源語のやり方はあるんですけど、そういうやり方があるんだなと。
どうやってやるんだろうな、ちょっと忘れちゃいましたね、本当に。
一体どうやってやるんだろうなというときは、自分だけのビットを作って、それで別意識する方ですね。
簡単な。
そうですね、はい。
というわけで、インラインSTのお話でございました。
はい、ありがとうございました。
ありがとうございました。
