How to Stop Sub VI Without Stopping Main VI

[DrNO23]

Hello All,

   I have a main VI that that is used for curve fitting of a lot of different kinds of data.  Some of the Sub VI's take quite a long time to finish running and its sometimes due to the inputs.  Is there a way to stop the Sub IV prematurely with a push of a button from the main VI without stopping everything?  I could figure out how to do it by passing a reference into the Sub VI but what about something like LabVIEW's 'NI_Gmath.lvlib:Downhill Simplex.vi' where I don't dont have access to the VI Block Diagram?

In the attached block diagram I would need to go from 'Step 1' to 'Step 2' but the SubVI may take a long time.  I want to stop the SubVI prematurely but still go to 'Step 2'.  Assume you didn't have access to the blockdiagram of SubVI.  Im OK if the SubVI throws and Error because I can handle it properly but I can't deal with the Main VI stopping.

[P@Anand]

So you don't worry about the result coming out of that VI? Why don't you try to have a case structure around it so that you can easily skip the execution of that vi?

[DrNO23]

So the problem is that the user doesn't know when to skip it until it starts and has been running for some time.  The 'SubIV' in my case is really a numerical fitting procedure that the user has to supply the information.  The more complex inputs will take MUCH longer to fit and I need to add a feature that allows the user to stop the SubVI, change the inputs and then run the SubVI again without stopping the Main program.

[mikeporter]

There are ways of accomplishing what you want but it is not as simple as some secret stop button.

The basic problem is that you can't really abort a subVI, it can only decide to stop on its own and return execution to its caller. There are a couple things you can do.

First, if the overall task it is performing can be broken into separate steps or chunks, you can write the subVI to do a few steps or chunks and then stop to see if it's taking too long. If it exceeds some time limit it can stop itself and return an error that basically says, "I was taking too long, so I stopped". A variation would be to use a user defined event to tell the subVI that it is taking too long.

Second you could structure the logic in the subVI as a separate process that runs in parallel with the rest of the program. The main application can then abort that separate process whenever it desires. A variation on this idea would be to make this separate process reentrant so the main application could spawn multiple copies of it. Depending on what the process is doing and how it is doing it, this change can increase the apparent bandwidth of your system by doing things in parallel, thus making better use of the CPU.

You should also take some time to go through the LabVIEW tutorials.

Mike...

[altenbach]

If the subVI is slow due to fitting, I assume that maybe you are doing nonlinear fitting. I typically query an action engine inside the model VI that throws error 43 ("canceled by user") and thus terminates the fitting automatically, returning the best solution found so far.

Of course your calling VI also needs to be more agile, so get rid of that dumb sequence structure and isolate the UI code into seperate loops so the cancelation can be triggered at all times (I sense the <escape> key in an event structure to interrupt fitting).

It would help if you could attach code that more closely resembles the actual problem. Your currenty VIs are just plain silly. Thanks.

[natasftw]

If you want to be able to stop something, why would you use a structure intended to prevent things from stopping?

[billko]

I've found that (MOST of the time) if I needed to stop a subVI before stopping the main, there was something wrong with my coding methods, and that the same logic could be arrived at in a more efficient way.

Nowadays I rarely run into this issue because my idea of what a subVI should and should not do are clearly defined in my mind.  e.g., loops that might need to be interrupted take place as a state whose next action - to repeat the state (in other words, loop) or to move on - is determined every time it runs through that state, and not as a subVI.  Unless the state machine, itself, becomes a subVI - which I believe usually just adds one layer too many to dig through, unless you have several such loops.

[DrNO23]

mikeporter,

   I will need to review exactly how to setup and execute a reentrant IV but it sounds like this may work.

[DrNO23]

 Altenbach,

   You are correct that I'm doing non-linear fitting in my 'SubVI'.  But could you explain what exactly you meant by "I typically query an action engine inside the model VI that throws error 43...".  Does this mean that your model equation VI's have a statement inside that will send an Error if triggered?  What do you do if a single iteration of your fitting takes 5+ minutes?

Below is an outline of my non-linear fitting IV where I take some initial inputs and then iterate until I have a good minimum solution.  If the user inputs a very noisy and very detailed signal (1000+ pts) a single iteration can take 10+ minutes.  I want to be able to stop the 'Simplex.vi', change the input parameters and then start the iterative process again even if its in the middle of the first iteration.

[altenbach]

---

@DrNO23 wrote:

 Altenbach,

   You are correct that I'm doing non-linear fitting in my 'SubVI'.  But could you explain what exactly you meant by "I typically query an action engine inside the model VI that throws error 43...".  Does this mean that your model equation VI's have a statement inside that will send an Error if triggered?  What do you do if a single iteration of your fitting takes 5+ minutes?

Below is an outline of my non-linear fitting IV where I take some initial inputs and then iterate until I have a good minimum solution.  If the user inputs a very noisy and very detailed signal (1000+ pts) a single iteration can take 10+ minutes.  I want to be able to stop the 'Simplex.vi', change the input parameters and then start the iterative process again even if its in the middle of the first iteration.

---

If the fitting takes too long, you need to optimize the algorithm. I am sure there is a lot of slack left. I also don't understand the reason for the FOR loop. The fitting should come to completion in a single call. Why simplex? How many variables? I sometimes fit thousands of points with hudreds of adjustable parameters and it completes in seconds.

You also seem to be doing otimization, not fitting. Please explain the problem you are trying to solve.....

If the model takes a long time, I assume it contains loops. You could query the interrupt condition in an inner loop so it acts faster.