How to "rendevous" two or more DQMH results ?

[Konan__]

Imagine to have a piece of code "X" (for example a button's click event handler) that send 2 requests, one to DQMH module A, and one to DQMH module B.

As we know, this is all asyncronous, so your event handler will complete, and it won't wait the results from A and B (unless you explicitly create a "request and wait").

So your results from A and B will come in the form of "broadcast event data" that you must be registered for in your event handler.

I want to know how can I arrange the software if I need to "rendevouz" with the 2 results.

I mean, many times it's good to go async, but at some point I can't go on and I need to wait the results.

How this is done in DQMH or Actor Programming?

In classical labview code, this could be done automatically with 2 subVIs. But that is all syncronous.

My question is how to do the same thing with asyncronous DQMH

thanks

[Ozfarmboy]

So you could just make sure you use a Request and Wait For Reply for both Module A and B. 

The calling code calls the Request and Wait For Reply VIs in parallel, and it simply waits (by merging the error wires after) until both are completed before proceeding.

[joerg.hampel]

I'd say it depends on the structure of your application:

• Can you use Request and Wait for Reply instead (or have two nested event structures registered to the corresponding broadcasts)? This would block the structure from which you're calling, obviously.
• Do you have to receive both broadcasts in the same event structure that calls the Requests? You could store on a shift register (or similar) which broadcast already came back.
• What is the piece of code that needs to wait for those replies? Is it a state machine? Then you could trigger transitions in this state machine from the event structure that receives the broadcasts.

This list could go on and on... Without the specifics, I find it hard to come up with a generalised recommendation.

Reading it back, if you would be happy "with 2 subVIs", just add replies to your requests and make these commands synchronous. 

[Konan__]

---

@Ozfarmboy  ha scritto:

So you could just make sure you use a Request and Wait For Reply for both Module A and B. 

The calling code calls the Request and Wait For Reply VIs in parallel, and it simply waits (by merging the error wires after) until both are completed before proceeding.

---

So if at some point I need a response "in line" (like in normal subVIs) it's better to create the "round trip" event, where I have EITHER the "async response model" via the broadcast event, AND the "sync response model" via the (optional) wait for reply (the boolean input)

@joerg

TY for the inputs

Exactly, I am doing mostly test sequences, so a state machine is basically the model.

I am trying to use DQMH to create more "modularized" code, previously I was just using just plain objects that call each other.

For example: if I had to interact with DMM (digital multimeter) I just create a DMM object.

The fact that labview is parallel "by design" via dataflow model (and a VI can be "reentrant") delayed the use of these parallel loops models (DQMH-style).

If I had to use C#, I would have faced these problems much early, because the text language is sequential by design (only recently C# has the async/await magic that is quite tricky though)

I got the archictecture of the helper loop with the state machine inside the timeout, now I am trying to cover some corner cases and caveats that comes with all this asyncronicity.

But at the end you are right, sometimes it's just better to call a simple classic (sub)VI

[drjdpowell]

Not sure how it could be done in DQMH, but this type of problem can be solved using the Scatter-Gather messaging pattern.