DAQmxGetWriteTotalSampPerChanGenerated returns wrong number of scans generated after 25 minutes

[whemdan]

Hi,

When using DAQmxGetWriteTotalSampPerChanGenerated, I noticed I get a wrong number of scans generated when running analog output for more than 25 minutes continuous. After some debugging I realized that the scans generated value returned from DAQmxGetWriteTotalSampPerChanGenerated wraps around 2^32 despite the data type being uInt64. I verified that the data type in NI-DAQmx C Reference help indeed indicates uint64 and no such limitation is documented so I just wanted to check if this was normal behaviour or a bug.

I am seeing this behaviour with NI USB-6255, running at the maximum sample rate for about 25 minutes.

I am using a Win64 machine with NIDAQmx driver version 9.3.0f2.

TaskHandle  taskHandle=0;

uInt64          data=0;

...

DAQmxGetWriteTotalSampPerChanGenerated(taskHandle, &data)

Attached is an NI I/O Trace illustrating this issue.

Thanks,

    Wael Hemdan,

    The MathWorks

[SchamWow]

what do you normally program in? I do a lot of programming in VB with my cards and I don't believe I've ever seen this behavior. There are also newer drivers I think - try those.

are you using windows 7 64-bit? or another windows 64-bit system?

[whemdan]

Hi,

I am using Win7, on a 64 bit machine.

Thanks,

   - Wael Hemdan

[SchamWow]

Hi Wael - I just tried using the DAQmxGetWriteTotalSampPerChanGenerated with the 9.5.1 drivers and this does not seem to be an issue.  I let it run for around 40 minutes in the background and it looks fine.  Can you try upgrading your driver?

[whemdan]

Hi,

Did you see DAQmxGetWriteTotalSampPerChanGenerated actually return a number of scans generated greater than 4300000000 (i.e. 2^32), It seems to be wrapping around 2^32 for me. So it continues to run and it continues to generate the output signal but I can no longer get number of scans generated greater than 4.295e9.

I am using NIDAQmx driver version 9.3.0f2.

Thanks,

   - Wael

[Mcdan · Accepted solution]

This behavior has been reported on X Series as Corrective Action Request (CAR) 353282.  I will update the CAR to reflect that it's an issue for M Series as well.

In the short term, you may want to work around this by adding n*2^32 (where n=number of rolls over) to the value returned by TotalSampPerChannelGenerated if you detect that 'TotalSampPerChannelGenerated' has decreased.

Dan

[Mike_TheKraken]

Regarding this issue, has the NI-DAQmx 9.6 driver fixed this issue?

http://download.ni.com/support/softlib//multifunction_daq/nidaqmx/9.6/readme.html

It causes substantial problems to our efforts.

thanks

[Mcdan]

DAQmx 9.6 should fix this issue for M Series and X Series.  Fixes for E Series, S Series, and 67xx devices should get rolled into a future version of DAQmx.  This is being tracked by CAR 362066 for those interested in this fix for those families of devices.

Dan

[Mike_TheKraken]

I dug and dug and found they already have a newer version, 9.6.1 you can find if you dig deep enough...

I'm using he USB-6351 and the D/A generating 40KHz signal would shutdown after 1/2 hour (also monitoring that signal using 2 A/D ports and doing small FFTs). I have loaded the new driver (9.6), but for some reason the system is still having problems keeping up when I run much graphics at the same time, such as a GUI and 8 plots in a window. Is anyone aware of a problem with the USB-PC-DAQ-Mathworks and a low bandwidth USB temperature logger combination that would cause things to be so touchy? We send KHz signals out and monitor them with two DAQ A/D and we poll the temperature logger through the USB port every few seconds. Running a few CPU-memory monitors I do not see anything on the PC which is taxed to 100% use or really even close. When I run the system I detect the signal shutting down and automatically restart it, but it really shouldn't be necessary and causes data/system problems.

[Mcdan]

Your issue sounds different from the one reported in 353282 (this was an issue with a specific property returning the wrong value after 2^32 samples had been generated).  Which of your tasks is erring, input or output?  What error code are you receiving?  What are your sample clock rates for input and output?

I'd like to get a little bit better understanding of your issue so hopefully I can provide some useful advice.

Dan