Alternatives to event structure for equipment control with UI on front panel

[ReklawLeinad]

Hello,
I'm writing some LabVIEW software to monitor, measure, and control a bunch of lab equipment to perform some tests with it. In essence, there are four main things I need to achieve with the code:

• Continuously monitor and display several digital inputs from a DAQ card, including alarms and warnings. 
• Measure analog signals from pieces of equipment like photodiodes and display them in graphs.
• Display a user interface for running several pre-defined tests and controlling variables on the equipment.
• Shut down the equipment safely once the above loops stop either through user input or an alarm.

I'm fairly confident that the first two bullet points can be achieved by two parallel while loops which monitor the equipment status and measure the data at different rates (faster for the monitor loop to pick up alarms and stop the code when necessary).

However, I've been trying to suss out the best way to manage the controls on the UI and running the pre-defined tests. I was thinking of using an event structure within a third while loop, but I'm not certain this is the best option. In this case, there would be several buttons or controls which trigger "Value change" events and run their respective code. The problem is that some of these predefined tests might take several minutes to run, and have while/for loops inside them as well. While these tests are running, the stop button and any errors for the program should still function and safely exit and shutdown the VI, aborting the current task. But having done a bit of research, it seems like event structures aren't supposed to contain long-running pieces of code. Is that correct, and what would the best alternatives be?

I've attached a mock-up of the kind of structure I'm looking at at the moment, but let me know if I need to clarify anything.

[crossrulz · Accepted solution]

I suggest using a State Machine architecture for your UI loop.  One approach I have seen here is to have the state cases inside of the timeout case of the Event Structure.  I have also seen a specific state to hold the Event Structure.  Play around with them and see what makes sense to you.  But the idea is that you do not have long things happening inside of any event case.  Instead, you call states in a specific order, possibly even repeating states.  The challenge is to handle the events in a reasonable amount of time while also not interrupting your test sequence.

[ReklawLeinad]

Thanks for getting back to me so fast. So, I've had a crack at it, and what I've got is that there would be a case structure, with "Init", "Idle", and some "Task #" cases. On the first run, it would start with "Init"-"Idle". "Idle" then contains an event structure to wait for a specific button press and then run the associated task. For shorter tasks that only need to run once, it would just transition to "Idle" after running it, otherwise it might have a more complicated sequence or - in the case of the example - would run for a set time. This way, it should be running the loop frequently enough to query the stop button in the outer loop in good time. Does that seem like a better implementation than originally? 

[crossrulz]

It looks like you are on the right track.