I'm a LV newbie with 30 years of embedded SW engineering experience. I've been researching how to execute shutdown code when a top level VI ends. I've found numerous examples but all of them are horrendously complicated. My gut tells me that such a simple design pattern shouldn't be so compilicated.
My app is a high voltage control app that needs to disable all HV control points when the SW ends. My VI code is running in a while loop with a stop button that causes loop exit. I can easily accomplish my requirement programmatically with a flat sequence that executes after the main loop ends. The flat sequence technique doesn't work when the user clicks on the abort button from the Front Panel tool bar nor does it work when the user clicks the application shutdown button (the X button) when running the app as an exe.
Can somebody please point me to a simple technique and example code that can show me a lean and elegant way to accomplish my task? It doesn't have to be an obvious solution (for example a watchdog induced shutdown seems simple enough).
Thanks - John Speth
Solved! Go to Solution.
You could use a statemachine architecture that, upon clicking the stop button, calls a shutdown state to clean up all of your references, etc. Without seeing your existing architecture, it's difficult to recommend something that would work for sure. I really like using the JKI statemachine because it already has code for starting up and shutting down an app, whether a VI running in development mode, or an EXE on the end user machine.
You could use event structure to detect the front panel Close X button event and handle the exit process how it should be.
-Simply avoid placing abort button (you can uncheck the show abort button in VI properties in Source file settings during exe creation) and give only stop button.
The flat sequence technique doesn't work when the user clicks on the abort button from the Front Panel tool bar nor does it work when the user clicks the application shutdown button (the X button) when running the app as an exe.
The abort problem is a hard stop, the common example is crashing into a tree to stop your car. This will stop program wherever it is, you cannot initiate a proper shutdown sequence.
As others suggested you can use a state machine for the proper shutdown sequence when the window X is closed. I do not remember where I read it, but I believe, that when you have an EXE you want to close the window last. When running in the LabVIEW IDE it is possible to close the window and have background processes still running and shutting down properly. For Windows EXEs, once the window is closed the applicatioon stops along with any unfinished processes.
1. Put this code in a VI:
Invoke that in your top level VI like this:
You don't mention what target you are running the VI on. If a PC, then in addition to the abort button and the upper right X, there is the task manager and the PC simply being turned off or losing power.
Both the Abort button and the upper right X can be disabled. The upper right X can also be captured with an Event structure.
To disable Right Click on the VIs icon. Then select VI Properties. Select Window Appearance from the category drop down. Click on customize. In this final window you can select how the VI looks when it is running. The "Show Abort button" when unchecked will take away that pesky abort. "Allow user to close window" when unchecked will grey-out the upper right X.
Neither of these do a thing for the task manager or power loss.
Playing around with window appearance can make things hard to debug. For instance if you code goes off in an infinite loop and the abort and X are gone, now what? (Task manager when in the IDE will take out all of LabVIEW, not just the runaway VI.) Similar for modal forms. These are things you set at the end of development and then test in the binary.
Thanks Paul for your excellent solution. It works great. It took some studying to fully understand it. Even more studying to get LV to bend to my will.
I'm surprised NI hasn't standardized a simple solution to this application problem.