-10920 error at low pulse frequencies

[Jamie Fraser]

For some time I have had an unresolved query regarding buffered period measurement using a DAQCard. Please see my thread entitled "-10920 Error at low pulse frequencies when doing simultaneous AI DAQ" for details.

In brief, if I do a simultaneous AI DAQ and buffered period measurement on my DAQCard, I get the -10920 error at very low frequencies (~68Hz). However, if I force the AI DAQ to interrupt at every sample (rather than every half FIFO) I can detect much higher pulse frequencies before I get the -10920 error.

This does not seem right. Although difficult to speculate from the outside, it is as if the counter interrupt is not being detected, but the AI interrupt is and the ISR/DPC that services the AI interrupt checks the
card for whatever data is available, whether it be AI or Counter data and grabs it all before returning. Therefore, it is the AI interrupt that is causing the card to be serviced, and, as there is counter data available, it is read as well.

The reason for this new post is that I have just read a KB article (KB824395) on the MS website that mentions a bug in W2k whereby PCI interrupts are not always detected in NT Server 4.0 style drivers.

Is this in anyway related to the problem I am experiencing?

With thanks

Jamie Fraser

[reddog]

I believe your problem is due to the fact that you must use interrupts as the data transfer mechanism with DAQCards, and the Traditional NI-DAQ driver is single threaded. Depending on the DAQCard, the size of your FIFO can range from 2 KS (DAQCard 6036) to 16 KS (DAQCard 6062). Since the default transfer condition is FIFO Half Full, you will get data transferred into your buffer in chunks of 1,000 - 8,000 samples at a time. Depending on the speed of your AI acquisition and the frequency of the signal being measured with the counter, this can lead to errors due to the blocking nature of the driver. For instance, if your acquiring data at 10 KS/s, data will arrive in your buffer every 0.1 to 0.8 seconds depending on the size of your FIFO. This means any time you
try to read data, you could be blocking up to 0.1 to 0.8 seconds. If the frequency of the signal being measured by the counter is greater than 10 Hz, you will likely get errors. When using a transfer condition of interrupt at every sample, a read call when trying to read N samples will block for as long as it takes to acquire N samples instead of FIFO/2 samples. This could account for the increased throughput you are seeing on the counter when switching to interrupt at every sample.

One thing you can try is to poll the driver for the number of points available to read, and only perform the read call once the number of points you want to read are available and can be read without blocking. Alternatively, you can try switching to the DAQmx driver which is multi-threaded. DAQCard support for the DAQmx API will be available in NI-DAQ 7.1 and should be available soon. In the meantime, you can use a beta driver for DAQCards if you want to try DAQmx sooner. See knowledge base 2XM6TE
B9 for details on how to download the beta driver for DAQCards.

[Jamie Fraser]

Hi, thanks for your answer.

I thought that blocking of the NI-DAQ DLL would only occur if one thread made a call into the DLL and another thread tried to make a call into the DLL before the first thread returned. This would be most problematic when using synchronous NI-DAQ functions that do not return immediately. In my application I am not doing this. I am always using DAQ_HalfReady() to test for data before copying from the primary buffer.

Also, even if the DLL is in use by a thread when an interrupt comes in from the card, can NI-DAQ still not service the interrupt? If this is not the case then it would be very problematic indeed; e.g if a thread is inside GPCTR_Watch() when an interrupt occurs, can the ISR/DPC write data to the primary buffer
, or does GPCTR_Watch hold some sort of lock on that array that prevents the ISR/DPC from accessing it? I would assume not, otherwise surely all counter operations would fail at some time if the buffer was in use by some function, particularly as there is only a single save register per counter on the DAQ-STC chip.

I hope you can enlighten me further.

Regards

Jamie Fraser