CompactDAQ sample rate question... Part Deux!

[chuggins143]

Ref: http://forums.ni.com/ni/board/message?board.id=250&thread.id=57350

Ok, I changed my Sample Rate and Samples to be Read and am now getting 20 samples/sec... now I have an error that keeps popping up.... 

"Error -200279 occurred at DAQmx Read (Analog 1D Wfm NChan NSamp).vi:1"

...with the message

"Possible reason(s):

Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten.

Increasing the buffer size, reading the data more frequently, or specifying a fixed number of samples to read instead of reading all available samples might correct the problem.

Property: RelativeTo
Corresponding Value: Current Read Position
Property: Offset
Corresponding Value: 0

Task Name: _unnamedTask<3>"

 I've never seen this before so I'm not really sure what to do about it.  I'm sampling at 20k Hz.  How would I increase the buffer size? ...or should I just go back to a fixed number of samples?

I do have a question concerning that... a fixed number of samples per what?  ...per second, per run, per test iteration, or what?

Thank you!

Chad

[chuggins143]

I changed the samples from Continious to N-Samples and that seemed to eliminate the error... I'm still a little fuzzy about what it does exactly.. ??

[John_P1]

You'd get that error if your loop rate can't actually keep up with the data coming in.  If using a finite task, you won't receive an error since the task restarts every loop iteration (i.e. there will be some gaps in your data from one iteration to the next).

If you want the loop to run at 20 Hz and avoid throwing away data, you can probably optimize the code a bit by using the lower level VIs along with a producer/consumer architecture.  The write to file coule very well be what is slowing down the loop (especially since you are converting data to ASCII on-the-fly).  The following example shows the general pattern:

Using Producer/Consumer Architecture for DAQmx Read and Write to File

Best Regards,

[chuggins143]

In reality it shouldn't have a problem since I'm only taking data for ~5 seconds at a time and this is happening very infrequently... basically, it dials in my test point, takes data for 5 s and then dials in the next point and so forth.  Dunno, seems to be working ok like this.  I'll run it for now and if I run into data issues then I'll sit down and do some rewriting.

Thanks,

C