Initialisation with wait for user input

[hutchforth]

Hi all, 

I'm not new to LabVIEW (Ex NI CLD), but I am very new to DQMH. I'm very impressed with the tools but I'm definitely still in the stage of trying to wrap my head around it and learn best practices. I'm creating a module for a bit of hardware that requires manual user confirmation as part of the initialisation process, e.g.

• Caller requests startup / initialisation of hardware through modules public API
• Init step 1 completes
• User must confirm before proceeding to step 2, user confirms on caller UI
• Init step 2 completes
• User must confirm before proceeding to step 3, user confirms on caller UI
• etc. 

I was wondering if anyone had tackled anything like this before within the DQMH framework and could offer any suggestions. I had considered the module sending a request to the caller and waiting for reply, but that would lock up the module which doesn't sound great to me! 

Alternatively maybe I should be handling this entirely on the caller, and then just making requests the module for the individual initialisation steps? 

I could probably find myriad ways to "fudge it" into working but I wanted to try and understand what a good way forward would be from a DQMH design perspective. 

Thanks in advance! 

Hutch

[Ozfarmboy]

You can do it two ways:

1) If the hardware module is just driving hardware, and it doesn't need to know if the init process has completed, then your application level code would be responsible for sequencing the process, ie. prompting the user.  This is how most traditional sequencers work. 

However this may backfire if the user is able to bypass the application level code (for instance just run via the API Tester), and run steps without waiting and potentially cause damage.  If this is the case then you may want to consider option 2:

2a) The hardware module itself manages the user prompt dialog.  This could be at the conclusion of the Step 1 MHL case, and then Step 2 MHL Case, etc.  Problem is then you'll more than likely exceed your timeout if it's a request and wait for a reply.  You could just make it a request, because the dialog will block any further actioning (the next steps will just be queued up).  But then what if init step 1 failed and you don't want to go any further.  Then you'd have to flush the queue.  Can get a bit messy. So option 2b...

2b) If each individual init step is not required to be called by the application level code, then the better option is to create a mini state machine within the Init MHL case, to carry out the entire init process in one MHL case.  Within the MHL case, create a while loop based state machine, that steps through each init step required. You need to keep an eye on the Stop Module event in case the system is shut down as you go through each step. As per above, you may want to either to make the Init case a request OR round trip, as opposed to a request and wait for reply. 

[joerg.hampel]

---

@hutchforth wrote:

Alternatively maybe I should be handling this entirely on the caller, and then just making requests the module for the individual initialisation steps? 

---

This one sounds about right to me - caller sends requests w/ replies.

If the individual init steps take longer than a few seconds to finish, I would suggest a more asynchronous approach where the hardware module immediately replies to the caller (basically saying "yes I will start the step") and then broadcasts once it's finished. That way, the caller is not blocked waiting for the reply. You could for example let the user cancel the operation without being stuck waiting.

Edit: Chris beat me to it.

[joerg.hampel]

---

@Ozfarmboy wrote:

create a mini state machine within the Init MHL case

---

...and as always I will suggest going for a proper state machine instead 🤷‍♂️

[hutchforth]

Hi Joerg and Chris, 

Thank you both for your input, that's very helpful, I will continue to give it some thought. 

In the instance I had many modules with a user interacting via some main UI I had envisioned the following:

• Module is responsible for waiting on input for next stage
• Module enters some state like "Awaiting user confirmation"
• On the main UI, some panel for the module will indicate the status of the module is "Awaiting user confirmation", this wouldn't be a popup, maybe I would just flash an indicator or something and have some associated status message...
• User would press a continue button on the UI (which is only enabled in the case that the module is awaiting confirmation)
• Module would then continue its process. 

Unsure if you see any obvious holes in that, to my mind it seems reasonable just might be a bit awkward to program, and at this point I'm trying my best not to build on poor decisions as I start my DQMH journey 😉

[Ozfarmboy]

Seems ok.