01-12-2023 03:23 AM
So i have a problem with Quit LABVIEW function in my app.
As a last resort if something goes wrong, i call this function to shut down the executable, however sometimes it still keeps a subVI running in the background.
From what i understand from function details, this function should close everything, but for some reason it doesn't, anyone knows why?
The subVI in question is called asynchroniously with a call and forget setting, in case this matters.
Solved! Go to Solution.
01-12-2023 04:16 AM
Hi Aero,
@AeroSoul wrote:
sometimes it still keeps a subVI running in the background.
From what i understand from function details, this function should close everything, but for some reason it doesn't, anyone knows why?
What does that subVI do?
Example: The subVI might call an external DLL and the code inside the DLL might be stuck in a loop: it might get hard for LabVIEW( runtime engine) to stop the execution inside that DLL…
01-12-2023 05:12 AM
The subVI is a VISA communication state machine and uses no external code.
It's a bit bloated (i made it as my first major VI when i started working with LabVIEW, but don't have the time to refactor it now) and sometimes doesn't shut down properly, at which point i have to kill it with task manager, before restarting the executable.
01-12-2023 07:58 AM - edited 01-12-2023 08:00 AM
Instead of trying to figure out clever workarounds for questionable programming, just live with killing it until you have time to properly refactor it. What I mean is that by the time you get some answer here that might work, you'll probably have figured out why it doesn't shut down properly in the first place.
01-12-2023 08:49 AM
Current workaround is to repeat the Shutdown command for State machine 6 times and hope it sticks... one of the Action engines seems to be corrupted and i don't know which one...
01-12-2023 09:26 AM
@AeroSoul wrote:
So i have a problem with Quit LABVIEW function in my app.
As a last resort if something goes wrong, i call this function to shut down the executable, however sometimes it still keeps a subVI running in the background.
From what i understand from function details, this function should close everything, but for some reason it doesn't, anyone knows why?
The subVI in question is called asynchroniously with a call and forget setting, in case this matters.
I have three answers, one for every paragraph in your Message.
As I recall, you did not attach your Project to your request for help, so I don't know the basic design you are using, other than it involves some "Start Asynchronous" calls (I'm going to use the term "Clone VIs" for this sort of code). LabVIEW, as you know, supports multiple loops running in parallel -- in order to stop a LabVIEW program, all of the parallel loops need to stop. One "crude, but effective" way to do this when no Clones are involved is to have a Global Variable, perhaps labeled "Panic Stop" (a good name, because that's what it is) that is OR'ed into the Stop terminal of every loop (including FOR loops -- if you are being "gross", you need to make sure the For loops can be stopped by turning on the Conditional Stop).
A much better way is to use some form of "signaling" -- when a Stop condition is met, messages are sent to all the parallel loops to ask them to do an orderly shutdown, closing files, releasing resources, etc.
But what about Clones? I assume your Clones have inputs from the host routine that spawned them. One of those inputs could, and probably should, be used to tell the Clone to do an orderly shutdown. So when the Top Level VI decides to Quit, it sends the Shutdown "command" to all of its clones, and they all shut down (including shutting down all the sub-VIs they might have running.
This works. About a decade ago, I wrote a "monitoring" routine that spawned up to 24 clones to monitor animal behavior for a few hours. There was a top-level "Stop" button (mainly used during trial runs, otherwise it ran for a set amount of time before doing Shutdown). On Shutdown, each clone was given a "Shutdown" command (the Host could send Commands to the Clones). Initially, the Clones were "Call and Forget", but I think I ultimately made them "Call and Collect" just to be able to have the Host "wait" for all the Clones to exit before exiting itself, raising a Warning to the Operator if it took too long (I don't remember what "too long" meant, but it was probably something like 30 seconds).
Bob Schor
01-12-2023 09:33 AM
@AeroSoul wrote:
The subVI is a VISA communication state machine and uses no external code.
Yeah, VISA doesn't really like being aborted and will sometimes cause a hang instead of dying.
Things can get tricky when you start dealing with asynchronously calling VIs because you have to worry about lifetimes of any support VIs and references (for example, queue references). We would need to see code to make any better assessments, even if it is a much scaled down version of the code.
01-12-2023 12:24 PM
@AeroSoul wrote:
So i have a problem with Quit LABVIEW function in my app.
As a last resort if something goes wrong, i call this function to shut down the executable, however sometimes it still keeps a subVI running in the background.
From what i understand from function details, this function should close everything, but for some reason it doesn't, anyone knows why?
The subVI in question is called asynchroniously with a call and forget setting, in case this matters.
If you change it to "Call and collect" instead of "forget" it should stop at the same time as your main VI.
Warnings if you do this though:
1. If this is a VI you start just once and leave running, it's fine if you never collect. But if it starts and stops, you should be sure to run the "collect" and then close the reference to avoid a memory leak.
2. This should be regarded as a band-aid to the real problem of the subVI not stopping, not a solution to it.
01-13-2023 01:55 AM
Thank you Bob, i did not know that Quit LABVIEW function only affects the main VI, as far as the original question of the thread, this is the answer.
To answer your questions, unfortunately i can't share the code and i don't think i could meaningfully replicate part of code where the problem lies.
I use Action engines extensively (mostly because the original code was written using them and it isn't in scope of the project to rewrite code) and as far as i can tell, one of them is corrupted. I tried replacing it but the bug still happened.
What happens is that when i write a command to this action engine sometimes it does not get updated. This only happens with this one AE, even though it's structured the same as all the others.
In total i have 10 asynchroniously called state machines, most for the different periphery we use on the machine. When i order a shutdown, a command is written to the action engine that shuts these state machines down. If the bug in question happens, all of them shut down except the one that uses this corrupted AE, which keeps the VISA comm open.
All of these state machines are initialized when program starts and shut down when program is closed, i do not start/stop them during program execution. If they are not needed during execution, they are put into Idle mode, but not shut down.