Help with gated buffered counting w/2 USB-6341

[Landauer]

Hi I am working on a program that needs to do gated buffered counting.  The code I am attaching is an excerpt that just has the DAQ parts of the code.  In the program I generate several signals.  Then count from a photo-multiplier tube.

Signals

• 4 KHz laser pulse
• 238 us gate to cut out PMT signal during laser pulse
• 300ms Shutter control to open shutter and illuminate sample with laser
• 10x 30ms buffer bins

I use the 4 KHz signal to trigger the 238us gate and the buffer bins.  The buffer bins trigger the shutters and act as the gate for the buffered counter.  The gating of the counts is handled by an external circuit.

I am having trouble with the buffered counting.  The counter is ignoring the signal I feed into the counter gate for the buffer.  The counter free runs and reads the 10 buffer bins in less than a ms.  Everything else is working fine.

I could really use another set of eyes on this.

[Kevin_Price]

Well, you've got a LOT going on there!

I mostly follow it, but not entirely.  With just a few spare minutes, I couldn't fully trace out all the input & output terminals, the dependencies of some tasks on others, the sequencing of task starts relative to signal presence, other details of task config, method used for reading counts, etc.

The one thing I *did* notice is that in your Main Counter config, the code as-posted has you setting up an Arm Start trigger.   The kind of "gating" you refer to would need a Pause Trigger.   It isn't clear to me whether you need both.

I'm having a hard time understanding the relationship of the different timing constraints.  The 4 kHz laser pulse and 238 microsec gate make sense together.  The 300 msec shutter and 10x30 msec bins make sense together.  I'm not understanding the connection though.

   My best guess is that you're initiating a laser pulse once every 250 microsec, and accumulating photon counts during the latter 238 of those 250 microsec.   But then you'll get 300/0.25 = 1200 total "reactions" during your 300 msec shutter time.  Those (apparently) get divided into 30 msec bins representing cumulative counts throughout 120 of those laser blasts.

   I would have thought you'd want individualized data for *each* laser blast which you could then accumulate (or do other analysis) as a software post-processing exercise.

-Kevin P

[Kevin_Price]

Another thing that looks, to my eye, suspcious:

Also in your Main Counter config, you don't specify the terminal whose edges you want to count (so the default Source pin for that counter will be used).  And then in DAQmx Timing, you declare a fixed 10 MHz sample rate for a sample clock that comes from a PFI pin.

I'm not sure any of this is technically wrong for your overall setup, but it *does* look like an opportunity for a config problem.

I further note that your read loop is starting and stopping tasks every iteration.  I would think you'd want a more continuous acquisition process rather than the intermittently-active method showing now.  I also note that you are reading 10 count values per iteration, so I suppose each reading represents counts across one of your 30 msec intervals?

If I'm following more-or-less correctly, I'd be looking to capture counts across each 250 microsec interval.  Then you could post-process to look at many different possible time-bin sizes.

-Kevin P

[Landauer]

Thanks for the quick response.

In the application I am exposing a sample to a laser and measuring the laser induced luminescence. 

You described the timing constraints correctly.  A 4 khz laser frequency results in a laser pulse every 250us.  The optical filtration in front of the PMT cannot completely remove the signal from the laser pulse so the gate signal provides time discrimination.  The 12us covers the laser pulse duration and some time after to allow the PMT to relax.  Then the luminescence is counted for the next 238us.

The binning is for a visual representation of the measurement period.  I suppose I could bin at each gate, but then I would just post process to recreate the 10 data points for the graph.  This is an update to a legacy system, so I need to keep the visual representation the same.  All data analysis is performed on the sum total counts during the 300ms period.

I am doing gating and buffered counting.  It was my understanding that NI hardware can gate a signal through the pause trigger or buffer a signal but not both, because they both use the gate of the counter.  The gating is handled by an external circuit with a NAND gate so the PMT pulses going into the counter have a 12us gap every 250us.  Then I use the gate of the counter for the buffer.  Is the pause trigger used for buffering?

For the main counter I do have the input counts connected to the default source pin.  Is it consider good practice to specify that source pin even if you are using the default?

For the DAQmx timing, the PMT outputs 30ns pulses so I think I will need to up that sample rate to 100 MHz.  For testing this I am using a function generator with 50% duty cycle so the pulses should be easy to count.  I have tried sample rates from 10 to max and it had no impact.  There must be another issue than this that is causing the counter to ignore the bins.

The loop does stop each time because each sample is only read during the 300ms shutter open time.  Continuous acquisition would just create a bunch of useless data that would need to be parsed out. 

Capturing data for each laser pulse or in the 10 bins boils down to what signal I am routing to the counter for the buffer.  I am generating the bin signal correctly I can see it on my scope.  But the counter is not using it for the buffered counting timing.  The counter is running very fast.  I put ms timers on either side of the counter and the difference is less than 1 ms, ie it does not register and I get 8-12 counts from a 100 khz signal which should be giving me 28500 counts.

[Kevin_Price]

I am doing gating and buffered counting.  It was my understanding that NI hardware can gate a signal through the pause trigger or buffer a signal but not both, because they both use the gate of the counter.

---

I'm pretty sure that's no longer true for X-series and newer devices built around the DAQ-STC3 timing chip.  (It *used* to be true for all prior generations of NI DAQ counter I'm aware of.)   I did a quick and not-totally-thorough test with a 6221 here and it appeared to check out -- I could both buffer and use a pause trigger simultaneously.

Is the pause trigger used for buffering?

No, it acts as a level-sensitive enable/disable control that gates the incoming timebase heading to the counter source pin.

For the main counter I do have the input counts connected to the default source pin.  Is it consider good practice to specify that source pin even if you are using the default?

Not necessary if your hardware wiring scheme is fixed and not subject to change.  But it doesn't hurt, especially considering all the other things you have that are configurable. 

For the DAQmx timing, the PMT outputs 30ns pulses so I think I will need to up that sample rate to 100 MHz.  For testing this I am using a function generator with 50% duty cycle so the pulses should be easy to count.  I have tried sample rates from 10 to max and it had no impact.  There must be another issue than this that is causing the counter to ignore the bins.

Nope.  Actual sampling is driven by the signal at the terminal wired into the 'source' input.  When using an external sample clock, what you feed to the 'rate' input is just gossip that DAQmx will believe but not verify.  That's why you saw no impact.

The counter is running very fast.  I put ms timers on either side of the counter and the difference is less than 1 ms, ie it does not register and I get 8-12 counts from a 100 khz signal which should be giving me 28500 counts.

I'm not following how these #'s relate to the other timing #'s you've presented.

-Kevin P

[Landauer]

---

The counter is running very fast.  I put ms timers on either side of the counter and the difference is less than 1 ms, ie it does not register and I get 8-12 counts from a 100 khz signal which should be giving me 28500 counts.

I'm not following how these #'s relate to the other timing #'s you've presented.

---

The overall goal of the code is to count pulses for 300ms.  Given a 100kHz signal from a function generator I should get 28500 counts and the counter activity should take 300 ms complete.  But the edges of the buffer are being ignored and the counter buffer fills in less than 1 ms with 0 to 2 counts in each bin instead of the 2850 I am expecting. 

Could you post the code you created for your buffer and pause trigger test?

[Kevin_Price · Accepted solution]

For the test I just used shipping examples and tweaked the settings suitably.   I counted the 20 MHz timebase, sampled with the 100 kHz timebase, and used another counter's output as a pause trigger.

The buffer of counts incremented by 200 each sample (= 20 MHz / 100 kHz) until I generated the pause trigger.  Then samples kept buffering, but the count stopped advancing while the pulse was high.  After the pulse, the buffer of counts went back to 200-count increments at a 20 MHz rate.  No errors from DAQmx.

I back-saved to LV 2015, see attached.

-Kevin P

[Landauer]

Thanks I got it to work.  I had the DAQmx Timing sample clock routed to the source for the counter and was putting my counts input to that same pin.  So I was binning at the frequency I was trying to count.  Once I defined the counter input and the timing sample clock separately everything worked.