Help on efficient SubVI interaction

[AlexP1]

I really could use some advice with how my main program passes data to my SubVi, and how the SubVi handles it.  Right now my main program passes values into the SubVi as fast as it gets it.  The whole point of the SubVI is to perform an integral on my data.  However, the change in time (dt) is never constant, so I need to always be calculating dt as I go.  So I take current time T2 and subtract from it time T1, which has been passed back through the shift registers. 

My questions are these:
1. Is a while loop in the SubVi the best way to go?  In the main loop, the program runs continuously until I hit the stop button.  So I want the SubVi to run until the main loop finishes.  How do I stop the Subvi?

2.  Suppose the 4 fuel flow channels don't come in at the same exact time?  Let's say Fuel Flow 2 gets fed to the SubVi .002 seconds after Fuel Flow 1, and Fuel Flow 3 comes in slighty after 2?  How is the SubVi going to run?  Will it wait until all four channels of data are received before executing?

3.  If there is no timing control for the while loops, like a wait function, I understand the the while loop will execute as fast as it can.  Since I have a while loop in the main program feeding data, and a while loop in the SubVi, am I going to need to syncronize these at all?

I included the SubVi itself, and a picture of the main loop, since it has a lot of functions that are custom. 

I appreciate any help.. starting to get into more advanced programming! 

Thanks,
Alex

[AlexP1]

Oops, attachments didn't go through.

[CFAMS Brad]

I cannot open the VI in LabVIEW 8.2, but I will try to answer some of your questions anyway.

1.  You have to have some control wired to your loop condition terminal in the subVI.  If you wire this to the subVI connector pane, then you can control both the Main and the subVI with the same stop button.

2.  The answer to the final part of this question is "yes."  If you watch the VI's run in execute mode (this is a pain if they are too complicated), you will see that the subVI waits for all data inputs to start processing.  I believe that takes care of the other parts of that question.

3.  Here, there may be problems.  I have begun to steer away using while loops in my subVI's because of this issue.  Why not try a for loop in your sub VI that integreates every N iterations of the main loop?  This N value could even be dynamically determined.  Then you would have a subVI without a while loop that runs once on demand.  Of course there will be issues with reiterating the main loop before your subVI has enough iterations to calculate a value, but I think it can be done.  Some of the more experienced voices on this list will have something to say about that, and I'd be interested to hear their responses to your third question.

Brad

[johnsold]

Alex,

Several things come to mind.

Run continuously (the looped arrows in the title bar) is not a good way to run a program. It is intended to be used for simple tests during program development.
Similarly, the Abort button should only be used to kill a runaway program, not as a means of routinely stopping a working program.

From the looks of your picture only one of the four fuel flow and engine time data lines will have measured data at any one time. The others will have default values. So the question about different arrival times does not make much sense to me.

If you want to speed things up to the milliseconds per loop rate, take all indicators outside the loop. If you need updates for the user, put the User Interface (UI) in a parallel loop and pass data between the loops via a queue. Also consider putting the TDMS functions in another loop.

The subVI will loop until stopped, but continues to use the data that was present when it started. The controls are outside the loop. Once the loop starts the values in the controls will not be read again until the subVI stops and starts again. To stop the subVI programmatically will require a queue, a notifier, or a global variable. Globals are discouraged because they violate dataflow and are prone to race conditions. I am not sure exactly what you want to do, but it will require some reconfiguration of the program.

Many of these things are basic dataflow programming concepts. If they are unfamiliar to you, a review of the LabVIEW tutorials or a Basics coursr might be helpful.

Lynn

[AlexP1]

Brad,

Thanks, I'm going to have to think about what you said.  In the meantime, here is a pic of the SubVi, although I don't think it'll change anything you said.  It's pretty simple. 

Thanks,
Alex

[CFAMS Brad]

Having looked at this subVI image, I agree with the response that pointed out that your subVI will not refresh with values.  I don't know what you have wired to the connector pane, but regardless, those values will not update until the while loop completes an iteration and restarts. 

[AlexP1]

Thanks for responding so quickly!  I thought about what both of you said, and I've been trying to think of the best (and easiest) ways to implement your ideas.  In response to some of your thoughts:

Brad -

I wired the stop button in the main program to the SubVi.  I think this is what you meant.  Seems simple enough.  Not sure why I never thought of that before.  As far as the for loop, it would take me some time to think about how to do that.  If this idea with the while loop doesn't work out, I'll have to try that next. 

Lynn -

When I said I stop the program, I meant stopping it using a button control on the front panel, rather than abort stop button in the front panel taskbar.  I saw what you meant about having my controls outside the while loop.  It's obvious now.  So I put them inside the while loop.  Now they should be updating constantly.  As far as the other things you were mentioning, like putting indicators and TDMS write functions in seperate loops, I don't know too much about how to do that, but I'd like to learn more about it.  Do you have any good resources in the help or online that have some simple examples demonstrating this?  I would very much like to make this program run more efficiently.  I don't mind doing a reconfiguration of the program.

Ok, so here are the changes I made.  Pretty simple ones.  I attached the pictures of the SubVi and the Main.  All I did in the main was to route the true/false control to the SubVi.  Now the SubVi will run until i stop the main program.  In the SubVi, I placed the time and data controls in the while loop, so its constantly bringing values in from the main program and processing them.  However, the very time the SubVi run, you have this condition where the first time T1 is subtracting a value T0 that is produced by the shift register from the left side.  Since the loop hasn't run yet, I dont know what it's subtracting.  I'd like to have T0=T1, so I set up a local variable to initialize the shift register.  After that, I expect the shift registers to pass values back, so cases will run such as T2-T1, T3-T2 and so on.

This seems like the simplest way to get this to work.  Do you see any problems I don't?  Unfortunately, I can't "test" this, it needs to work the first time.. so I appreciate the help. 

And at the risk of sounding like a complete nerd, I love programming in Labview.  Lots of awesome challenges figure out and new ways to do things!

Thanks,

Alex

[Dennis_Knutson]

Okay, you are missing some basic understanding of how LabVIEW (and other programming languages) work. When you call a subVI as you have done, it starts to execute and control will not return to the main program until the subVI finishes. The main VIs stop button will not do anything to stop the subVI. What you have created is an inifinite loop if the subVI's panel is not visible. I'm having a bit of trouble understanding why you are doing by just looking at some pictures but I think you need to remove the while loop completely from the subVI and place your shift registers in the main. Then, the code in the subVI executes just once everytime it is called.

[AlexP1]

Ok, I see what you are saying.  This goes along the lines of what Lynn was trying to communicate to me before.  I made a small, example program to demonstrate this to myself.  No data within a while loop will pass out of it until it has completely finished executing.  So wiring the stop control from the Main program to the SubVi is worthless.  The SubVi, once initiated, will continue to run forever without passing any data out until it stops.  And the only way it'll stop is if I stop the main program.  Kind of defeats the purpose. 

I'm glad to get rid of a while loop, so I tried what you said and instead placed the shift registers in the Main program.  It certainly got a lot messier, but I think it I have everything configured correctly.  I still have a few concerns: 

1.  How can I initialize the shift register to the same time as the first time that the fuel flow case structure reads? 

2.  Also, the shift register time data goes through a whole bunch of case structures before it reaches the right one.  Is this going to have any impact?

3.  When passing data out of the case structures, I had to select "Use Default if Unwired" on the boxes in order for the VI to execute without errors.  What does this do?

Thanks,
Alex   

[bburress]

Hey Alex,
    Nice work with the shift registers.  It looks a little messy, but should be functionally correct.  You might check and make sure that each passage of a wire through a case structure is truly needed, as this tunnel creates a copy of the data in memory.  Here are my responses to your questions:

(1)  You can initialize the shift register by wiring a value into it on the left hand side.
(2)  The impact of a shift register going through many tunnels will only have the effect I have mentioned above.  It will create a new copy of that data in memory for each tunnel it passes through.  This could be a problem if you are trying to minimize your program's effects on the memory of your system.
(3)  If you select to use "Default if unwired," then that tunnel will pass out the default value of that data type when it doesn't have anything else wired to it.  I don't believe that this is what you are wanting to do.  I suggest wiring the shift registers from the left side through to the right side in cases where they aren't being written to.