DAQCard6062E hangs intermittently during acq

[quill]

Code written in VC++ 6.0, NIDAQ 6.9.3, OS: Win2000&98, various laptops from P2-450MHz to P3-1.2GHz.

Using SCAN_Start for continuous mode acquisition to a single buffer (16 channels, 20KHz). After a variable number of samples acquired (usually around 1e6 to 14e6), acquisition hangs. At this point DAQ_Monitor returns error -10845 (overFlowError) once, and then -10608 (noTransferInProgError) thereafter. At this point, the acquisition must be stopped and restarted.

The hangs only occur after many cycles through the acquisition buffer, so I don't think it is a buffer boundary problem. Hangs also occur even if there are no transfers to secondary buffers (via DAQ_Monitor), so I don't think it's a memory access conflict.


Greatly lowering acquisition bandwidth (e.g. 20kHz X 1 channel) eliminates the problem, but the driver hangs at acquisition rates well below maximum bandwidth (e.g. it hangs using 20kHz X 8 channels = 160KHz aggregate).

I have included a simple console app that demonstrates the problem. This app does not actually do anything but monitor the acquisition once it starts. When the acquisition hangs, a beeping message is displayed.

I hope someone can help me solve this problem, or at least tell me what I'm doing wrong. I am at wit's end!

John Burt

[JustinBritten]

John,

Actually, the error -10845 is a hardware, not software, overflow error. This error occurs when the NI-DAQ driver cannot read data from the DAQ device's FIFO buffer fast enough to keep up with the acquired data. In your case, this is probably because the FIFO buffers on a PCMCIA card are much smaller than those found on a PCI card. Furthermore, the PCMCIA bus does not support Direct Memory Access (DMA) which is used for fast transfer. The DAQCards rely on interrupts to transfer data from their FIFO to PC memory. Unlike DMA transfers, interrupt transfers consume processor time and are thus highly system dependent. Additionally, they are much slower than DMA transfers.

There are two primary solutions to this issue. There are lowering the sampl
e rate or using a much faster computer to process the interrupts at a higher rate. Additionally, the FIFO on this board is limited to 8,192 samples. You should ensure that you are not acquiring more than this many samples at a time.

Please reference the following Knowledge Base article for more information on this subject.

Data Acquisition Errors -10845 and -10846, What Is the Difference?
http://digital.ni.com/public.nsf/websearch/70C74F12DC728114862568EB007F5338?OpenDocument

Regards,
Justin Britten

Applications Engineer
National Instruments

[quill]

Thank you Justin,

Is a 1.2GHz Pentium III computer too slow?!

"You should ensure that you are not acquiring more than this many samples at a time."

How does this relate to using the NIDAQ drivers and API (i.e., AI_Config, SCAN_Start, etc)? Are you saying I should not set the acquisition buffer in AI_Config to a size larger than 8,192 samples? I had assumed that the NIDAQ driver manages the hardware level interface using intermediate buffers.

Thanks,

John Burt

[JustinBritten]

John,

I know a 1.2GHz PIII doesn't seem slow, but this is entirely dependant on how many interrupts are being generated. You may want to take a look at the Set_DAQ_Device_Info function and have an interrupt be generated only when half of the FIFO is full. If your current setting is to generate an interrupt at every sample, and you are acquiring at a rate of 200kS/s, you're going to need an extremely fast computer. This is covered in the Set_DAQ_Device_Info and FIFO Transfer Condition (2-30) sections of the NI-DAQ Function Reference Manual.

The NI-DAQ driver does manage the intermediate buffers. However, you usually request a sample count. For example, an input to SCAN_Start is the sample count. Just don't ask for 10,000 samples wit
h your board.

Regards,
Justin Britten

Applications Engineer
National Instruments