How to perform correctly time-related steps with a Sequence Engine using DQMH Requests?

[maurizio.bollini]

Consider the scenario with 3 DQMH module.

Module 1 is a Sequence Engine - it is a loop on an array of "steps"; each case is a Request to Module 2 or Module 3.

Module 2 is an I/O module which send and receive commands to an electronic device on the serial port.

Module 3 is an I/O module connected to a DAQ.

A command on Module 2 can take a variable time (up to 4 seconds) to complete.

A command on Module 3 is fast as supposed to be with DAQmx VIs.

When "steps" are implemented as DQMH Requests, the timing of each step is not respected by the Sequence Engine because it fires a new request without wait for the completion of the previous step. As consequence, steps becomes partially overlapped, which is wrong.

Question is: which is the best practice to make the Sequence Engine to fire the next step only when the previous is completed with DQMH messaging without adding synchronisation VIs (like notifiers) ?

Regards,

Maurizio.

[ChrisFarmerWIS · Accepted solution]

Hi Maurizio. Use a Request and Wait For Reply, instead of a Request. Ensure you change the timeout value if you think 5s won't be long enough. Also ensure to handle the timeout if you get one. 

[joerg.hampel]

...and if you don't want the Sequence Engine to wait directly at the place where you call the other modules ("up to 4 seconds" sounds like the timeout might become quite long), you could have your I/O modules broadcast when they're finished with stuff, and register your Sequence Engine for these broadcasts.

If your modules are designed in a tree structure, and the Sequence Engine module starts the I/O modules, it would make sense to make them work like this (I/O modules are not statically linked to Sequence Engine module).

Cheers, 

Joerg

PS: Maurizio, on a side note, we'll be restructuring our DQMH templates and libraries. Please get in touch if you want to get involved.

[maurizio.bollini]

Hi Chris - Thanks for your message. I've changed the "Request" to "Request and Wait For Reply" and now the sequence run as expected with correct timing. In addition, it allows me to send the error cluster originated in the I/O module to the Sequence Engine module in order to manage the sequence cleanup on error.

Great!

Maurizio Bollini.

Certified LabVIEW Architect

http://www.met.it

https://www.linkedin.com/in/mauriziobollini/

[maurizio.bollini]

Hi Joerg,

thanks for your message.

Your suggestion is a great idea too. At the moment the Sequence Engine waits for the completion of the step. When the step is completed, a VI to decide the next step is called.

In your design, I can make the next-step-decision-VI in a separate case of the Sequence Engine and call it by a broadcast sent by the other module step. It means that the Sequence Engine is more often in idle and respond to step execution requests and to next-step-decision-VI call.

Thanks Joerg.

Maurizio.

PS: I'd like to get involved in your DQMH templates and libraries. They are both the base of my current ad future designs. I'll drop you an email. Thanks again.

[FabiolaDelaCueva]

---

@maurizio.bollini wrote:

Hi Chris - Thanks for your message. I've changed the "Request" to "Request and Wait For Reply" and now the sequence run as expected with correct timing. In addition, it allows me to send the error cluster originated in the I/O module to the Sequence Engine module in order to manage the sequence cleanup on error.

---

Hi Maurizio,

I am glad your sequencer is working now. Just in case someone else comes to this thread, I want to add that people can convert existing DQMH Request Events to DQMH Request and Wait for Reply using the Tools>Delacor>DQMH>Event>>Convert DQMH Event… tool.

Thanks to Chris and Joerg for helping you out.

Regards,

Fab

[maurizio.bollini]

Hi Fabiola - DQMH Request Events to DQMH Request and Wait for Reply converting tool works great! A true timesaver.

Thanks,

Maurizio.