"inactive" Case while loop continues

[GaryAtAMI]

I'm using a Tab Control to set a large Case Structure to swap out code for the currently visible controls. Since each case "talks" to the same I/O with different methods, this seems ideal.
Each case has it's own infinite (but timed) While Loops since the loop execution rate is imperative.

Here is the problem: Tab 1 is a Sin/cos waveform generator at .05 Hz at a 33msec update/iteration rate. Testing has shown it's running perfectly.  Tab 2 is also a Sin/Cos waveform generator, but under manual control.  I have a 360° knob I can turn to produce the voltages. If I start the VI with Tab 1 visible, then switch to Tab 2, the knob doesn't work and the other case still runs.  If I start the VI with Tab 2 visible then switch to Tab 1, the waveform generator doesn't start and none of the controls work.

The tab control IS outside any loop and I run the VI in continuous mode.  I've tried some tricks to stop the loop(s)  not in the current case, but I can't seem to start the loop again without restarting the entire VI.

Any help would be appreciated ............. I'm almost done with this hairy yet nice looking VI and this has been annoying me for a week!

[smercurio_fc]

Your architecture is wrong. Once the VI starts it reads the value of the tab control and goes into the appropriate case structure. You said that each case structure has its own infinite loop. Therefore, you're sitting inside the infinite loop for whichever case was active when you started the VI. At that point it doesn't matter what you do with the tab control. The VI has been set to run.

You also should NOT be using continuous run. This is only intended for special cases, and should not be the normal way of running a VI.

You should only need one loop to control the running of your VI. Why do you have separate loops for each tab?

[mikeporter]

A better way of accomplishing what it sounds like you are trying to do is to utilize a subpanel. That loads the frontpanel of other VIs into itself. With this structure you can have any number of processes running independently in the background but hidden. As you make selections, you load their front panels for display.

As far as the background process are concerned they don't see any interruption or change in their operation as a result of the interface changes so your loop rates are maintatined - or at least are maintained to the degree that Windows is capable of maintaining them...

Mike...

[altenbach]

You need exactly one while (or timed) loop containing a case structure for all the tab cases. Hook the tab terminal directly to the case structure and it will label the cases like your tabs for convenience.

All the shared code belongs outside (probably to the right of) the case structure, but inside the loop, of course. For example all your IO would be outside the case, while the case structure feeds it the desired parameters.

[GaryAtAMI]

Thanks for the reply! Everything you mention makes sense as far as explaining what I'm seeing. The reason it came to be this way is because the VIs were individually developed to stand alone. I thought I could just drop in the resulting block diagrams into each case ......... WRONG! 

I think I saw an answer further down that should help me fix this.

[GaryAtAMI]

ooooooooohhhhhhh - good advice!  I'll write a test VI and try this out.   ARGH -  I hope I don't have to rewrite large sections ............ 

[mikeporter]

The subpanel approach would probably require the least rework in that the formerly independent VIs would still be running independently - just in the background.

Mike...

[GaryAtAMI]

Update to my previous problem.  The solution was simple but it never stared me in the face.  I was wiring the tab control thru an outer/slower while-loop, tunneled into the case structure, then tunneled into the inner-most critical-timed while loop to see what case is selected and to stop if "not my case".

All I had to do was to delete the wire and add a local variable to read the tab control inside the inner-most while loop to start/stop it. There is a slight pause from stopping the current case and starting the new case since the outer/slower loop is currently set to 1 sec, but that's okay in this application.

At first glance, I didn't think it would make any difference - but it made all the difference in the world!

Thanks for y'alls suggestions!

Gary