Problems with PCI-6111 Analog Input timing

[SNL_NB_1167]

I'm trying to read the analog input of a PCI-6111 which is receiving a 1 KHz square wave with a duty cycle of 50%.  I set the sample rate to 1 MHz and expect that the data points are 1 usec apart.  When I check the waveform received, it appears that the duration of each period of the square wave is 1.22ms instead of the expected 1.0 ms.

The following is a code snippet of what I tried:

        int NUM_SAMP = 10000;
        DAQmxCreateTask("",&mTaskHandle);

DAQmxCreateAIVoltageChan(mTaskHandle,

   "/Dev1/ai0","",DAQmx_Val_Cfg_Default,-10.,10.,DAQmx_Val_Volts,NULL);

DAQmxCfgSampClkTiming(mTaskHandle,"",1000000,DAQmx_Val_Rising,DAQmx_Val_ContSamps,NUM_SAMP);

DAQmxReadAnalogF64(mTaskHandle,NUM_SAMP,10.0,DAQmx_Val_GroupByScanNumber,mDataBuf,NUM_SAMP,&numRead,NULL);

Can you tell me what I'm doing wrong?

[Brandon_B]

Hello,

Thank you for using NI forums.  For the most part I would say that this code looks correct.  One thing I did notice is that you're not calling the DAQmxStartTask function.  Have you verified the frequency of your square wave by measuring it on an oscilloscope?  Also, what pins are you using on the 6111?

Regards,

[SNL_NB_1167]

The reason I'm not calling the DAQmxStartTask function is because the read operation should start the task automatically (as indicated in the help documentation for DAQmxStartTask).  Since I'm getting data, I assume this is correct.

I checked the frequency of the square wave using a calibrated oscilloscope and it is correct.  Also, I had the PCI-6111 calibrated and it passed all tests.

I'm using the analog input 0 BNC connection of an NI BNC-2110 to input the square wave.  I'm assuming the signal is mapped correctly via this interface, but don't know which pins are being used.

[ColeTrain · Accepted solution]

Hello SNL_NB_1167,

A good place to look at code you know works would be the example finder.  Open the example finder and browse to Hardware input & Output»DAQmx»Analog Measurements»Voltage»ContAcq-IntClk.prj

Run this code and see if you are getting the same results.  If so, then we would know that this is a hardware issue and not an issue with the programming.  If you see the correct behavior, then you have code that you can model yours off of.  Hope this helps.