エラークラスタの扱い方 | マーブルルール

エラークラスタの扱い方

使い方集

スポンサーリンク

LabVIEWでプログラムを書くときの強みの一つは、ユーザーインタフェースであるフロントパネルをドラッグアンドドロップの操作だけで簡単に構築することができることだと思います。

本ブログのまずこれのシリーズでは主にプログラムのアルゴリズムの部分の書き方について解説してきましたが、アルゴリズムを知っているだけではプログラムは書けず、どのような選択肢があるかということも知っておく必要があります。

使い方集は、まずこれのシリーズでステートマシンまでの知識はある程度知っている前提で、アルゴリズム以外に関わるプログラムの書き方について紹介するシリーズです。

本記事ではデータタイプの中の一つであるエラークラスタについて紹介しています。なお、エラーの解消方法、いわゆるデバッグについての記事ではなく、プログラムを作るうえでのエラークラスタの取り扱い方、特にオリジナルのエラーをカスタマイズして作成することについての紹介をしています。

スポンサーリンク

エラークラスタの基礎

まずは何はともあれエラークラスタの基礎について確認していきます。

エラークラスタは、コード、ステータス、そしてソースの3つのデータが合わさった、文字通りクラスタの形式を取っています。

しかし、他のクラスタとは区別された特別扱いのデータタイプであり、エラークラスタ特有で使用できる関数がいくつか存在します。

エラークラスタは、そもそもの役割としての「エラー情報を伝える」という目的で使用することもあれば、単純にLabVIEWのデータフローの仕組みに基づいて、このエラークラスタのワイヤで実行順番を制御するために用いることもあります。

以下の図では「A」や「B」などと書かれているのはそれぞれ何かしらの処理をする関数として扱っています。

エラー情報がどこかのタイミングで生成されたとして、エラーを処理するには大きく分けて次の二つの方法があります。

  • ケースストラクチャに配線し、特定のエラーに対して特定の処理を実行
  • エラーをクリアする、あるいはボップアップする

ケースストラクチャを使用することで、エラー時にだけ特別な処理を行ってから、エラーが起きていない時と同じ処理をたどる、といった書き方もできます。

他にも、エラーの状態をそもそもなかったことにする、あるいはユーザーに知らせるためポップアップや表示器で表示する、といったことを行うこともできます。

いずれにせよ、意図した動作をしていないエラー状態をいかに対処するかにおいてエラークラスタ、エラーワイヤの配線は重要です。

もちろん、これらを組み合わせて、例えば「エラーが出た際に特定の処理は実行するがその後の動作に影響がないようにクリアもする」といった場合もあり得ると思います。

ただし、ここでいうエラーはあくまで「LabVIEW(ソフトウェア)が元々想定した、意図した動作になっていない状態」に対してしか表示されません。

単純な話、「エラーをどう表現したいか」はプログラムでどういったことをしたいかに依り、「LabVIEWが元々示すエラー内容で十分」なのであれば、本記事の以下の話は知らなくてもいいこと、になります。

が、ある程度の大きさのプログラムや本格的なプログラムを作るにあたっては、不便が生じることがあります。

例えば、オリジナルのプログラムを作成した際に、そのプログラム独自の「エラー」と呼ぶべき、意図した動作になっていない状態が発生したとき、必ずしもLabVIEW側でもともと用意されたエラーのメッセージが適切とは限らない、という場合があります。

実際、LabVIEWが用意したエラーメッセージというのはテキストファイルにまとまっていて、逆に言うとそれらテキストファイルに載っていないものはエラーメッセージとしては当然出てきません。

そこで、自分で作ったプログラムにふさわしい(?)独自のエラーを定義する必要が出てきます。

エラーのカスタマイズ方法

では、そんな独自のエラー定義についてですが、ここでは以下の二つの方法を紹介します。(実際には他にも方法はあるのですが、主に以下の二つの方法を使えれば困ることはほぼないと思います)

  • エラー用のテキストファイルを用意する
  • エラーリングで動的に変化するエラーメッセージを用意する

それぞれの方法について紹介します。

エラー用のテキストファイルを用意する

まずは、LabVIEW側が元々エラー用のテキストファイルを用意しているのと同様に、オリジナルのエラー情報がリストされたテキストファイルを作成するという方法です。

この機能はLabVIEW自体に備わっていて、メニューバーの「ツール」から「上級」へと進み、「エラーコードの編集」を選択します。

表示されるウィンドウで、エラーコードの番号と、その番号に対するエラーメッセージの内容を編集していきます。

エラーコードの数字はなんでもいいかというとそうではなく、LabVIEWでもともと定義されたエラーコードの数字以外を指定します。

いわば、カスタムでエラーを定義できるエラーコードの範囲が決まっていて、ヘルプファイルによると

  • -8999~-8000
  • 5000~9999
  • 500,000~599,999

の範囲のようです。

リストを作り終えたら保存するのですが、このテキストファイルは

C:\Program Files (x86)\National Instruments\LabVIEW XXXX\user.lib\errors

というフォルダに置く必要があります(32 bit版のLabVIEWを使用している場合。XXXXには2020などのバージョンの数字が入ります。)また、LabVIEWを一度再起動させる必要があります。

こうして複数のエラーをまとめて定義して、あとはそのエラーが起こった際にエラーコードとしてその値が渡せるようにプログラムを編集します。

一応動作を確認してみると以下の図のような感じになります。

カスタマイズしたエラーコードを表示させられるようにするためには、そのエラーコードをエラー表示器やシンプルエラー処理の関数に渡せるようにプログラムを変えることになります。

以下の図のように、選択関数やケースストラクチャを使用するような組み方が考えられます(実際は赤枠で囲まれた部分ごと「A」の中に入れるとより見た目がすっきりします)

このエラーファイルを作成するというのは、作っているプログラムが他のPCで実行するようなものであり、複数個のサブVIで共通して同じエラーが使用されるような場合に便利な方法です。(せっかくカスタマイズしたエラーがあっても、使用しているPC環境にこのエラーファイルがないとLabVIEW上で正しく表示されません)

エラーリングで動的に変化するエラーメッセージを用意する

もう一つの方法は、ファイルとしてエラー情報を記録するわけではありません。ですが、エラーメッセージをもう少し柔軟に、メッセージの内容を動的に設定することが可能です。

これには、エラーリングというものを使用します。

エラーリングをブロックダイアグラム上に置くと、エラーを選択の画面が出てきます。

「エラーコード範囲」を選択し、「カスタムエラーコード」を使用します。

なお、もしカスタムでエラーファイルを作成している場合には、エラーリングの部分でもこの中身を確認することができます。

新しいエラーを作成することを目的とするので、カスタムエラーコードを選んだ状態で中身を編集します。

エラーコードを決める部分はエラー用のテキストファイルを作成するのと同じですが、エラーの説明の部分で「形式文字列」が使用できるのが利点になります。

これにより、文字列にフォーマットの関数などにも使用されるのと同じく、特定の入力を外部から受け付けることができるようになります。

例えば、以下のような表示を行うことができます。

ここに、そのデータタイプに合った値を配線することで、エラーのメッセージ内にその値を反映させることができます。

他にも形式文字列は複数存在します。よく使用されるであろう形式文字列を例に、いくつかエラーリングがどうなるかの例を紹介します。

この機能を使用することで、プログラム実行中に何か動的に値が変化するものをエラーメッセージの中に入れ込むことができ、エラーの状況や理由をより分かりやすく表現することが可能になります。

エラー用のテキストファイルを作る、エラーリングで定義する、これら二つの方法、併用することもできますが、どちらが自分のプログラムへのオリジナルのエラーメッセージとしてふさわしいかを考えながら実装する必要があります。

「正しく」エラーを定義、表示させることができるようになれば、プログラム完成後にエラーが起きてもどんな対処をすればいいかがより明確になり、それだけトラブルシュートのしやすさにもつながってくると思います。

本記事では、エラークラスタの扱い方について紹介しました。

特にエラーのカスタマイズについては本格的なプログラム、アプリケーションを作るとなると必要になる場面も出てくると思います。何となくでも頭の片隅にでも入れておくと、いざ必要な場面に出くわした際にどうすればいいかの対応が早くできると思うので、とりあえずはこういうことができるんだ、程度に参考になればうれしいです。

ここまで読んでいただきありがとうございました。

コメント

タイトルとURLをコピーしました