How to control process with DQMH?

[1984]

Hi,

not the best phrased question, I was unsure what would be the best name for this topic, but here is the explanation what I'm thinking about:

Traditionally LV uses the dataflow model which is like this: (ignore the fact that in this case opening and closing is not strictly neccessary):

In this example (2) can't start its execution unless (1) is finished and (3) can't start until (2) finished. Thats very strightforward and easy to control a process with. If I need to close 3 valves in an order then I just connect them with wires and we are good assuming that the valve control VIs wait until the valve is closed. This is what I'd call a blocking VI from here. It means it doesnt just initiate something, it really waits until the thing happens. Like when in DAQmx you read samples, the VI block the execution until the right number of samples collected or a timeout occured.

Using blocking VIs certainly have disadvantages, but also have the huge advantage that it is really easy to follow the order of execution. I'm unsure how to create something like this with DQMH as in DQMH everything happens asynchronously, so when I launch one of its requests then I really start something running in parallel in the DQMH main.

Initial ideas

1. set the timeout of the module to something high and let the control and readback happen in the MHL. By this the request VI becomes blocking, but at a huge price: the DQMH module can't process new requests (eg: emergency stop) until the blocking process is completed and I guess that could clog the messages queue. So this looks a bad idea
2. Move the blocking process to a helper loop of the dqmh main. If possible this looks even worse as then the request VI will not block the execution but again we have something in the dqmh main which runs for a longer period.
3. Create a wrapper around the dqmh request: create a subVI which has the DQMH request to start the process and then:
   1. use a loop which reads the internal state of the module to see if the process is over. The bad thing about this is that in this case I'm flooding the module with requests
   2. run the request and create an event structure registered to the broadcast sent when the process is finished plus the stop module. Also it could have a timeout so if the process can't finish in time we'll know it

Even the third option has issues as much as I understand and as you probably figured I'm struggling verbalizing the problem itself. I hope you got my point though and have some advice for me.

Thanks!

(We have fair amount of DQMH modules already, but they are responsible for things really can be executed as async (eg logging, sending mails, handling user login / logout etc. Now we have a new project and I'd like to understand if we need to go with the traditional way or if there is a better approach)

[joerg.hampel]

While it might not be the best solution to concatenate three simple VIs, a state machine is an invaluable helper if you're looking at larger or more complex scenarios.

For us here at HSE, our HSE State Machine template would be the answer to your question/requirement. 

[FireFist-Redhawk]

Another option is: set the Wait for Reply to False in the Request that is going to be blocking, and then have the event structure set to look for the broadcast to then enqueue next steps in the test sequence. Here, I am doing that with reading a Picoscope and then looking for the broadcast to process the data and decide if that's the end of the test or not. Sample size is set low for testing, but once finished it will be a combination of motor RPM and polling speed which will usually end up being a 2 minute poll that grabs millions of data points. But in that 2 minutes, a Stop button could be pressed by an operator to make that broadcast worthless when it does come.

Spoiler

[drjdpowell]

Your initial idea #1, blocking request-replies, is actually the best option a lot of the time.  If you have a complex 10-step process that is executed in under 50 ms, and "emergency stop" can afford to wait 50 ms, you are much better doing things clearly and simply, rather than the complexity of any of your other options.

[1984]

Yes sure, if the steps are super quick then they can be in the MHL. But in my case most of these "blocking" steps (eg collecting samples from a DAQ device) could take seconds.

[ChrisFarmerWIS]

Option 1 - we have done this plenty of times at WiS.  You can have a mini state machine (a sub-VI with a while loop and case structure) running within a single MHL, whilst also monitoring a stop event (using a separate register for events for the MHL loop) and checking this within each iteration of your mini state machine.

Option 2 also works for more complex control situations.  See Joerg's suggestion aboe.

I wouldn't do Option 3.