10920 error during buffered counting

[amc50]

Hi,

I am using the buffered edge counting vi found in the examples (buffered period counting vi gives similar problems though) using the NI 6602 card. I am using an internal clock as the source (either 80 Mhz, 20 Mhz or 100 Khz) and using an external signal as the gate. Eventually I would like to use an avalanche photodiode as the gate, but at the moment I am just using a signal generator. The problem is that if I try to use a gate faster than 10 kHz, I get the error 10920.

I have read the knowledge base http://digital.ni.com/public.nsf/websearch/8FB9091CB9BB452B8525642000554799?OpenDocument as well
as the links from it.

We configured the board to use DMA transfers as described in the knowledge base (by altering the example VI). We also tested our gate signal to make sure it looks ok and since we are using the internal time base as a source we expect that to be ok.
I'm pretty much left with our system not being fast enough, but as far as I can tell it should be.

We are using NI-DAQ with labview 6.1.
We are using Windows 2000 professional with a 2.4 GHz processor and 500 MB ram (intel pentium IV)
No other applications are running and we put labview on highest priority.

Are there any suggestions for what else I could check or try?


Thanks!

Alice

[Tom_W_[DE]]

Hi Alice-

I have been testing with this example and have been able to force the same error you're seeing when using high frequency gate signals. My performance varied and seemed to work at higher frequencies than that which you're using (i.e. approx. 500kHz).

My suggestion is to increase the buffer size and the number of samples to read to reduce the card's access to the PCI bus. Also, my operation never failed in finite operation but always failed after the first iteration in continuous operation. This meant that the actual time spent in the While loop reading data from the buffer lasted longer than the time it took to refill the buffer and resulted essentially in a buffer overwrite. This is the origin of the 10920 error and explains why the operation is heavily system performance-limited.

I would suggest increasing the buffer and samples to read to see if you can increase performance at all. Also, I would try to run the example on another machine to see if you experience better performance. My machine is a 3.2GHz P4 with 1GB of RAM.

Please let us know if you have any additional luck.

Regards,

[amc50]

Thank you for the reply!
We have made some progress on the problem.
One simple thing we did was to disable another PCI board in the computer and that helped.
However we are still having a problem although it is slightly different than described previously.

We can get up to 800 Khz gate using finite mode.
We make the buffer equal to the counts to read and have varied it between about 100 and 10000. The problem now is that it works part of the time but on a fairly regular basis we get a 10920 error. When we are running with a smaller buffer we can get through more "runs" than if we use a larger buffer. (a "run" being hitting the start button and letting the program run it's course until it stops)

Also although it gives a 10920 error it returns all of the expected data points with the expected values. For instance if we are trying to read 10000 points it returns 10000 points with the correct values (100 for an 80 Mhz source with a 800 Khz gate, plus or minus 1 for some phase slip).

From your previous answer I understand how you could get a 10920 error if using continuos mode and you started writing the buffer before you had read all of it out.
However when using finite mode, I don't understand what the mechanism for generating the 10920 error could be or why it should be intermittent.

Thanks for any more suggestions or insight into how these counters are working!

Alice

[Tom_W_[DE]]

Hi Alice-

I might have been sort of unclear on the buffer issues in my previous post. I didn't mean to suggest that the buffer was being overwritten- this situation would result from a buffer being too small for the intended operation. You can probably understand that filling a small buffer and not reading from it fast enough will result in buffer overrun errors. The NI-DAQ driver uses a "circular" buffer and simply starts writing again at the beginning of the buffer if the end is reached before samples are removed. This situation will result in a -10846 error which I have seen in troubleshooting.

The -10920 error results from fundamental hardware speed limitations either across the PCI bus or with PC resources in general. So my earlier suggestion that processing time between iterations might be the culprit was not to say that card itself wasn't keeping up but rather that the PC was processing the samples into memory while the card continued to push samples to the bus. This situation can likely result in dropped samples and will result in the -10920 error.

The best suggestion is to make sure that you are using DMA transfers (which you already mentioned you were) and to make sure that processing for other applications and access to the PCI bus by other cards is absolutely minimized if not completely removed. You may also want to test the application on a different machine to see if you can find any better performance. Also, you may want to check out a DAQmx Example because DAQmx generally provides better performance and ease of use.

Thanks,

[Jamie Fraser]

Alice,

You may have sorted your problem now, but to answer one of your questions regarding why you still appear to get all of your pulse measurements returned, see below.

As already mentioned by the other poster, the -10920 error arises because the card cannot get rid of the sampled data fast enough before it is overwritten by other gate signals coming in. This will probably be due to bus congestion or the DMA controller not being allowed (by the code executing on the CPU at the time) to take control of the PCI bus fast enough. I'm not sure if the card you are using uses the DAQ-STC chip, but if it does this has very little hardware buffering so throughput is very susceptible to bus congestion. There is a good technical document on ni.com regarding the DAQ-STC chip.

The reason you 'appear' to get all your pulses is because all your pulse period measurements are the same so it looks like you have acquired all the data you expected. The card is just telling NI-DAQ that its buffer was not read before it had to overwrite the data.

Good luck.

Jamie Fraser