forcing a sequence to continue

[marshieparshie]

i'm working on a flow injection program that controls some valves and reads measurements from an instrument. the part that reads and graphs the measurements is in a subVI. currently this subVI is in a sequence structure because i need to execute some things before it is called. when the program gets to the frame with the subVI, it calls the subVI and waits for the subVI to finish before going to the next frame. the frames after control the timing of the valves, so they need to execute while the subVI is running. is there a way to make the sequence progress when the subVI is called instead of waiting for the subVI to end?

if no one can help without looking at the VI, i'll post it tomorrow afternoon when i'll be back at work.

[Guenther]

You can call the sub-VI dynamically, this way it operates indepentently from the main program and the sequence will not wait for the sub VI to finish.

Check out this thread in the NI forum

Good luck

Guenther

[mross]

i'm working on a flow injection program that controls some valves and reads measurements from an instrument. the part that reads and graphs the measurements is in a subVI. currently this subVI is in a sequence structure because i need to execute some things before it is called. when the program gets to the frame with the subVI, it calls the subVI and waits for the subVI to finish before going to the next frame. the frames after control the timing of the valves, so they need to execute while the subVI is running. is there a way to make the sequence progress when the subVI is called instead of waiting for the subVI to end?

if no one can help without looking at the VI, i'll post it tomorrow afternoon when i'll be back at work.

I never hurts to post code.

It sounds like you are not yet on the dataflow bandwagon. Dataflow differs from sequential programming in that functions, structures and sub vis run when the get all their wired input data. And finish when all the wired outputs get data (default values can substitute if they are enabled). It is not only possible but desirable that these nodes may operate in different order depending on circumstance. In this way LabVIEW is inhenently parallel and having numerous loops running simultaneoulsy is common.

Each frame of your sequence structure will run when the sequence before it completes AND when it gets all its input terminals filled. Then it only completes when the vis and functions within it complete and all the output terminals are filled. So the sequence is acting exactly rigth and it does not relase to the next frame until the VI is done itself. The borders of loops and structure are important. Terminlas on boreders represent buffers for data.

If you wire a control that is outside a border to a border it creates an input buffer.

If you wire any indicator outside a border to the border it creates an output buffer that must be filled for the structure to complete.

If you wire a control inside a border to the border an output buffer is created.

If you wire an indicator inside the border to the border an input buffer is created. This is tricky: if you don't wire something from the outside to the input terminlas they are uninitialized and under some conditions they may not be empty.

Output terminals can have a defalut value if unwired.

You should consider getting away from the use of multiple frames of a sequence. This sounds weird but we often use a single sequence frame to encapsulate functions that need to occur at the same time, but we avoid just what you are doing as it is too restrictive and can slow down program execution. If the VI can go ahead with some operations, it should and a set of sequence frames stops this from happening.

The border between sequences is the same as wiring an output from an individual sequence to the input of another. With both stacked and flat sequences the wiring betwen sequences is implied and the output terminal is the input of the next. Hmm, I don't know if two buffers are created as would occur with two discreet structures.

You said: " because i need to execute some things before it is called. " Execute those initialization things within a single sequence frame, but then wire something as an output to the subvi, but the subvi is outside the sequence. You can have additional sequence frames if you like and now the subvi can run independently of it.

You can even run basically nonsense wires just to control data flow. Suppose you ssubvi has an input that is a boolean. Creat that input control on the subvi, drag it into the sequence frame and the wire it from the contro to the sequence border and then to the subvi. Now when the sequnce frame is done the data on the border is released, it passes to the subvi which will not run untill is gets that input.

There is a highlight function to track dataflow on the block diagram. Click the light bulb and when you run the vi it will show you all the data as it flows through the vi. This is a great way to learn the implications of dataflow.

It is very common to use the "Error" clusters which are built into functions and vis as dataflow controls. The error cluster starts with some early function in the block diagram and is passed through the various functions to which it is wired picking up errors along the way for dsiplay at the end or at different points during execution by placing indictaors. Becasue no function, or structure will run until it gets all its input data, it waits for the error from the eprovious VI and passes it to the next one when it finishes.

Mike

[marshieparshie]

thanks for the replies. i'll try them when i go to work in a few minutes.

i've only been using labview for two weeks, so i don't know all the basics yet. i think i remember trying to put the subVI outside the sequence structure and have inputs from within the structure and it didn't work right, but maybe i didn't do it right.