What is the best way to run two programs simulataneously using the output from one to run the other?

[twolfe13]

I just kind of wanted to get an opinion from some people on here. I have two main VIs. The first is a DAQ system that reads 99 different sensors and feeds that data into an array. The second is a real-time processing system that is designed to take the array and do numerous calculations. Both VIs output data to the front panel that I want to see, so I don't want to just use one as a SubVI.

Is there a simple way to run both VIs, using the output from the DAQ system to feed the processor so that you can easily see the front panels of both VIs? I had considered just copying the real-time processor code into the DAQ VI, but I'm worried the resultant VI will be very large and unsightly.

On a side note, am I over thinking this? Excuse me if this is a rather dumb question, it's been a long week...aaaand it's Wednesday.

[johnsold · Accepted solution]

Look at the Producer/Consumer Architecture.  It will be a good starting point, although you may find that you need to modify it.  By running the DAQ and processing tasks in parallel loops, they can both run simultaneously.  Both can feed data to the main VI panel.

I would probably use three loops with the third being the only user interface.  Anything which is to be displayed to the user is sent to the GUI loop from the DAQ or Processing loops and any commands or inputs from users are sent back to those loops, probably via queues.  The DAQ VI panel and the processing VI panel are never displayed to the user.  Especially the processing, since it is running on a real-time system, should avoid the timing issues that a GUI can present.

Lynn

[LV_Pro]

There are a number of ways that you can go about this, but having both front panels open isn't a problem (assuming there is screen space!). Both could be sub-vi's of another "calling" vi, with their front panels set to open when called. The data from the DAQ side can be sent to the other through a number of ways, "producer-consumer" (many threads about this topic, examples in the LabVIEW examples, etc.) is one of the more robust techniques. If created correctly it allows one to run at a different rate than the other, although if the producer is "producing" much faster than the consumer can "consume" it will end up with problems.

I guess I type too slowly

[LV_Pro]

I second the suggestion of running the process and DAQ parts "in the background" and displaying the info in a GUI vi, anytime you display the front panel that vi runs in the "User Interface" thread, which is already pretty busy dealing with display stuff. I don't know if you meant that the processing is running on a "Real Time" system, or just meant it is trying to do the processing as the data becomes available, but either way, you don't want it running in the UI thread, which it will if it has any user interface displayed.

[Ray.R]

(if you are using sub-vi's)

In addition to the above (which I have not fully read), if your sub-vi's Front Panels are not too big, you could have a main VI that has two sub-panels which run the sub-vi's.  Your data can then be exchanged using (a) queue(s) or using references.

The use of queues and/or references can also be used without the use of sub-panels.

[JÞB]

I've got to second Ray's remarks about using sub-panels! It's pretty important to limit the number of copies of the DAQ data (99 sensors can generate a LOT of data)  Passing the data from the DAQ vi to the vi that acts on the data is going to be a lot faster if you use a Queue or DVref since the "Writer" and "Reader" will share a single copy of the data.

[H_SH]

I will go with early suggested Producer/ Consumer Architecture. Three loop is good option as all doing different task of acqusition, processing and representation. Select only relevant data to show on screen.

- HS

[LV_Pro]

Keep us informed of your progress, it sounds like an interesting project.