Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

6602 buffered event counting needs synchronous mode?

If I understand you correctly, then the "sample clock" is what I was calling the "gate signal", a 0-5V square wave at ~10kHz (varies a bit, but on that order of magnitude) coming from an externally-triggered SRS signal generator.

Thank you for the tips, I'll keep you updated on any progress I make.

-- Ian Leroux
0 Kudos
Message 11 of 16
(2,099 Views)
Yeah, what you call the "Gate input" in traditional NI-DAQ buffered counting is now called the "sample clock" in DAQmx.   So you're buffering at a rate of ~10kHz while the actual count values are incrementing at anywhere from 0 Hz to ~8 MHz?
 
I threw together a really quick and dirty trial using DAQmx and it looks like it'll take care of your problems.  I generated 2 pulsetrains using copies of one shipping example, and I did a few mods to another example for buffered edge counting.  I specified one of the counter outputs as the "sample clock" and the other as the timebase Source.  Then I just ran them all at once.
 
I was able to successfully increment counts all the way up to 20 MHz while buffering at a sampling clock rate of 100 kHz.  The "Duplicate Count Prevention" property also allowed me to buffer at a higher rate than the count rate.  For example, a sampling clock of 10 kHz with a "photon rate" of 5 kHz would produce a buffer like  0,1,1,2,2,3,3,4,4,...
 
I didn't do any traditional NI-DAQ work and don't understand the 6.5 MHz limit, but meanwhile thought you should know that making the switch over to DAQmx should be worth the effort as it appears to solve your problems.
 
-Kevin P.
 
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 12 of 16
(2,089 Views)
Thanks for the encouragement and the demonstration.  I'll check that possibility out as soon as I can (might be a couple of weeks, due to other priorities) and post any new findings.

Again, thanks for your efforts and advice

-- Ian Leroux
0 Kudos
Message 13 of 16
(2,083 Views)
Unfortunately, several of the instruments used in our system, in particular the PCI-6601 and PCI-6602, only show up as Traditional NI-DAQ devices in MAX.  I interpret this to mean that they are not supported by DAQmx in the software versions we have installed (LabVIEW 7.0.1, August 2003 Driver edition).  So rewriting to use DAQmx isn't currently a viable solution.  Can anyone point me to a list of which driver versions support which hardware under DAQmx so I'll know when it's safe to upgrade?

-- Ian Leroux
Message 14 of 16
(2,017 Views)

Hi Ian-

Actually, LabVIEW 7.0 is supported fully by NI-DAQmx.  My guess is that you have a version of NI-DAQmx installed that is earlier than v7.2 (the first to support the 6601/6602 devices).

The latest version of NI-DAQmx features support for both devices as well as LabVIEW 7.0.  I would encourage you to upgrade and take a look to see if it can help meet your application's needs.

Hopefully this helps-

Tom W
National Instruments
0 Kudos
Message 15 of 16
(2,009 Views)

There's a big list posted here.  It shows the latest version of DAQ drivers that support various hardware under various operating systems.  The page I linked to shows PCI cards but you can find out about others too.  You can download and install DAQmx 8.0 without affecting the version of traditional NI-DAQ you're using.

Note that you CAN use both DAQmx and traditional NI-DAQ in an app if they aren't both used on the same device (board).  So for example, you can start by programming the 6602 board with DAQmx to get the behavior you want without needing to change the way to interact with any of the other boards.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
0 Kudos
Message 16 of 16
(2,007 Views)