6052E DAQ-STC Counter help

[SHGfun]

Hello, I am really new to the labview programming community. I was trying to figure out a way to collect non-cumulative bins of TTL pulses out of my photon-counting pmt using the on-board counter of NI 6052E. After searching through messages posted in the past, I kind of patched together a simple vi to run the task. But several questions still bothered me:

I'd like to use the 'Measure Buffered Period (DAQ-STC).vi', but it didn't reset the count to zero after each rising edge of the gate pulse generated from another counter, contrary to the info provided in the help. Instead, I used 'Measure Buffered Pulse (DAQ-STC).vi', but then I might run into problem since 'The counter is only incremented between the rising and falling edges of the gate'.

A separate question would be how can I output the buffered TTL counts to a binary or spreadsheet file?

Any input/help will be greatly appreciated.

Newbie,

JJ

[Laura F.]

Hello JJ,

I would recommend using the NI-DAQmx API instead of Traditional DAQ (Legacy) if you are just getting started with your application and you are using LabVIEW 7 or above.  NI-DAQmx supports the hardware that you are using.  If you would like to read about NI-DAQmx you can do so in the following tutorials:  Advantages of NI-DAQmx, Learn 10 functions in NI-DAQmx, and NI-DAQmx FAQs.

You may have seen this thread about photon counting with NI-DAQmx already, but I want to draw your attention to it if you have not.  It lists two examples,

Meas Dig Periods-Buffered-Finite-High Freq 2 Ctr.vi

Meas Dig Periods-Buffered-Continuous-High Freq 2 Ctr.vi

which can be used to count in a non-cumulative fashion.  If you read to the bottom of that thread, a community member who has previously done what you are looking for recommends using a separate loop to save the data to file.  He used queues to send data to the second loop.  If you are interested in this architecture, there are many examples of using queues to transfer data between loops if you search in the Example Finder for "queue".  The other method is to store the data in an array and save it after all data has been collected.  Only do this if you are certain that your array size will stay manageable.  In the above thread I have referenced, there is a VI posted using DAQmx that does this. 

If you must continue to use Traditional NI-DAQ, you can use the same two methods of saving to file. 

Please let us know if you have additional questions.

Thanks,

Laura

[SHGfun]

Thanks Laura, I'll look into that thread you mentioned.

Meanwhile, in terms of using traditional DAQ, does anyone know the thing I asked about period counting?

Thanks,

JJ

[Kevin_Price]

JJ,

1. I've done a lot of buffered period measurements with E-series boards and traditional NI-DAQ and the buffered counts DO get reset to 0 on each active edge of the gate pulse.  So the problems you're having are not due to inherent limitations of the board or driver.

2. Can you post your code?  Lacking that, I can only speculate as follows:

- Are you sure your measurement counter was fully configured to use the other counter's output as it's Gate?  This can be done programmatically without any wiring.  Down in the LabVIEW examples folder (something like examples/daq/counter/ni-tio.llb) are some really handy config vi's including one called 'Counter Gate (NI-TIO).vi'.  Using that you should specify 'other counter output' as the Gate signal and 'rising edge' as the Gate mode.

- What kind of data did you get?  You could get strange data if there are any Gate pulse train periods during which there are no Source edges.  I *think* that what I've seen in practice is for the previous interval's value to repeat.  However I also sorta recall that the 'official' specs wouldn't guarantee that behavior all the time.

    DAQmx provides a property called 'Duplicate Count Prevention' to help handle this case more cleanly.  Under traditional NI-DAQ, there's a mode called 'synchronous counting' or something like that to try to handle such a case.  Check the manual and/or online help.

Post back with code and/or more details.  Meanwhile, I'd also recommend DAQmx if it's an option.  Just realize that all interactions with your E-series board should be either traditional NI-DAQ or DAQmx, but NOT a mixture.  So if you go with DAQmx for the counters, you must also go with it for any analog or digital tasks.

-Kevin P.

[Kevin_Price]

I wrote:

DAQmx provides a property called 'Duplicate Count Prevention' to help handle this case more cleanly.  Under traditional NI-DAQ, there's a mode called 'synchronous counting' or something like that to try to handle such a case.  Check the manual and/or online help.

Oops!  Sorry about that advice above.  The "synchronous counting" feature isn't actually available for E-series boards.  So under traditional NI-DAQ, you're sorta stuck.  However, the 'Duplicate Count Prevention' property can be used under DAQmx to get the right behavior from E-series boards.  One more reason to switch...

-Kevin P.

[SHGfun]

Kevin,

Thanks for the advices. The vi I'm using are just from the daq examples as attached.

It seems this specific vi of period measurement can specify the gate using other counter's output. Although according to the help, signal to be measured should be connected to the gate, right?

Too bad that I may have to stick to the traditional daq now, since some other aquisition using matlab are using traditional daq, and I want to run both at the same time.

JJ

[SHGfun]

I have to take back something I mentioned from the last post. I was feeding the signal to the source not to the gate. Upon flash of light, I can see pulse of photons counted, if I do the same thing with measure period, then I just get a ladder map of some accumulating counts.

Seperate question: I am having some trouble reading the binary file saved using matlab. I just use fopen then fread with 'uint32' format, somehow the numbers are messed up, showing 10E9 intead of say 100. Any ideas?

Thanks,

JJ

[Laura F.]

Hello JJ,

If your acquisition using MATLAB uses a separate DAQ device than the one doing your photon measurement, you will be able to use NI-DAQmx for your photon measurements.  However, as Kevin says above you need to use the same driver if you have only one device. 

 Unfortunately, I am not very familiar with file functions in MATLAB.  Also, if you would like to move your other data acquisition program over to LabVIEW, there are hundreds of users that monitor these forums that are happy to help.   

Regards,

Laura

[SHGfun]

Laura and Kevin, thank you for all the helpful input and I have to apologize for my very first post.

I went back to count the internal time base, and I found that the period measurement is indeed zeroed at each rising edge of the gate pulse. So it must be something with my photon counting pmt output and this lack of duplicate prevention thing in traditional daq.

One thing still puzzles me though, since both the pulse measurement and period measurement vi lack duplicate prevention, how come one is okay while the other is not under the same conditions?

JJ

[Kevin_Price]

One thing still puzzles me though, since both the pulse measurement and period measurement vi lack duplicate prevention, how come one is okay while the other is not under the same conditions?

Good question, and I don't really know the answer.   It seems that down at the lowest level, period measurement could work like this:

- on receipt of active gate edge, store count register in buffer then reset count register to zero.  However for some reason, probably tied to the actual counter hardware on the board, the presence of an active source edge is needed between consecutive gate edges.  It probably resets or reactivates some part of the counter circuitry.

With pulse width measurement I imagine it could work like this:

- on receipt of leading gate edge, reset count register to zero

- on receipt of trailing gate edge, store count register in buffer.

So do pulse width measurements that have no source edges between gate pulses result in a series of 0-values in the acq. buffer?  I don't think I've ever tested that scenario and agree that it's a bit puzzling why pulse widths give predictable & reasonable values while periods may not.  The way the counter operates is only slightly different...

Not much of an answer, just didn't want to leave your question hanging too long.  I'd be curious to get an answer too.

-Kevin P.