9213 Conversion Time

[Dave_Thomson]

  I'm trying to use a 9213 TC module in a USB cDAQ-9178 (not cRIO).  I'm using LV 2010 with DAQmx 9.1.5 on XP.  The spec's say that the 9213 can do 1S/s across all channels, or 55ms/channel in high res mode, or 75S/s across all channels in high speed mode.  The problem is, my program bogs down when I configure more than a few TC channels.  I'm try to run at a 1 Hz loop rate, but if I configure more than 3 TC channels on the 9213, the DAQ call becomes greater than 1 second.  I put in a property node that reads the "Max Rate", and with 14 TC channels configured, it says the max rate is 1.2 Hz.  Should still work.  But the DAQ alone takes more than 2.5 seconds.  WIth 4 channels configured, the Max rate claims to be 4.5 Hz, but the daq call takes 860 ms.  This is with Constant cjc Source and No AutoZero.  With internal cjc and Every Sample AutoZero, it gets a bit worse, as expected.  The NI example for a single TC measurement shows a similar problem.  Note that I've done the timing with Tick Count before and after the daq call.  The profiler claims the daq call is taking no time, but that's because the call is interupt based, so apparently the time is lost just sitting waiting for the daq call to have data ready.

Two questions:

Why is the 9213 so much slower than the specs and the property node say it should be?

Where is the property node for selecting High Speed mode?  I found it in a cRIO example, but no mention of it in any DAQmx examples, and I can't find it in the Class Browser.  In cRIO it's called Conversion Time with options "High Speed" and "High Resolution".

Thanks,

   DaveT

[Jim_S]

Hello Dave,

After looking over your post, it looks like you are having problems with NI 9213. From reading your forum it looks like you are trying to acquire at 1 Hz frequency but it takes longer than 1 second to record all the data. In order for me to understand your system more completely, I have a few questions to ask:

1.) How are you setting up the timing for the task? Are you using continous, finite, or software timing?

2.) If you are doing this, how many samples are you asking for on your DAQmx read?

3.) If you are using software timing or On Demand sampling, I would change this so that you are using hardware timing. This is going to reduce the amount of time it takes to get the information from the card. Here is an example that I would start with to see if this fixes the problem:

As for changing the ADC timing Mode, this property can be changed by using the DAQmx Channel property under Analog Input >> General Properties >> Digitizers/ADC >> Timing Mode.

[Dave_Thomson]

Jim,

  Thanks for the reply, especially for pointing out where the resolution/timing property was.

  I found the problem.  I am using software timing, similar to the Cont Acq Thermocouple Sampels - SW Timed.vi in the Example Finder.  The critical difference was, I had forgotten to include a DAQmx Start Task VI.  If you leave that out, the data acquisition still works, but it takes much longer.  I wonder if it is init-ing and closing the task for every call in that case.

   Anyway, it's working now at the advertised rate, even with software timing.

Thanks,

   DaveT