LabVIEWでプログラムを組むときに必要になるデザインテンプレートの案を紹介しています。本ブログで紹介している具体的なプログラム例のベースとなる組み方を説明しています。
この記事ではエラーの発生回数で処理内容を決めるステートマシンを紹介しています。
このデザインに必要な知識
全体的な構造としてはステートマシンを前提にしているため、ステートマシンの知識は必要です。
ただし、今回は途中で割り込み操作を行うような仕組みをいれており、これはシフトレジスタを使ったオーソドックスなステートマシンでの実装だと難しいので、キューを使用したステートマシンの構造が理解できている必要があります。
そのため、必要な知識としては
- ステートマシン
- キューを使用したプログラム
になります。
ステートマシンの作り方とは、ステートマシンがどうやって状態を移っていくか、そのためにLabVIEWでどのように組む必要があるかということがわかっていれば十分かなと思います。
具体的には以下の記事で紹介しているようなプログラムが特に不自由なく組めるのであれば問題ないかなと思います。
キューについて使い方がわからないという方は以下の記事が参考になるかもしれません。
また、エラーのカウントにはフィードバックノードを使用したサブVIを用いています。
フィードバックノードを使用しなくても、機能的グローバル変数のような形でWhileループを1回実行するだけの形のプログラムにしても同じことができます。
このデザインの基本的な構造
動作を説明するために、今回はわざとエラーを発生させる仕組みを設けています。
フロントパネル上には、プログラムが通常動作していることを表すためにランダムな数値を表示し続ける以外に、ボタンが2つあり、それぞれのボタンを押すとそれぞれ異なるエラーを発生させるようにしています。
プログラム実行中、エラーを発生させるためのボタンを何度か押してそれが決められたしきい値の回数以上押される（＝エラーが発生する）ことで処理が変わるようにしています。
今回は、エラー発生回数がしきい値を越えたらプログラムを終了するようにしています。
なお、エラーの発生回数は、それぞれのエラーで別のカウントとしています。
エラーの種類に関係なく、プログラム実行中にある回数発生したら、ではなく、それぞれのエラーごとにカウントしていき、いずれかのエラーの発生回数がしきい値を越えたら終了していきます。
このようなプログラムを作るためには、エラーを処理するためのケースを用意し、エラーが発生したらそのケースでエラー発生回数をカウントしていきます。
そのための仕組みを設けやすいのはやはりステートマシンで、エラー発生時にそのエラーの回数をカウントするためのステートを割り込ませるためにはキューを使用したステートマシンが便利です。
そのため、ブロックダイアグラムにはキューを使用したステートマシン用にWhileループを一つ配置しています。
シフトレジスタは使わず、次のステートへの遷移を全てキュー関数で指示しています。
ステートの中身として、最初のinitステートとendステートは特に面白いことはなく、initステートで次のステートであるmeasureステートを指定し、endステートはWhileループを終了させています。
measureステートでは今回は測定を模擬するために乱数の値を数値表示器に出しています。
本来は例えば何か特定のハードウェアからの測定値の取得処理を行うものと考えてください。
そしてその処理の過程で何かエラーが発生した時、エラー発生に応じてerrorcheckステートに進むようにしています。
今回は乱数の関数を使っておりエラーは出さないので、強制的にエラー発生状態を作るためにブールのボタンを設け、押されたらそれぞれ異なるエラーがでるような仕組みとしています。
errorcheckステートへの遷移には、エンキュー関数ではなく先頭へエンキューしています。
errorcheckステートでは、エラー情報を受け取って、error count.viでエラー発生回数をカウントしています。
今回は、異なるエラーが発生した場合にはそれぞれのエラーごとにカウントしていき、あるエラーがしきい値（下の画像では2としているerror limit）を越えたらプログラムが終了するようにしています。
error count.viの中身は以下の通りで、フィードバックノードを使用してこのサブviが呼び出されるたびに今まで発生したことがあるエラーの情報（クラスタの配列）を使いまわし、発生したことのないエラーなら新たに配列に追加、発生したことのあるエラーならカウント値を増やす処理をしています。
ただし、上記のerror count.viの仕組みだと、エラーの内容（メッセージ部分含め）が完全に一致しないとエラーカウントは増えていきません。例えばエラーメッセージが異なっていてもエラーコードが同じエラーならカウントを増やす場合には1D配列検索を行う部分の処理の仕方を変える必要があります。
エラー発生の過程を知る
エラーが発生してもすぐにはプログラムを止めず、何回かエラーが出てから止まるようにしたとして、その過程でどういったタイミング、どういった順番で複数のエラーが出たかを知るために、errorcheckステートにてエラーのログをとるように処理を追加してみます。
以下の図はその一例で、error count.viの結果しきい値を超えるエラーがまだ出ていない場合、つまりケースストラクチャがFalseの場合にエラーの内容をerrlog.txtに保存しています。
このケースの中で開いて閉じてまでを完結させていますが、この部分はサブVIにしてもかまいません。
中で使用しているerror text conv.viは以下のようにしており、エラークラスタの中身に対して文字列にフォーマットを使っています。
今回の記事では、エラーの発生回数で処理内容を決めるステートマシンを紹介しました。
エラーが発生するということはプログラムが正常に動作していないということを意味するため、エラー発生時点でプログラムを終了させたい、という場合が多いと思いますが、中には数度のエラーなら許容してそのまま動かす、という場合もあると思うので、そういった場合のエラー処理として参考になればうれしいです。
ここまで読んでいただきありがとうございました。
コメント