Abort or Emergency stop button on LabVIEW User Interface?

[binpersonl]

Dear all,

Is it possible to create an 'Abort' or 'Emergency stop' button on my LabVIEW program user interface? The function is similar to press the "abort execution" on LabVIEW toolbar?

We are controling some motor movement, we want some Emergency stop in case motor reaches the end limits.  Can I put a button whoes function is similar to press the "abort execution' on LabVIEW toolbar?

Thank you very much!

[perhult]

If you want to stop your motor I suggest you deal with it by ...eh... actually stopping your motor! Not by "emergency stopping" your vi.

How depends on how your application is built up (post your vi!). But if you are controlling equipment such as a motor you either want to have no inner loops that takes time to complete, or a method of stopping inner loops that takes time to complete.

[crossrulz]

1. Have a really well layed out State Machine so that you can constantly check the E-Stop condition and do a proper shutdown.

2. E-stops really need to be done in hardware (BIG red button that cuts power to the motor would be the first choice).

[binpersonl]

Thanks, I just need a button which is similar to "abort execution" on the toolbar of LabVIEW.  For users which is not familiar with LabVIEW, they may not know the "abort execution" button on the toolbar, so I prefer to put a button on user interface with similar function.

[crossrulz]

---

@binpersonl wrote:

Thanks, I just need a button which is similar to "abort execution" on the toolbar of LabVIEW.

---

For safety reasons, you do NOT want to use the Abort Execution.  You have to put your hardware into a known safe state.  Otherwise you could be killing your program, but you are in a state that leaves the motor running.  Not at all what you want.  Again, you need a good state machine that can handle an abort situation to properly put the system into a safe state.

[binpersonl]

---

'Abort Execution' is what we need right now. We have hardware emergency stop to stop the motor running. We just need a software emergency stop button to stop all the unfinished and unwanted tasks in LabVIEW program.

Thanks.

@crossrulz wrote:

For safety reasons, you do NOT want to use the Abort Execution.  You have to put your hardware into a known safe state.  Otherwise you could be killing your program, but you are in a state that leaves the motor running.  Not at all what you want.  Again, you need a good state machine that can handle an abort situation to properly put the system into a safe state.

---

[natasftw]

The abort option is NEVER "what you need" in a finished application.  It's there to allow you to get out of problems in the development environment.  Imagine what you'd do without it if you accidentally created an infinite loop.

If your architecture is in a place where you can't easily add a check and stop the motor from moving based on that, you'll want to re-think what you're doing.  What you need right now is to stop using bandaides to fix actual wounds as sooner or later your application will bleed out.  It's better to fix it now rather than down the line.

As others have pointed out, hitting that abort at the wrong time can leave your motors running.  If your entire goal is to ensure the motors don't go beyond their limits, wouldn't it be a bit awkward to teach your users to push something that can cause them to continue pushing?  Really, why aren't you just adding limit switches into your hardware setup and reading them in your software to remove your user from this all together?  That way, the motors are automatically stopped without relying on your users to notice and hit the button.

You originally asked a question.  We've tried to answer.  It's very difficult to tell you how to modify your code to allow the stop button to perform the task you'd like without having any idea of what your code looks like.  In most cases, it'll be trivial to make this change and get the application to stop.

[binpersonl]

'Abort execution' seems the easiest solutions to our problem right now. My question is actually that "can we realize 'abort execution' function in user interface"? Maybe I should not say anything about motor to diverge from this question.

Limit switches is not the solution to our problems. Our goal is to abort the program in some situations. Our data acquisition process is lengthy and time-consuming. We do need to abort the program in the middle if we find the data is not what we want instead of waiting the program to finish in a couple of hours later. We want to be out of the program (events, loops, sequence etc), not just the motor.

natasftw wrote:

The abort option is NEVER "what you need" in a finished application.  It's there to allow you to get out of problems in the development environment.  Imagine what you'd do without it if you accidentally created an infinite loop.

---

[Blokk]

"We do need to abort the program in the middle if we find the data is not what we want instead of waiting the program to finish in a couple of hours later."

You clearly use a wrong design for your application, since you do not have the option to abort/stop ongoing DAQ/data processing in a short time and in a sane way. Never create code or sequences which execute for long time without the chance you can stop them in a programmatic way! Always split up calculations/DAQ into smaller parts. I guess your code has also plenty of Flat Sequence structures?

If you use a proper State Machine, you have the option to properly Abort/Stop in a short time and at any time (including stopping all hardware/interfaces in a sane way)! If you do not program your application in this way, you are doing it wrong. Right now you are looking for some fix to something which is inherently wrongly designed.

I really hate to give "bad practice" advice, but anyway, you wanted...You can use the "Abort VI" invoke node: http://digital.ni.com/public.nsf/allkb/4B2CAA3159737AFD86256F2B00788A79

But this neither will help you, if your design is so bad that for example you put long executing code in your Event structure case(s). If your GUI is locked up, you cannot fire this "Abort VI" from your Event loop.

Or you could create a parallel While loop with an Abort button connected to a Case structure with this invoke node inside (plus like a 100 msec Wait in the while loop, not to burn your CPU)...

[binpersonl]

---

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? 

There are so many LabVIEW programs examples doesn't use state machine, so I haven't use state machine a lot either. Again, thank you for your advices. 

@Blokk wrote:

"We do need to abort the program in the middle if we find the data is not what we want instead of waiting the program to finish in a couple of hours later."

You clearly use a wrong design for your application, since you do not have the option to abort/stop ongoing DAQ/data processing in a short time and in a sane way. Never create code or sequences which execute for long time without the chance you can stop them in a programmatic way! Always split up calculations/DAQ into smaller parts. I guess your code has also plenty of Flat Sequence structures?

If you use a proper State Machine, you have the option to properly Abort/Stop in a short time and at any time (including stopping all hardware/interfaces in a sane way)! If you do not program your application in this way, you are doing it wrong. Right now you are looking for some fix to something which is inherently wrongly designed.

I really hate to give "bad practice" advice, but anyway, you wanted...You can use the "Abort VI" invoke node: http://digital.ni.com/public.nsf/allkb/4B2CAA3159737AFD86256F2B00788A79

But this neither will help you, if your design is so bad that for example you put long executing code in your Event structure case(s). If your GUI is locked up, you cannot fire this "Abort VI" from your Event loop.

Or you could create a parallel While loop with an Abort button connected to a Case structure with this invoke node inside (plus like a 100 msec Wait in the while loop, not to burn your CPU)...

---