Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

PCI6602+Qt

I am using Qt and PCI6602 for edge count. I am using an external clock which is 4Mhz. The code is:

step 1. DAQmxCreateTask("",&newtaskHandle);

step 2. DAQmxCreateCICountEdgesChan(newtaskHandle,"Dev1/ctr2","",DAQmx_Val_Rising,0,DAQmx_Val_CountUp);
step 3. DAQmxCfgSampClkTiming(newtaskHandle,"",4000000.0,DAQmx_Val_Rising,DAQmx_Val_FiniteSamps,bufferlen);

step 4. DAQmxStartTask(newesttaskHandle);
step 5. DAQmxReadCounterF64(newesttaskHandle,1024,10.0,inputdata,1024,&read,NULL);
step 6. DAQmxStopTask(newesttaskHandle);

It takes 2ms from step 4 to step 6.

Now, I want to synchronously use eight counters, ctr0-ctr7. Each counter reads 1024 samples.

My question is:

1. Is it possible that I synchronize the eight counters on PCI-6602 and How to do this if this is possible?

2. What is the Maximum external clock ? 

3.  How can I reduce the time from step 4 to step 6?

0 Kudos
Message 1 of 4
(2,167 Views)

You won't be able to *sample* 8 counters at 4 MHz with the 6602.  It doesn't have a big enough hardware FIFO or DMA channels to keep up.  You can *count* a 4 MHz signal though. 

 

What is your purpose for wanting to sample at 4 MHz?  What are the overall needs of your app?   A better answer to your other questions depends on the bigger context of the kind of measurement(s) you need in your app.

 

A common mistake newer users sometimes make with counters is to assume that they must sample much faster than the frequency of the signal they measure, much like applying Nyquist to an analog acquisition.  That simply isn't the way things need to be done with counters.   The ability to count fast signals and the ability to have excellent timing *resolution* are independent of the sample rate.

 

 

-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).
Message 2 of 4
(2,124 Views)

Dear Kevin P,

thanks for your reply.

what we want to do is to count photon numbers of eight channels. we use this function: DAQmxReadCounterF64(newesttaskHandle,1024,10.0,inputdata,1024,&read,NULL). 

we want to count eight channels at the same time using PCI6602. 

we need to do this every 20 ms. That's why we want to sample at 4Mhz or higher.

 

 

 

 

0 Kudos
Message 3 of 4
(2,113 Views)

we want to count eight channels at the same time using PCI6602. 

we need to do this every 20 ms. That's why we want to sample at 4Mhz or higher.

To capture counts every 20 msec, you only need to *sample* every 20 msec.  This is 50 Hz, not 4 MHz!!!   Like a lot of counter tasks, *counting* happens in hardware in the background then you sample the count values at a convenient rate (such as 50 Hz).

 

Here's what you'll need:

- an independent 50 Hz clock that you'll physically wire to a PFI pin and then all your tasks will configure to use it as their sample clock.   Alternately, you can count with only 7 counters and use 1 to generate this sample clock.  (Dunno if the 8 counter channels is a true need or more of a goal.)

- 5 of the 8 counter tasks will need to be configured to use *interrupts* rather than DMA. Back around a decade ago it was necessary to configure this explicitly, I don't know whether more recent versions of DAQmx do this automatically

- you'll need to get the tasks started in sync.  There's a (fairly) easy way and a hard way.  The easy way is to start your counter tasks *before* starting the external clock signal, and then discard the 1st sample from all your tasks.  (It'll hold the meaningless value for # counts occurring during the unknown time before you started sampling).

    The hard way gets into the use of the "Arm Start" trigger.  You'll find more info here using that as a search term, I don't have time to re-type it just now.

 

 

-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 4 of 4
(2,106 Views)