LabVIEWは簡単？
LabVIEWはグラフィカルな開発環境です。そのため、情報科学やプログラミングの専門的教育を受けていない人(特に科学者や技術者)でも、比較的簡単に計測用プログラムを作成することができます。私も情報科学を専門としていないので、その1人と言えます。特に、NI DAQからデータを集録するプログラムなら、DAQ AssistantのExpress VIで対話的に簡単に作成できます。Express VIで対話的にプログラムを作らない場合も、ブロックを置いて配線するという直感的な操作でプログラムを作ることができます。また、LabVIEWでは操作画面(フロントパネル)とコード(ブロックダイアグラム)がセットで存在するため、コードを作る過程で自然と画面ができるというのも利点です。
しかし、計測器が増え、測定方法が複雑になり、アプリを使用する人が開発者以外になると、直感的にプログラムを作れるLabVIEWでも高品質なプログラムを作ることが難しくなります。むしろ、直感的にプログラムができるからこそ、場当たり的にコーディングを進め、気づいたら配線がスパゲッティ状態になって詰むというリスクがあります。
ここまでカオスなコードはなかなかないですが、似たようなコードを見ることもありますし、作ることもあります。グラフィカルなのでスパゲッティが可視化されます。
LabVIEWでアプリケーション開発するには？
LabVIEWで複雑な要件のアプリケーションを開発するには、うまくいきやすい例をまねして設計するのが有効です。NIはそれをデザインパターンとしてテンプレートを公開したり、その使い方をトレーニングで紹介したりしています。デザインパターンの使いどころと使い方が分かればどんな計測アプリケーションうまく作れる…とは限らないですが、失敗のリスクは減らせるかもしれません。
しかし、LabVIEWのデザインパターンについて知る機会は多くなく、情報源があっても英語であることが多いです。また、どのデザインパターンを使うのかの判断も必要になります。ここでは、LabVIEWでうまく開発する足掛かりとして、いくつかのデザインパターンを紹介できればと思います。
主なLabVIEWデザインパターン
これは個人的な考えですが、どのデザインパターンを選ぶか…それはこれからやる仕事をどんな組織体制でやるかに似ていると考えています。つまり、1人でやったほうがいい仕事なら1人でやるような手法を選び、階層型の組織を形成したほうがいいならそういうデザインパターンを選びます。LabVIEWの場合、アプリケーション開始処理をしてから終了処理をするまでずっと回っているWhileループの数が人数に相当すると考えています。n個のWhileループをどうやって統率するか(あるいはそれが不要か)でデザインパターンを選ぶ感じですね。まあ、最終的には経験と勘(と最近なら生成AIさんの意見)で決めることになると思っていますが。
*各デザインパターンのイメージは個人的なものです。妄想ともいいます。
State Machine (ステートマシン)
これはWhileループが1つのデザインで、1人ですべての仕事をする感じです。
使い方の例
Producer/Consumer (生産者/消費者)
これはWhileループが複数あるけど、生産者は生産するだけで、消費者は生産者から受け取ったものを消費するだけというイメージです。会社の組織みたいに言うなら営業が案件を製造や開発に丸投げし、製造や開発も勝手に作るという、あんまり成熟していない組織というイメージで、私自身、このデザインパターンは簡単な検証でしか使わないです。どうしても消費者→生産者の情報伝達がほしくなりますし。
Queued Message Handler (QMH、キューメッセージハンドラ)
これはWhileループが複数あり、互いに連携をとれるようにしたものです。このあたりのデザインからちゃんとチームでシステムの処理をするという感じになります。このときのチームメンバーは全員対等な関係で、各々の仕事をしながら必要な時に必要な相手に指示や報告をする感じです。
使い方の例
関連情報
- Queued Message Handlerをよりうまく使うには ～メッセージキューの作成～
- Queued Message Handlerをよりうまく使うには ～ユーザーイベントの活用～
- Queued Message Handlerをよりうまく使うには ～メッセージキューの破棄～
- Queued Message Handlerをよりうまく使うには ～エンキュー～
Delacor Queued Message Handler (DQMH)
QMHではすべてのWhileループが対等な関係になりやすいので、Whileループが多いと収拾がつかなくなることがあります。そういったときに、全体を統括するリーダーを配置したくなります。それを可能にしたのがDQMH…だと私は思っています。各Moduleがいて、Moduleを呼ぶLauncher VIがいる形です。Moduleはそれぞれ自分の仕事をしつつ、Launcher(にいるイベントストラクチャ)にBroadcastしたり、LauncherからのRequestに対応したりします。司令塔がいる感じですね。
使い方の例
Actor Framework (AF、アクターフレームワーク)
リーダーだけでは足りない場合、階層構造を作る必要があるかもしれません。例えば、組織の統括責任者とファイル作成の担当者の間にファイルを扱う部門だったり、計測機器を取り扱う部門だったりが必要になるかもしれません。…まあ、イヤですけど。そういったとき、DQMHは階層構造をとるようなものではないですが、AFならActorクラスをネストすることで階層構造を作ることができます。…何世代もネストするようなAFのプログラムを作ったことはないですが。
使い方の例