error 10920

[Stella Opti]

Hi,

     I am using a counter-timer PCI-6602, and I have a wierd problem with the buffered mode. Here is the description of my setup for the measurement---

    A signal generator( which can generate square wave with frequency up to 15MHz), it's normally used as a SOURCE signal

    Counter0 is used as a pulse generator to generate a GATE signal, and the frequency is set at 10KHz.

    Counter1 is used as a counter, and the mode is event counting.

The first problem is:

    When the SOURCE frequency is set at a frequency lower than 12MHz, the counter works quite well in both buffer mode and non-buffer mode. When the SOURCE frequency is set at a frequency higher than 12MHz, the counter generates an error 10920 in buffer mode while still works fine in non-buffer mode. What really confuses me is that the GATE frequency never changes during the experiment, which means the numbers of data I get are 10,000/sec whatever the SOURCE frequency is. The only difference is that at higher SOURCE frequency, the value per count is larger. In this case, even increasing the buffer size doesn't work. The reason behind this error, I guess, may be that the counting rate is too high at 12MHz , and the counter is overwhelmed/saturated(?! sorry if it sounds silly.:-P)

    So I changed the setup a little bit, instead of using a standard signal generator, I use a real photon detector. The incoming rate of photon is approximately 100,000/sec( in this experiment, the length of the pulse for a photon is approximately 30ns, the interval of adjacent photons varies), much lower than 12MHz. So the counter is unlikely to saturate at such a low rate. By modifying the signal, we can reduce the noise significantly, so that it doesn't affect the performance of the counter. The same error message appears after running for SOME time if the GATE signal is 10KHz, that's understandable since the buffer can be filled up after some time, but the error message appears instantly if the GATE signal is 20KHz, so the counter doesn't work at all. My second problem is:  If my guess of the reason of the error is right, what's the limitation of the GATE signal?

    The third problem is a little complicated because I CHANGED the setup quite a lot. The same photon detector is connected to the GATE, and I use time mode to identify each incoming photon using the internal clock( of the PCI board). It works quite well in non-buffer mode, but in the buffer mode, the error 10920( why is it still haunting me?:-() pops up instantly. Since the GATE signal frequency ( the photon incoming rate) is lower than 10KHz, why on earth it crashed again? Maybe two photons happens to come very close, but in this case, even if the counter can't distinguish the two photons, it's OK, since it's really rare. So my feeling is that the counter is good at distinguishing the incoming pulses with a seperation of 30ns or less, since it's a 80MHz good couter, but somehow it has some annoying unidentified pitfalls when used in buffer mode.

     Thanks for your attention, and if you still have questions about the details, please contact me.

[Kevin_Price]

Those -10920's can be tough...  Have you seen the standard knowledgebase article for it?

Your first scenario is strange -- I can't think of a good reason why a higher SOURCE frequency would make the error occur more frequently, unless the quality of the SOURCE signal deteriorates at that higher frequency.  The second scenario is a puzzler too -- I wouldn't think a 20 kHz GATE would lead to an instant error.  Combined with the 3rd scenario, I would again wonder if the photon detector GATE signal might be "noisy", particularly in the sense of "ringing" on its transitions.  That kind of ringing can produce too many GATE edges too quickly -- I've seen -10920 errors in such cases.

For some other general insight, it's worth noting that the counter/timer board has a rather small on-board FIFO.  See this thread for example.  Successful buffered acquisitions depend on constant interaction between the driver and board across the PCI bus.  If this bottleneck is at fault (and your near-instant errors make that seem unlikely), then perhaps you might want to try using the DAQmx driver.  it was designed to be more efficient in several ways, and I don't imagine it'd hurt any to try.

-Kevin P.

[Stella Opti]

Yep.. I have seen the standard article. But the problem is so weird that I can't see another way right now except to try DAQmx immediately. Thanks a lot! And I will report my progress ASAP, hope it works....

[Stella Opti]

Thanks! Guys. After trying it in Labview, and using DAQmx, I solved the problem. It does seem to be a glitch in other drivers.