samples cdaq 9172

[bassinbc]

The following vi allows user to choose 1-8 global channels of data and record either a set number of samples or record for a set time. A file is written to the users selected location. Any channel can be filtered seperately through an IIR filter, and the user can select the rate and sample size. There is a chart display of each channel and a digital display for each. The problem is that I keep getting a timeout of samples. If I set the sampling rate high (say 2500) I start missing samples. I am using the cDAQ 9172 chassis. The error is 200279, attempted to read samples no longer available. When saving samples or when saving a timed save, the number of samples aren't correct at the higher rates. Do I have a problem with my vi logic?

[Doug_L._Bear]

Hey bassinbc!

The reason you are missing samples at higher rates in your files and that you are receiving the error is that you are not writing to file fast enough out of the buffer and are loosing samples as they are overwritten.  This KnowledgeBase Article might be able to address the issue in further detail. This error can also occur if you are not reading off the buffer on the DAQ card fast enough, as addressed here.  Hope this helps!

Doug

Applications Engineer
National Instruments

[bassinbc]

I added the indicator and I do see the count go up at different rates. I have the daqmx timing set to sample clock with a source of onboard clock. If I set this to 80mhz timebase how do I set the x-axis timing to be correct. With onboard clock selected for daqmx timing, the x-axis has to only be set to absoulte timing in the chart properties. When I select the 80Mhz timebase the x-axis seems to be way out of wack. Is the 80 Mhz timing the correct timing to use for getting faster reads?

[DavidMN · Accepted solution]

The 80 MHz timebase can be used for the counter / timer source inputs.  Generally, the 20 MHz or 100 kHz is used to generate the AI and AO timing signals.  This information, and more, can be found in the NI cDAQ-9172 User Guide and Specifications.  As such, the issue with the x-axis is most likely due to the fact that it is trying to use a timebase that is too high.  In order to read faster, we can increase the number of samples per channel to read with the DAQmx read vi, as suggested by this KnowledgeBase article.  Also, you may want to move the DAQ portion of your application towards a producer / consumer architecture, as that can also increase the read rate.  There is an example of the producer / consumer architecture at the bottom of the KnowledgeBase article linked above.  Also, this DeveloperZone Tutorial has a good explanation of the design pattern.

David

Applications Engineer

National Instruments

[bassinbc]

I believe I have the producer/consumer architecture in this version. Also, I took out all the processing in the producer loop. This really seems to speed things up quite a bit. Thanks for the advice. The onboard clock seem to give the best timebase, not sure why. Anyway the event process has a timed save, and that seems to be working well now. Before I would get varying results when I saved the data. The samples saved wouldn't match the rate.