Multifunction DAQ

Showing results for 
Search instead for 
Did you mean: 

Continuous data acquisition and save using DAQmx

Hello !

This is my first post here, I hope I didn't miss an obvious answer in the huge documentation avalaible on NI site, sorry if it is the case.

First, the configuration I'm using : Pentium 4 (2.8 GHz) PC with 1 GB RAM using Windows XP SP1, Labview 7.1 with NI-DAQmx 8
 and a rather old PCI-MIO-16E-4 NI card.

I'd like to continuously acquire data and stream it to the hard drive for further evaluation. Regarding data sampling, the faster, the better, regarding acquisition length, it might be very long (specially considering the card's max frequency that is at 250 KS/s). Using traditional NI-DAQ, I'm aware of the continuous buffered acquisition example, but I don't find an equivalent to buffered acquisition using DAQmx. Is it enough to just select "continuous acquisition" and put the data read in a while loop ?
0 Kudos
Message 1 of 11
Yep, you've got the right idea.  Some of the naming conventions have changed from Traditional (Legacy) NI-DAQ to NI-DAQmx.  The term "Buffered" is no longer used, simply because NI-DAQmx takes care of all that stuff behind the scenes.  So, to answer your question:  Yes.  If you have set up a continuous acquisition and do a DAQmx Read in a while loop, it will be "buffered".  And NI-DAQmx will give you appropriate errors if you ever have buffer over/underflow or timeout issues.  One other thing to mention with file I/O, make sure not to do the opening and closing of the file inside the while loop.  That will cause way to much file I/O overhead.  You should open the file before the while loop, write to it inside the while loop, then close the file outside the loop.  Note:  The easy file I/O VIs, like "Write to" will open, write, and close the file.  So you probably want to stay away from those.  Hope this helps!
-Alan A.
Message 2 of 11

Oh, forgot to mention.  When you install NI-DAQmx, tons of great examples are installed.  Check out the example finder in LabVIEW.  Go to Help>>Find Examples.  Then navigate to Hardware Input and Output>>DAQmx.  Then for analog input, go to Analog Measurements>>Voltage.

0 Kudos
Message 3 of 11
Well, I forgot to thank you for your fast answer, it's done, now.

I was aware of the examples, which are often a great source of inspiration for me.

Since I wanted to minimize both bandwidth requirements and hard disk space, I decided to start from the exemples showing how to deal with compacted data (you can find them at : )

However, I seem to encounter a bug in my application, which I can't explain : from times to times, the application crashes, with a message such as that joined in the bmp attached file.
I've tried both to lower the sampling frequency (down to 100 kS/s) or raise the samples number (up to 4096 samples, which does not seem to impact the effective buffer size allowed by the DAQmx driver), but nothing changes. When I try to make really long runs (say, 1 000 000 acquisitions), the application crashes after an unrepeatable number of measurements. I tried to play with XP's "Advanced" Performance's settings and with the vi executable thread behavior (via the Properties / execution pannel), but nothing changes. Of course, there is enough space on the hard drive.

My application is a small deviation from the basic single channel compacted data example, I've joined it for reference (sorry for the ugly diagram layout). Any comments / ideas on where to dig are welcommed.
Download All
0 Kudos
Message 4 of 11

Hello mseb,
I've got a couple things to mention.  First, you are on the right track with solving this problem.  As the error message indicates, some samples are being overwritten before they are read, which boils down to the fact that the loop with the DAQmx Read simply isn't being executed fast enough or perhaps we just aren't reading enough samples in each iteration.  The tricky thing about this type of problem, is that the rate in which this error occurs is usually completely system dependent.  On my machine (P4 3GHz, 1G RAM), I can not reproduce the error at 250k S/s and 1,000,000 reads (2048 samples to read) which is of course 2048 million samples.  I had to decrease the number of samples to read (In your program, Points/bloc) to less than 20 before I received the error.  Anyway, my suggestions are to read more samples per iteration, so increase your Points/bloc, even by a factor of 10x or so would probably be ok.  Additionally, you can explicitly increase the size of the buffer that is allocated by NI-DAQmx, which might be necessary for your system.  NI-DAQmx automatically selects a buffer size based on the sample rate (see image from NI-DAQmx help below).  However, you can explicitly increase the size of that buffer using the "DAQmx Configure Input", located on the NI Measurements>>DAQmx - Data Acquisition>>DAQmx Advanced Task Options palette.  Hope one of these (or both) helps!
-Alan A.

Message Edited by Alan [DE] on 01-30-2006 11:33 AM

0 Kudos
Message 5 of 11

One other thing I noticed (and this is purely a LV programming suggestion) is that it looks like you want to start your acquisition on a button press.  The best way to go about this in LabVIEW is to use an event structure.  Take a look at the attached simple example.  You might want to consider this for future apps.
-Alan A.

0 Kudos
Message 6 of 11
Once again, thank you for answering fast.

The point is that our machines seem very similar. I'm aware of the origin of the failure, however, I don't understand where its roots are : your machine and mine should behave similarly IMHO. Required memory and disk bandwidth must be small enough to fit in my system's specs, according to rough analysis. This seems indeed the fact, since the acquisistion might run for more than 30 minutes without problems.
That's the reason why I think it might come from an "accident", but I could'nt figure it. I've checked windows power saving paramaters as well as the screen saver : they should not be the problem.
As for the buffer size, maybe you can enlighten me : it's in RAM isn't it ? According to the docs, my device has an onboard memory of 512 points, which is far less than the 100 kS that should (and actually is) allocated. I'll try tomorrow (I'm at home right now, french time) to increase the buffer size. Do you have a rough gess about the magic number ? 1 MS ?

Thank you for the comment about the "labview programming way"-, it's welcommed, anything other ?
In fact, it's been a looooong time since I've done such things, back to labview 5 days, and moreover, the start button was a fast and dirty trick to do the job, nothing more. Your comment is very welcommed, I'll change this tomorrow (no labview at home).
0 Kudos
Message 7 of 11

Hi mseb,

I have not looked at your VIs, but it sounds like your application is running into throughput problems and is not able to keep up with both data logging and data acquisition simultaneously.

To solve a throughput problem, you need to find the "bottleneck".  Either the data acquisition or the disk throughput is likely to be the "bottleneck" to your application; however, other factors (such as additional processing) can be the bottleneck sometimes.  To determine which part of your application is the bottleneck, try to run either Write to Disk or the DAQmx Read in a loop by itself.  If you want to use Write to Disk by itself, you should determine maximum rate by which you can write data to disk, which will depend on the number of samples you write at a time and how fast your disk drive is.  With standard off the shelf drives you should not expect much more than 10 Mbytes / second.  However, if you have a RAID controller, you may get faster performance.  If it is not the Write to Disk that is slow, then you can run DAQmx Read in a loop by itself and see what is the maximum rate you can acquire data without getting an error.

Also, if you want to increase the DAQmx buffer size, use DAQmx Configure Input Buffer VI in the "DAQmx : Task Config/Ctrl" palette to increase the buffer size used by the DAQmx driver.  The default buffer size depends on your acquisition rate; for high rates the default is 1 million samples per channel. 


0 Kudos
Message 8 of 11
It seems so trivial now !

Increasing the input buffer size up to  1 000 000 Samples, did the job : the application has been running for more than 4 hours now and has not shown the previously mentionned crash.

Thank you all very much for your tips.
0 Kudos
Message 9 of 11

Hello, I'm trying to do something similiar to your application. Would it be possible to get a copy of your application. My program uses a NI-6543 Data Aquisition card and I'm sampling data a 20Mhz with the data being 32-bits. I'm going to set up a RAID system to store the data. Also, I didn't catch what Allen was speaking about using the event structure?





0 Kudos
Message 10 of 11