Counter/Timer
DAQMX continuously buffered period measurement
![Ryan_V[DE]](http://forums.ni.com/attachments/ni/170/152606/1/V-ferret.jpg "Ryan_V[DE]"){kind=avatar}
JJ,
You'll want to set the CI.Period.Term property to be your other counter's internal output. Then, you'll set your counter timebase source (CI.CtrTimebaseSrc) to be the line on which you are counting pulses. Think of it like this: In basic period measurement, the source is implicitly the internal timebase of the card. The gate (or sample clock) is the signal whose period you are measuring. When you select "ticks" instead of "Seconds," you get "ticks of the internal timebase," which is really no different. In this case, each rising edge of the gate latches in a new measurement, whether it be Seconds or ticks (it is all the same in HW). In your application, you want some periodic signal (generated by your other counter) to latch these new measurements, therefore it should be the gate, or sample clock, or other counter's internal output. Then, you'll want the "timebase source" to be the signal that you are measuring. I won't tell DAQmx that this isn't some periodic clock with a known frequency if you don't
. This is where duplicate count prevention comes in. As your device is not TIO-based, it does not support this property. This means that for any gate period which does not recieve source pulses, you will not buffer a data point. Will this likely be an issue for you (in other words, will you ever get no photons for 1 ms)?
Finally, as a retriggerable, finite, pulse generation requires 2 counters, you will not be able to perform this at the same time as your event counting task. In order to do this, you would need to upgrade to a board with at least 3 counters. Coincidentally, these boards (660x Series) also have duplicate count prevention. Please let us know if you have any more questions.
Hope this helps,
You'll want to set the CI.Period.Term property to be your other counter's internal output. Then, you'll set your counter timebase source (CI.CtrTimebaseSrc) to be the line on which you are counting pulses. Think of it like this: In basic period measurement, the source is implicitly the internal timebase of the card. The gate (or sample clock) is the signal whose period you are measuring. When you select "ticks" instead of "Seconds," you get "ticks of the internal timebase," which is really no different. In this case, each rising edge of the gate latches in a new measurement, whether it be Seconds or ticks (it is all the same in HW). In your application, you want some periodic signal (generated by your other counter) to latch these new measurements, therefore it should be the gate, or sample clock, or other counter's internal output. Then, you'll want the "timebase source" to be the signal that you are measuring. I won't tell DAQmx that this isn't some periodic clock with a known frequency if you don't
. This is where duplicate count prevention comes in. As your device is not TIO-based, it does not support this property. This means that for any gate period which does not recieve source pulses, you will not buffer a data point. Will this likely be an issue for you (in other words, will you ever get no photons for 1 ms)?Finally, as a retriggerable, finite, pulse generation requires 2 counters, you will not be able to perform this at the same time as your event counting task. In order to do this, you would need to upgrade to a board with at least 3 counters. Coincidentally, these boards (660x Series) also have duplicate count prevention. Please let us know if you have any more questions.
Hope this helps,
Just to continue from the last post. In LabVIEW help file, it stated "If no source edges are present
between two consecutive gate edges, then the previously saved counter value is
saved again",
and that is exactly what I am observing in my experiments using DAQ-STC
based counter program. Unfortunately I didn't finish reading the
setence saying "For NI-TIO-based devices, you can set the counter to count in a
synchronous mode". I was 'dreaming' of using duplicate count prevention in MX to correct this on my E board. 
Regarding again about the 'retriggerable' issue, I guess I was not using the right terminology. In DAQ-STC continous pulse generation program, it can be gated by a terminal such as PFI0 of the device, and I found that in my experiment, it will only output pulse train if TTL trigger to PFI0 stays high, thus, indirectly, I can set a retriggerable counting scheme for my photon counting using this gate pulse train. That is why I put trigger property node value of 'pause when low' in the pulse train generation part. But, apparently this doesn't work as I hoped.
Is there any method that I can use in DAQ-MX to achieve the 'retriggerable' pulse train?
Thanks for help!
JJ
Regarding again about the 'retriggerable' issue, I guess I was not using the right terminology. In DAQ-STC continous pulse generation program, it can be gated by a terminal such as PFI0 of the device, and I found that in my experiment, it will only output pulse train if TTL trigger to PFI0 stays high, thus, indirectly, I can set a retriggerable counting scheme for my photon counting using this gate pulse train. That is why I put trigger property node value of 'pause when low' in the pulse train generation part. But, apparently this doesn't work as I hoped.
Is there any method that I can use in DAQ-MX to achieve the 'retriggerable' pulse train?
Thanks for help!
JJ
Message Edited by SHGfun on 03-22-2006 04:36 PM
