What happens when you press 'Abort Execution'

[billko]

---

@crossrulz wrote:

What I do is use the Event Structure with a "Panel Close?" filter event.  This way, when you try to close the window, this event will be called.  Since it is a filter event, you can "discard" the closing and proceed to close everything out before letting your VI run to completion (ie all loops have completed and any additional code after said loops are done running).  More commonly, people will have a stop button and use the Value Change event to stop their code in a similar manner.

---

Unless the UI becomes too cluttered, I like to give the user three types of exit choices: menu, button, filtered [x].  (They all do the same thing.)

[JÞB]

---

@timematcher wrote:

Hi, I am facing similar problem (only that LabView does not crash). I want to be able to clear any memory and close any handles as well as running VIs upon clicking the abort button.

It can be immensely helpful as I won't have the need to close LabView every time I do that.

In my case LabView opens sockets which remain open after I click on the abort button. so I would like that not to happen or at least be able to perform some kind of cleanup.

Is there an even that is fired/triggered when abort button is clicked? If there is one, it might be possible to capture that event in an external dll maybe and perform cleanup manually? Can LabView support/admins shed some light on it please?

Thanks

---

Don't click the abort button.  Ed has a nice signature that mentions ... Stopping your vi by clicking the abort button is like stopping your car....by running into a tree! 

Your car may cease forward movement...you could be harmed by unintended effects of Newtonian Laws (Hmmmmm.... They don't even call them "Theories")

Stop Aborting!  (look i'm not trying to bring up Roe vs Wade or stuff tike that but, Abort means "Stop Executing Now!" and no clean-up is done.  Do NOT hit that button unless you know how you have messed up a vi during development.

[alecjcook]

So, when you press abort it kills the app, and then LabVIEW scurries around and does lots of tidying up. It closes off open references, it removes its memory allocation for variable manipulation, along with other little 'tidy up' jobs. My advise is to correctly and programatically close off all your references and program in your own 'stop' button. (LabVIEW goes, but it really doesn't like stopping)

[timematcher]

The real issue is not that I would want to use the abort button. The real issue is, the abort button mimics the same of behavior as would an application crash.

The goal here is the to be able to catch such an event to perform cleanup manually. The goal is not to use the abort button. I mentioned this very clearly in my original post and I say it again. Abort button is the closest thing to an application crash where labview does not close or crash, there are open handles, open sockets and running the application again inside labview would recreate redundant sockets and handles and cause undesired behavior which is a severe challenge during debugging applications crashes.

So, let me try to ask again: Is it possible to catch an even in case of an application crash when working with Labview and 3rd party applications (the closest thing to that behavior being the Abort button), so that manual cleanup can be performed, sockets, handlers and VIs can be closed so that applicaiton can be run and debug again?

Please let me know if the question is not clear or relevant. The goal is not to use Abort button here, I repeate. Its the only thing close the behavior in case of an application crash... (sigh) !

[drjdpowell]

---

@timematcher wrote:

Is it possible to catch an even in case of an application crash when working with Labview and 3rd party applications (the closest thing to that behavior being the Abort button), so that manual cleanup can be performed, sockets, handlers and VIs can be closed so that applicaiton can be run and debug again?

Please let me know if the question is not clear or relevant. The goal is not to use Abort button here, I repeate. Its the only thing close the behavior in case of an application crash... (sigh) !

---

Crash of LabVIEW, no.   But hard stop of a particular VI, due to the Abort button or certain fatal errors like out-of-memory, yes.  Aborting a VI stops that “VI hierarchy”, but not other running hierarchies, such as those started by an Async Call-by-Reference.  And one can use a reference created in one VI hierarchy (closed automatically on Abort) to signal an async-running VI to perform cleanup actions.

[cbutcher]

If you have some sort of configuration file, you can write on startup "valid shutdown = false" or similar and only overwrite it with true once you closed resources.

Then, when your application starts, if the value for that key is still false, you know it crashed/failed to close properly last time.

Would that help?

[billko]

---

@cbutcher wrote:

If you have some sort of configuration file, you can write on startup "valid shutdown = false" or similar and only overwrite it with true once you closed resources.

Then, when your application starts, if the value for that key is still false, you know it crashed/failed to close properly last time.

Would that help?

---

Along the same lines, MS Word has an auto-save feature in case Word crashes.  I put those words in italics because not even an application like MS Word can handle a brutal shutdown by the operating system.  (I think that's what you are asking about, right?  Graceful shutdown after a processor exception or similar event?)  It can't for instance, save a file before exiting, which would be the equivalent of LabVIEW closing all references and disabling the outputs of your equipment.  the best you can hope for is that the next time it is run, the app understands that it did not shut down properly before and take steps to handle that situation.

I think the best you can hope for is that LabVIEW itself can handle it gracefully enough not to have the entire operating system crash.

[rolfk]

If you call external code throught he Call Library Node, then yes there is some sort of event. It is located in the Callback Configuration tab in the Call Library Node. It requires some C functions in the DLL which are specifically written for that use. The Reserve function is called when the Call Library Node is loaded and it can initialize a memory pointer with whatever it wants. The Unreserve function is called when the VI containing the Call Library Node is unloaded. And the Abort function is called when someone hits the Abort button. The Instance Data Pointer all these functions accept as single parameter can then be also added to the function parameters that you call in the actual Call Library Node function. Your function then can store there information about operations it is doing and return control back to LabVIEW while LabVIEW will make sure to call the Abort callback funciton when someone hitst the Abort button. 

All nice and cool but it of course requires specific functions to be added in your DLL and the actual function you want to call has to support this extra parameter. So it's not something you can do for arbitrary DLLs but only DLLs that have been developed specifically with this use in mind. And doing that isn't something for someone who doesn't have serious C programming experience.

It's not likely what you look for. but if the external code is the reason that LabVIEW locks or crashes it's there were you need to fix it. Of course the alternative is to not use the Abort button, which is actually something you should do anyhow. A proper application terminates because of a button or menu on your application that the user selects and which then causes it to properly close and deinitialize anything it opened.

[timematcher]

That is exactly what I was looking for. I have taken over some code in Java to which LabView talks to via a C DLL. I do have access to the source code but really wanted to know what were my options and if at all there existed such events which could be handled inside the C DLL to perform the necessary cleanup.

I might request more information when I head into changing the C code. But for now that is a ray of hope and a a good start, thanks to you! 🙂