how can i set the Daq rate on the compactDAQ NI 9237?

[manliff]

I am using the  NI 9237 module in the CompactDAQ 9172 chassis, with a single channel.  I am using LabVIEW 8.2. I cannot find any software where I can set the DAQ rate on the module. The "daq assistant" in LabVIEW, the "Measurement and Automation explorer test panel and the example VI's all seem stuck at a rate of 5000 samples/sec. I only need 32 samples/sec.  The software offers an input variable for "rate" but does not respond.  Note that in the"Measurment and automation explorer test panel seems to allow higher rates but not lower.  Am I missing something?   My application has been crashing from time to time for not being able the retreive the data fast enough, I thought to minimize the rate to lower the transfer load on the operating system.

[Abhinav T]

Manliff,

The 9237's specifications say that it can only sample at rates 50kS/s / n where n is 1,2,3 ... 31. This is actually incorrect, n can only go up to 13 (40R8O95I). So regardless of what rate you give the task, it will be coerced to one of the valid sampling rates (the lowest being about 3.84kS/s).

Your specific error about pulling data fast enough is related to the number of samples per channel, you can sample at higher rates by increasing the number of samples per channel.

Abhinav T
Applications Engineer
National Instruments

Message Edited by abhinav T on 10-30-2006 03:27 PM

Message Edited by Support on 10-30-2006 04:05 PM

[Abhinav T]

Manliff,

I wanted to clarify something a little further. The limit for the value of n is a limit on the current version of the NI-DAQmx driver(v8.3). When the 9237 is used with a cRIO chassis, n can be increased to 31. At this time you will not be able to sample any slower.  This issue should be fixed in the future however.

Please refer to this post for more details.

Abhinav

[lopez]

Manliff,

I seem to be having a similar problem with reading data using the 9237, I have tried setting the rate on the sample clock, changing the number of samples and inserting timers to my loop, but I keep crashing with the error that I need to acquire samples faster (in continuous mode). However, if I do this, I cant write data to file without it being a huge file.

Any advice as to how I can use the finite sample mode on the sample clock?  I try using this and getting an error that I try to read past the available sample point, even though I set the sample clock to 600 samples and 5 samples/sec, which should allow it to run for two minutes.

Thanks for any advice.

Alfonso

[Jarrod_B.]

Hello Alfonso,

It sounds like you might be getting errors -200279 and -200278.  (In the future, if you post the actual error codes, it helps us to know exactly what is happening).  Error -200279 happens when you are performing a hardware-timed acquisition (meaning the data is sampled according to a clock signal on your board), but your LabVIEW program is not reading the values from the buffer allocated for that task in computer memory fast enough.  Basically it's a buffer overflow error.  It means older samples have been overwritten before you attempted to read them out.  As the error message suggests, "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."  For more information on this error, please see the KB (DAQmx) Error -200279 During a Continuous, Buffered Acquisition.

Error -200278 happens most often when you have configured a finite acquisition, but are calling the DAQmx Read function in a loop.  If you want to perform a finite acquisition, you should only call DAQmx Read once.  For more information on this error, see the KB Error -200278 at DAQmx Read.

Finally, please refer to Abhinav's earlier post about the sample rate on the 9237 module.  As he described, the NI-DAQmx 8.3 driver will only allow you to set the sample clock to integer divisions of 50k (50,000/n, where n can be 1, 2, 3...13).  Since the maximum divisor is 13, the smallest sample rate that can be used is 3.846 kS/s.  You can check what value the driver is actually using for the sample clock by reading from the SampClk.Rate property of the DAQmx Timing property node.

I hope this helps!  Let me know if you have any questions about what I've described.

Best regards,

[KyleBryson]

Hi Alfonso,

You won't be able to sample at a rate as slow as 5 Hz; see previous posts.  However, it should be pretty simple to only save every 1000th sample to disk if you want to log values at a much slower rate than you are sampling.

In general, you shouldn't need a timer in your data acquisition loop; if you (for example) set your acquistion to 5 kHz, put the DAQmx Read VI in a loop and read 1000 samples each time, it will execute at 5 Hz.  You could then log a single point to disk, and display, process, or discard the rest of the data.

Regards,
Kyle

[lopez]

Jarrod and Kyle,

thanks for your comments.

Jarrod, your explanation was very good, I understand what is causing the problems regarding data acquisition and write to file. I will implement discreet data write as per Kyle's suggestion.

Thanks.

[lopez]

Jerrod and Kyle,

I have focused my program to deal only with the write portion . I have included it here. the current solution works to cut down the amount of data written to file.

What I did not realize clearly is that all previous runs of this program are stored in the same data file. One is appended to the next.

It would be usefull to write to the same file name each time, but delete the data from previous runs.  Can you point me in the direction to clear the file before it is opened?

I tried using "TDSM flush" vi. but this only clears the current memory, not the hard file. I am sure there must be a vi to do this, I just don't know where it is.

Thanks again.

Alfonso