QUIT LabVIEW.vi works differently in LC8.2

[johnitv]

RE: "QUIT LabVIEW" vi behaves differently in 8.2.  Using (essentially) identical application (*.exe) executes a "QUIT LabVIEW" vi  function, LV 7.x and 8.0 built code behaves as expected, that is:  LabVIEW is completely exited including any and all Front Panels.  The application and all remnenats of all VIs disappear from the desktop.   .....With 8.2, the built application "stops" and the front panel of the top VI remains on the desktop. 

Did something change in 8.2?  What am I missing? 

[smercurio_fc]

Works fine for me. Are you sure you don't have it tied to some logic that checks the "application kind"?

[PLEXSYS]

I am experiencing the same issue. I have a code line that has existed since 6.1 that has behaved normally up until i migrated between 8.0.1 and 8.2. Since upgrading to 8.2, my application now "Stops" instead of "Exiting". I am at a loss to explain why, but three other apps i have exit normally. I have compared every setting between the three that work and the one that doesn't and i am still unable to explain the failure to exit. If you have resolved this issue, or have other insights you can share, please post here.

[tst]

Stupid question - did you try removing the function and putting in a new one?

Also, did you check the documentation for the function to see if it has anything to say about this?

[johnitv]

NI suggested a fix (aka workaround) for my original problem and, it solved my issue. 

To insure the Front Panel gets removed from the desktop on an EXIT (in 8.2), intentionally force a "FP.close" funtion by using "invoke node" prior to the EXIT.vi.

John

[CoastalMaineBird]

The QUIT LABVIEW function has a QUIT boolean input. It's a boolean that you can use.

I always wire it to a AM I IN A LIBRARY function, so that the real built apps quit completely, and the dev. system doesn't, using the same code.

Is it possible that you are doing something similar, and your test has different results with LV8?

[johnitv]

To CoastaMaine ....

My original QUIT.vi boolean input was unconditional, that is, always TRUE. 

It performed as expected (shut down eveything) in 8.0.  With 8.2, the FRONT PANEL was left dangling on the desktop.

Small test applications, the QUIT function work OK.  It failed to close the Front Panel only on very large applications. 

[PLEXSYS]

All,

   Thanks for the quick replies. I have three apps that exit normally, and one that does not. Coincidentally, the largest one is the one that doesn't exit normally. I have tried wiring a "true" boolean to it with no change. I have also tried having the first control executed by the app be the "Quit" vi, and it also only Stopped the app. I wire a App.Kind node to a case structure to "Stop" when in devel, and "Quit" all else. There is one other bit of functionality in the default case that is executing, so i know it is executing the correct order, but i have yet to isolate what the difference is between the apps that quit normally and the one app that doesn't. All options under VI Properties are identical (minus name) to the apps that work as advertised. Last night i used a conditional disable loop and commented EVERYTHING except the init and exit code, and it quit normally, so that is where i am looking next...

   I have not looked specifically at the documentation, but the only change initially between 8.0.1 and 8.2 was a mass compile from the main splash screen. The same code worked in 8.0.1 in a production environment.

[tst]

The reason I mentioned the documentation is because sometimes things work fine in one version and then work differently in another because something seemingly unrelated was changed.

The last thing you mentioned seems to suggest that the program never gets to the quit VI (and maybe it is actually executing an abort VI found in some other place in the code instead), but it seems you have verified that the code in the same case is executing. Have you tried deleting and replacing it?

[PLEXSYS]

I've now isolated it to a single loop running outside of my main loop... but what i don't understand is why. I have a bool control wired to a stop if true while loop. I set the control to true via a local variable in write mode. I use a 100 ms wait until next ms multiple to set the iteration timeout... and i have a case statement that defaults to do nothing. I have tried to have this while loop floating on its own, and connecting a wire from my init sequence to it to make sure it executes after init. Both fail to exit normally. If i use a diagram disable on just that loop, it exits normally.

Thoughts?

I am going to try a property node (signaling) instead of the local variable and see if that changes anything.