loop in subVI to be stopped by control in calling VI.

[Tzench]

I have a loop in a subVI that is supposed to run untill a stop-button is pressed in the calling VI. This doesn't work due to data flow issues. It has coem to my attention that this can be done using references, invoke nodes and/or property nodes. How is this done?

[craigc]

I tend to use a Functional Global / Action Engine for this.  A Functional Global is basically a safer replacement for using a global variable but with a lot more functionality.

Action Engine

I have a very basic Func Global That is unique and has the means to stop / start the loop from anywhere else from within the LabVIEW environment

Craig

[Tzench]

So what you suggest is a subVI (action engine) that is a switch, triggered by the calling VI and observed from inside the loop of the subVI?

[craigc]

Thats the one Tzench,

You have the loop "reading" the FG and your top level VI "Writing to it"  With a few more options you can do all sorts with this technique.  Restart the loop, Pause it, put a delay in etc etc.  You just build up the states within your AE / FG

Craig

[Tzench]

I tried the method using this VI. It still doesn't change the fact that a subVI does not go outside itself to check for data; The subVI checks the StopSwitch VI, but the StopSwitch does not check the button in the main program.

[johnsold]

Your subVI needs to be running in parallel with the Vi which has the button.  If it is truly a subVI of the button VI, then dataflow will prevent the action you want.

Can you post or clearly describe the overall architecture of your program?  Show both the main VI and it relationship with the subVI.

Lynn 

[IanW]

Tzench

You need to put a case structure inside your StopSwitch.vi loop, with the switch in one case (write) and the Lamp in the other (read). You then need a control to switch between read and write. In the read case, make sure you wire the connection all the way through to the right hand shift register. Now in your main program call this vi at the start of the program, set to write with a false constant, this will initialise to the off position. Call it again in your the loop of your Main program with the stop switch connected and set to write. Now in your subvi call this in your loop with the setting for read, connect the lamp to the stop control of your loop.

This should be working in it’s simplest form, as craigc says, you can develop this further to give many more features.

Hope this helps.

[Tzench]

The main program is a long series of events connected by an error wire. The image shows only the relevant function call.

[johnsold]

The Stop button is probably read as soon as your main  program starts and is never read again unless the main program is also a loop. From the image it is likely that the Stop switch will be read before the ET_loop VI runs and will certainly not be read again until after the ET_loop VI completes.

Also the StopSwitch.vi will produce a True output at most one time in the ET-loop VI and cannot be used to stop more than one subVI.  It should have two cases, read and write and a control to select which mode will be used in each situation.  The instance which is connected to the Stop switch would be set to write and the ones connected to stop terminals in loops would be set to read.  IanW gave a more complete description of this in his response.

Lynn 

[Tzench]

The main program is not a loop. I've known the problem about dataflow since the beginning, and I thought the action engine could be a way around it. Could it be, if I use the case-structure?

I've been working a little with references, but I cant get the Control Refnum in the subVI to understand what it is supposed to refer to. Can anyone help me with this?