incorrect number of samples returned by PCIe-6351

[WM_John_Weeks]

Sorry for the long and complicated post. It's difficult to describe, but a real problem.

This code pseudocode:

int32 NIerror = 0;

do

{

NIerror = DAQmxReadBinaryI16(taskhandle, DAQmx_Val_Auto, 1.0, ..., &sampsPerChanRead);

if (NIerror)

{

if (NIerror != DAQmxErrorTimeoutExceeded && NIerror != DAQmxErrorSamplesNotYetAvailable )// harmless errors

{

report error

return err;// ***** EXIT *****

}

}

if (sampsPerChanRead > 0)

store N samples

if (WaveIndexForRead == nSamples)

{

break;

}

if (user requests to stop)

{

err = new NIDAQ_error(devName, USER_ABORT);

return err;// ***** EXIT *****

}

} while (1);

is used within some pretty indirect and complex code to get the results of an analog input scan. It generally works fine- with scans that take longer than 1 second, it causes the acquired data to be read in chunks, each chunk except the last returning a DAQmxErrorSamplesNotYetAvailable error. I do this so that it can be interrupted if I wish. That'

I have one customer using a PCIe-6351 who reports that on a 523-sample scan who reports that occasionally this code results in reading 522 samples, but with the scan reported by the driver as being finished. My code here goes back to get the last sample, but the driver says it's done, and returns DAQmxErrorSamplesWillNeverBeAvailable.

Here is a portion of NIspy output for a successful scan. Note that adding up 105+104+105+104+105 = 523, the full number of samples requested originally.

1074. DAQmxStartTask (0x6DE8C9F0)
Process ID: 0x00000E2C Thread ID: 0x00000944
Start Time: 14:19:52.728 Call Duration 00:00:00.000
Status: 0 (0x0)

> 1075. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFF9,0xFFBB,...}, 4184, 105, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:52.730 Call Duration 00:00:01.043
> Status: -200284 (0xFFFCF1A4)

> 1076. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFEE,0xFFB2,...}, 4184, 104, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:53.774 Call Duration 00:00:01.043
> Status: -200284 (0xFFFCF1A4)

> 1077. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFB9,0xFFE0,...}, 4184, 105, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:54.817 Call Duration 00:00:01.045
> Status: -200284 (0xFFFCF1A4)

> 1078. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFB6,0xFFDB,...}, 4184, 104, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:55.862 Call Duration 00:00:01.047
> Status: -200284 (0xFFFCF1A4)

1079. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFC8,0xFFBF,...}, 4184, 105, NULL)
Process ID: 0x00000E2C Thread ID: 0x00000944
Start Time: 14:19:56.909 Call Duration 00:00:01.043
Status: 0 (0x0)

Here is a portion of the unsuccessful scan. Note that adding up 104+104+105+104+105 comes to 522 samples, one short of the total requested.

1181. DAQmxStartTask (0x6DE8C9F0)
Process ID: 0x00000E2C Thread ID: 0x00000944
Start Time: 14:19:58.128 Call Duration 00:00:00.000
Status: 0 (0x0)

> 1182. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFF7,0xFFAE,...}, 4184, 104, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:58.130 Call Duration 00:00:01.040
> Status: -200284 (0xFFFCF1A4)

> 1183. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0x001C,0x0015,...}, 4184, 104, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:19:59.171 Call Duration 00:00:01.046
> Status: -200284 (0xFFFCF1A4)

> 1184. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFCD,0xFFE9,...}, 4184, 105, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:20:00.218 Call Duration 00:00:01.043
> Status: -200284 (0xFFFCF1A4)

> 1185. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFC9,0xFFB7,...}, 4184, 104, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:20:01.262 Call Duration 00:00:01.044
> Status: -200284 (0xFFFCF1A4)

1186. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFB2,0xFFBD,...}, 4184, 105, NULL)
Process ID: 0x00000E2C Thread ID: 0x00000944
Start Time: 14:20:02.306 Call Duration 00:00:01.044
Status: 0 (0x0)

> 1187. DAQmxReadBinaryI16 (0x6DE8C9F0, "DAQmx_Val_Auto", 1, "DAQmx_Val_GroupByChannel", {0xFFB2,0xFFBD,...}, 4184, 0, NULL)
> Process ID: 0x00000E2C Thread ID: 0x00000944
> Start Time: 14:20:03.350 Call Duration 00:00:00.000
> Status: -200278 (0xFFFCF1AA)

It looks to me like the NI-DAQmx driver is dropping a sample now and then. Is this a known problem? I tried it in my office using a PCI-6229 and this code worked without error for several thousand iterations.

Thank you for your help and patience!

[timtamslam]

Hey John,

Regarding your customer that is seeing the 522 samples using the PCIe-6351; Has the code always functioned in this manner? Was there ever a time that it worked correctly or has this always been the behavior? Also, in this NIspy output (thanks for printing this out, its very helpful!) The missing sample is in the first read chunk. In the instance where one of the scans is missed, is it always in the first chunk or is it sometimes in other sections of the scan?

If it works correctly in your system 1000+ times there's a good chance that there are no issues with the code. Have you tried adjusting the sample rate to see if this helps alleviate the issue? I'm not sure how strenuous your specifications need to be for the sample rate but i'm curious to see if it helps.

[Mcdan]

John,

I wrote a quick LabVIEW example that reproduces this behavior.  This seems like a bug.  I have filed CAR 329485 to track the issue.  I did find one possible work around.  Rather than using DAQmx Read's timeout to dictate how long read takes, I put a short wait in my code (this would be equal to your read timeout), then queried available samples per channel (DAQmxGetReadAvailSampPerChan).  I pass this number as DAQmxReadBinaryI16's numSampsPerChan parameter.  This results in very similar behavior to what you desire (read gets split into multiple short chunks) and I no longer run into the -200278 error.

Hope that helps,

Dan

[WM_John_Weeks]

Hi, Tim-

Thanks for wading through all that stuff, it's a slog!

The code has always functioned this way. I was able to run several thousand iterations on a slow old XP box with a PCI-6225. If you haven't guessed, this is a data acqusition add-on for WaveMetrics' Igor Pro. It's programmable, so there's my C++ code outlined above, plus the customer's code in Igor's language. I ran the customer's Igor code on my system without seeing any errors.

---

@Tim-A wrote:

Also, in this NIspy output (thanks for printing this out, its very helpful!) The missing sample is in the first read chunk. In the instance where one of the scans is missed, is it always in the first chunk or is it sometimes in other sections of the scan?

---

 I guess you're looking at the difference between 105 samples and 104 in the first read. But the exact numbers depend on chance. In my own testing, the first chunk had 69 or 68 samples apparently randomly.

---

Have you tried adjusting the sample rate to see if this helps alleviate the issue?

---

The only thing I really know about it is that if the sample rate or number of samples is adjusted so that all the samples are read in a single call, the problem goes away. I don't know how sensitive it is to small changes in sample rate. So there's something (a race condition in the driver?) that only occasionally results in the dropped sample. The customer reports hundreds of successful scans (the NIspy output was a very small part of what the customer sent me) and only occasional misses. But those misses are critical...

I'm going to link the customer on this thread, maybe he can add something to the info.

[WM_John_Weeks]

---

@Mcdan wrote:

John,

I wrote a quick LabVIEW example that reproduces this behavior.  This seems like a bug.  I have filed CAR 329485 to track the issue.  I did find one possible work around.  Rather than using DAQmx Read's timeout to dictate how long read takes, I put a short wait in my code (this would be equal to your read timeout), then queried available samples per channel (DAQmxGetReadAvailSampPerChan).  I pass this number as DAQmxReadBinaryI16's numSampsPerChan parameter.  This results in very similar behavior to what you desire (read gets split into multiple short chunks) and I no longer run into the -200278 error.

Hope that helps,

Dan

---

Thanks, Dan!

That's two of you that have slogged through all that detail. This is great!

I'm running out of time at the moment; I'll try your solution next week. I'm going into a Nutcracker tunnel- rehearsal tonight and tomorrow, and six performances in three days this weekend. Tuesday I should have some time to do this.

Thanks for the idea.

[WM_John_Weeks]

Dan-

I finally got back to this project. I didn't do quite what you suggested- I used DAQmxWaitUntilTaskDone() with a timeout, and loop on the DAQmxErrorWaitUntilDoneDoesNotIndicateDone error code. When it returns without an error, I then read all the samples at one time.

I just got a report from my customer that the new code appears to work correctly.

Thanks for your help!