How can I disarm the counter in a specified time?

[shireman]

I am using 6602 counter. I use 2 counters to perform "Buffered Period Measurement ". I use internal time base (20MHz) as the SOURCE, and wire the signal to the Gate. The counters are triggered by a trigger signal.

Now I just want to stop counting the signal in a specified time after the counters triggered. After that time, even the input signal is still running,the counting must be stopped. How can I implement this purpose? I don't know how to disarm the counter when the counter are still running, and how to exactly determinate the stop time.

Thanks for any advise. I have attach my present routine here.

[Tiptop]

Hello,


So our problem is how to stop the counters? Well, with �Buffered Period Measurements� the only way to stop the counter is with a software call. If all we can use is a software call, and we need to stop after a specific amount of time, then we will have to figure how much time has passed since the arming of the counter. In DAQmx we would simply compute the sum of our arrays which contain period information. In Traditional DAQ, we could figure out how many pulses there are in the amount of time that would like to have pass, and then add our array of pulses.

The overall goal would be to reset the counter as soon as we know, in software, that a specific amount of time has passed. Just let me know if you have any further questions or need more detail
ed information in a specific area.


Best regards,

Justin T.
National Instruments

[Kevin_Price]

Just to expand a bit on Justin's answer to outline a few particulars.

You mentioned using 2 counters to capture buffered periods so I'm assuming that you'll enable triggering to guarantee that they both have the same start time. Note that in this scheme, element #0 of your array of buffered periods will represent the time from the Trigger edge until the first Gate edge.

Since your description made it sound acceptable to ignore pulse periods occurring later than the interval of interest, perhaps you can collect data for a little longer than necessary, then reset the counters and trim off the periods that came in "too late" using 'Array Subset.' A quick-and-dirty way is to loop over each array of periods, performing a cumulative sum until it exceeds the specified data collection time interval. That'll tell you the length of the subset you need to keep.
The hard part is that after starting the measurement, you'll need to poll task attributes/properties to determine when the trigger has been received. Only after that's been determined would you start keeping track of approximate time in software.

There are ways to do the timing in hardware if you get more of the 6602's counters involved. Here's one way:
1. First configure your 2 counters for buffered period measurement. However, instead of using the internal timebase for a Source, use another counter's output as a Source. Under DAQmx, the internal routing details are handled for you; under traditional NI-DAQ, you'll need to make explicit routing via RTSI.
Note that in this scheme, these 2 counters don't need to be triggered.
2. Next, generate a finite-duration pulse train at 20 MHz (examples can be readily found under LabVIEW help or this website). This pulse train should last for your data collection time interval, and will act as the Source signal for your period measurements. It is important that the period-measuring counters are started before the finite pulse train.

The finite pulse train uses 2 counters -- one to generate the output pulse train at 20 MHz and a "helper" that produces a single pulse whose duration equals your data collection interval time.
If you need to synchronize to some external trigger signal, you can set the "helper" counter to be triggered, but there'll be one subtle catch. The first period measurement in your buffers will not include the time from the external trigger signal until the beginning of the single "helper" pulse, i.e., the "delay" time spec for the pulse. You can either make this very very short and ignore it, or make it any convenient duration and then add it to the first period measurements. Be careful though: the timebase for this "delay" time isn't necessarily the same as the timebase used to measure periods.

There's quite a bit of complication there, so let me suggest an easier way that assumes no need to synchronize to an external trigger. (I'll use DAQmx terminology, since the traditional NI-DAQ would get complicated again with explicit RTSI signal routing.)

A. As describe in #1 above, configure your period-measuring counters to use a 3rd counter's output as the timing source terminal.
B. After starting your 2 period-measuring counters, start up the 3rd counter to generate a continuous 20 MHz pulse train.
C. After the 3rd counter starts, call the 'Wait (ms)' function from the Time & Dialog palette. Wait for slightly longer than your desired collection time.
D. Read all buffered periods from the counters. You may need to first query each to find out how many are waiting to be read.
E. Reset all 3 counters.
F. Do the cumulative sum work on the two buffered period arrays to determine where each should be truncated.

Note that step "C" above will leave you stuck while data is being collected. A small variation would be to read a reference time ("Tick Count (ms)") right after starting your 20 MHz counter, then set up a loop that allows you to terminate early (logical OR of, say, "abort" button, data acq error cluster error, and time comparison). In that loop, you put a delay of maybe 50-200 msec using "Wait (ms)."
"Wait (ms)" will output a tick count from which you subtract the reference time. When the difference exceeds your data collection time, you can exit the loop and continue with step D above.

-Kevin P.