Abort or Emergency stop button on LabVIEW User Interface?

[Blokk]

Thank you for your help.  Say, if the user clicks a button, generates an event to execute a loop. However, he regrets before the event and loop finished, and wants to abort the program. Generally, how to use state machine for this? 

First of all, there should be a dedicated While loop (or module, etc.) with Event structure inside, lets call this the GUI loop. This loop is ONLY to capture user commands from the GUI, and send these commands via a Queue (or other things like Channels in LV2016) to another loop. So this GUI loop does NOT have any code inside which execution takes longer than a few mseconds.

Then, just for an example, you have another While loop with a State Machine inside. This loop can receive commands from the GUI loop via the Queue. Otherwise it does what State Machines do: executes states. There are different subvariations for such State Machine, but one thing usually is common: the state machine has a state or a method to frequently check whether there is a new incoming GUI command from the Queue, like an "Abort ongoing procedure" command.

To be able to do this, this state machine should NOT have any case (state) which executes for very long time (more than a second for example, but actually it depends on your "abort reaction time" requirement, in cases you might want to be able to Abort in 100 mseconds, etc...). So in your "Process" or "DAQ" state you do some of the work, then you check if it has been done yet, if not, you come back to this same state in the next iteration. If you split up the task into chunks, you can abort in a short time, and in a sane way...

[binpersonl]

Thank you. Sounds like multiple-thread, but doesn't often check GUI commands, then come to the next state slows down the DAQ process when you have lots of data points to acquire? 

Thank you very much for your helps, need to go to bed now, will check your replies tomorrow.

@Blokk wrote:

Thank you for your help.  Say, if the user clicks a button, generates an event to execute a loop. However, he regrets before the event and loop finished, and wants to abort the program. Generally, how to use state machine for this? 

First of all, there should be a dedicated While loop (or module, etc.) with Event structure inside, lets call this the GUI loop. This loop is ONLY to capture user commands from the GUI, and send these commands via a Queue (or other things like Channels in LV2016) to another loop. So this GUI loop does NOT have any code inside which execution takes longer than a few mseconds.

Then, just for an example, you have another While loop with a State Machine inside. This loop can receive commands from the GUI loop via the Queue. Otherwise it does what State Machines do: executes states. There are different subvariations for such State Machine, but one thing usually is common: the state machine has a state or a method to frequently check whether there is a new incoming GUI command from the Queue, like an "Abort ongoing procedure" command.

To be able to do this, this state machine should NOT have any case (state) which executes for very long time (more than a second for example, but actually it depends on your "abort reaction time" requirement, in cases you might want to be able to Abort in 100 mseconds, etc...). So in your "Process" or "DAQ" state you do some of the work, then you check if it has been done yet, if not, you come back to this same state in the next iteration. If you split up the task into chunks, you can abort in a short time, and in a sane way...

---

[Blokk]

Thank you. Sounds like multiple-thread, but doesn't often check GUI commands, then come to the next state slows down the DAQ process when you have lots of data points to acquire?

This is a good question. Well, if you use a proper design, no such danger. One possible solution is that, you use a three loop (or 4) structure: 1 GUI, 1 "Message handler", 1 DAQ, 1 Data processing/logging/displaying loop. As an example, have a look at the "Continuous Measurement and Logging (NI-DAQmx)" template from your LabVIEW start window-->Create Project menu. Actually many people dislike this design template, well, it has advantages and disadvantages as well, and it is a bit overly convoluted. But it can give you some idea how to decouple certain parallel tasks in a code, like user interactions from DAQ...

There are many other templates exist, just google for them.

Back to your actual question about what if we need to acquire lots of data points? Well, it is possible to acquire some data points at every iteration, and always check whether there is an incoming "Abort" or "Stop" request to act. Example: imagine your acquire analogue input data using DAQmx, rate is 1 MHz. You can setup your DAQmx task in a way, it will give you 100k data points per 100 msec at every iteration. You send these 100k data points via a lossless Queue to another while loop for further data processing. In this way your data processing/display/logging does not slow down the DAQ loop. Moreover, when the user requests an "Abort" command, the DAQ loop will act in not more than 100 msec! But still, you have a continuous data acquisition...

[Intaris]

---

@binpersonl wrote:

'Abort execution' seems the easiest solutions to our problem right now.

---

It's a trap!

Abort execution only leads to further bad design (not caring about interruptable processes).  Relying on Abort to finish your code precludes you from making the investment in proper design at the beginning (or at least as early as possible).

Abort lures you in with promises of met deadlines and time saved.  It promises to be really helpful and says it wants to spend the rest of its life with you.  Then it moves in with you.  In the beginning, things are great but slowly, "Abort" stops doing the washing up after eating.  Then stops with all housework.  Then is stops even putting its dirty clothes int he hamper.  Then it even stops paying attention to you and instead invites its other cool friends over to watch TV in YOUR living room.

So as you can see, Abort stops everything, but that's not always good.

[binpersonl]

---

Can you provide us some templates for proper design? Thanks.

@Intaris wrote:

It's a trap!

Abort execution only leads to further bad design (not caring about interruptable processes).  Relying on Abort to finish your code precludes you from making the investment in proper design at the beginning (or at least as early as possible).

Abort lures you in with promises of met deadlines and time saved.  It promises to be really helpful and says it wants to spend the rest of its life with you.  Then it moves in with you.  In the beginning, things are great but slowly, "Abort" stops doing the washing up after eating.  Then stops with all housework.  Then is stops even putting its dirty clothes int he hamper.  Then it even stops paying attention to you and instead invites its other cool friends over to watch TV in YOUR living room.

So as you can see, Abort stops everything, but that's not always good.

---

[natasftw]

You're right. There are plenty of examples that don't use state machines.  Some examples are too simple.  Some use more advanced architecture.

But, how many have you seen that can't respond to button presses within 2 hours?  You haven't been building your code based on examples.

This is why we're suggesting you need to take a look at your architecture and why I stated the abort isn't a solution.  Your original question still can't be answered based on what you've given us.  If you're filling your application with sequence structures, as it sounds like you are, the answer is no.  You can't make an emergency stop button.  If you want NI based documentation to support this: http://www.ni.com/newsletter/51735/en/

Two hours of a non-responsive application is pretty insane.  That's not something you ever want to do to yourself.  The solution to your problem is NOT an abort button on your front panel.  It's taking a step back to fix what you've broken.

At a base level, you want code to be:

1) Readable

2) Reusable

3) Maintainable

The code you have now is likely none of the three.  If it's going to process for 2 hours straight, it's likely a mess to read.  It's certainly coupled very specifically to the task and can't be reused.  As you're now seeing, adding anything to the code is a mess.  That's not maintainable.

You'd be doing yourself a service to take a bigger picture look at your code.  You're asking for a way to implement an abort and ignoring any advice that doesn't specifically state how you'd do that as "not your solution."  You're focused on the small picture and are ignoring what this does to your application.  Often when people ask for advice, I ask them to explain why they want to do what they're doing.  More often than not (this case included), you find what they're wanting to do doesn't make nearly as much sense as making other changes.  Do yourself a favor and open up to ideas that are meant to help you long term rather than slap a bandaide on a broken application that eventually is going to need more.  You're delaying the inevitable at your own peril.

[Blokk]

---

@binpersonl wrote:

---

Can you provide us some templates for proper design? Thanks.

---

Did you ever check what LabVIEW provide you? For example via the main window what you see after launching LV,  you can click on: "Create New Project". There are lots of different design templates. Some of them are simpler, some of them are more complex, like the Actor Framework using object oriented (OO) approach...

Here is a list:

http://www.ni.com/product-documentation/14031/en/

You could also have a look at the DQMH template: http://sine.ni.com/nips/cds/view/p/lang/en/nid/213286

This one also uses some OO programming, but you do not need to understand OO in order to be able to use it.

However, if you want to move to proper LV programming designs, I strongly recommend you to first taking some further tutorials/trainings, like the Core 3 and some further trainings (also available online or as classroom courses) --> http://www.ni.com/training/labview/

In order to gain 100% benefit from the available design templates, you need to have a solid understanding in important concepts of LabVIEW, just to mention a few of them: Functional Global Variables (and other type of variables), Type Definitions, State Machines, Synchronisation techniques (Notifiers, Queues, Channels), Dynamic User Events, etc...