LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

5khz 1 minute capture - what am I doing wrong?

Solved!
Go to solution
I am using LabVIEW 8.0 and an USB-9162 DAQ to record pressure data from a microphone. I have been capturing 1-5 second samples at 5khz using the "N samples" functionality of the "DAQ assistant" block. However, I now need a 60 second continuous sample at 5khz, which gives 60*5000=300,000 samples. I have never gotten the program to complete at this large of a sample set. I tried 20 seconds and it still never finished, but 10 seconds did (on time). I'm writing to four different text files as well, but I disabled that for this test and am just displaying the data in graphs.

Am I overflowing a buffer in the DAQ or something? It seems like I had actually done this test before (300,000 samples at 5khz) and it worked fine. Any ideas?

Thank you for your time,
Eric
0 Kudos
Message 1 of 14
(4,485 Views)
10 seconds is the standard time-out time for a lot of DAQmx functions.
DAQ-assistant is a nice starter for such projects, once you get nitty-gritte leave it (and never look back).
You should do a continous acquisition and read every half-second the last items and store them to disc. Stop this routine after one minute.

Ton
Free Code Capture Tool! Version 2.1.3 with comments, web-upload, back-save and snippets!
Nederlandse LabVIEW user groep www.lvug.nl
My LabVIEW Ideas

LabVIEW, programming like it should be!
Message 2 of 14
(4,471 Views)
Thanks for your reply!

I know how to run continuous, but would I read by the half-second? Would I need to write some code for this or is it something in the "write to measurement file" block?

Thanks,
Eric
0 Kudos
Message 3 of 14
(4,454 Views)
I've determined that even 10.2 seconds (51,000 samples) will make labview record indefinitely. 50,010 samples ran okay, though. But it definitely does look to be a timeout in the vicinity of 10 seconds.
0 Kudos
Message 4 of 14
(4,439 Views)
Now I am throughly confused. I tried to run continuous mode with the intention of simply trimming the meausurement file by hand, but the first sign of trouble occured when I selected continuous mode but it did not "gray out" the "samples to read" dialog. However, it ran continuously when I clicked the " run continuously" button (but not the "run" button).

What's really bad though is that the "sample to read" number is controlling the time stamp of the measurement file. If I have 50,000 samples in that dialog (which will not gray out or allow me to remove a value, it autoinserts the last one if I just delete the number) at 5khz, it runs from 0-10 sec and repeats in the file, with 10,000 samples it does 0-2 seconds and repeats, etc. Mind you, it is continuous, but the timestamp is in error, and it's not just at the 10 second cutoff.

So I have a way of ostensibily getting continuous data, but depending on the sample size driven mechanism that revealed by the timestamp behavior I may be experiencing discontinuities in data collection at the timestamp restart point. Plus my timestamps are wrong which is going to confuse anyone looking back at the data Smiley Sad

Any ideas? I DO recall being able to run continuously before just by clicking "run" when the DAQ assistant was set to continuous. I don't know why that option would become nonoperation.

Thanks for your time,
Eric
0 Kudos
Message 5 of 14
(4,421 Views)
Although it's goofy, I have a workaround - set to continuous mode and set a really high "N samples" and the timestamp goes from 0 to infinity and does not repeat periodically. This is good enough for me Smiley Happy
0 Kudos
Message 6 of 14
(4,418 Views)
Hi Eric,

never, never ever, under no circumstance (ok, very rare conditions) use that "run continuous" button!!!

That being said:

Use a while loop around your DAQ code. Get samples of 0.5 seconds in the loop, save them to file and re-iterate. That is what being meant by "continuous aquisition"!
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
Message 7 of 14
(4,417 Views)
I think I understand why you say that; I found the following discontinuity in my measurement files, with 1st column being time.

Differential Pressure Transducer Voltages
9.845200    5.846405
9.845400    5.850229
9.845600    5.847361
11.812275    5.810388
11.812475    5.813894
11.812675    5.818356
Ouch.

Although I have no idea how to implement it in LabVIEW (will read the user's manual), will using the described while loop "skip" an appreciable amount of time between iterations? I'm using the pressure data to generate FFTs and then power spectral density graphs to examine their frequency content. The frequencies of interest are about 200-500hz, so I would guess that any time skip could miss important peak frequency changes, etc. I am not trained in signal processing, but I want to insure that all the data I take it sound and tight as possible so that it can be taken apart with a finely toothed comb if necessary.
0 Kudos
Message 8 of 14
(4,413 Views)
Hey sippy, I would recommend looking at some of the DAQ examples that LabVIEW comes prepackaged with. If you go to Help >> Find Examples it will open up the Example Finder and you can select the Hardware Input and Output >> DAQmx >> Analog Measurements >> Voltage directory. There are several examples that show both finite and continuous acquisition. I would suggest starting with the Cont Acq&Graph Voltage-Int Clk.vi.
Adam

National Instruments
Applications Engineer
Message 9 of 14
(4,377 Views)

Fast foward 6 months! This issue has come up again and it's time to fix it. I have examined the example you mentioned and I think I can modify it to work for me. I'm going to do long-time measurement by iterating the while loop a set number of times. I have already run a modified example that does this and writes it to disk by grabbing 0.5s segments in a while loop, so I know it will work.

 

However, I need to know if the loop is dropping any bits between iterations. I figured I would place an elapsed time VI both in the measurement/write while loop and in a separate while loop, and see if their values differed. If they did, then in theory I would know how long the while loop "disconnected" between iterations.

 

But I have two questions:

 1. When a while loop completes an iteration, stops, checks stopping criteria, and then starts a new iteration, does the elapsed time VI inside the while loop stop counting from the end of the last iteration to the beginning of the next iteration?

 2. This is kind of a dumb question, but my second (just the elapsed time VI) while loop won't run until the first one finishes. This manifests in the fact that the first (measurement/write loop) timer starts and stops on the fron tpanel, then the dedicated timer loop timer starts on my front panel. Am I missing some sort of execution control on my while loop?

 

Thanks for your time,

Eric

0 Kudos
Message 10 of 14
(4,206 Views)