LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

how can i be notified when abort execuation button is called

hello, 
i have a program implemented in LabVIEW, there is some script that should be run after finishing this program or terminated.

i can handle one case when the user press stop from the vi, but there are another two cases I can't handle

1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")

2: when the user ends the program from task manager 

 

any idea about handling these two cases?

0 Kudos
Message 1 of 17
(2,194 Views)

Hi Peter,

 


@Peterboshra wrote:

1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")


Simple solution: hide the toolbar! Your users should NEVER see it…

 


@Peterboshra wrote:

2: when the user ends the program from task manager 


Why should your user want to do that?

Have you tried to use an event structure to handle those Application events?

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 17
(2,158 Views)

i am handling the edge cases that could be happened, I should run some program to reset the hardware components to the initial state so I should handle any edge case that terminate the program

0 Kudos
Message 3 of 17
(2,151 Views)

Yes, a deployed application should never show the toolbar. It should not even have a stop button on the front panel, because we already have the [X] in the upper right that is universally known to end a program. To intercept that, you simply need a "panel close?", "application close?" etc. filtering event that discards the event, initiates the shutdown sequence, then closes the program once everything is in order.

 

Killing a process from the task manager should only be needed if the program is poorly written and buggy and is in an unknown state where it no longer correctly runs (deadlock, partial crash, etc.), so trying to handle that in the same program seems like a poor choice. You also need to deal with the possibility that the computer crashes.

 

Maybe you need a hardware safety switch or some independent watchdog program running on separate hardware that pulls that safety switch when an unusual state is detected (e.g. when it stops receiving regular "I'm alive" messages from your program over the network.

 

Of course when the program starts, it needs to correctly initialize all hardware and not assume a defined state. How dangerous is a condition where shutdown is incomplete (deadly voltages? overheating? etc.)

0 Kudos
Message 4 of 17
(2,128 Views)

@Peterboshra wrote:

1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")

2: when the user ends the program from task manager 

 

any idea about handling these two cases?


1. You should NEVER show the abort execution button to the end user.

 

2. There is nothing you can do for this case short of some type of hardware watchdog that can put your UUT into a safe state if the LabVIEW program does not "pet the dog". 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 5 of 17
(2,118 Views)

@Peterboshra wrote:

1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")

The VI can create a queue and pass it's reference to a dynamically started VI. That VI then dequeues a queue element, and that will basically hang forever (because no element is enqueued).

 

If the VI dies for whichever reason, the dequeue stops waiting, and returns an error. The dynamic VI can then take actions.

 

I agree that your code shouldn't do this. However, during development, I like that I can abort my code. And if the code locates dynamic resources, I do want (and sometimes require) that those resources are freed. A dynamic VI waiting for a queue created in the caller does this.

 

@Peterboshra wrote:

2: when the user ends the program from task manager 


The process can't do anything when it's killed.

 

You'd need a 2nd process.

Message 6 of 17
(2,084 Views)

@GerdW wrote:

Hi Peter,

 


@Peterboshra wrote:

1: when the user click on "abort execution from Toolbar", how can I know the user pressed ("note I shouldn't remove this button")


Simple solution: hide the toolbar! Your users should NEVER see it…

Depends on who the users are.  Sometimes I create tools for developers.  In those cases, I leave the toolbar, with the abort button; -- unless I really need to enforce a shutdown.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 7 of 17
(2,052 Views)

FYI Ctrl+. is always available whether toolbar/menu is displayed or not. #TeamNeverToolbarOnUIs Of course I'm lazy and don't turn off toolbars unless I'm sharing/deploying and then I'll turn them off for anything I display. To me that's either valuable real estate or open to causing headaches due to everything else not cleanly closing or orphaning stuff running async so abort usually means I'm going to need to completely close LabVIEW to kill everything off anyway.

 

For OP, it sounds like you want to create a separate program that runs in the background. While the LabVIEW program is running, the LV program can periodically communicate to the other program and then anytime that stops for too long, the background app can run the needed script. There are a bunch of edge cases of how LV code can stop, crash, be aborted, or killed to really do much of anything other than something like a watchdog process.

 

 

0 Kudos
Message 8 of 17
(2,000 Views)

I tried to experiment with the possibility and found out that ending a task from Task Manager is actually the same as clicking the top right close button. If you disable the Abort button and handle the stop with Panel Close? event, you should be good for most use cases.

-------------------------------------------------------
Control Lead | Intelline Inc
0 Kudos
Message 9 of 17
(1,995 Views)

That will be true as long as the application gracefully handles it. If it doesn't close at that point, Windows can kill the process ungracefully. It'll depend on what cases you need to cover and why they're going into task manager to stop the app; presumably because it's hung and not responding to normal close requests.

Message 10 of 17
(1,978 Views)