Bug: DAQmxReadAnalogF64 (DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely) sometimes underflows or returns insufficient samples, when in loop

[RichardNeiill]

When using:  DAQmxReadAnalogF64 (DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely),

configured in Finite sampling mode (and with the default value of DAQmxSetReadReadAllAvailSamp = FALSE), 

this is supposed to:

   - block forever, until the chosen number of samples is available

   - return exactly that many samples.

I then run it in a retriggerable loop (some parameters omitted for clarity):

-----------------------------

DAQmxCreateTask()

DAQmxCreateAIVoltageChan()

DAQmxCfgDigEdgeStartTrig ("PFI0", DAQmx_Val_Falling);
DAQmxCfgSampClkTiming( OnboardClock, 100_Hz, DAQmx_Val_FiniteSamps, 100_samples) 

DAQmxSetReadReadAllAvailSamp (FALSE);

DAQmxTaskControl (DAQmx_Val_Task_Commit)

while (1) {

    DAQmxStartTask()
    DAQmxReadAnalogF64 ( DAQmx_Val_Auto, DAQmx_Val_WaitInfinitely, &samples_read);

    /* samples_read should be 100; process the data */
    DAQmxStopTask(taskHandle);
}

--------------------------

What this should do is give me exactly 100 samples, every time that the external trigger occurs.

This does work most of the time. But there is about a 10% probablilty on any iteration of the loop that either:

     samples_read < 100

or

    I get error - 200278, telling me that the task has prematurely stopped.

I think this is a bug in DAQmx, in the case of the NI 4462.

How should I proceed? (NI doesn't have a public bugzilla, and I can't investigate further myself without the source of libnidaqmx.so.1.6.0)

Thanks for your help - Richard

P.S. I attach a full program (in C) that demonstrates the problem. It's basically the above snippet, but in runnable form.

P.P.S. This originally started in this thread, but diverged so much from the original title that it seems worth creating a new thread:

http://forums.ni.com/t5/Multifunction-DAQ/How-can-I-detect-a-missed-trigger-i-e-2nd-trigger-arrives-...

[Steven_K.]

Hi Richard,

Given the formatting and the comments of your C file it looks like you are developing for Linux. Which distro are you using and what version of DAQmx do you have? I'd like to see if I can reproduce it on my end.

[RichardNeiill]

Hi Steven,

Thanks for your help. I'm running kernel 2.6.29.6 on Mandriva 2009.1 on 32-bit x86.  I'm using DAQmx 8.0

I did look at the contents of the RPMs for DAQmx 8.02, but the package contains exactly the same version of libnidaqmx.

Let me know if there are any other tests I can do to help.  If it would be useful, I can set up a guest SSH account on that machine for you.

Richard

[RichardNeiill]

I've set up a guest ssh account on that dev machine for you, with access to the NI4462 card, and the ability to trigger it remotely. If that's useful, send me an email and I'll reply with login details.

[RichardNeiill]

Dear Steven,

Have you had any luck in reproducing this problem? Or, for that matter, in not reproducing it?

If the latter, can you perhaps let me know your configuration, and I can try altering my own system to match? 

Thanks - Richard

[Steven_K.]

Hi Richard,

I appreciate your patience. I'm currently in the middle of testing out this issue. I'll report back if I'm able to reproduce it. In the mean time could you manually setting the numSampsPerChan to the number of samples in your finite task? I'd like to see what happens on your end.

[RichardNeiill]

Thanks for your message. I've tried the change you suggest, i.e. this line:

   DAQmxReadAnalogF64(taskHandle, NUM_SAMPLES_PER_FRAME, DAQmx_Val_WaitInfinitely,

                 DAQmx_Val_GroupByScanNumber, data, (sizeof(data)/(sizeof(data[0])*4)), &samples_read_thistime, NULL);

i.e. hardcoding the value 100, rather than DAQmx_Val_Auto.

Unfortunately, it doesn't help: I still observe both types of error.

Are there any other tests I can help with?

[Steven_K. · Accepted solution]

Hey Richard,

I was able to reproduce the - 200278 error on my Windows machine using C. What happens if you remove the commit task? That seemed to prevent the error from occuring. If that is the case on your machine as well, I will file a Corrective Action Request for this issue.

[RichardNeiill]

Dear Steven,

Thanks for spotting that. That seems really weird, but yes, your suggestion does seem to work.

At least it's run for 5 minutes so far, which is about 4:53 longer than usual!  I'll leave it running (and logging) overnight.

Best wishes,

Richard

P.S. One consequence of this (which isn't relevant for me, but may be for others), is that, if configuring AC coupling, it's usually necessary to insert a ~0.7 second sleep in between taskCommit and taskStart, to allow the input to settle (this is the RC-time constant of the input capacitance). If there is no explicit Commit, but we rely on the implicit Commit in taskStart, then the first second of data may be compromised.

P.P.S. This sort of issue argues strongly for NI putting the DAQmx documentation online, prefereably with some kind of wiki or user-comments. Might I suggest that the php.net documentation offers a good model?

[RichardNeiill]

Dear Steven,

Yes, I can confirm that this has now run stably overnight, and I think we got the root cause.

I think these are the remaining issues arising from this:

  * Actually fix this in libnidaqmx, and create a new binary for download. (Would this be a good point to make a request for the source too?)

  * Find a different solution for people who need AC_coupling: for whom it's necessary to commit the task before starting,in order to get the capacitors to settle (as suggested by the NI Data Aquisition manual)

  * Put the current DAQmx documentation online on the NI site, with notes about this bug (and any others that come to light).

  * I also noticed that, even when everything is working, libnidaqmx doesn't clean up all of the lockfiles that it leaves in /tmp/natinst/

Thanks very much for your help - that ware really important to me for my PhD, and very much appreciated.

- Richard