SubVI Outputs

[DominickC]

Hello -

I've created a subVI with two outputs - an enum and a boolean. Within said subVI, there are a few while loops running that cause the output of these two pieces of data to be delayed until the end of the subVI execution when placed within a main VI. To further clarify, the subVI outputs the correct data at the correct time when run alone, however not so when run within a main VI.

Is there a way to configure the subVI to output the data continuously alongside these loops?

Dom

[Mark McLeod]

How about running your subvi in parallel to everything else, like what the Periodic Tasks.vi does.
Then creating a subvi to be called by your other loops to just return the last values produced.

Your description sounds like it's a problem because your subvi isn't started until it's called, then it takes too long to run start to finish.

[DominickC]

Here is my current code.

PneuController is the "main VI' which will run the subVI.
PneuStateMachine determines which state ReqPos should pass along to PneuState. ReqPos will ensure a state is not run more than once, however I've yet to integrate this code.
PneuState sets the outputs based on the state.

Sorry for the lack of comments and the rather messy block diagrams.

EDIT for clarity: PneuStateMachine functions as expected and desired. When PneuStateMachine is put into another VI to run as a subVI, the outputs are not updated until the end of the loop.

[Mark McLeod]

Think of the shell of the subvi as a single-loop itself.
No output will be released from the subvi until it concludes, just as no new inputs are accepted until it's run again.
It's the same reason that long delays in Teleop.vi are bad.

One way around this is to use a global variable in place of Output and Moving? as a mechanism to pass along intermediate values.
You'd need an additional flag to indicate when it's safe to read those global values, and handle the tiny window where Output has been updated, but Moving? hasn't yet.

Teleop doesn't have this problem, because it writes settings out to the FPGA, rather than producing top-level vi outputs.

[Greg McKaskle]

To rephrase what Mark said, the white box inside a loop is called a diagram. The white box inside the window of the subVI is also a diagram. They have many of the same execution rules. To communicate data in parallel, you need to use something like a global, a queue, an event, etc. For most FRC tasks, a global is a fine mechanism to share data.

Greg McKaskle