NI 9217 randomly returning zero results using DAQmx C driver

[mbconcept]

I have a NI-cDAQ9178 along with a NI-9217 RTD module and am using the DAQmx C driver.

I configure the module to take readings every 10ms. Every 100ms, I ask the module for all available readings. I randomly get zero readings from the module.

I configure the module using the following:

DAQmxCreateAIRTDChan(taskHandle, moduleAddress, "", -50.0, 500.0, DAQmx_Val_DegC, DAQmx_Val_Pt3851, DAQmx_Val_4Wire, DAQmx_Val_Internal, 1e-3, 100.0)

 And I read the values using the following:

DAQmxReadAnalogF64(getTaskHandle(), DAQmx_Val_Auto, .01, DAQmx_Val_GroupByChannel, readValues, readArraySize, &numSamplesReadPerChannel, NULL);

Any ideas why I sometimes receive zero readings?

Thank you for your assistance.

[Brad_K]

Hi mbconcept,

Does your program check the error codes returned from all DAQmx functions? I bet you're getting a timeout error along with those zero readings.

Setting the timeout to 10 ms doesn't configure the module to take readings every 10 ms. Instead, it tells DAQmx, "give up and return an error if the data I asked for isn't available within 10 ms". Does your program also call DAQmxCfgSampClkTiming() and DAQmxSetAIADCTimingMode() to configure the module timing, or is this all the DAQ-related code?

Brad

[mbconcept]

Brad,

Thank you for the reply and sorry for my incomplete post. I do call the following:

DAQmxCfgSampClkTiming(taskHandle, "", 100, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 20));

Most of the time I receive 10 samples per reading (as expected). Sometimes I receive 9 or 11 which is probably because my computers clock is not synchronized with the DAQ clock which is fine. The problem is that sometimes I receive zero samples.

Thanks,

Mike

[Brad_K]

Hi Mike,

> I do call the following:

>

> DAQmxCfgSampClkTiming(taskHandle, "", 100, DAQmx_Val_Rising, DAQmx_Val_ContSamps, 20));

Good, you need to set the sample clock rate to 100 S/s if you're expecting to read 10 samples every 100 ms.

Note that the default conversion time for the NI 9217 in CompactDAQ is 200 ms per channel, so setting the sample rate to 100 S/s is going to cause the chassis to return repeated samples. To convert all channels every 10 ms, you need to select high-speed mode by calling DAQmxAIADCTimingMode(taskHandle, "", DAQmx_Val_HighSpeed).

> Most of the time I receive 10 samples per reading (as expected). Sometimes I receive 9 or 11 which is probably because my computers clock is not synchronized with the DAQ clock which is fine. The problem is that sometimes I receive zero samples.

I think I misinterpreted your use of "zero readings". Are you saying that the values in 'readValues' are getting set to 0.0 deg C, or that 'numSamplesReadPerChannel' is getting set to 0? For now, I'll assume it's the latter.

Setting the 'numSampsPerChan' parameter to DAQmx_Val_Auto causes DAQmx to read as many samples as are available, limited by 'readArraySize'. In combination with a non-zero timeout, this should cause the DAQmxReadAnalogF64() call to block until there are enough samples to fill the read array, or until the timeout expires, whichever comes first. How many channels are you acquiring, and are you getting a timeout error from DAQmxReadAnalogF64()?

In addition to clock drift, the number of available samples is affected by how long the device buffers the data before sending it over the USB bus. The cDAQ-9178 is designed for throughput, not latency, so by default, it buffers data until it has a full 512-byte USB packet to send over the bus. Depending on the sample rate, how many channels you are reading, and the sample size (which is 4 bytes per sample on the NI 9217), this could cause your data to be delayed. 

If you set 'numSampsPerChan' to a specific number (like 10), then DAQmx will tell the device to send that many samples over the USB bus as soon as they are acquired, instead of waiting for enough bytes for a full packet. Please try that and see if it solves the problem. If you start getting timeout errors, try increasing the timeout.

Brad

[mbconcept]

Note that the default conversion time for the NI 9217 in CompactDAQ is 200 ms per channel, so setting the sample rate to 100 S/s is going to cause the chassis to return repeated samples. To convert all channels every 10 ms, you need to select high-speed mode by callingDAQmxAIADCTimingMode(taskHandle, "", DAQmx_Val_HighSpeed).

I made this change. For anyone who needs to do this in the future, I think it should be:

DAQmxSetAIADCTimingMode(taskHandle, "", DAQmx_Val_HighSpeed)

 instead of

DAQmxAIADCTimingMode(taskHandle, "", DAQmx_Val_HighSpeed)

I think I misinterpreted your use of "zero readings". Are you saying that the values in 'readValues' are getting set to 0.0 deg C, or that 'numSamplesReadPerChannel' is getting set to 0? For now, I'll assume it's the latter.

The latter is correct. numSamplesReadPerChannel is zero.

Setting the 'numSampsPerChan' parameter to DAQmx_Val_Auto causes DAQmx to read as many samples as are available, limited by 'readArraySize'. In combination with a non-zero timeout, this should cause the DAQmxReadAnalogF64() call to block until there are enough samples to fill the read array, or until the timeout expires, whichever comes first. How many channels are you acquiring, and are you getting a timeout error from DAQmxReadAnalogF64()?

I am reading all four channels. However, I have only one RTD physically connected. Could this be a problem?

I am not getting any errors from the DAQ.

If you set 'numSampsPerChan' to a specific number (like 10), then DAQmx will tell the device to send that many samples over the USB bus as soon as they are acquired, instead of waiting for enough bytes for a full packet. Please try that and see if it solves the problem. If you start getting timeout errors, try increasing the timeout.

I set numSampsPerChan to 10 and started getting timeout errors. I changed the timeout to 30 milliseconds and am still getting timeout errors. I can't go above a 30ms timeout. Am I pushing the limits of the module?

This also created another problem. If the module has more than 10 buffered readings, the remainder are going to be included in the results of my next read. I would like to clear the remainder of the buffer after I read my 10 samples.

 Thanks for your help,

Mike

---

[mbconcept]

It turns out that my 100ms scans are not working properly. It is a bug in my code. Two scans are randomly occuring very close together (much less than 100ms). The first scan is fine and the next returns zero samples as expected because there is no data available.

Thank you for your help,

Mike

[mbconcept]

Brad,

I was mistaken. The problem is not due to multiple scans occuring close to each other. I do have a little more info though... I am now printing the timestamp along with the number of readings I am receiving per channel. Notice the reading with 20 samples per channel.

TIME(ms)    NUM_SAMPLES_PER_CHANNEL
0093          10
0193          10
...
0793          10
0893          10
0992          10
1093          20
1192          0

NOTE: I switched the DAQmxReadAnalogF64 numSampsPerChan back to auto and set the timeout to 0. Also, arraySizeInSamps is 400 samples.

There are only two things that I can think of that cause this problem:

1.) My system clock is off by at least 90ms.

2.) The 9217 module, the cDAQ-9178 chassis or the DAQmx driver is doing something that I am not expecting.

Thanks,

Mike