00:00
Astral Factory Automationへようこそ。クリスです。
今回は一人回ですが、いろいろと何をしゃべればいいかな、というテーマを考えて、
今回はFB、Function Blockについて話したいなと思っています。
最近ではないですが、だいぶ昔から各社にもある程度Function Blockに対応できるので、
でも実際に使っている方はまだそこまで多くないので、このチャンスでポッドキャストについて、
Function BlockとFB、そもそも何かを簡単に紹介しようかなと思っています。
どうぞよろしくお願いします。
FBとは、あらかじめに定義された標準な処理機能を持つプログラムの要素の塊だと思ってはいけないかなと思っています。
FBを定義されたプログラムを自分のユースターボードに入れることによって、
出力パラメーターを設定するだけでこのFBを使用することができます。
またちょっとややこしいですが、このFBの中には基本はアドレスがなくて変数だけでプログラムをするので、
この辺りでちょっと抵抗感がある方がいるかもしれないですね。
それでその名の変数をパラメーターと呼びますね。
その前にまずFBを使うとどんなメリットがあるかちょっと話したいなと思っています。
FBを使っていることによって複雑なプログラムユニットを簡単に切り分けるとか再利用することができます。
一度FBを作成して、ライブラリの形、景色、各社でどうやって保存するかはちょっと別論して、
保存すればプログラムの中にFBを配置して、IOのパラメーターを設定するだけで再利用することができます。
なので再利用する目的によってプログラムを作成するときのデバッグ。
ライブラリでもたくさんデバッグされているので、プログラムのデバッグの時間も大幅に短くなるんじゃないかなと思っています。
また、前を見て長い巻物みたいなプログラムではないので、プログラムの理解も理解しやすくなりますね。
それは大きなメリットとして、例えば読みやすくブラックボックスをデザインしていますね。
さっきも言った通りにプログラムを入力したり読んだりするときはプログラムにはブラックボックスのようなものなので、
余計な調査は必要ないですね。
その通りにちょっとライブラリは揺れて、それに輸出力を割と当たるだけなので、
それだけでオンラインキャプターランスのライブラリのアルゴリズムを理解するために
03:03
余計な時間を使わなくてもいいんじゃないかなと思っている意見もあります。
例えばSeamenさんとかもライブラリを出しているんですね。
インワーターとかサーボアンプとかPIDとかの制御するライブラリも出しているし、
AMRONさんでも通信ライブラリを出しているんですよね。
例えばMQTTとかライブラリとかモーション制御ライブラリも出しているし、各社も何かでライブラリを出していますよ。
水道さんでもSafetyを使うときに非常停止のブロックとか両手同時制御のブロックとかも実際に提供されているので、
皆さんも知らないうちにたくさんのSPが使っているかもしれないですね。
次は一つのファンクションブロックを使うによって複数のプロセスをできるんですね。
一つのファンクションブロックでさまざまなプログラムがあるので、
簡単に作成して使用できるので、プレオリジナル化としては大きなメリットじゃないかなと思っています。
コーディングエラーの減らしですね。
もちろんライブラリ化されたプログラムだったらある程度デバッグされたので、
デバッグ済みのブロックを利用するので、もちろんこの辺は正常通り動くんですね。
次はプログラムの作成の開発時間も短縮ですね。
ファンクションブロックなので中身は全部同じですね。
同じブロックを何回もプログラムが呼び出すので、中に一箇所書いたら全部自動的に反映されるので、
今まで作ったのは巻物みたいな、
こっちを修正したら同じ回路を10回も修正しなきゃいけないという手間がなくなりますね。
次はプロポークスカーサのローハウスですね。
いわゆるファンクションブロックを各社でもあるので、読み取りの保護機能がつけることができます。
これをつけたら、例えば使用者、ユーザーがこのプラゾンブロックを使えるんですけど、中身は見ることができない。
その点、自分の会社的なローハウスを保護することもできますね。
次はデータプロジェクションのほうにちょっと話したいなと思っていて、
ファンクションブロックの内部の変数を外から直接アクセスしたりとか変更したりとか基本的にはできないので、
外から中の動きを直接変えることはできない。
全部のIOのパラメーターを経由してないとダメというところがありまして、
なので中の変数を保護することができます。
次はファンクションブロックの構造を見ていきたいなと思っています。
ファンクションブロックは実際にファンクションブロックの定義をすると大きな2つの部品が分かれてきます。
ファンクションブロックの定義自体、インスタンスです。
06:04
ファンクションブロックの定義から話しますと、定義はつまりプログラムですね。
プログラムの定義にはアルゴリズムと変数定義があります。
アルゴリズムもこれから制御したい、サーボームーターとかBIDとかインワーターとかの
どういう制御をしたいのかを作るアルゴリズムをファンクションブロックの中に作っています。
この言語は、例えば皆さん使うIC6133だったらラウダーとかSD言語のFPとか何でもいいのでこれを使ってアルゴリズムを作成します。
次は変数定義ですね。変数定義は各社もあるので、変数定義テーブル上でもあるし
どこでもあるので、各変数の用途、有力なのか、出力なのか、ライブ変数なのか、またプロパティ、
どんなタイプなのか、定義するのかを設定しているんですね。
これが終わったらやっとプログラムの定義が終わります。
次はインスタンですね。インスタンも難しい解き方もありまして、
何回も言いますが、ファンクションブロック自体は車だと車の設計図ですね。
インスタンスは設計図に基づいて作った車なので
実際にファンクションブロックをプログラムの中で使用するときに
ファンクションブロックを所有してインスタンスをファンクションブロックに基づいて作ったプログラムを
所有するというイメージですね。
ちょっと分かりにくいかもしれませんが、とりあえずファンクションブロックは車の設計図、
インスタンスは設計図に基づいて作った車なんですね。
パラメータの中に先にインプット、アウトプットとインナウトとか書いてもらったんですけど、
インプットは有力だけのデータですね。
例えば現在圧力とか現在温度とか現在のモーター速度とか、これはインプットパラメータ。
そのパラメータはファンクションブロックの中で一回言うことができないです。
読み取り専用ですね。
次は出力ですね。
出力は何があるかというと、
例えばモーターの設定、スピードセットポイントとかポジションセットポイントとか
オンのセットポイントとかURENABLEの信号とか、そういうのが出力信号ですね。
次がインナウト。
インナウトはちょっと違って、
09:02
このブロックの中にファンクションブロックの中に読み取ったりでもいいし、
書き込んでも大丈夫ですね。
何があるかというと、
例えばレシピデータとか。
レシピデータをファンクションブロックの中に入れて、
この中でチェックして、それでまた書き込んだり変更したりとか、
そういうときはインナウトを使うんですね。
最後はインターナル。
インターナルは内部変数ですね。
外を基本アクセスできない変数になります。
エクスターナルもあるんですけれども、
外部のグローバル変数をアクセスすると。
基本は推奨しないので、
だから、APIからは基本はグローバル変数は使わないようにします。
最後、実際各社のPMCはほぼ対応できるんですけど、
ファンクションブロックって対応的な差がありますね。
例えば、PACOPS & CODIS系とかは、
ファンクションブロックのOOBコンセプトに対応できるので、
プロパティとか、メソッドとか、エクスタンドとか、
インプレンツとかも対応できます。
POS-NEXTは基本のファンクションブロックが対応できて、
プラスメソッドが対応できるって感じですね。
CMENさんは基本ファンクションブロックだけですね。
プロパティとか、メソッドは対応してないですね。
AMRONさんも同じ。
MELSECも同じですね。
KEYENさんも同じだと記憶があります。
なので、実際にファンクションブロックを作る時に、
例えば、ペンザンの他の中で、
PACOPS & CODIS系も使ったり、
PACOPSも使って、
でもCMENさんも使った場合は、
公約数を取って、
同じ各社の中で、
同じあるファンクションブロックの仕様に沿って、
ライブラリを作った方がいいんじゃないかなと、
私は思っています。
ちょっと10分以上くらい喋ったんですけど、
今回のPodcastで、
FPの簡単紹介、これで終わろうかなと思っています。
また次、またテーマを喋りたいなと思っています。
今日はPodcastは以上になります。
ありがとうございました。
今日も一時お疲れ様です。
また今度で。
