LabVIEW
LabVIEW 2013 SP1 Quit LabVIEW
@chicken_81 wrote:
Hello
i have problems when i make robotics projects:
- I can't save my data if i download and run it on the Robotics Staters Kit 2.0, but it is nomal when i run it on LabVIEW's framework
- I created a Fuzzy VI and then integrated with programs controlling DC motor. Fuzzy logic VI runs well in LabVIEW's framework but can't run on the Robotics Staters Kit 2.0
Please help me
thank you so muchrelated file:
http://www.mediafire.com/download/hd5f3sgq535etb1/Robotics+VI.rar
And this relates to the topic of this thread how? Please make a new thread. There is a button on the top-left corner of the main LabVIEW forum page labeled "New Message." (Don't feel bad about missing it - many people, including myself, have.)
@Norbert_B wrote:
@Heinrich-Hans wrote:[..]
1. I need 'Quit LabVIEW' to end the process of my executable. If not used, the
executable will stay open with a FP and I have to select File -> Close .
[..]No, if there is no running VI left, the application will end its process even if you do not call "Quit LabVIEW".
Quit LabVIEW is a very convenient way to end the process, true, but not the only one. There are even developers who consider the usage of Quit LabVIEW to be bad practise!
If your application doesn't end if you close all windows, it is an indication that there are VIs still running in the background. Maybe it is better to look for these potential "zombies" rather than discussing the bug of Quit LabVIEW.
I do, nevertheless concur, that using 2013SP1 should work with Quit LabVIEW. Point is, that somehow it seems to be connected to your machine as at least Veronika cannot reproduce the issue with her machine and the same EXE she used is NOT working correctly on your machine.......
Regarding your 3rd point, i have no experience; it sounds like a good idea to track and react on external shutdown issues. If your approach is capable of doing this...i don't know. A short test at least didn't help me in understanding what would be a best practise on this requirement.
Norbert
This is what the help for "Quit LabVIEW" says:
Stops all executing VIs and ends the current instance of LabVIEW.
This function shuts down only LabVIEW. The function does not affect other applications. The function stops all running VIs the same way the Stop function does. If there is any unsaved work in memory, you will be prompted to save. Selecting Cancel will abort the quit.
I guess some would consider it bad practice because it actually aborts the VI before closing out LabVIEW. The mitigating circumstanc would be that, upon exit, all resources are closed upon LV exit anyway. But I would advise caution and use this only after you have cleaned up after yourself - but then, if you've cleaned up after yourself already, why not just exit gracefully anyway?
IMHO, if you need "Quti LabVIEW" to get your executable to close out, then you are treating the symptom and not the problem. Figure out why it isn't closing properly and take care of it. Errr, just like Norbert said. 😉
I acually have no problem with usingg the Quit LabVIEW feature in this way. In fact I keep this VIT in Frameworks.
It might be preferable to set the Windows apperance property "Close afterward if originally closed" but that's often overlooked and the primitive handles that case as well as any other method. And, the property is not exposed in the build spec custom vi property page or the vi server. vi. vi class p-node. So its fater to code review this rather than navagate the three deep dialog to get to the checkbox that isn't even selectable with the default new vi settings. Besides if I run the vi from the project explorer for debugging I don't usually want the FP to poof out when I exit. Other people may have other styles but you'll notice Quit LabVIEW is the last possible thing to run and all clean-up is done by this point.
My problem with your implementation was the wiring of anything to silient shutdown when you do not want the process the event. By doing that you are setting some flag somewhere that you probably should not be touching. Besides, you really DON"T want that dialog anyway right? you are shutting down without the user even present to click the dialog and hey your aren't aborting the executio here anyway you are starting a shutdown process that may take some time. (Which reminds me, you do have a mechanism in place to know when the shutdown process is complete right?)
I haven't used Quit LabVIEW in ages. Simply making sure all the front panels are properly closed (not just hidden, which includes sending a shutdown event to any asynchronous background deamon that was started up as independent top level hierarchy) has always been enough to make the LabVIEW application terminate gracefully. If it didn't, I had forgotten to shutdown a background deamon and I would rather want to know about that than hiding it with a Quit LabVIEW primitive.
