I haven't fully fleshed out this idea, but here it is in a think-out-loud form.
I'm assuming you don't have clocked analog output in your app, and will lean on using an AO task solely for its clock.
Here's the idea:
1. One of your counters is set as a retriggerable single pulse generator. Let's say it's CTR0. Use the external ~1Hz signal as its trigger, and set it up to generate a single pulse with a 100 msec high time and a minimal low time. You'll need a DAQmx property node to make it retriggerable.
2. Configure an AO task to generate at 10 kHz, corresponding to your 100 microsec bins. Configure it to be pause triggered by the output of CTR0. Thus, the AO generates samples at 10 kHz, but only while CTR0 output is high (for 100 msec). You'll have to write a buffer of analog values to generate, but it can just be an array full of 0 voltage, and you don't have to wire that output to anything either.
3. Configure your other counter, CTR1, for period measurement. This may be tricky to configure with DAQmx property nodes, but ultimately you'll need to treat your pulses of interest as the timebase for the measurement while using the AO sample clock as the signal to be measured. That sounds backwards, but the effect will be to store the number of your pulses of interest that occur between AO clock edges. You will need to research "duplicate count prevention" to make sure that 0 values get buffered properly.
I *think* that sort of arrangement could work. About every second, you get an external trigger. That trigger causes CTR0 to generate a single pulse with a 100 msec high time. Your AO task generates a clock pulse every 100 microsec, but only during the 100 msec when CTR0 is high. Each of those AO clock pulses buffers a value for your CTR1 period measurement. This should produce a measurement buffer like the first one you listed.
4. (Simpler Alternative) Configure CTR1 for simple counting. Use DAQmx Timing.vi to specify the use of the AO Sample clock, and specify your external pulses of interest as the signal to measure. By default, LabVIEW will expect to see those pulses at CTR1's default SOURCE pin. This arrangement should produce a measurement buffer like the second one you listed, though you may still need to research "duplicate count prevention" to make sure that gets set up right.
5. I can't help but think there's another way to do this without the AO stuff, but nothing's coming to me now.
-Kevin P
Message Edited by Kevin Price on 02-01-2010 02:19 PM
ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
