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を検討したいと思います。

[mikiofuku]

DQMH : 小規模なアプリ開発でDQMHを使用しましたが、普段は未使用です。
普段使うフレームワーク：LabVEW標準のQMHを参考に作った自作QMH

DQMHを使うにあたっては大きな障害は感じませんでした。サンプルとDQMHのドキュメントで十分でした。

普段で実装するアプリは実験や研究のために短期間(1年～せいぜい3年)しか使用せず、導入後長期間使われると言うことはありません。
そのため実験や研究に柔軟に対応できるように見通しの良いブロックダイアグラムにしたいので、自作QHM(Queueで通信する複数ループ)を使っています。

DQMHは仕様がきっちり決まっていて長期間メンテナンスをするアプリには有用だと思いましたが「がっちり仕様を決めなくても動く」レベルの実装にはオーバーヘッドが大きい気がしました。そこまでがっちり仕様を決めなくてもDQMHは有用ですが、LabVIEWの宿命かも知れませんがクローンされたVIのデバッグが面倒というのが個人的には気が重くなる点です(何か良い方法があれば教えてください)。

DQMHは非同期にVIを並列実行できるフレームワークとして完備しているので、今後自作QHMにDQHMを取り込んでバックグラウンドで動作するVI部分はDQMHに担当させてもいいかなあと考えています。

[Tepig]

「Clone VIを効率的に開発し運用する」という観点で、DQMHは優れていると感じています。

また、PantherLABなど様々なパートナーがDQMHのアドオンを開発しており、

開発のしやすさ、メンテナンス性、ドキュメントなど (Antdoc)、一からプロジェクトを開発する場合と比べ、非常に効率的に作業ができます。

一方で、多くの場合はQMHで実装が済んでしまうため、DQMHを本格的に使うようなプロジェクトには多く出会えていません。

学習コストも言語のために若干高く、日本で導入する際に費用対効果が十分に見込めるかが心配どころです。
(せっかく学習しても、DQMHを使う必要があるほどのプロジェクトになかなか出会えない。)

[Tepig]

@joerg.hampel

We have received great feedback from Japan users. With the help of a translation tool, you too can read the comments.

While we understand the usefulness of DQMH, we commented that we are using the original QMH,
and that the initial hurdles are high due to the lack of Japanese-language resources.

They also mentioned specific problems they are having, such as how to debug Clone VI.

I would personally like to know what percentage of projects in Japan should use DQMH.

I also feel that it is preferable to know and be able to choose between using QMH and DQMH rather than having to struggle without knowing DQMH.

I would like to talk somewhere about what ideas can be taken for the next Japan User Group Meeting.

[sergiovelderrain]

---

@Tepig wrote:

@joerg.hampel

We have received great feedback from Japan users. With the help of a translation tool, you too can read the comments.

While we understand the usefulness of DQMH, we commented that we are using the original QMH,
and that the initial hurdles are high due to the lack of Japanese-language resources.

They also mentioned specific problems they are having, such as how to debug Clone VI.

I would personally like to know what percentage of projects in Japan should use DQMH.

I also feel that it is preferable to know and be able to choose between using QMH and DQMH rather than having to struggle without knowing DQMH.

I would like to talk somewhere about what ideas can be taken for the next Japan User Group Meeting.

---

On my previous visit to the user group at NI Japan, i talked to multiple developers and it became clear how not having content available in Japanese is impacting us as a community. It was nice to see the positive impact it had when i talked about tools such as DQMH or Antidoc. The language barrier is evident, but i can see this changing very soon.

[joerg.hampel]

---

@Tepig wrote:

@joerg.hampel

We have received great feedback from Japan users. With the help of a translation tool, you too can read the comments.

---

Thank you so much for helping with all this, Yusuke, and thanks to everybody here for your candid feedback. Please continue to help us understand your situation.

I appreciate that the language barrier is a huge one, and I have no good ideas right now for how to mitigate it, other than starting to work with all of you on creating content that is easily consumable for speakers of languages other than English. I think our documentation at https://documentation.dqmh.org is a good starting place, as it is friendly to translation tools.

As for technical boundaries and limitations, I would LOVE (capital letters here!!) to get a chance to discuss these with all of you. I have a very strong feeling that DQMH is superior to the native QMH pattern in many, if not most aspects - especially for debugging cloneable modules - and I would be surprised if I was proven wrong (although that has been known to happen in the past :-p). 

We'll be in touch soon!

[FabiolaDelaCueva]

I second everything @joerg.hampel said

Joerg and I are willing to present at a User Group Meeting. I know that I would be biased as the lead architect for DQMH, it is my baby after all... But Joerg decided to make it the main tool they use at his business. I believe that he could present to you his perspective as a business owner and an Alliance Partner as to why DQMH is his favorite tool in his toolbox. 

I convinced Joerg to be part of the DQMH Consortium because he is committed to the success of DQMH, it is that important to his business.

I was surprised to see some of the comments here, the one that surprised me the most was finding that debugging cloneable modules was hard. DQMH is the only tool I know that makes debugging cloneable modules easier, thanks to the DQMH API Testers. 

Thanks for all your feedback and we hope we can make DQMH more accessible for LabVIEW developers in Japan and elsewhere.

Best regards,

Fab