Does LV2013 support inline subVI's (and am I thinking about them right?)

[gpsmith]

Good evening,

I've been cleaning up my diagram with subVIs, and have run across a dataflow issue.

Within a larger while loop, I am continuously polling data through the Oscope Express VI.  The outgoing datastream is passed to a subVI where I have a Tone Express VI attempt to extract the frequency and amplitude.  However, it looks like when I'm in that subVI, all updates to the datastream stop (as all measurements show identical outputs, and the graph of the signal freezes on the main vi.

As I see it, I have two options:

1) Bring the subVI functionality back into the main VI.  Reasonably possible, but a pain as it will make the overall program much larger than one screen.

2) I recall using an inline subvi, which if I recall would effectively do 1) without actually unwrapping it all.  However, I don't seem to see that option anywhere. Online help suggests it's simply flipping a switch in the properties window, but I don't seem to have that switch.

Any opinions would be welcome.  Thanks!

[RavensFan]

I'm pretty sure that Express VI's are meant to be inlined.  They are meant to give a new LabVIEW programmer an easy way to configure the way the Express VI operates.  Inline subVI is an advanced LabVIEW feature meant for programmers who have already taken off the training wheels of Express VI's.

[chembo]

The switch you are looking for is located in VI Properties / Execution (lower left corner), but I think that this option will not solve data flow issues.

Additionally your subVI contains a Express VI and  I am pretty sure that  RavensFan meant 'are NOT meant to be inlined' in the first sentence of his post.

[Bob_Schor]

My opinion would be Never use Express VIs for anything "serious".  You have no idea what (possibly unnecessary, often redundant) code is being executed on your behalf.  This is perhaps most egregious with the DAQ Assistant -- with MAX + a few excellent NI White Papers on DAQmx, you really can do 80% of your DAQmx tasks with 10 DAQmx functions!

Bob Schor

P.S. -- most Express VIs have a right-click option that "unwraps" them, giving you the underlying code.  Note that this is a one-way street, so do the unwrapping in a blank Block Diagram first.  Once you see the pieces, decide which you don't need (because you are using the Default values or are "not doing that") and reduce the Express VI (with all of its mysterious inputs) to a tailored sub-VI that has just the functionality that you need and want.

[altenbach]

---

gpsmith wrote:

I've been cleaning up my diagram with subVIs, and have run across a dataflow issue.

---

What you are describing a a natural side effect of dataflow and has nothing to do with inlining. You loop cannot go to the next iteration until all code in it has completed. If your analysis express VI is the slowest part, it will determine the loop rate. Even if you would inline the code, it would still do basically the same analysis. All you save is the subVI call overhead, which is probably a small fraction.

As others have already said, if you are worried about performance, don't use express VIs and dynamic data, they carry sigificant amounts of additional garbagebaggage around.

Also, please be more specific in your problem description. What is your target loop rate? How fast is "continuously polling"? What are the frequencies involved? How many points do you have per measurement? You don't need thousands of cycles to get the dominand frequency and phase, so maybe your DAQ settings are unreasonable. I don't know the complexity of the tone analysis, but I guess it is at least O(NlogN), thus you can speed it up by shortening the chunks.

What do you know about the signal? How constant is the frequency? What is the reference for the phase? Are all measurement chunks coherent in phase?

[gpsmith]

Well, then, it sounds like I'm a bit off on how data interacts with some of the structures then.  I'd thought that the signal would push into the for loop and continue to provide "latest" information.  Attached are the two VIs that I suspect will be the cause of the problem.  There are many other housekeeping subVIs, but I wanted to keep the attachments as light as possible.

We're collecting data through a NI myDAQ, using AI0 and AI1.  We also control a function generator through NI-MAX.  Signals will be between 1 and 10kHz., but stable for a given run.  I'm expecting noise from the lines and ambient sources, but anticipate that the driving signal will dominate.

=====MAIN.VI=====

State Machine Idle

pulls in a bunch of control information that's presented on tabs 1-3, alowing the user to vary a bunch of settings relevant to the situation.

State Machine Initialize

is the first thing we do when collecting data, which is to create a repository folder for all the information.  Originally, there were other things here which were more related to "Initialize", so the name is out-of-date

State Machine Collect Data

is the heart of the program where most of the actual work is done (tab 4).  The user by this point has defined a series of frequencies and amplitudes, defining a 2D matrix of possibilities.  The program steps through them all in two nested for loops.  For the f/Amp of interest, the program adjusts the output generator to the desired settings, and executes the subVI "Record APS Data"

=====RECORD APS DATA (subVI)=====

This is a flat sequence (as I was a bit less confident about setting up a state machine within a state machine).

The first frame creates a new subfolder for the given frequency and amplitude, and waits a certain amount of time for the new parameters to settle out.

The second frame handles the data we're dumping into the subfolder.  First we check a reference folder to see if a file has been updated.  This file is from an outside program I can't interace with, and so the best I could come up with was to have it continually cycle it's output.  Every 100 seconds or so, it completes its measurements and copies the output to a directory (overwriting what was there before).   When the update occurs (defined by a change in the date modified), we take that to mean it's "good".  While we're waiting for that update, the intent is to continually measure amplitude, frequency, and phase of the myDAQ data (collecting the moment-by-moment measurements and at the end taking the average value - which should take care of any introduced noise).  Once the latest reference file is found, it's copied into the data subfolder, and the information about the myDAQ signal is copied into a text file.  Thus, I get three copies of the reference file, and three measurements of the signal associated with those files.

The issues:

• the main graph output of the myDAQ is effectively an oscope display.  I'd like this to continuously run.  Right now, it freezes when we enter the nested for loops (which I think is due to the dataflow issue)
• the information exiting Tone Measurements are constant, showing no variation between runs.  I suspect this also relates to the dataflow; when we enter the first for loop, the dataflow from myDAQ is frozen, and so for all iterations, the input data would be identical.

Not sure how to fix it per se, but I'm thinking (after reading these discussions) that somehow I'd need to move the NI ELVISms Oscope into the inner for loop, with it's own while loop to ensure we're continually repolling.  However, that would only show an output while collecting data.  Perhaps I can have two oscopes (one in Idle and one in Collect Data), trading the Resources between those two and running the outputs to a share graph (who decides which oscope to pull from based on which state we're in).

Is that the right direction?

I understand it's a lot to take in, and I appreciate your patience as you roll your eyes at this.  I program in LV sporadically, and that leads to bad habits and incomplete mastery (hence the use of express VIs, though I'll admit I also don't like that I'm using them).

Thanks!

[RavensFan]

Why don't you put your O-scope reading subVI INSIDE all of the for loops?