NI 9205 sampling rate if not specified

[JosephM]

Dear all,

    I have an application that requires the generation of a binary sequence (for this I am using NI-9401). After every number is generated the DOs are connected to a demultiplexer, every output of the demux generates a voltage that I must acquire with an NI-9205, i.e. after every number is generated I must acquire an analogue voltage. This process must be very precise. To minimize errors I take 10 readings of everyvoltage an generate an average. I have done this as shown in Reading, but my question is the sampling rate, what is it determining the sampling rate, is it the time if takes LabVIEW to read the Analog DBL 1Chan 1 Samp?

    I have also come to a result as shown in Reading 1, however even when the results are correct, starting and stopping the task in every cycle is not time efficient for my application.

    I am using an 9172 chassis.

   Thank you very much for your help

[Dennis_Knutson]

When you use 1 sample mode, the actual sample rate is dependent on your pc - the OS, the processor, background tasks, etc. When you specify N samples, you are using hardware timed acquisition and the interval between samples is very precise. The time between acquisitions is dependent on your wait function and the same pc variations above. 

As you mention, starting and stopping the task inside the loop is not effecient. Simply move them outside the loop.

[Brad_K · Accepted solution]

Hi JosephM,

Your first picture (Reading.PNG) is using on-demand timing for both tasks. This means that DAQmx doesn't input or output anything until you call DAQmx Read or DAQmx Write, and the timing is entirely controlled by when your VI calls these subVIs. Adding a delay to the for-loop will increase the time between analog input samples, but software timing on Windows has a significant amount of jitter (it may delay significantly longer than you requested).

Your second picture (Reading 1.PNG) uses sample clock timing instead of on-demand timing for the analog input. This makes the analog timing much more precise because the analog input is synchronized to a sample clock that is generated in hardware. However, the digital output is still software timed. You can reduce the time spent in DAQmx Start on the AI task by calling DAQmx Task Control(Commit) outside the loop. This will cause DAQmx to reserve and partially program the AI hardware once per run instead of once per loop.

Do you need precise timing? If so, you need the digital output to be hardware timed too. The cDAQ-9172 supports correlated DIO in slots 1-4, which is hardware timed digital I/O using an external sample clock source (or a sample clock from another subsystem, like ai/SampleClock or Ctr0InternalOutput). To use this, you will have to generate an array or waveform containing the digital patterns you want to output, and in this array or waveform you will control the timing by repeating samples. A couple of example VIs that should get you started: DAQmx/Digital/Generate Values/Correlated Dig Write With Counter and DAQmx/Digital/Generate Values/Write Dig Chan-Ext Clk.

Note that the cDAQ-9172 has two internal counter channels on the chassis that are useful for generating sample clocks for correlated DIO: /cDAQ1/_ctr0 and /cDAQ1/_ctr1. These show up in the physical channel I/O control if you right click and select "IO Name Filtering..." and check the "Internal Channels" checkbox.

If you synchronize your DIO directly to your AI, you may need to insert additional DO samples and discard initial AI samples to account for the time it takes your demux to settle. If you keep using software timing, you may need to insert a software delay to account for settling time.

Is power line noise (60 Hz or 50 Hz) an issue? The sample rate and number of samples may affect how well your averaging eliminates power line noise. Additional signal processing such as windowing may help.

Brad

[JosephM]

Hello Brad and Dennis,

Thank you very much for your help I was thinking that you have told me about 1 sample method, it depends on the system characteristics I just wanted to be sure.   I have performed a large number of tests regarding timing and after the mean is taken it produces good results. I think I will go for this option now. As my data is not noisy I think it is not necessary to apply a windowing method, taking the mean is good enough.

   I cannot put the Start and Stop task outside the loop because then my readings become not as precise as I need them to be, because by the time I take the reading the system seems to have acquired some data that do not correspond to the data I expect after the binary number had been sent, I have tried changing the buffer size with the sample clock in continuos mode but it hasn't worked for me; probably I am missing some point here if you have any suggestions they will be always welcomed.

   I will try using the control task to check the time improvement.

   Thanks for your help again.