LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

aquiring and saving analog data with producer consumer template

Solved!
Go to solution

Someone on this message board, in a separate discussion last week, suggested that I use Producer Consumer template for data acq.  My ultimate goal is to acquire analog data on 1-4 channels continuously, display it strip chart style, and save the data to disk starting when user hits "Start Saving" button (and chart recorder display will continue).  Saving will stop when user hits "Stop Saving" button but strip chart display will continue to run. 

My attempt to use Producer-Consumer template is attached (LV 8.5 only).  It does not work.  I have not yet attempted to implement user controls for saving - I'm just trying to do simple continuous display and save (1 channel) at this point, using this template.  VI runs, but the strip chart is never updated with actual data, and the data file which is saved has zero bytes in it.

Thank you.

 

0 Kudos
Message 1 of 8
(3,825 Views)
Solution
Accepted by topic author WCR

WCR,

 

 

Looked at your code, and you're right.  It won't work.

 

Take a look at this example:

 

http://decibel.ni.com/content/docs/DOC-2431

 

The acquisition VI should be inside the producer loop.  Also, you need to tell it how many samples to get (otherwise, it will get 0).

-Matt Bradley

************ kudos always appreciated, but only when deserved **************************




Message 2 of 8
(3,823 Views)

Thank you Matt!  I changed my code as you suggested, and more.  Problem solved, and now I can turn saving on and off with button pushes, without interrupting strip chart display.  New version attached.

 

Remaining concern:  I tried deleting the 125 ms wait timer in the "producer" loop, and when I did, the amount of data saved dropped from 1000 points (at 100 Hz sampling rate for about 10 sec) to about 10 points.  Why?  Does it mean that a few data points are dropped every time the "producer" loop recycles?  This may not be enough to be obvious if recycling is every 125 ms or slower, but it would still be intolerable.  I can't just lose a few data points on a recurring basis.  (I have restored the 125 ms timer.)

 

Remaining wish: Now, when user first clicks "Start saving", user is prompted for a filespec to save to.  Then, if user clicks "Stop saving", then clicks "Start saving" again, the second batch of data is appended to the same file as before.  I would prefer the user be prompted for a new filespec.  I tried to accomplish this by movin ghte shift register with the filespec "in" from the outer consumer loop to the inner True/False box, but this was not allowed.

0 Kudos
Message 3 of 8
(3,808 Views)

How do you know you are losing data?  Without the 125 msec wait timer, I don't think you'd actually lose any data.  But the producer loop would be able to run very quickly, possibly quick enough that no new samples would have been acquired to be read by the DAQmx read and you wind up passing empty arrays into the queue.  And that would make the consumer loop run much faster as well without doing a whole lot with empty arrays.  But it probably could not run as fast as the producer loop.  So having the 125 msec wait slows down the producer loop enough to have a chance for some data to be acquired and gives some time for the consumer loop to be able to keep up.

 

If you'd like to have a new file each time Save is pressed, put another case structure inside the one you have.  Store the value of the Save button in a shift register.  You can have the inner case structure run when Save is now true, but it was false on the previous iteration.  You wire path through in the true case, but put an empty path constant in the false, so that it will ask you for a filename when you hit save now, but it wasn't saving on the previous iteration.

Message Edited by Ravens Fan on 06-15-2009 11:27 PM
Message 4 of 8
(3,801 Views)

Thank you, Ravens Fan, for that great solution to the file naming question.  Your solution is simple and elegant and best of all it works.  (I too am a Ravens fan, and before that a Colts fan, in the Johnny U days.)  I am working at Univ. of Delaware athletic complex, across the parking lot from the stadium where Joe Flacco played as an undergrad.)

 

I think I'm losing data when I remove the 125 msec wait timer because in 5 sec at 100 Hz, I only get 6 samples instead of 500 as expected.  When I put the timer back in I get the expected amount, at least approximately.

0 Kudos
Message 5 of 8
(3,765 Views)

It's good to hear from another Ravens fan.  Unfortunately, I was never a Colts fan.  I was an Orioles fan first.   The colts left town before I started following football.  Did you hear that the Orioles drafted Joe Flacco's brother?  If he would happen to make to the majors for the Orioles, we can be Wacko for Flacco for both major league teams.

 

That is strange about losing samples.  I would put an error indicator after the DAQmx Read to see if there are any buffer overwrite errors occurring.  Perhaps only have the Enqueue data occur in the event that the array of data read is not empty.  Perhaps the queue is flooding with a bunch of empty arrays and it is slowing down the overall code.

 

On the VI you just posted, watch out for that last while loop.  I'm not sure why it is there.  It will either run once if the boolean going in is True (and do nothing in the process) or run forever if the boolean goin in is False (and do nothing at top speed.)  Once that while loop starts, the value on the boolean wire can never change.

Message 6 of 8
(3,759 Views)

Got rid of the loop you said to get rid of.

I added the error indicator, and with the 125 msec wait, there were no errors.  I don't plan to investigate possible errors with the no-wait case cuz I don't need to; I can live the 125 msec wait.  I also collected a triangle voltage waveform at 100 Hz (with 125 ms wait) and carefully inspected it graphically for missed points, which would cause a greater than normal jump between adjacent points.  No points were missing.

I had not heard about the other Flacco.  I hope he succeeds.  I lived near Memorial Stadium back when it had two teams, and when it went down to one.

0 Kudos
Message 7 of 8
(3,756 Views)

Yes.  There is no reason not to have the 125 msec wait.  I was just curious as to why eliminating it would cause a problem.

 

Here is a story about Mike Flacco.  What I didn't realize is that he was playing at a local community college that is very close to where I live.

http://www.baltimoresun.com/sports/orioles/bal-osflacco0611,0,4192084.story

 

Read a little further and you'll see the O's also drafted Steve Bumbry, Al Bumbry's son.

Message 8 of 8
(3,753 Views)