How to prioritize a counter task

[Meg T]

Hi,

I'm sure this issue has been discussed previously, but I was not sure how to phrase the question to find the previous threads. We're working a gated photon counting vi using a pair of 6229 cards. We generate a gate with one counter and count pulses from the pmt with the other counter.  We have a relatively old computer (that we're updating) and when we attempt to open folders or other windows, the counter seems to lose cpu priority temporarily and the resulting output is unreasonably high.

Accurate "counts" are the basis for our experiment, so we'd like to know if there is a way to prioritize the counter tasks or to create a buffer which would prevent this windows-related glitch in our program. Any insight or even a link to a previous thread would be quite useful!

Thanks!

[John_P1]

Hi kate04,

How are you generating the gate signal?  If you implement a Continuous CO task then the period of the gate signal should remain constant regardless of the CPU.  Additionally, configuring "Implicit" timing on the CI task will ensure that every sample is latched into a buffer--if the CPU can't keep up with the data coming in you would receive a buffer overflow error (but you can increase the size of the buffer or read more data per loop if necessary).

Could you post the code you have so far so we can take a look?

Best Regards,

[Meg T]

Thanks for your help! Here are the 2 vi files. The "integrated gate mover" generates a delayed gate from a TTL output sent from our pulsed laser. The "integrated data taker" uses the gate for counting the pulses coming from our PMT.

[John_P1]

The problem is that using the gate signal as a "Pause Trigger" does not latch in the values into a buffer.  Instead, you should configure a Pulse Width Measurement with Implicit timing that will sample the value of the count register at the end of each gate signal.

You probably want your read VI to look more like the attached code.

Best Regards,

Message Edited by John P on 05-17-2010 11:52 AM

[Meg T]

Hi John,

Thanks for sending the VI. We don't quite understand how to execute it yet. When we try to run the VI, we get the following error:

Error -200143 occurred at DAQmx Start Task.vi:16

Measurements: Counter timebase rate must be specified for external counter timebase sources in order for frequency and/or time calculations to be made correctly.

Set the Counter Timebase Rate property to the appropriate value for your external source.

I don't completely understand how to take advantage of the pulse width measurement to make an edge counting measurement. It seems like your VI would take the pulsed output from the PMT ("actual counter input") and use this as the counter timebase source. The pause trigger (which is the gate that was  generated by our "integrated gate mover" from the laser's TTL) is being used as the source of the pulse width. Is it fair to say that we are attempting to measure the width of the gate (pause trigger) in terms of the pulses come from the PMT? For example, if we had a large signal, more pulses would be observed during the gate, so the pulse would effectively have a larger width. Is this relative time base the reason that we use "implicit" timing or is implicit just for the purpose of creating a buffer in memory?

Sorry for the confusion! We've been trying to figure this out with labVIEW help, but haven't been able to put together a complete understanding.

Thanks!

[John_P1]

Oops, I left out one thing:

You'll need to add the "ticks" input to the Create Channel VI:

Indeed, this would be measuring the width of the gate in terms of pulses from the PMT.  The value of the counter will reset after every gate pulse and would look something like this:

In this case, Implicit means that the value is latched into a buffer at the end of every pulse on the gate signal.

For further reading a good place to look is the Counter Input Applications section of the M Series User Manual.  Although it doesn't show how to program the counters, it will give you an idea of how the hardware works which is very important to be able to understand the software calls that are necessary to control it.

Best Regards,

[Meg T]

Hi John,

Your suggestion worked for us. We are able to count the pulses inside the gate. The vi works as a single gate counter, but we would like to count 5000 gates in series since our laser operates at 5kHz and we want to determine counts/second. We are somewhat concerned about speed and would like to integrate gate counts in the shortest possible amount of time. By configuring the task to count "n samples" we are able to count the gate samples quickly (faster than by looping), but we are limited to outputting 1000 data points into an array. We tried to increase the buffer size as suggested in the help by using "daqmx configure input buffer size" but we still appear to be limited to 1000 data points. Is there a way to increase the buffer size or to write data from the buffer? If not, is there a reasonably fast way to count 5000 samples?

Hopefully we're almost there with this solution. We really appreciate your help!

Thanks!

[John_P1 · Accepted solution]

Hi Kate,

Thanks for the extra info--it sounds like you changed the instance of DAQmx Read to be N samples but still need to wire the samples per channel input to the DAQmx Timing.vi

Using samples per channel is another way to set the buffer size.  For finite tasks (which is the default), the buffer size = samples per channel (unless otherwise specified).  The default samples per channel is 1000.  Wiring this should allow you to tell the task exactly how many consecutive gates to measure--regardless of the buffer size the task will end after samples per chanel acquisitions have been completed.

Reading N samples will indeed be much faster (just watch out for timeouts).  You can actually leave the number of samples per channel unwired on the DAQmx Read--the default is -1 which means to read all of the desired samples from your finite task.

Best Regards,

[Meg T]

Thanks! This solves our problem!