LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Abort VIs But None Are Running

Solved!
Go to solution

So I have a strange one and it is hard to isolate the issue.  Originally I had a medium to lage sized project, with 8 or so actors using user events to communicate between modules.  I had several UI elements that might spawn brat VIs, for inserting into subpanels or making floating and what not.  Every time I ran my main VI and then when to quit LabVIEW would pop up a dialog stating 

 

"Quitting will abort all running VIs", with an option to Quit or cancel.  I thought this was odd because none of my VIs were still running.  So I thought maybe one of my asynchronous processes started, and for some reason missed the quit command.  So I started disabling parts of my code looking for this error to go away.  It was a bit time consuming because I needed to fully quit LabVIEW, start it up, open the project, disable something, run the VI, then stop it (through the clean-up process) then quit LabVIEW to see if the dialog still said some VIs were running.

 

After paring down the VI more and more I was finally at a place where my main VI had just one giant disabled diagram structure, with no code actually in the enabled code, only in the disabled case.  Running this VI still caused LabVIEW to think that a VI was running, and that quitting LabVIEW would abort it.

 

I tried copying the BD to a new VI but it also had the same behavior.  If I deleted the diagram (and then all code in it) the quit dialog wouldn't be there.  I tried forcing a re-compile of the Main VI, and that had inconclusive results.  The VI I copied the the BD to quit without the dialog, but the original Main did not.  I'm having a real hard time isolating it and I may just re-create the VI from scratch in the hopes it goes away.  Has anyone see any thing like this where you know, no VIs are running but the quit prompts you to stop them?  Sorry I don't think posting something will be easy, due to the complexity, dependencies, and inconsistency of it all.

 

EDIT:  Sorry forgot LabVIEW 2015 32-bit Windows 7 x64

0 Kudos
Message 1 of 10
(4,308 Views)
Solution
Accepted by topic author Hooovahh

Another developer here asked me about the same problem earlier this week.

 

I do not think he figured it out but I did recomend going to the VI hierachy screen then doing a ctrl-a to show all VIs. That may give you a clue.

 

Otherwise I can only ponder if there is an X-Control involved.

 

Done with my thoughts.

 

Please let me know if you figure it out.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 10
(4,294 Views)

I can only assume this is a LabVIEW bug at this point, but narrowing it down into a more easily reportable issue is the problem so far.

 

Also I just recreated my main VI, and it exhibits the same issue, even when outside of a project.  But again all that functionally happens in the VI is a disabled diagram structure is called with no code in the enabled case.

 

I do have one XControl that I know of for sure, but it is not in the Main VI (so never called in my disable test).  I'll continue pruning.

0 Kudos
Message 3 of 10
(4,279 Views)

Hooovahh,

 

     I'm sure you tried this, but did you do an "App.AllVIs" property node and check that none of the VIs it returns (and it should return almost none, right?) have an Exec State that looks suspicious?  I wrote, at one point, an "Abort" routine based on this because I had asynchronous clones that "escaped" ...

 

Bob Schor

0 Kudos
Message 4 of 10
(4,261 Views)

Okay figured it out, sorta.  

 

So there was an XControl that was in a VI not being ran, but it had an Init ability that allows it to run a VI when the XControl is brought into memory.  This init VI spawns an asyncronous process to perform things as needed.  The idea is you may have N XControls and they would all send request messages to this one spinning process.  This one process would then try to determine if any XControls are still valid that uses it, and if there aren't any, it shuts down.  It does this by reading if a reference made by the init ability is still valid.  The Unit ability exists which will destroy this reference, and cause the process to shutdown.  

 

The description for the Uninit ability is this:  LabVIEW calls Uninit when the XControl is removed from memory. Uninit releases any resources allocated for the XControl.  

 

Problem is, this ability seems to be called when an XControl is deleted, not, when a VI is requested to close.  So the spinning process keeps running regardless if the VI has stopped executing or is requesting to exit.  Putting a breakpoint I see the uninit is called if you click Quit, probably because the spinning process sees the XControl taken out of memory, before the request to abort the VI is issued.  This XControl was not made by me, so I'm not sure why the developer choose to use this mechanizm for starting and stopping the running process, instead of using the State Change, but I'll have to play around and see.  Has anyone done anything with XControls and starting and stopping asyncronous processes before?  I think I could write a subVI that is added to the library that forces a shutdown.

 

EDIT:  Well that won't work 100% because you could open the VI there by running the init and starting the process, then attempt to quit without ever running the VI and a change state won't be triggered....

Message 5 of 10
(4,243 Views)
If the async process is event driven make it able to respond to the application instance close event?

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 6 of 10
(4,214 Views)
Or maybe in the XControls deinit VI fire an event to stop the async process.

Mike....

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 7 of 10
(4,198 Views)

@mikeporter wrote:
Or maybe in the XControls deinit VI fire an event to stop the async process.

This is what currently happens, the uninit ability performs a cleanup function that stops this VI, but this only happens if the VI that has the XControl gets closed, before invoking the quit LabVIEW (CTRL+Q).  I also tested creating a close XControl function, but the way it is made, this would only get called if the VI is ran, but still opening the VI and not running then invoking quit will still leave this VI spinning because it is started on init of the XControl.  A better solution might be to spinn up and stop this process on running the XControl, not on the XControl going through init.  I may just live with it for now because I didn't write the XControl and am unsure what kind of affects changes like this might have to interaction with the XControl when the VI isn't running.

0 Kudos
Message 8 of 10
(4,129 Views)

This is more in relation to your original question, but I have always found Darren's utility to be very helpful.

 

http://forums.ni.com/t5/LabVIEW/Darren-s-Occasional-Nugget-08-11-2008/td-p/760429/highlight/true

 

It will list anything running whether it is "open" or not.  It is also useful when I accidentally leave a modal window open and run the main VI, since it will always take modality away from what's running.

 

Matthew

 

0 Kudos
Message 9 of 10
(4,095 Views)

This doesn't work on asynchronously running clone VIs.  The All VIs in Memory property doesn't list clones.

0 Kudos
Message 10 of 10
(4,077 Views)