LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The engine is in the process of shutting down...

"The engine is in the process of shutting down but the following VIs are not responding to the notification.  These VIs must  be halted before the engine can fully shut down."
 
I've looked at the following document, but unfortunately does not provide any useful info to me...
 
Unfortunately due to confidentiallity issues I can't post any of my vi's, but here is a description of how the software for this test stand functions...
 
A.vi (top level) has a loop that calls B.vi then C.vi.  B.vi gathers some information from the user and depending on what is input will select one of two .scf files to load (this works fine).  B.vi ends, and passes some of this info to C.vi.  The operator uses C.vi to operate the stand and run the test.  When this is ended, all loops are terminated and C.vi ends.  A.vi then loops back to B.vi.
 
My problem occurs when back in B.vi if the info that is input by the operator indicates that a different .scf is needed.  What is supposed to happen in this case is that B.vi stops the engine (using Engine Shutdown.vi), wait until it falls (by monitoring Get Engine Status.vi), then loading/launching the other .scf (by calling Engine Launch.vi).  What I get is the above error referring to C.vi.
 
C.vi isn't running at this point.  When A.vi calls either B or C, it waits until the respective vi completion before it carries on.  I don't understand how/why C.vi is interfering with this.
 
I am relatively new the LV, so I do appreciate your patience and help with this issue.
I'm running LV 7.1.
 
--
Sean
0 Kudos
Message 1 of 7
(2,686 Views)

Sheesh....

I've stared at this soo long...  The deadlock is infact referring to A.vi.

A.vi does not directly make any calls or interaction with the Tag Engine.  Neither does B.vi, aside from loading/shutting it down.  Only C.vi.  Is it because C.vi, which has not been called a 2nd time yet resides in A.vi that I'm getting this issue?

If I start the software with a given .scf already loaded and the engine running, and go right into the case where the .scf change is required, this works fine.  It's after C.vi has already executed once that I get this issue.

(No those aren't the real names if you're curious, confidentiallity and all...)

--
Sean

0 Kudos
Message 2 of 7
(2,680 Views)


@Kahless wrote:

.... Is it because C.vi, which has not been called a 2nd time yet resides in A.vi that I'm getting this issue?


Yes.

One way around the problem is to call C.vi dynamically (i.e. using VI server) rather than have it as a subVI in A.vi's hierarchy.

I think the Tanks example and a few others still shipped with LVDSC7.1.  If so, take a look in ...LabVIEWxx\examples\lvdsc\_common\Tag Engine.llb.   You'll find Launch Tag Engine.vi,  and also Launch Tag Engine I.vi and Launch Tag Engine II

In the documentation for Launch Tag Engine.vi there's the statement:
"If you diagram contains LVDSC modules such as "Read Tag", "Write Tag" and so on, this module doesn't work properly. Use the two VI "Launch Tag Engine I" and "Launch Tag Engine II."

Those 2 vi's can give you ideas on how to do what you want ... or you may even want to incorporate them into your program.

=====================================================
Fading out. " ... J. Arthur Rank on gong."
0 Kudos
Message 3 of 7
(2,663 Views)
Hi Sean,
just an idea: run C.vi either with Call by Reference or through the VI server's Run VI method, specifying to wait for vi termination run; after completion, close C.vi's reference.

Paolo

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 4 of 7
(2,661 Views)

Thank you both so far for your replies.  So far I tried pincpanter's suggestion using Call by Reference.  This did not work for me.  I hooked it up following the instructions in the "Creating a Strictly Typed VI Reference" help file.  Basically, in A.vi, now instead of calling C.vi as a subVI, I do so as follows.  Please tell me if I erred...

"Open Vi Reference" -> "Call by Reference Node" -> "Close Reference"

On Open Vi Reference I have the path wired (as a path, not a string), and select C.vi as the server in the constant I created at the "Type Specifier VI Refnum" input.

And of course the inputs for C.vi in the Call by Ref icon are wired up as well.

I get the same error now, even if I start with the Engine already running and dive right into the change .scf case (opposite to what I mentioned in prev post).

All of the was supposed to replace the C.vi I placed in A.vi right?

--
Sean

0 Kudos
Message 5 of 7
(2,655 Views)
I tried running "Launch Tag Engine I.vi" to test, but I get the deadlock message again this time with both A.vi and Launch Tag...vi.  I do not have Launch Tag Engine II.vi in Tag Engine.llb (just this one and Restart Engine & Caller.vi).  Would you be able to post it for me please and any other suggestions aswell?  Thanks much.
 
--
Sean
0 Kudos
Message 6 of 7
(2,645 Views)

Sean wrote:
... I do not have Launch Tag Engine II.vi in Tag Engine.llb (just this one and Restart Engine & Caller.vi).  Would you be able to post it for me please and any other suggestions aswell?

Launch Tag Engine II.vi in LV6 may have been renamed to Restart Engine & Caller.vi in LV7 (it would make sense since that's what LTEII's function was... and there was the advance from "Set Control Value" in LV6 to "Set Control Value (Variant)" in LV7). 

Open up the block diagram of LTE I.vi; go to the "Stop engine" state and see what the name of the VI being invoked (jpg from LV6 attached).  If it's Restart Engine & Caller.vi, you've got what you need.

As for:

"I tried running "Launch Tag Engine I.vi" to test"
Did you just run it as a top level VI while A was running?   That definitely would not work.

I've never actually used it and mentioned it mainly so you'd have something to look at as an example for using an invoke node to start a VI.  Using it in your code would require a few changes to your A,B, C.vi hierarchy/model.
What you're trying to do can be done ... I'd just go the route of replacing the call of C as a subVI with an invoke node and pass the required data with Set Control Value (Variant).  Setting "Wait until Done" to True would be best in your case ... if my guesses about A, B and C's setup are correct.

A.vi (top level) has a loop that calls B.vi .  When  B.vi ends, C.vi is called dynamically.   When test ends, C.vi stops.  A.vi then loops back to B.vi. etc. etc.

=====================================================
Fading out. " ... J. Arthur Rank on gong."
0 Kudos
Message 7 of 7
(2,625 Views)