LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to: Close Application Properly

Solved!
Go to solution
Is it because the processes (i.e. VISA) you are starting are not controlled by the RTE?
0 Kudos
Message 31 of 42
(1,959 Views)

To my experience the garbage collector of VISA is working perfectly well since at least LV 7.1.

I have seen the same issue when calling an dll device driver when I didn't call the Close procedure. I guess this hang occures when the garbage collector calls the finalize section of the dll (which is hanging).

 

Anything apart from VISA you use? ActiveX (which might be dll's)? Other device drivers?

 

Felix

0 Kudos
Message 32 of 42
(1,945 Views)

lavalava wrote:

 

Are there any application engineers out there, could you please document this case and see if someone can investigate a little further why there are inherent problem with the Exit labview VI and VISA (GPIB) in general? 


 

No one can document anything unless you provide exact details and/or a reproducable example. I certainly don't know that there are "inherent" problems with this combo, just the Resetting VI dialog appears sometimes, and I'm fairly sure this has to do with aborting a VI, not with the Quit LV primitive (which presumably tries to abort all VIs which are still running).

 


It shouldn't be looping back to Resetting VI state and freezes itself no matter what.


I don't know what Resetting VI means, so I wouldn't make any assumptions about it.

 

 

In any case, I agree that it's possible that this is something that's not caused by your code, but without being able to reproduce it, I doubt NI can do much.


___________________
Try to take over the world!
0 Kudos
Message 33 of 42
(1,927 Views)

tst wrote:

No one can document anything unless you provide exact details and/or a reproducable example. I certainly don't know that there are "inherent" problems with this combo, just the Resetting VI dialog appears sometimes, and I'm fairly sure this has to do with aborting a VI, not with the Quit LV primitive (which presumably tries to abort all VIs which are still running).
 

No one can document anything unless you provide exact details and/or a reproducable example. I certainly don't know that there are "inherent" problems with this combo, just the Resetting VI dialog appears sometimes, and I'm fairly sure this has to do with aborting a VI, not with the Quit LV primitive (which presumably tries to abort all VIs which are still running).



 

Then could you please explain what your definition of a program exit?

 

My definition is Labview should not wait forever while doing garbage cleanup then shutdown.  Regardless of what resources/memory/dll/sessions/junks/etc.. that an end user has accumulated up to the point of exit event.  If he agrees to exit then Labview should treat all those accumulations as garbage.  It should perform a fast timeout and should not be waiting forever. 

 

You don't know such inherent problem because you didn't built Labview.  And neither did I.  That's why I ask.  This isn't to disrespect you in anyway but NI pride themselves on creating an easy to use software.  We paid a premium for this.  We shouldn't be spending time playing around with garbage that we have no controls over at the point of exit, especially if they're not part of the codes.

 

 

 


In any case, I agree that it's possible that this is something that's not caused by your code, but without being able to reproduce it, I doubt NI can do much.

Even if I can replicate this issue, it's still pointless because there is no guarantee you or anyone have the same set of test instruments that I'm using to try it out.  What's more important is that's not part of the discussion.  The discussion was Labview should not be calling to other garbage (regardless of what it is) while waiting forever for it to unlock on its way to the exit.  Even you attested to have seen this problem too, so it is not something that I'm the only one who have witnessed.  Exiting the program should not be a complicated matter and we shouldn't be argue over something both you and I have already seen.  We both saw it has frozen before.

 

0 Kudos
Message 34 of 42
(1,904 Views)

I agree there should be one well documented way of doing this.  I have only ever used the Quit LV VI.  I also agree NI should be handling all of this.

 

It would seem that in order to properly close an application it is essential to have an Event Structure in your application to intercept the necessary OS events.

0 Kudos
Message 35 of 42
(1,897 Views)

lavalava wrote:


My definition is Labview should not wait forever while doing garbage cleanup then shutdown.  Regardless of what resources/memory/dll/sessions/junks/etc.. that an end user has accumulated up to the point of exit event. 


I agree that if you call a function which is supposed to abort everything and shut down then LV should not get stuck. I don't know whether LV should automatically crash the process if this happens, although I don't think there's anything else which can be done at that point. I also don't know how easy this would be to do. Presumably, this happens in a section of the code which locks the rest of the execution for a good reason. In any case, I will point again that I don't think that this is related to exiting the app, but to aborting a VI, something which can done in LabVIEW as well (e.g. by clicking the abort button).


___________________
Try to take over the world!
0 Kudos
Message 36 of 42
(1,881 Views)

battler. wrote:

I agree there should be one well documented way of doing this.  I have only ever used the Quit LV VI.  I also agree NI should be handling all of this.


There *is* one documented way of doing this - Clean up your code, then call Quit LV at the end of your code. I'm not sure what you mean by "all this", but you have some responsibilities as the programmer (see the next paragraph).


It would seem that in order to properly close an application it is essential to have an Event Structure in your application to intercept the necessary OS events.


Your assertion is correct only if you are planning on using the "standard" application closing methods, which is not always the case. My apps are sometimes designed not to be closed, so you have to go into a limited access part of the app to close it, and then you get a dialog warning you of the consequences. Another example would be an application running on a PDA, where closing the window does not shut down the app.


___________________
Try to take over the world!
0 Kudos
Message 37 of 42
(1,879 Views)

By "all this" I meant that there is:

 

<Application> Intance Close

<Application> Intance Close?

 

<This VI> Panel Close

<This VI> Panel Close?

 

Can you please put a meaning to each of these?

 

I was advised only to use the <This VI> Panel Close? event and that is apparently the proper way of closing (followed by clean-up and Quit LV of course).  Are there any other situations when I might use any of the other events to close my application?

 

Thanks.

Message 38 of 42
(1,870 Views)

Did you try looking at the help? It explains what each event does and the difference between notify event and filter events (those are the ones with the question mark).

 

In short, the Panel Close event is called when you close the window (e.g. by clicking the X button) and the App Instance Close event is called when the app gets an external quit command (e.g. if you're shutting down the OS while the app is running).


___________________
Try to take over the world!
Message 39 of 42
(1,852 Views)

battler. wrote:

By "all this" I meant that there is:

 

<Application> Intance Close

This event is triggered when the application will be closed externally, either from exiting the OS or by using the 'Close application' in taskmon

<Application> Intance Close?

This event is triggered when the OS tries to close the application, (either from exiting the OS or by using the 'Close application' in
taskmon), it allows you to cancel the close action. However if you cancel the close action you should be aware taht this might trigger non-standard behaviour to the end user.

 

<This VI> Panel Close

This event is triggered when the front panel will be closed, either from a close window (ALT-F4) call, a click on the 'close window' button, a shortcut (ctrl-w). A LabVIEW method <Close Front Panel> will not trigger this event.

<This VI> Panel Close?

 

This event is triggered when the front panel tries to be closed, either from a close window (ALT-F4) call, a click on the 'close window'
button, a shortcut (ctrl-w), you can cancel this action and take appropriate action. I advice you to discard this event and take a 'Front Panel Hidden' approach. (as suggested here)

 

Can you please put a meaning to each of these?

 

I was advised only to use the <This VI> Panel Close? event and that is apparently the proper way of closing (followed by clean-up and Quit LV of course).  Are there any other situations when I might use any of the other events to close my application?

 

Thanks.


 There is no need to use the Quit LV function, just close (don't hide them) all the open front-panels.

 

Ton

Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 40 of 42
(1,820 Views)