Counter/Timer

cancel
Showing results for 
Search instead for 
Did you mean: 

Timestamped event counting with M-series device

I'm just getting started learning DAQmx, and am struggling with some of the concepts and (I think) the limitations of my card. I'm using a PCI-6221 card, which has two counters, and LabView 8.2.

I have an input signal consisting of digital edges arriving at random times (~1KHz, from an avalanche photodiode). I would like to set an accumulation time, then timestamp every edge which arrives within this accumulation time. I would like to stop detecting edges exactly when this accumulation time is reached. It is possible that there will be very few or no counts within this window.

I've been reading through several of the threads on this forum, and have settled on an idea which works reasonably well. I have created a CI Cnt Edges task with one counter (ctr0), which is connected to a Sample Clock in continuous samples mode whose source is the gate of the counter (pfi9). This is then connected to a DAQmx Trigger property node, with CI.CountEdges.Term set to the 80MHz timebase. The start is hardware-triggered, and I do a 'Counter 1D DBL NSamp' acquisition in a loop. Thus, each time I receive a signal on the gate of the counter (pfi9) I read in the current count at the source, which is easily converted into a timestamp. My problem is stopping the counting process at the correct time. Right now, I wait until the buffer is full, and check the timestamp of the final count; if it is larger than the accumulation time, then I know I've counted far enough and terminate. If there are not enough counts, I rely on the timeout of the read task. However, this doesn't work very well: the number of samples (buffer size) needs to be exactly right or I get very erratic counts. I think the reason why is that if the buffer size is too large, then the VI relies on the timeout to stop, which is controlled by software timing, while if the buffer is too small, it gets overwritten before the timestamps can be stored.

Does anyone have a suggestion on a good way to do this? I think what I want to do is create a finite pulse train at the source of the counter, which has a very high frequency and lasts for the accumulation time. This would let me know exactly when the accumulation has finished, enabling me to have a very large buffer size and no missed counts. However, I only have two counters available and was of the impression that doing things this way would require three counters. Any ideas or sample code would be very much appreciated.

Thanks!
Ben
0 Kudos
Message 1 of 4
(4,028 Views)

Hello Ben,

You do need three counters to accomplish this task.  If you want to get a counter board, I would recommend a PCI-6602.  However, there might be an easy work around, since you have an M-Series DAQ board. 

You could simulate a gate signal from an analog output channel.  The analog output signal would be a square pulse at your desired accumulation time.  Use this square pulse as the gate to your counter.  Effectively, you have created a finite pulse generation with one counter instead of two. 

Make sure that you synchronize all of these tasks.  The best way to accomplish this is by making one of the tasks a master and the other tasks a slave.  Start all of the slave tasks first and then start the master task.  This can be accomplished by data flow using the error cluster.  There is a great shipping example that illustrates how to accomplish synchronization.  (Hardware Input & Output >> DAQmx >> Synchronization >> Multi-Function >> Multi-Function-Synch AI-AO.vi)

 
Respectfully,

Rob F
Test Engineer
Condition Measurements
National Instruments
Message 2 of 4
(4,006 Views)

Rob's suggestion is a good one, based in hardware-level timing.  I just wanted to offer up a simpler idea which may or may not work for your needs.  Since you said you're new to DAQmx, you're probably not familiar with the tradeoffs of different methods.  I'm proposing a method that can work with only 1 counter.

I don't have LV handy to look at your vi now, but I *think* a key sticking point is how you handle the call to DAQmx Read.  It sounds like you aren't familiar with some more flexible ways to work with that vi, relying on either reading all the data at once or letting the call get stuck until it times out.  These are NOT your only options for interacting with a DAQmx acquisition buffer.

Check out the DAQmx Read Property Node.  You can call that to query a property named "NumAvailableSamples".  By monitoring this value and also monitoring your elapsed time in a loop, you can put yourself back in full control.  You can terminate the loop on the earlier condition, whether it's based on elapsed time or based on accumulating the max # of samples you want.  After ending the loop, you can call DAQmx Read.  Just wire in as the # of samples to read the # you know is available.

Then your software would just inspect the timestamps you gathered, in case you need to trim off any samples near the end that occurred slightly too late.  (There will be a finite software reaction time which you should allow for.  Make sure the software elapsed time is allowed to be slightly longer than the true hardware collection time.  You can always ignore samples collected slightly too late, but you don't want to read them too early and risk missing some.

There are many variations on this theme, but the essence of it is to let your software monitor both time and samples, putting you back in control of the application software timing.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 3 of 4
(3,993 Views)

Hello Ben,

Either method should work for your application.  Just beware of using software timing with your application.  If you are using Windows as an Operating System (OS), then you may not be able to get the accuracy that you can achieve with hardware timing.  Windows is non-deterministic and cannot guarantee that a specific event will happen exactly when you want it to.  Usually, Windows is going to give you an accuracy of approximately in the millisecond range. 

With hardware timed applications, you can usually get better timing resolution specific to your application.  Hardware timed applications might be a little harder to setup but it is usually a better solution.  Software timed might require you to acquire more data than you need and then discarding this information through software.  With hardware timed application, you are assured that you will only acquire the data that you want. 

Respectfully,

Rob F
Test Engineer
Condition Measurements
National Instruments
0 Kudos
Message 4 of 4
(3,975 Views)