Counting photomultplier TTLs per ms using the 6602

[SteveP]

Kevin,

I believe the DAQmx Channel property node you're refering to is Counter Input > Period > Input Terminal. It shows up as CI.Input.Term
When I insert this into the the Meas Dig Period - Low Freq 1 Ctr.vi example, choose PFI0, and have a 100 Hz signal at PFI0, I get 200,000 ticks. This is 1/100 th of a 20 MHz timebase. So it still seems to be using this Input Terminal as the Sample Clk or gate and the internal 20 MHz clock as the Source, i.e. normal period measurement

Steve

[Kevin_Price]

SteveP,

Yeah, you're right. Sorry about that. It appears that for DAQmx period measurement, the DAQmx Timing vi must be set for "Implicit" and then you're not allowed to specify the source of the signal to use as a Sample Clock. Instead you specify the Timebase source using a DAQmx Channel property node. Thanks for the catch!

Here's a screenshot of something that worked when I tested it on hw. I used an M-series counter to perform the buffered period measurement. I used MAX to generate the pulsetrains I specified as the "Timebase Source" and the "Period Input Terminal." Note that setting the "Duplicate Count Prevention" property to True will buffer up values of 0 during intervals in which no timebase edges are seen between period input edges. I'm still scratching my head over why this behavior is considered "prevention==True" rather than "prevention==False." In case this has changed, I should note that I used DAQmx 7.3

-Kevin P.

[SteveP]

There is a difference in behavior for different boards at least for buffered Event Counting using DAQmx 7.4 when no Duplicate Count Prevention property is being used. On an E series MIO-16E-4, if no input counts are present, zero values are returned in the buffer time bins. With a 6602, the buffer is not returned, probably because it is not being filled with a value of zero counts in its time bins, and a timeout error results. Adding the Duplicate Count Prevention property and changing from its default state of False to True causes the 6602 to return values of zero and not timeout.

[gus]

The name duplicate count prevention makes more sense in the context of E Series vs. TIO/M Series counters rather than just the TIO/M Series counter itself. In retrospect, I completely understand why it is confusing. In DAQ 7.4, extra logic has been placed in the driver for the default selection of the duplicate count prevention attribute which will hopefully make it easier to use. From the NI-DAQ 7.4 Readme:

"The default setting for the duplicate count prevention attribute/property on M Series and TIO-based counters has been changed. This change affects all input counter operations, with the exception of single-point edge counting and position measurements. Duplicate count prevention is now on by default as long as the following conditions are met:

The duplicate count prevention attribute/property has not been explicitly set.
The selected counter timebase source is not set to an internal timebase.
The prescaler attribute/property has not been set.
The counter output event has not been configured."

With this logic, most applications should appear to behave very similarly to E Series devices. Additionally, more documentation for duplicate count prevention has been added to the DAQmx Help document under Device Considerations >> Counters >> Duplicate Count Prevention.

I hope this helps!
gus....

[SteveP]

Kevin,

For your method of doing buffered period measurement as a way of getting non-cummulative event counts per bin, I am continuously acquiring a finite number of bins following each external digital trigger using re-triggerable finit pulse generation as the clock source for the bins. After each trigger, I sum the results from each bin onto an existing array to continuously obtain the average counts per bin. Is there any way to not have the bins re-zero themselves so this summation would happen automatically in hardware ? Some way to re-use the same buffer but not clear it for each cycle ?

Steve

[Kevin_Price]

Steve,

Here's an example to make sure I'm answering the question you're asking. I'll assume 5 useful bins per trigger, and that Bin 0 was already discarded if necessary.

What you get now from the hw (individual trial counts, one bin per line):
------------------------------------------------------------------
4, 3, 3
9, 9, 6
13,11,12
10,12,14
5, 8, 9


What you would prefer from the hw (cumulative total counts, one bin per line):
--------------------------------------------------------------
4, 7,10
9,18,24
13,24,36
10,22,36
5,13,22

If this illustrates what you're looking for, then no, I don't know of any way to make the hw do that for you. What's the problem with doing it in sw? I wouldn't normally expect this sort of integer array addition to become a speed or memory problem.

-Kevin P.

[SteveP]

Kevin

Yes, that is what I had in mind. It can certainly be done in software, as long as the computation time is shorter than the period between triggers of course, which should not be a problem. I would like to do a real time plot every so often, which can be done with use of a large buffer, or other means. I just thought that if it was easy to do the summation in hardware, why not and be safe ?

Steve

[jimmer]

Hi,
I have been trying to follow this thread with great interest.  It is however a bit complicated for me being relatively new to Labview and DAQmx in particular.
I have a very similar application which even sounds a bit simpler than the original post.
I have random TTLs coming from a photon detector which I want to count the number of pulses in a given time bin - so far the same as the previous post.  However, after collecting over this bin (say 4ms), I want to stop counting and reset the counter.  Basically, I am collecting a fluorescence image, so at a given point in my 2dimensional scan, I collect photons for 4 ms, then I stop counting, move the scanning stage to the next pixel, and count again for 4 ms, etc etc. until I have sampled each point in the 2d scan.

I have my photon TTL pulses going to one input pin, and I have a clock pulse going to another input pin of my BNC 2110. 
Right now what I have done is used "DAQ Assistant" edge counting with the acquisition mode set to "1 Sample (HW timed)" .  This is where I get a bit confused.  I am not entirely sure how to tell Labview to only collect for 4ms.  (I would ideally like to include this in the front panel as a control, where the user could select the integration time per pixel for the scan)  I have my external closk set to 250 Hz, so that 1 Sample equates to 4ms.  Is my understanding correct in how Labview counts the pulses here?  Once this count is complete, I then DAQ mx stop task.vi to stop the DAQ Assistant and effectively reset the counts to zero.  Next time around the loop (i.e. next pixel) it does it all over again.
I am convinced there is an easier way, or more elegant way, to do this.  For instance: do I really need an external clock?  It seems bizarre that with all the electronics in the PC and card, that I can't get a clock from somewhere ...! ( I have the PCI 6229 by the way).
Another strange thing, that could be an effect of how I collect counts, is that there seem to be random spikes in the counts occuring through the data.  This is not likely from the detector, but seems to be electronic noise from within the card/PC.
Anyway help would be much appreciated.
CHeers,
Jim

[Sean_C.]

Hi Jim,

Take a look at the attached VI.  In it I use Ctr0 to generate a 250 Hz pulse train.  I then use that pulse train as the sample clock for a continuous buffered event counting task.

Every element in the array indicator was taken 4 ms after the previous element.  With this information it is a simple matter of subtracting one element from the next to find out how many pulses have occured within that 4 ms.

Does this help?

Regards,
Sean C.

[jimmer]

Hi Sean,
Yes this is definitely helpful.  I stepped through and I'm pretty sure I follow what happens in this sequence:
The clock is generated in Labview itself right?  You send the clock signal to an output pin, where/how do you bring the clock signal back into the program?  Or is that not necessary?  From the looks of it I do not need an external signal generator like I was hoping.
If I now want to adapt this to my own application, is it correct that I would set the "samples to read" control to "1" so that after one 4 ms sample count, the program would exit the loop, step the piezo one step and then go back into the 4 ms sample count for another count?  I guess the point is that between each 4 ms count, I have to step my scanning stage, and during the stepping process, I don't want to be counting any pulses from my detector.
Thanks again, you have put me on the right track (assuming the above assumptions are correct ...)
Cheers,
Jim