DQMH Getting started CML Example

[nikvl]

Hi all,

I've recently started trying to learn and get into DQMH (that said, having never learned the regular QMH). I've watched various videos and other documentation and am currently looking at the sample project which is shipped with LabVIEW.

There's this piece of code that I'm not sure what it does, and I would greatly appreciate if someone could tell me or point out the resource for the information. When the user event of Start Acquiring is triggered a message is sent to the MHL, which then sends a message to the helper loop (HL) to "wake up" and start acquiring data. Back in the MHL, the information of the HW ID and error is put into the Wait Notifier (see part circled in red in the diagram). What does this do or go? Where does the Notifier broadcast this or who calls this? Doesn't the HL already obtain this information from the Data wire?

Also, I'm curious about what the white triangles in the pink input box of the data cluster typedef (and also appears in the blue input for the timeout) into the case structure and/or event mean? It's not a sort of coercion dot, is it? When you fork a new wire from it, it doesn't automatically appear.

Thank you in advance.

[UliB]

---

@nikvl wrote:

Hi all,

I've recently started trying to learn and get into DQMH (that said, having never learned the regular QMH). I've watched various videos and other documentation and am currently looking at the sample project which is shipped with LabVIEW.

There's this piece of code that I'm not sure what it does, and I would greatly appreciate if someone could tell me or point out the resource for the information. When the user event of Start Acquiring is triggered a message is sent to the MHL, which then sends a message to the helper loop (HL) to "wake up" and start acquiring data. Back in the MHL, the information of the HW ID and error is put into the Wait Notifier (see part circled in red in the diagram). What does this do or go? Where does the Notifier broadcast this or who calls this? Doesn't the HL already obtain this information from the Data wire?

Also, I'm curious about what the white triangles in the pink input box of the data cluster typedef (and also appears in the blue input for the timeout) into the case structure and/or event mean? It's not a sort of coercion dot, is it? When you fork a new wire from it, it doesn't automatically appear.

Thank you in advance.

---

The Wait Notifier Reference is part of the Acquisition lib API "Start Acquiring". Who ever calls this API-VI is receiving the payload over the notifier reference (In this example the VI is called in "Test Acquisition API" and in Main.vi of CML UI). "Start Acquiring" is not a simple request but a request and wait for reply message.

The white triangles shows that the tunnels are "linked tunnels". One input tunnel is linked to an output tunnel. If you create a new case the tunnels will be automatically connected. The possibilities are in the right click menu of an output tunnel.

[nikvl]

Thank you for your quick response!

I suppose this leads to the next question, what purpose does a Request and Wait for Reply message serve? I read that so that it's for synchronous processes but I'm not quite sure what that means. Can you perhaps give a concrete example for its use? And why would one have a "request and wait for reply" message instead of a roundtrip? Wouldn't it be useful to also need to broadcast the reply if a wait for reply exists? (whether it was a fail or success, for example when trying to establish connection to hardware). 

[UliB]

---

@nikvl wrote:

Thank you for your quick response!

I suppose this leads to the next question, what purpose does a Request and Wait for Reply message serve? I read that so that it's for synchronous processes but I'm not quite sure what that means. Can you perhaps give a concrete example for its use? And why would one have a "request and wait for reply" message instead of a roundtrip? Wouldn't it be useful to also need to broadcast the reply if a wait for reply exists? (whether it was a fail or success, for example when trying to establish connection to hardware). 

---

Well, I would say it is as always: It depends on the use case.  How does one design the messages and the reactions to the messages?

There are (at least) two differences between request and wait for reply and a broadcast which are obvious:

- You get the data of interest right at the place where you called the API message, you don't have to go through EHL and you don't have to handle it in a different MHL case. You can work on the data right away.

- Only the calling code gets the data of interest, other modules will not be affected.

An other question is: How did you layout the module structure? 

Does one module have only one listener or multiple? If there is only one listener then you do not need an additional broadcast when using request and wait for reply.

I don't have a real world example. What I often have are broadcasts which sends some data only when this data has changed. In my latest project I also can start the module testers during the execution of the application. If the testers start they don't have the latest data and would need to wait for a broadcast to get the latest data. With a request and wait for reply they could get the data and all other modules would not need to handle the broadcast. (I do not say that I implemented it this way.)

But as I said: No real world example and it depends.