この記事では、他の記事で一つずつ取り上げるほどではないものの、もしかすると知られていないかもしれないなという LabVIEWを使用する上でのいくつかの小ネタを独断と偏見で5つ選んだので紹介しています。
過去の小ネタは以下の記事に載せています。
列挙体の項目を文字列として取得する
列挙体はユーザーに選択肢を文字情報として表示させたりステートマシンでステート名をケースストラクチャのケースラベルにそのままの名前で表示させることができるなど、様々な場面で便利に使えるデータタイプです。
ただ、列挙体はブロックダイアグラム上の表示あるいは詳細ヘルプで見てもわかる通り、LabVIEW内部としては数値データ扱いであるため、例えば項目名をファイルに保存するために文字列にしようと思っても、数値にしか変換できないと思われがちです。
ただ、実際はこの項目名を文字列に変換できる関数があり、それが「文字列にフォーマット」関数です。
この関数は形式文字列を指定することで複数のデータタイプを受け取ってまとめて一つの文字列にしてくれるなど大変便利な関数ですが、列挙体に対しても使用することができます。
あるいは、プロパティノードで項目名プロパティを取得し、これと指標配列を組み合わせるといった使い方で項目名の文字列を取得することもできます。
ファイル保存時の「操作」入力の違いについて
LabVIEWでファイルへのデータ保存を行う際には、どのファイルに保存するかという選択を行う必要があります。
TDMSを除き、ファイル操作には「ファイルを開く/作成/置換」の関数を使用するのが通例ですが、この際に操作オプションとしてデフォルトであるopen含め全部で6つの選択肢があります。
TDMSの場合にはTDMSを開く関数ですがこちらの場合は選択肢は5つです（「replace」がなくなっています、また、「replace or create with confirmation」の代わりに「open (read-only)」があります）。
この操作の種類によって、ファイル保存にかかる時間が異なるようだったので、確認してみました。
前提として、以下のプログラムを使用するとします。
また、既にこのプログラムを一度実行して、result.csvが存在している状態とします。
このときに、まず操作をopenとした場合、かかった時間は9000~11000程度でした。
これはreplaceやopen or create、replace or createでも大体同じ傾向でした。
しかし、createの場合には250程度で、大幅に少ない時間で終わりました。
(replace or create with confirmationの場合には、既存ファイルがある場合にユーザー操作を必要とするため比較対象にはいれていません)
Tdmsについて同様な比較を行った場合、openではおよそ1000程度でした。
Open or createでもcreate or replaceでも同じ傾向です。
しかしcreateとするとこちらも250程度となり、他の選択肢より圧倒的に早く終わりました。
恐らくは、「何か+create」の選択肢を使用した場合には、その既存ファイルを読みに行ってその領域にデータを書き込む（上書きする）といった処理がなされるので、ディスク上のその書き込み領域を探したりする時間が発生するのに対し、単純な「create」の選択肢は全く新規のディスク領域を使用することにより探すという操作をする必要がないことからこのような差が出るのではないかなと考えられます。
ディスクへの書き込み時のメモリ使用効率を考えると無駄があるのかもしれませんが、何かしら早さを求めるデータ保存を行う場合には、既存ファイル名を使用してかつ上書きしてもいいのであれば、「create」を選択した方が処理は早い、ということになるかと思います。
設定で外観が変わるオブジェクト
LabVIEWは、グラフィカルにプログラムを表すというだけあって、あらゆるものを視覚的に表現します。
いわゆる関数やノードも視覚的にわかりやすくなっていますが、その一部は設定次第でデフォルトの見た目（関数パレットからブロックダイアグラムに直接配置した時点での見た目）から変わるものもあります。
せっかくなので、クイズ形式としています。これらはどんな設定で見た目が変わっているか、考えてみてください。
まずはこちらです。
以下の図で、ライブラリ関数呼び出しノードがありますが、外観の色が黄色とオレンジ色になっているのはどういった違いがあるでしょうか？
答えは、片方がUIスレッド、もう片方が任意スレッドで実行するという違いがあります。
次はプロパティノードで一つ。
以下の見た目になるのはどのような時でしょうか？
答えは、プロパティノードのエラーを無視の設定を有効にした場合です。通常一つのプロパティノードで複数のプロパティを指定している場合に上から順番に実行し、途中でエラーが起こった場合にはそれより下の項目は行われませんが、この設定を行うことで途中でエラーが起こったとしても最後まで実行できます。
では次、以下のような水色の強制ドットはどのようなときに見られるでしょうか？
答えは、固定小数点の設定で出ることがある、です。
例えば、固定小数点の積の計算で、咳関数のプロパティで手動で出力構成を変えた場合にこれが表示されることがあります。
赤い強制ドットの場合もそうですが、これはない方がいいので、もしこれらの強制ドットが出た場合には表記法の変換であったり、表示器の出力構成をうまく変更するのが望ましいです。
では最後。以下の図のように和の関数にエラーの入出力が表示されるのはどのようなときでしょうか？
答えは、ダイナミックデータ（Express VIから出る）同士の演算を行う場合です。
ダイナミックデータはExpress VIでしか扱わず、ほとんどのExpress VIは効率が悪かったりするので、LabVIEWに慣れた人ほど逆に見る機会が少ないと思います。
以上、設定や使い方によって見た目が変わるオブジェクトを挙げてみました。
複数のエラーを保持しておく
設定で外観が変わるオブジェクトの一種でもありますが、エラー結合の関数は実は複数のエラーを保持しておくことができます。
ヘルプを見れば書いてありますが、設定をすることで、結合されたエラーの中に複数のエラーがあった場合、それらのエラーの情報をまとめて取得することができます。
ただし、エラー結合の関数自体はエラークラスタ単体（配列でない）を出すだけです。
それなのにどうやって複数のエラーを保持できるかというと、特殊なステータスメッセージの中に複数のエラーの情報を持つ、JSON形式となっています。
このJSON形式の文字列、そのままJSONから非平坦化の関数が使えればいいのですが残念ながらそうはいかず、実際にはステータス文字列を少し改変してやる必要があります。
しかも、エラー結合された複数のエラークラスタの中に、実際にエラーがあった数が1つか2つ以上かで改変の仕方が少し異なります。
上で示していたのは複数のエラーが出た場合ですが、エラーが一つだけだった場合には下の図のような表示になります。
そのため、どのような場合でも対応できるようにするには少し処理を書いてやる必要があります。
一例として、パターンで一致の関数によってエラーの数を調べてケースストラクチャで場合分けする方法を紹介します。
ブックマークでスペースを入れる
LabVIEWで、コメントやデバッグを残すために使用できる便利な機能にブックマークがあります。
作り方は簡単で、コメントにハッシュタグとブックマークの項目名を入力するだけで、プログラムの複数箇所で作成したブックマークをブックマークマネージャで一覧表示および特定のブックマーク箇所にジャンプする機能があります。
ブックマークの項目名には好きな文字を入れて管理ができるのですが、スペースを入れたい場合には注意が必要で、「半角スペース」だと項目名とみなされず、その前までの文字がブックマーク項目として登録されるのに対し、「全角スペース」だと項目名の一部とみなされます。
これについてはアンダーバーやハイフンを使うといった形でスペースを使わずとも区切りを入れられるのですが、何らかの理由でスペース区切りで管理したいという場合には参考にしてみてください。
本記事ではLabVIEWの小ネタを5つ紹介しました。
列挙体の項目の文字列化については活用できる場面があるかもしれませんが、他の項目についてはまさにトリビアみたいなものが多いかなと思います。
ただ、知っておけば他人のプログラムを読んだりデバッグを行うのに役立つこともあるかなと思うので参考になればうれしいです。
ここまで読んでいただきありがとうございました。
コメント