Counting pulses using PCI 6602

[snh22]

Hello,

I want to count TTL pulses from an APD using PCI 6602 counters and Labview.I have gated the APD signal using an external clock.I I generated this signal using PCI  it has  2.5microsecond on time and 0.5microsecond off time.Then I am counting the pulses at the counter from APD and write it in a file.I am using a queue structure to do this.The VI seems to work fine without error but the values of the pulses counted keep on increasing I don't understand why this is happening.I think the values are just garbage value or may be cummulative values.Does the counter in PCI give cummulative values?I am confused.I have my VI below.Please help!

snh

[snh22]

Hello,

I want to count TTL pulses from an APD using PCI 6602 counters and Labview.I have gated the APD signal using an external clock.I I generated this signal using PCI  it has  2.5microsecond on time and 0.5microsecond off time.Then I am counting the pulses at the counter from APD and write it in a file.I am using a queue structure to do this.The VI seems to work fine without error but the values of the pulses counted keep on increasing I don't understand why this is happening.I think the values are just garbage value or may be cummulative values.Does the counter in PCI give cummulative values?I am confused.I have my VI below.Please help!

snh

[Kevin_Price]

Yes, an edge-counting task will continue to count and give you cumulative values.  It sounds like you'd want the features of period measurement, where each sample interval restarts the count from 0.

I don't have time for a lot of explanation right now, but I modified the task configuration accordingly in the vi you posted.  The snippet is posted below, give it a try and see if it gets you the data in the form you're looking for.

-Kevin P

[Kevin_Price]

Ok, I've got a couple minutes to explain a bit of what I posted yesterday.

Counters can be pretty versatile and I've found that the habit of thinking about measurements in units of "Ticks" has been a helpful way to tap into that versatility.  It's a holdover from learning under the older driver that pretty much demanded that perspective.

The key concept is that period measurement mode already provides a means to have the count restart from 0 during each sampling interval.  Then it's just a matter of configuring the physical signals to map to the right function.  In buffered period measurement, source (aka "timebase") edges cause the count to increment while gate (aka "sample clock") edges will buffer the instantaneous count and also reset the count register back to 0 for the next interval.

So the APD signal is configured to act as the timebase in this task -- these are the edges you count.  Another counter is generating a sample clock and you are then characterizing the period of that sample clock in terms of the # of APD pulses that occur per interval. 

To accomplish this, the DAQmx Timing vi is set up to use "Implicit" timing.  In period measurement mode, that means that the signal whose period is being measured implicitly sets the timing of sampling based on whenever its edges arrive.  So we finish off by setting up that sample clock signal as CI.Period.Terminal

The whole approach is kinda inside-out from how you'd normally think of doing period measurement on a variable signal.  Instead of using a constant timebase to measure a variable interval, you're using a variable timebase to "measure" a constant interval.  But when you think it through you can see that this method gives you the results you're after.

The last comment is on the "Duplicate Count Prevention" property.  It might be True by default, but I'm making sure.  When True, it will buffer values of 0 during intervals in which 0 APD pulses occur.  Behavior when set to False can vary with different boards, but it's rarely what anyone would prefer.

-Kevin P

[snh22]

Thank you very much for the detailed explanation Kevin. I will make the changes you suggested and let you know if it works.

snh

[snh22]

Hello Kevin,

I modified my code and now what I am measuring are definitely the APD pulses. Thank you very much for the suggestion.But now when I run the code after 5-10 seconds I  get error 200279.It says the following "Attempted to read samples that are no longer available. The requested sample was previously available, but has since been overwritten."

I read solution for it online and the best solution is a producer/consumer loop which I  have already implemented in the code.I understand the basic idea of a producer/consumer loop, it has a enqueue loop and dequeque loop. I have also included a loop which gives me the queue status.But what I observe from the queue status is that the elements in the queue keep on increasing and the queue never gets emptied.I tried decreasing the enqueue speed my using a wait timing option so that the dequeque loop gets some more time but still the error is continuing.I don't know how to correct this error.Pleas help!

I have attached the modified VI for your reference.

snh

[I.B.Hating]

snh,

Did you read this article?

http://digital.ni.com/public.nsf/allkb/AB7D4CA85967804586257380006F0E62

The reason that you are seeing this error is you are putting more data in your buffer than you are taking out so your onboard buffer is filling up. The reason that a producer-consumer loop is recommended is because it is assumed that you are doing some sort of operation on your data before grabbing more data, adding to the time it takes to grab data points. To fix this problem you will either have to take the data from the buffer and put it in your computer quicker or reduce the rate at which you are putting data points in your buffer.

The producer-consumer loop allows you to take data out of the buffer at a rate which is not dependent on the time it takes to do whatever operation you are doing on your data. You will not want to put any sort of wait here, you will need to keep at least the first enqueue element as fast as you can.

You can also just reduce the sampling rate of your 6602 which will fill up the buffer slower and will allow you to grab data out at a comparable rate.

The article also recommends increasing your buffer size however if you are doing a continuous acquisition this will only delay the amount of time it takes to fill up the buffer. If you are not doing continuous acquisition this may be a solution.

Does this help?

[snh22]

Hello Brian,

Thank you very much for your reply.I did read the page you suggested earlier itself and from that  I implemented their solution of reading the data more frequently which sugested architecting(producer/consumer loop) to solve the problem.

I tried decreasing the sample rate as you suggested by decreasing the frequency of my gate pulse  from 333khz to 10khz the code does run for a longer period but eventually buffer gets overwritten giving me 200279 error.So the problem is still not solved 😞

Also what I observed is the DAQ card does read the correct number of samples(did this by using DAQ Read property- total number of samples acquired per channel)  but doesnot write all  the samples that  it acquires.For example if 9000K samples are acquire  in 15mins it only writes 13,795 samples.Why is this happening?How do I correct it so that it writes all the 9000K samples?

Thirdly,If I want to keep my rate high i.e. 333kHz then I must implement the your first suggestion  ie take the data from the buffer and put it into computer quicker..how do I do that I don't understand?

Thanks a lot for you help.I appreciate it very much 🙂

snh.

[Kevin_Price]

Ok, I didn't have time to look last week, but I think I see some issues.  To begin with, I think your status loop is probably consuming too much CPU and starving out your other loops.  So the first thing I'd suggest is to get rid of the status loop entirely.  If you want to query the data queue for # elements, put that query in the consumer loop.

Once reduced to only 2 loops, the next item of concern is the unbounded "Build Array" in the consumer loop.  You're trying to grow that array indefinitely and this will eventually lead to out-of-memory errors.  For now, get rid of the "Build Array" and Feedback Node.  (Note that your status loop was also setting you up for an additional out-of-memory problem.  The boolean queue was being over-stuffed by the status loop while the consumer loop was limited to run only once per data array from the producer loop.  Eventually, this overstuffing would also lead to out-of-memory problems.)

I have very little familiarity with the file writing Express VI you used in the consumer loop, but am suspicious that it could be another significant source of inefficiency.

The last thing I'd note is that there are several better options for communicating the "Acq stop" boolean between the two loops.   I wouldn't bother sending a False value since it doesn't have any effect. I'd only send the value when it turns True.  I'd also use a Notifier instead of a Queue.  (With a Notifier, set the 'ignore previous' input to False and the 'timeout' input to 0.)

-Kevin P

[snh22]

Hello Kevin,

I am still working on trying to count photons.My gate signal now is the 80Mhz timebase present inside the PCI 6602 card.I am getting error 50103.I have the snippet of my VI.Please let me know if you understand why I am getting this error.Thank you 🙂

[sassyaspy]

Hello snh22,

There are a few reasons why this might be happening with your code, and most of those are detailed in this article from our website:

http://digital.ni.com/public.nsf/allkb/485201B647950BF886257537006CEB89

Although it is hard to say for sure without knowing the full scope of your project, a likely reason for the error in this case is "Having counter tasks that need two counters and one of them is being used by another task on the same device." Hope this helps!