LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Queues: using SubVIs as Producer and Consumer

To any LabVIEW developers out there,

 

I have been writing a program to acquite and log data from DAQmx. I am nearly finished already, but I recently encountered a problem.

I needed four channels for my expriment, so I thought that I would prototype one first then make it into a subVI and duplicate it three times.

The program had been working well until I made some part of the mainVI into a subVI: no data was enqueued and sometimes the program wouldn't stop when I pressed the stop button (Broadcasted to SubVIs via the "Global Process Stop" Global Variable.) I should mention that in the experiment,there are many conditions which each will be repeated many times (that's the purpose of the for loop in the top subVI). Each experiment is separated by a "-1" data and a "-2" data means the end of acquisition for that condition. 

 

I have attached a snippet of the main VI and the SubVI mentioned. In the mainVI snippet,  there are two subVIs shown: the top one is the producer loop which will acquire data from the DAQ hardware and enqueue the data; the bottom one is the consumer loop which will dequeue data and log the data into a TDMS file. 

 

Any further details needed, please don't hesitate to ask. 

Thank you in advance! 🙂

Download All
0 Kudos
Message 1 of 3
(2,828 Views)

Your code relies too heavily on global/local variables and frame structures. Take time to learn how to use data flow to control your execution. Flat sequence frame structures can generally be replaced with a state machine. State machine are much easier to control, modify and maintain.

 

How are you executing your code? I don't see any control loops. Are you using the run continuous button? If so, this is not the correct way to execute your code repeatedly. Do not use "special" values to control your operations. Your queues should use messages, not just numbers. One of the most flexible message types is a cluster which contains a message type (either a string or a typedefed ENUM) and a variant. Based on the message type the variant con be interpreted corrected as the proper data type for the message. Some mesages will not need to actual have any data. For example, an "Exit" message would not need any data while a message such as "New Data Value" would carry the actual data as well as the message type.

 

You should spend some time going through the examples looking at the state machine and producer/consumer examples. These will help you to improve your current code.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 2 of 3
(2,780 Views)

Do what Mark has recommended.

 

To start an answer for your question, the other three channels you are looking to add will be additional rows to your data comming from the DAQmx read VI.  Each row will be a channel of data.  Don't make a subVI for the sake of making a subVI, break up your code where is makes sense to do so, and where you will avoid duplication in the future.  For the most part, you may be able to change your double precision wires to 2D arrays and make what you have work (but again, follow Mark's advise and make the improvements you can to the code).  Press the down arrow on the DAQmx Read VI and select multiple channels and continue with your selections.  Additionally, you can write better code by naming your VIs with straight forward names, such as Producer.vi instead of Top.vi.  Then your peers can get an instant idea of what your code is suppost to do, instead of having to open it up and look around.

 

I dont' know what kind of speed you are hoping for from this application, but the way have it currently will be slow from data point to data point.  If you are hoping to get anything more than maybe 2 data points per second, you will need to move your DAQmx start and stop VIs outside of your for loop on your producer code.  You should only have to start and stop once per experiment, unless there are some advanced extenuating circumstances you are trying to code around.

0 Kudos
Message 3 of 3
(2,746 Views)