Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Continuous Buffered Edge Counting with the NI PCI 6602 using multiple counters

Dear Community,

 

I am new to the DAQmx developement and I have a basic problem which raises some questions. The situation is quite simple: I want to perform, as indicated, a continuous buffered edge counting using multiple counters. I have read some documentation and from what I am given to understand there are some subtleties involved. 

 

I started with the "Count Digital Events-Buffered-Continuous-Ext Clk.vi", which is provided by NI. Here is my first question: I get the "data was overwritten before it could be read by the system", using the VI without modification. What are the possible sources of this error? I am given to understand that there is a limit to this, this limit seems to depend on how fast you can read out the so called FIFO buffer, and that this is limited by the number of counters you use. Is there any specific documentation or some example VIs who address this kind of problem? If I could get my hand on information on how exactly the buffer readout process works and how it changes when you employ different kinds of read out situations occur I would be helped a lot.

 

Thank you in advance!

 

Cheers Kai

0 Kudos
Message 1 of 10
(7,408 Views)

dear kai,

 

you are discribing a fifo overflow. It depends on the fifo size and the transfer rate of your device. If you want to know the transfer rate of your device, you can have a look in the manual (http://www.ni.com/pdf/manuals/372119c.pdf) on page 2-8.

 

Maybe this knowlegebase will help you a little bit: http://digital.ni.com/public.nsf/allkb/A224DA0551EEA073862574F60060AB6F?OpenDocument

 

http://digital.ni.com/public.nsf/allkb/CEC4263BC5D02DA88625737D006FE5EE

 

regards 

hofstk

 

Message 2 of 10
(7,379 Views)

This has been very helpful! Thank you very much! So let me get this straight:

 

There is a data storage, the buffer, on the NI card. Acquired data is written on it, and read out to store it on the hard drive. The rate and method of doing both can be manipulated by the user. If there is more data written on the buffer than read out, a problem arises, labeled as buffer overflow. So we need to have:

 

Acquisition rate <= Readout rate

 

Am I right so far?

 

If so, here are some further assumptions. 

 

Acquisition rate: 

This rate can be manipulated by the Timing VI. The rate is a key term here. It specifies how many samples are acquired per second. My question is: Can I infer that timing rate = acquisition rate?

 

Readout rate:

This rate depends on the hardware and can be improved by certain settings, for example by switching to DMA. It seems to depened on the buffer size, according to the table you refered to. Is there a way to find out the exact rate for my model and configuration?

 

Another issue is the following. All I need is a time resolution of the counted photons, so I need the quantity photons per second. This resolution does not need to be very hight, it could be in the microsecond range. If I use the onboard clocks (the only ones that are routed are 20 MHz and 80kHZ) it seems to be a bit of an overkill. It says that I could specify another counter as a source for the gate frequency. How exactly would I have to configer this counter? Right now almost all counters are available, so there is no restriction.

 

Thank you for your help! It is very much appreciated. 

0 Kudos
Message 3 of 10
(7,371 Views)

So far i know there is no explicit way to find out exact readout rate. But the timing rate is the aqcuistion rate with a small variance.

If you want to know the exact scan rate you have to look at this: http://digital.ni.com/public.nsf/websearch/5782F1B396474BAF86256A1D00572D6E?OpenDocument

 

For your project... do you know the LabVIEW examples? Maybe they can help you a little bit. (http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/de/pg/1/sn/catnav:ex/q/6602/)

Also usefull could be the daqmx getting started guide, which you can find here: http://www.ni.com/white-paper/5438/en/

 

regards 

hofstk

0 Kudos
Message 4 of 10
(7,359 Views)

Thank you!

 

The examples look promising, unfortunately they are too old to get loaded in my labview version. I have a precise question:

 

How do I route a signal of a frequency chosen by me to the gate of my counter? Since the Timing VI has a "source" property, I guess I have to select the channel I previously configured there. Am I right?

 

If so, the question is reduced to get a counter to produce a digital output of a given frequency. This question however seems so fundamental that it should be answered in the documentation, which I will check out now. 

 

I will come back later!

Kai

0 Kudos
Message 5 of 10
(7,345 Views)

Alright,

 

I experimented a little bit and got so far. My current status in appended. There arises a problem: The second read vi throws error -200284, "Some or all of the samples requested have not yet been acquired." Without that, the error does not occur. What am I missing?

 

Greets

Twerp

0 Kudos
Message 6 of 10
(7,246 Views)

After some tinkering I have a working implementation, but still I would like to know what is going on exactly. So here is an illustration of how I imagine the process takes place:

 

ContiniousBufferedEdgeCounting 

 

So. Since the Gate frequency f_g denotes how many entries are written to the buffer per second, it must be that in the optimal case f_r = f_g (*), so that the readout is as fast as the counting. In this simple model there would be problems if

 

  • f_r > f_g - the readout would be faster than the acquisition, there would not always be values to read
  • f_r < f_g - the readout would be slower than the acquisition, the buffer would overflow

Am I correct this far? Is there a need to always, in the long run, fulfill condition (*)?

 

Regards

Kai 

 

0 Kudos
Message 7 of 10
(7,055 Views)

I realize I counted wrong in the buffer, no need to worry. It has to be cumulative of course.

 

 

0 Kudos
Message 8 of 10
(7,048 Views)

Hi Limping_Twerp,

Can you please tell me if you could finally count pluses with time resolution using PCI 6602, Every post I'm looking there is a problem and it seems no one has been able to use PCI 6602 for counting.

Best

Rasbar

0 Kudos
Message 9 of 10
(6,212 Views)

It'd probably help to start a new thread with a very specific question.

 

Meanwhile, I'd highly recommend some more searching and perhaps some reading of the DAQmx Help.  There are plenty of folks like me who've successfully done all manner of counting / timing operations with the 6602 and similar boards.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 10 of 10
(6,194 Views)