Nesting Obtain Request Event Inside Multiple SubVIs of a State Machine

[ESCO805]

Hello, 

I'm new to DQMH and currently have the DQMH State Machine set up inside my start test MHL. This works great however I have a SubVI that will go inside one of the states and has a two minute wait. 

I decided to also have this SubVI register for events so every time it loops (500 ms) it can check if an event was sent to abort/exit. Thus, having a nest of obtain requests three levels in (MHL --> State Machine VI --> 2 min wait VI). 

My question is, am I following best practices by doing this or should I be doing something else? Also, if this is okay how far can this nest go?

[Darren]

Most DQMH developers solve this use case by implementing the state machine in a Helper Loop instead of the MHL. Here's the DQMH Help topic on Helper Loops:

https://documentation.dqmh.org/dqmh/7.0/AddHelperLooptoDQMHModule.html

Note that the tooling for adding a Helper Loop to a module was added in DQMH 7.0, which just released.

[ESCO805]

Okay I see, but this will still lead to my nesting issue for SubVIs within the state machine who may take too long to finish before receiving an exit/abort event. This isn't going to be every state/SubVI just two or three.

I do have two helper loops set up already for power supply monitoring and load monitoring. I will take your suggestion and make another helper loop for the state machine.

Thank you to the DQMH team for making that a feature it has helped me a lot as a beginner, I am using DQMH 7.0.

[Ozfarmboy]

If you have 3 helper loops, you may want to consider whether the power supply and load monitoring loops can be turned into their own DQMH module.

With regards to the state machine, you can monitor the stop event within each state to catch the exit/abort early rather than waiting.

[ESCO805]

I started brainstorming with separate modules at the beginning for each instrument, however I couldn't figure out how to have my launcher/main module initialize all three other modules based off one button. Ideally this is what I would like to do, but I'm not too experienced with DQMH yet.

So when I wrote this initial post I was just trying to stay within one module and use it as an upgraded QMH, but within this time frame I see how I can actually make that happen. Thanks for the suggestion and push to better practices.

Can you expand on monitoring within each state? I think that is what I'm doing by having a SubVI within a state register for events. This works I'm just concerned on if it is the best solution.

[joerg.hampel]

Maybe take a look at our State Machine Template and take some inspiration from it:

https://dokuwiki.hampel-soft.com/code/dqmh/state-machine

[Ozfarmboy]

---

@ESCO805 wrote:

I started brainstorming with separate modules at the beginning for each instrument, however I couldn't figure out how to have my launcher/main module initialize all three other modules based off one button. Ideally this is what I would like to do, but I'm not too experienced with DQMH yet.

---

We create a launch children private event in our highest DQMH module, that is called from the MHL Initialize case.  Then the EHL acts on this event and launches each module in a FOR loop, one at a time.  The order of which module is launched first does matter a little, so we control this via the FOR loop.

---

So when I wrote this initial post I was just trying to stay within one module and use it as an upgraded QMH, but within this time frame I see how I can actually make that happen. Thanks for the suggestion and push to better practices.

---

Time to make the leap to break out of the QMH design pattern!

---

Can you expand on monitoring within each state? I think that is what I'm doing by having a SubVI within a state register for events. This works I'm just concerned on if it is the best solution.

---

So if you've got a state machine VI running within a helper loop, you can keep an eye on the stop event within each loop of the VI.

I would also make sure that your state machine VI is not sitting there with a massive WAIT statement, and that you're looping around the same state waiting for something to change - say once a second. Then you can check the stop event each second, and break out early.