Main Vi not showing SubVi Output

[yup860]

Hi everyone,

Fairly new at LabView and I am designing a Vi that takes a current reading and translates that measurement into a PSI reading. I made the Vi and it works as intended, but when I make it into a SubVi and connect everything, I don't get an output to the main vi. What's interesting is that when I run the main Vi and look at the front panel of the SubVi, the values there are changing. Been stuck on this for hours and can't figure it out. I saw some posts on using references but others are discouraging the usage of them. Some input would be great.

Thank you!

Main Vi

SubVi

Untitled 1.vi (main)

prsi-transmitter.vi (subvi)

[Kyle97330]

The outputs from a subVI only output when the subVI finishes running.  If you're just sitting there as the subVI spins through its While loop forever, nothing gets output to the main VI.

Whatever you read about references being a bad idea is correct.  Not because it doesn't work, but because it's not flexible or scalable, i.e. you can get it to work on this project but as soon as you want to copy this code to use somewhere else or modify it to work differently it will cause problems.  Depending on how it's done it can also slow down your program a fair amount as the LabVIEW user interface loop is slow in some circumstances.

If you were to do it properly I would recommend a Notifier-based messaging system, but that's not your only option and may or may not be best for whatever your program gets expanded to later.

[yup860]

Ok gotcha. I'm also reading about using global variables and functional global variables. But there are so many differing opinions on which to use. This system I am building is going be using at least 5 pressure transmitters (as well as a BUNCH of other sensors and water valve controls). So I am trying to make the sub-vis as compact, efficient, and reusable as possible. Based on this information, do you have any more comments to add? Thanks for responding by the way.

[GerdW]

Hi yup,

---

@yup860 wrote:

Ok gotcha. I'm also reading about using global variables and functional global variables. But there are so many differing opinions on which to use.

---

Don't use globals for data exchange (more than one direction of dataflow)…

---

@yup860 wrote:

 Based on this information, do you have any more comments to add?

---

Based on the images in your first message I recommend to get rid of the (mostly useless) MainVI and only use the subVI…

Other recommendation: don't put any (quite endless) loop in your subVI. Place the loop in the MainVI and split your subVI into 3 VIs: init, DAQ, cleanup. Call those 3 new subVIs from a statemachine in your new MainVI…

[yup860]

My thinking might be a bit wrong, but this is what I'm imagining. I'm going to have a lot of these PSI sensors so I need to make a subvi so that I don't have the copy and paste the code a bunch of times in the main vi. This project at the end is going to have A LOT more stuff in it. Is it bad practice to make the who psi vi into its own subvi and expect it to function properly?

[Bob_Schor · Accepted solution]

Because LabVIEW is a "Data-Flow" language, it can easily be adapted to "do what you want it to do", namely run a bunch of PSI sensors (I'm assuming they run similar code, but are hooked up to different "things-to-be-measured" and you'll want to be able to collect data from multiple sensors running asynchronously, each with its own set of parameters.

Have you heard about managing data streams using a Producer/Consumer Design Pattern?  This is where you have two loops, a Producer typically one connected to a data-collecting device that produces data continuously, looping many times as more data are acquired (much too much data to store inside the collecting loop), and the other, a Consumer that can "accept" data packets from the Producer and "do something useful" with it, like display it, or stream it to a disk for storage and subsequent analysis.  The two loops run in parallel -- the Producer is "clocked" by the data-collecting hardware (for example, sampling 1000 points at 1 kHz means once a second, you have to "do something" with the data or it gets over-written), while the Consumer loop processes data very fast (writing 1000 samples to disk takes a tiny fraction of a second) and can sit idle until the Producer gives it data.

How does this work?  The Producer, when it gets data, immediately "gets rid of the data" by putting it in a Queue (or a Stream Channel Wire) and "exporting" it to the Consumer, sitting idle waiting for something to consume.  Together, these two loops take very little CPU time -- the Producer basically "waits" for 1 second until the hardware says "Here are some data", and as fast as it gets the data, it ships it out, so of the loop sits "idle" waiting for data 99+% of the time.  Similar story for the Consumer -- when one loop is waiting, the other can be processing (or waiting).

There's a related Design Pattern called the Master/Servant pattern,  The Master says "I have N PSI devices that I  want to run simultaneously", and spins up N "Servants", a LabVIEW VI that "knows" how to run one PSI device and "do something useful with the data".  Each Servant is assigned a PSI device (you don't want the Hired Help to squabble over who gets to use PSI #1 -- the Master provides that information.

Note that since you are doing Data Acquisition (I'm uncertain what a PSI device actually is, but I'm pretty sure it involves collecting data from something and doing something with it, at a minimum displaying the data coming in and saving it to disk for later analysis.  OK, so the Servant (once it knows what device and possibly what file name to use for the output) can simply "do its thing" using a Producer (for the hardware) / Consumer (for the display and data storage) design.  You want, ultimately, for the Servant to run inside its own VI, and you want to be able to "spin up" as many of these VIs as you have simultaneously-running Data-collecting/displaying/saving tasks to run.

So how do you get almost-identical VIs (Servants) to run and remain under the control of a single top-level VI (the Master)?  Tune in next week when we'll discuss clones and starting VIs running asynchronously ...

[Don't get discouraged!  LabVIEW can do this!  Getting started and learning to do something complex like running multiple (and I assume functionally identical) instruments simultaneously does have a learning curve, and is best down in collaboration with a colleague to help with the learning process.]

Bob Schor

[GerdW]

Hi yup,

---

@yup860 wrote:

 Is it bad practice to make the who psi vi into its own subvi and expect it to function properly?

---

It's only bad practice when you forget to THINK DATA FLOW!

You can run a lot of VIs in parallel when you transfer data with better methods. Look up for QMH schemes as explained by example projects in LabVIEW...