NI-9212 first scan shows old data?

[ChronicTiger]

Hello,

Has anyone experienced this with a 9212? The task is always created and closed out formally.  Maybe it's not old data?  Could the first scan just have bad data?  The code is like any other task - create task (continuous), setup timing, set ADC to high speed mode, start task, enter into While loop for reads.  I also use a DAQmx Read property to set "Overwrite Unread Samples".  Setting that property makes be believe that if there are old samples hanging around that they'd be overwritten.  I cannot figure out why my first scan of TC data looks bad.  There is an AI module and a Dig I/O module as well - the data from them is always accurate first scan.  

Any thoughts would be appreciated!

Thanks!

[JÞB · Accepted solution]

Its difficult to guess without any code or data attached.  But, I'll offer some insights

• The overwrite old data property only effects what happens when the data buffer fills. It does not change anything about the first sample  
• The 9212 does have open TC detection.  When set to High Speed mode the Open TC detection circuit can introduce a expected (but sometimes surprising) settling delay.  If this is what is really happening there are two experiments you can try performing to see if that is the cause.
  • See if the data changes using hi resolution mode.  Most temperature changes DO NOT happen at 30CPS anyway!
  • Commit the Task using DAQmx Control Task.vi 0.75sec prior to Starting the Task. Explicitly Committing the Task will "spin up" the hardware including the open TC detection circuit but when you just "Create / Start the Task the Hardware is neither Reserved nor Committed until the implied state transitions required to Start the Acquisition.  0.75sec is the Open TC Settling time according to prophecy.

[ChronicTiger]

This is some great information.  Much of which I was not aware of.  Thanks so much for your insight and time.  I most likely wont get on the hardware until Friday.  I will def update you and hopefully be thanking you!

Take care,

Chris

[ChronicTiger]

You nailed it! Thanks!

[ChronicTiger · Accepted solution]

Actually, that was not the solution.  Daqmx "Commit" function does not spin up the 9212's ADC. What I am seeing happens only when the user inputs a data rate higher than the max rate of the 9212. In this case the 9212 does not have enough time to convert the first read, since the first read has to be returned at exactly 10.5ms (High Speed Conversion Time). 

Some useful info from tech support:

The commit function is useful when we want to accelerate the time that takes for the Start VI to initialize the hardware, but in this case, the actual acquisition will start only when the device receives the trigger. Basically, there is no way to accelerate the conversion time of the ADC. 

Our Temperature Modules are the only ones you can set a higher sample rate than what the module is capable of using. The reason is that these modules have a really low sample rate and if we want to synchronize them with faster modules it won't be possible, in this scenario what the driver does is just repeat the last sample taken by the device until a new one is taken with the actual sample rate that the device can handle. 

So for example, let's say you configure a sample rate of 190 Samples per second, which is double the maximum sample rate allowed by the NI-9212, the module will take one real sample, then for the next sample since the device hasn't taken a new real sample the driver will just take the previous sample and store it again in the buffer, then the next sample will be a real one and the cycle starts again. 

[Frozen]

---

@ChronicTiger wrote:

Actually, that was not the solution.  Daqmx "Commit" function does not spin up the 9212's ADC. What I am seeing happens only when the user inputs a data rate higher than the max rate of the 9212. In this case the 9212 does not have enough time to convert the first read, since the first read has to be returned at exactly 10.5ms (High Speed Conversion Time). 

Some useful info from tech support:

...
So for example, let's say you configure a sample rate of 190 Samples per second, which is double the maximum sample rate allowed by the NI-9212, the module will take one real sample, then for the next sample since the device hasn't taken a new real sample the driver will just take the previous sample and store it again in the buffer, then the next sample will be a real one and the cycle starts again. 

---

That makes sense when it is spelled out like that. Hopefully the 9212 manual has similar verbiage?