0～１秒間での測定のプロット数が４プロットしか取れません。増やすにはどのようにすれば良いでしょうか？

[deviceg]

タイトル通りです。以下にプログラムのサンプルを載せておきます。そのサンプルプログラムでは０から１秒での測定で20プロットとれるプログラムを組んでいるにもかかわらず、実際には4プロットでしか測定データを取り込むことができません。どのようにしたらプロット数を増やすことができるのでしょうか？

[T.Yasukawa]

ご質問ありがとうございます。

VIを拝見させていただきました。

何点か確認したいことがございます。

①こちらのVIはご自身で作成されたのでしょうか。もしくはメーカー様が作成されたのでしょうか。

(もしメーカー様が作成され、推奨されているデバイスにてきちんとプロットされない場合は、メーカー様にお問い合わせ頂いたほうが早期解決に繋がるかもしれません)

②使用されている集録デバイスはNI製品でしょうか。もしくは他社製品でしょうか。

(見たところGPIB通信で他社製品を制御しているのでは、と推測しております。)

③1秒間で20プロットとれるプログラム、というのはどの部分でしょうか。基本的に集録のタイミングを制御するのは待機関数です。Forループの中にも待機関数があるようですが、入力値に関しては少々複雑な計算をしているようで、毎回のループでどれだけ待機するのかはわかりません。

例えば、待機関数で毎回50msec待機する(よって1秒間で20回ループが回る)ようにしているのに、実際はループの実行速度がもっと遅くなってしまう、ということであれば、待機関数以外のコードの部分で、予想以上に処理に時間がかかっている可能性があります。次のループは、前のループ内の処理が全て終わらない限り実行されません。

ブロックダイアグラムを見た限りですと、機器と通信をしてデータを取得するLCRメーター4というExpress VIが遅延の原因ではないでしょうか。中ではGPIB通信をしていますので、通信に時間がかかっている可能性があります。

VIをこちらで実行できない以上、お客様ご自身でデバッグをしていただく必要がございますが、まずはどの処理に時間がかかってしまっているのか、調査をお願い致します。

処理にどれだけの時間がかかっているじゃ調べる際によく使う手法としては、添付したような、シーケンスストラクチャとティックカウント関数を使用した方法です。お試しください。

[deviceg]

返信ありがとうございます。

①私自身が作ったプログラムです。

②hp4284aのLCRメータを使用しております。GPIBケーブルは、NI製品を使用しております。

③VIを少し変えて、集録データを二つだけにしてみました。この場合も４プロット(250ms間隔)になりました。測定間隔は、待機時間の10msだと認識しております。

ティック関数の方は、まだ試せていませんがとりあえずの状況報告になります。よろしくお願いします。

[T.Yasukawa]

やはりLCRメーターExpress VIが遅延の原因のような気がします。

Express VIで右クリックして、フロントパネルを開くで変換を選択しますと、Express VIがサブVIに変換され、ブロックダイアグラムが見れるようになります。

実際に見てみますと、WhileループにVISA読み取り関数をいれ、ある特定以外のエラーが出るまでwhileループで読み続ける、といった方法を取っているようです。

何故このような方法を取っているのかは不明ですが、あまり効率的ではありません。

更に取得したテキストデータを解析して、ほしい部分だけを抽出する処理もあります。

おそらくこの二点の処理が予想以上にかかっているのではないでしょうか。

ご提案できる点としましては、二点

①Express VIではなく、下位関数を使用し、より効率的なプログラムを作成する。

測定器側の設定で、コマンドに終端文字を追加できるような設定はありますでしょうか。恐らく現在はなしの設定になっておりますが、もし設定できますと、読み取り関数は終端文字が来た段階で読み取りを終了しますので、余計な時間を短縮することが出来ます。

LabVIEW側ので終端文字の設定はLCRメーターExpress VI内で使われているプロパティノード、TermChar及びにTermChar Enableで設定する事ができます。

また標準で搭載されているサンプルもご覧ください。サンプルファインダよりGPIBと検索しますと、VISA関数を使用したGPIB.viがございます。こちらを参考にしていただくと、どのようにコマンドを書き込み、読み取るのかがわかるかと思います。これに終端文字の設定を加えながらカスタマイズしてみてください。

また最終的にはWhileループで何度も書き込み、読み取りをする必要があるかと思います。その際の注意点としまして、ループで囲むのは、VISA書き込みから読み取りまでにしてください。頭のOpen関数やプロパティノード、最後のClose関数まで含めてしまいますと、非常に処理が遅くなります。

②キュー関数による処理の切り分け

キューとは何ですか - National Instruments
http://digital.ni.com/public.nsf/allkb/862567530005F0A1862568C0005577AD

キュー関数を使用することで、片方のループで高速でデータを取得し、もう片方のループでそのデータの処理ができます。これは処理がおもすぎて集録に影響が出る際によく使われる手法です。サンプルファインダでキューと検索しますと、簡易キューというサンプルがありますので、ご覧ください。

これを使用して、VISA読み取り関数からデータを受け取ったあとの所望の部分を抽出する処理を別のループにて行わせてみてください。もしかしたらデータの取得速度が向上するかもしれません。

以上の対策をとっても早くならない場合はGPIB通信の限界かもしれません。他のソフトでGPIB通信して高速でできた、ということはありましたでしょうか。他でやっても出来ない場合は、通信限界が考えられます。

長々と書いてしまいましたが、現状では様々な部分に可能性があります。よって改善する前に、実際にどこで時間がかかっているのかティックカウント関数を使用して特定してから、ピンポイントで改善したほうがいいかもしれません。Express VIの実行速度、その中の読み取りの部分、データの抽出の部分、それぞれでベンチマークを取ってみてください。

よろしくお願いします

[deviceg]

連絡が遅くなり大変申し訳ありませんでした。

返信ありがとうございます。

LCRメータのサブVIのある特定以外のエラーが出るまでwhileループで読み続けるの部分を削除してティックカウント関数を使い、どこに遅延が見られるのかをやってみました。すると250ms要しているところがわかりました。visaの読み取りと書き込みのところで時間を要しているみたいです。添付にLCRメータのサブVIをのせておきます。

キュー関数がうまくいかず苦戦しています。

この状況でも通信の限界は考えられるでしょうか？

宜しくお願いします。

[pipipi0405]

VISA関数は機器との通信を行う部分です。そこで250msかかっているということは、おそらくLCRメータの応答速度の限界が250msだということなのではないでしょうか。応答速度についてメータの仕様書に何かかかれていたりはしないでしょうか。

[deviceg]

解決いたしました。ご教授いただきありがとうございます。