DQMH request and wait for reply for instrument control?

[1984]

Hello community,

Do I need to use a simple "request" or a "request and wait for reply" when I control an instrument? I mean if the control function has no returning value / confirmation from the instrument (eg: setting OVP, or turn on an output etc) a request seems ok, but on the other hand the driver VI may return an error which I can capture only if I wait for a reply (eg: the instrument is powered down, connection lost etc)

I feel that by using a request I may miss an error, but by using a ...wait for reply I complicate my code cause then at least I need to return a "success?" boolean which I have to utilize in my main VI.

What would you recommend?

Thx!

[Konan__ · Accepted solution]

---

I feel that by using a request I may miss an error, but by using a ...wait for reply I complicate my code cause then at least I need to return a "success?" boolean which I have to utilize in my main VI.

What would you recommend?

Thx!

---

DQMH encourage async operations, non-blocking.

Having said that, there are cases where you have nothing else to do than wait the data replied from the instrument or whatever module, so in that case a "send message and wait for reply" will make the call like a static subVI call, that is even if your data is processed in another loop, the called VI will stay there and wait the reply synchronously. 

Note that actually this synchronous behaviour (wait for reply) has a timeout that you should handle (dont wait indefinitely or you perma lock your software).

---

@1984  ha scritto:

[....] but on the other hand the driver VI may return an error which I can capture only if I wait for a reply (eg: the instrument is powered down, connection lost etc)

---

This is not correct at all.

You can always capture errors by handling broadcast events (there is built-in error broadcast, you have to register for that, and generate that properly in your sub-module)

[Darren]

For a DQMH module that wraps an instrument driver, I think it's good practice to make every command to the instrument a Request and Wait for Reply for the exact reason you mentioned... any command could potentially return an error. And I agree with Konan... that error will be on the error wire coming out of the Request and Wait for Reply VI, so there's not any extra monitoring of a "success" flag that you would need to do.

[1984]

Now I see... I was unaware that the error cluster wired from the instrument driver to the reply payload cluster in the module's main will appear on the error out terminal of the request VI. Great mechanism, thanks for highlighting it.

This generates the next question though, what is the purpose of the error cluster running thru the bottom of the message handler loop of the main VI? When I create a new "request and wait for reply" event then a merge error node is placed on that error, but I dont get its purpose.

[Darren]

---

@1984 wrote:

what is the purpose of the error cluster running thru the bottom of the message handler loop of the main VI?

---

Other modules may be registered for the 'Error Reported' broadcast of your instrument control module. Those modules wouldn't necessarily be calling the Request and Wait for Reply VI, but they may be interested in errors that occur, and any error that happens in the MHL will call the 'Error' message frame of the MHL, which will send the Error Reported broadcast.