Labview executable fails to close front panel when meeting 'quit labview' funtion.

[dwinkle]

Hi, all

I have made my application, which has a thrid party Active X container for the control of USB device, 2 serial ports are open and connected with the devcices each.

My application has 4 parallel while loop  in two of which has a event structure and mainly handles the user event related to device control , and  the other two are handled with simple queue structure.

For aquisition of the data, I registerd event callback function in the event case.

The exe file of the application performs good on the windows7,  but when it exits, it fails to close the front panel.

The process of the exit of my application is first closing the 4 while loop in order and releasing all resources, and outside these loops by meeting 'quit labview'. I monitor this process by placing  the 4 LED indicators outside the while loops and for knowing the all the loops are normal closed when the indicators turn ture, and all the process is fine, the application is stopped but the front panel still exit.

Even when I click the window x button in the upper right corner, its icon still exits on the task bar.

I am sure i correctly unregister the event callback, and make all the resources released properly.

I have been spending quite a lot of time googling to get the solution of this, and found the many cases similar to my one. Some of them were solved they said, some of them were not.

Anyway I can't find any clear reason and the solution even from the NI. Lots of known issues have been reported related to this, but no clear solution I guess.

Would you give me some advice for this? I'm about to give up using labview to finish this project.

[wiebe@CARYA]

If you do try the same (incl. Quit LabVIEW) in development environment, do you get a "Resetting VI" dialog?

I'd concentrate on the AX. Maybe you need to close it? Perhaps you're not closing all opened references? Maybe there's a stop or dispose method you need to call?

Do you get the problem without the AX? I know, you won't get anything useful, but you'll learn if AX or something else is the problem.

---

@dwinkle wrote:

My application has 4 parallel while loop  in two of which has a event structure and mainly handles the user event related to device control , and  the other two are handled with simple queue structure.

---

AFAIK, More then one event structure is allowed nowadays (it wasn't for a long time). But if you try to catch the same event in each event structure (say a stop button), you could get problems.

I suppose that since all loops seem to stop, this isn't the problem. But event structures can hang your UI if they are used in the wrong way. You will see things similar to what you describe.

[dwinkle]

Thanks, wiebe@CARYA

Using the 'state machine structure' doen't work either.

As for the AX reference close, currently i'm not closing the reference. Because I am not opening the automation open, and I am using AX container instead, which doesn't need to close reference, as the NI document says. I was closing all the AX control reference before I read the document.

Anyway, every reference close of the AX control didn't work either.

When I switched the 'quit labview' to 'front panel close method' at the very last action of this application,

the front panle locked and no input is allowed. To check whether it happend at the last action or not, I placed the progress bar counting 20 in the 2second right before the exit function. 

[wiebe@CARYA]

But if you make a VI that only does the AX, does it hang?

If you make the same VI without AX does it hang?

If you use the AX container, but skip certain methods, does it change?

The Quit LabVIEW should simply quit LabVIEW code. Not a good idea per se, but it should. It won't kill external routines, like dlls (incl. AX and .NET). That's why I suspect AX.

The AX might be running something on the background. From your description (registered AX events) this seems likely. Those events will be triggered by some process.

If you 'start' the AX perhaps you have to 'stop' it. If you 'run' it, perhaps you have to 'abort' it. Etc..

If there is a AX routine running on the background, this might very well prevent LV from stopping.

[billko]

The best way to use"Quit LabVIEW" is not to use it at all, but to let the executable terminate itself in a graceful fashion.  "Quit LabVIEW" pretty much stops LabVIEW in its tracks.

The last time it was recommended to use it to terminate an executable was back in LV 7.1, I believe.  I guess back then LV didn't properly clean up after itself.

[dwinkle]

wiebe@CARYA Proven Zealot

Thank you for your advice.

I've also suspected the AX event callback, but there is no way to confirm if that is. No Error message pop-up on OS.

The only thing I can do with the event callback function,  is 'unregister event callback'   I think.

Is there any other way futher to forcely stop the AX function?

Do I really have to discompose my code, and figure out the problem one by one?

[wiebe@CARYA · Accepted solution]

---

@dwinkle wrote:

The only thing I can do with the event callback function,  is 'unregister event callback'   I think.

---

But it might not be the event callback... It could be the AX routine that is sending the events to the callback. That might need to be stopped.

There could be race conditions between the 'unregister event callback' and Quit LabVIEW. Hard to say without seeing the code...

---

@dwinkle wrote:

Is there any other way futher to forcely stop the AX function?

Apart from the methods of the AX component, I don't think so.

---

@dwinkle wrote:

Do I really have to discompose my code, and figure out the problem one by one?

---

You do if you want to get to the bottom of things.

Either make a VI that uses the AX in the most simple way. See it it reproduces the problem.

Or disable it from the real VI. See if it reproduces.

You can do this in copies of your code (and hopefully you have everything in Source Code Control).

This shouldn't take that long...

The only alternative I can think of is calling a TerminateProcess... This won't be nice.

[dwinkle]

Thank you very much for your comment.

I will give it try as your advice. 

Have a nice rest of the day!