DQMH use case in Japan

[Tepig]

日本における、DQMHのユースケースや、「使ってみたいけどよくわからない」など、DQMHに関するご意見を募集しています。

DQMHとは？

DELACOR 社の "D" が冒頭に冠された、LabVIEWのリファレンスデザインです。

Queue Message Handlerが基本となりますが、複数モジュールの並列実装やモジュール間通信等、

複雑なアプリケーションが必要とする機能を容易に実装できます。詳細はこちらをご覧ください。https://dqmh.org/

DQMHをベースとした拡張機能も充実しており、以下のようなパッケージも提供されています。

• DQMHの開発を容易にするUI -- Panther Dashboard for DQMH by PantherLAB
• TestStandへDQMHを適用 -- TestStandifier for DQMH by Neosoft Technologies

お伺いしたいご意見

DQMHに関する内容でしたらなんでも構いません。実名、アカウント名お任せします。

• DQMHを使ってみたい
• 開発で使っている実例
• フィードバック
• Q&A

背景

先日開催された日本のLabVIEWイベントから端を発し、Sergioを介して Hampel Software Engineering の @joerg.hampel より、
日本におけるDQMHの状況について知りたいと連絡を受けました。
LabVIEW Champions Member Profile - Joerg Hampel

ここで頂いたコメントはJoergに伝わり、次回ユーザー会の参考とさせて頂きます。

是非忌憚のないご意見をお知らせください。

[J.H.Watson]

DQMHは優れたアーキテクチャで、サポートツールも便利だと思います。
使い始めるにあたっての最大の障壁は言語だと思います。日本語の説明書や動画がありません。アーキテクチャの理解には詳細な説明が必要です。ツールを使う前に「シングルトンって何？」でつまづき、あきらめてしまいます。

私もDQMHを採用していません。ただし顧客がコードを修正したいという場合に限り、LabVIEWに標準で付いてくるQMHを使います（DQMHはこれの拡張版だと認識しています）。顧客が目にするアーキテクチャは公開されているものでないといけません。

普段は自作のQMHライブラリを使っています。LabVIEW7.1時代から使い続けているためコード資産が大量にあります。ほとんどの新規プロジェクトは過去のプロジェクトをコピーして改造することで対応でき、不自由は感じていません。

[yokohama_turkey]

DQMH：未使用（インストールしたが英語ドキュメントが読めず挫折）

普段使うフレームワーク：LabVEW標準のQMHを参考に作った自作QMH

以前、JKIステートマシンを使うためにJKIの有料のトレーニングコース（英語）を購入しました。

自分は英語ができないので、コース動画で表示される説明テキストを翻訳サイトに入力し、

日本語に置き換えながら理解を進めましたが、それなりの時間と労力が必要でした。

DQMHに興味はあるのですが、現時点では英語の資料をコツコツと翻訳して理解できるまで

時間と労力を注ぎ込むのは難しいと感じています。

下記のTom McQuillan さんのビデオに日本語字幕（自動翻訳でなく、ちゃんと意味が

わかるもの）が付くとDQMH理解への取っ掛かりになる気がします。

「https://www.youtube.com/playlist?list=PLmF-6jvwRvVOpNdPcRzskvnGbW79ug6AZ」

[GRE_]

DQMHを使用して製品設計の妥当性確認のためのリアルタイムテスト用の通信モジュールを開発したことがあります。
このモジュールは、WindowsとLabVIEW RTのアプリケーション間でコマンドや測定データをやり取りするゲートウェイとして機能します。
モジュールの開始と停止は、TestStandのシーケンスによって管理されます。
このモジュールは、テスト開発者やオペレータがほとんど注目を払う必要がない、バックグラウンドで実行されるシンプルなサービスとして動作します。

この開発でDQMHを使用することで、いくつかの利点を実感しました。
まず、DQMHモジュール内にリソースが完結されるため、モジュールとTestStandのシーケンスの間に明確なデカップリングが実現されます。
また、フレームワークが生成するテスト用コードを利用することによって、モジュールを完成したアプリケーションに統合する前に、単体で簡単に動作確認ができます。
さらに、VIサーバプログラミングを抽象化することで、フロントパネルの表示・非表示、再入可能・非再入可能、同期・非同期のVIを扱う際のハードルが低くなります。

DQMHの内部仕組は、最初は複雑に感じるかもしれませんが、その詳細をすぐ把握していなくても、有用なフレームワークです。

今後のプロジェクトでも、DQMHを検討したいと思います。