Abort Button

[pete_dunham]

On my current team past LV programmers have always left abort programs in the test program

Team members in the lab who use and evaluate our GUIs and programs are on my back about hiding the abort button and having a proper STOP button. (Some people don't like change).

This is more a fun argument, because I am the one controlling this feature...but I want to officially end this spar. I thought fellow LAVAiers (???) could do the heavily lifting for me and bring peace back to the LV world.

Without getting into the nitty gritty of using development setups as tester setups (the VIs never got pushed to exes), I am looking for an arsenal of reasons to end this argument.

(1)We are using high voltage power supplies... so SAFETY has been my number one argument.

I also found from ni.com:

Provide a stop button if necessary. Do not use the Abort button to stop a VI. Hide the Abort button. Details

The Abort Execution button stops the VI immediately, before the VI finishes the current iteration. Aborting a VI that uses external resources, such as external hardware, might leave the resources in an unknown state by not resetting or releasing them properly.

[Shaun Hayward]

The biggest one, especially with safety is that the Abort button will not carry out any proper shutdown routines - your application is stopped dead. In constrast a "stop" button, would property shutdown your hardware etc, making sure that the system was left in a sensible/safe state. In orhter words - abort could leave your HV on whereas stop would make sure it is turned off.

Edited August 10, 2010 by Shaun Hayward

[crossrulz]

Shaun hit the big one. You need to properly shut down your system: turn power supplies, function generators, DIO, etc. off, reset other equipment, close out references and handles. The abort button will not do that. I have troubleshot a program where someone hit the abort button and ran again and wondered why the DIO port was not available (because it wasn't released from the previous run!).

My experience, however, is mostly with non-LabVIEW people as my user and 99.9% of the time they do not see my giant Stop button (even though it is in the top right corner) and go straight for the Windows "X". If you don't handle this properly, the VI is still actually running even though you don't have a front panel. This will lead to a similar problem as just aborting. So I don't use Stop buttons anymore and just use an event structure and the "<This VI> Panel Close?" filter event. I discard the event, close up everything properly, and then shut down (if needed).

[smenjoulet]

Ditto Shaun! Ditto crossrulz!

I can't echo enough these sentiments and the recommendation from NI to properly exit programs using a Stop button or some other exit mechanism.

If...

1) You can't make them see the value in this and they still complain, and

2) crossrulz's suggestion of using Windows "X" window close button is not a good enough compromise for them (FWIW, I like to implement a Stop button and handle the window close event)

then you could always resort to trickery and skullduggery...

Implement some button that look just like the LabVIEW IDE buttons. Hide them when the VI is not running and show them when running.

Really, you just need to educate them to the potential hazards of using abort and that is why you don't show it.

-Scott

[PaulG.]

Dittos dittos dittos. Abort prevents the remaining code from completing, including any safety shutdown routines, file closings, power-downs, etc. That is all the ammo you need. Period.

[Ton Plomp]

And maybe the most impressing one, it could crash the VI and LabVIEW and that might cause a VI-file corruption....

I know NI is working hard to prevent those things to happen, but once in a while (once a year) I see this happening to a colleague who refuses to use an event structure...

Just make you don't just hide the toolbar, also disable the abort button (other wise ctrl-. will still work).

Ton

[Cat]

I have quite a few programs with both Abort and Stop.

Abort means "halt whatever you're doing, cleanup, and return to idle state to await the next command".

Stop means "halt whatever you're doing, cleanup, stop the program, and make it go away ".

If this is applicable in your situation, you can give them both.

[Tim_S]

The Abort Execution button stops the VI immediately, before the VI finishes the current iteration. Aborting a VI that uses external resources, such as external hardware, might leave the resources in an unknown state by not resetting or releasing them properly.

An unknown state of the hardware can leave it unaccessible until you power cycle the equipment. The example that comes to mind is a counter/timer card where an aborted VI can leave the counter occupied as the task was not cleared... solution required rebooting the PC.

You could argue safety regulations and standard industry practices without much effort. And you could always include removing them in ISO 9000 proceedures.

Tim