Learn the number of pulses created in a finite pulse train

[MG83]

Hello

I am using the PCI-6602 Board to produce a finite number of pulses with counter0.

I want to know how many pulses that are already created by the counter, while my program is running and show this number on an indicator on the front panel of my VI.

What is the best way to do this with LabVIEW?

Of course I can use another counter to count the pules and route the output of counter0 to its input.

However I wonder if it is possible to solve the problem without using another counter, because DAQmx internally already uses a second counter to produce the finite pulse train so it should be possible to read this counter, isn't it?

Thanks for every help.

[Matthieu Papaux]

Hi MG83,

Have a look on this Forum which ask the same question as you...

You will need another counter to do this or create a finite number of pulses and count how many times you restarted your generation.

Have a great day.

Matthieu
NI Switzerland

[MG83]

Hi Matthieu

Of course I have searched the forum before posting.

However I have found a solution with a second counter only (or exactly with three counters: one for frequency generation, one for counting the pulses and one used internally by DAQmx to stop the finite generation).

Is it not possibel to read directly the counter which is already used internally by DAQmx for the generation of a finite pulse train?

[stilly32]

Hi,

I believe Matthieu forgot to include this link to a similar post, rather than imply that you haven't searched the forums

As far as why a third counter is required, you have to consider how a finite pulse train is generated. Basically, the counter you specify for the finite generation is set up for continuous generation, but is gated by the paired counter. The Paired counter generates a single pulse with the pulse width calculated to stay high long enough to generate the desired number of pulses (using the known output frequency to calculate). So the question becomes, what value could be queried to determine how many pulses have been generated? The continuous counter is just toggling when the counts have been reached, the paired counter just returns once it's pulse has been generated. For this, there is no value to acquire. You really have two options - use a third counter to monitor the tick count, or keep track of when the generation started, and what the current time is and calculate out the number of pulses generated based on the frequency of generation. This is highly dependent on OS timing, so it would work for slow generations (say under 100hz) but would be pretty inaccurate for anything much faster.

Hopefully this answers your questions, if not please post back.

Cheers,

Andrew S

[Kevin_Price]

I actually had in mind a fairly complicated method, and I was going to ask just how important it was for you to avoid using a 3rd counter.  Now, after reading the last reply from Andrew (stilly32), I think his "tick count" method is liable to be almost equally good and *very much* simpler to understand and implement.

The gory details go roughly like this:  You generate your finite pulse train using old-school manual techniques.  Specifically, you would configure your pulse generating counter (let's say Ctr 0) for Continuous Samples, but you also configure it to be pause-triggered.  The signal that activates level-based pause triggering will be the internal output of the paired counter (Ctr 1) which you will control manually for generating a single pulse.  You would need to properly calculate the high time of the pulse to allow exactly the correct finite # of Ctr 0 pulses to be generated.

I would also suggest setting up both the low time and initial delay of Ctr 1's single pulse to be the minimum possible time, very likely in the 10's or 100's of nanosec.  Then you'd start the Ctr 0 task first.  Nothing will happen until you generate Ctr 1's single pulse to "un-pause" the Ctr 0 pulse train.  After you do, you can repeatedly query a DAQmx property node to retrieve the "count" value from Ctr 1.  You'll see this value count down toward 0.  When it reaches 0, the pulse will be over.

You'll need to know the starting value for the countdown, which is = (high time) / (timebase period), give or take a count.  Then, knowing the instantaneous value of the count and the timebase period, you can figure out how much pulse-generating time has passed.  Finally, knowing this time and your Ctr 0 frequency, you can figure out the # of pulses generated.

Pretty nasty, eh?  Do yourself a favor and go with the msec tick count software call.  The several odd msec of uncertainty in the OS won't even be noticeable for the sake of updating a human-viewable front panel indicator.

-Kevin P.

Message Edited by Kevin Price on 10-30-2007 02:07 PM

[MG83]

Thanks for your answers.

I have been mistaken in the function of the paired counter. I assumed that it is counting the pulses of the first one and compare it with the number of pulses specified instead of just generating a gating signal.

In the meantime I have solved the problem just by using a third counter, because this is no problem at the moment. If I should really need all counters in the future, I will implement the software based method mentioned by Andrew, which should work fine because the frequency is in the range of approximately 1 Hz only.

However, I wonder where I can get such detailed Information about the internal functionallity of the DAQ-devices and the DAQmx driver?
Please let me know where you get this information from. (So that I can avoid using this forum in the future)

(At the moment I have only the "DAQ Getting started" guide, the help function of DAQmx and some examples as a source of information, but I lack a comprehensive description of the whole functionallity of the DAQmx-driver.)

[Kevin_Price]

---

However, I wonder where I can get such detailed Information about the internal functionallity of the DAQ-devices and the DAQmx driver?  Please let me know where you get this information from. (So that I can avoid using this forum in the future)

Speaking just for myself --- the source has been generally the school of hard knocks. I started doing a lot of special timer/counter work right around the Y2K timeframe. The legacy driver now known as traditional NI-DAQ was then the only game in town.   The programming and terminology under trad. NI-DAQ tends to require you to understand the hardware at a lower level.  The programming used more counter-specific terminology like Gate and Source signals.

So for a lot of this stuff, I came into DAQmx with a good understanding of the low-level hardware capabilities, and I just needed to tromp around a bit to find the right syntax.  Consequently, I'm not much help for pointing you toward info sources as I haven't relied on them much.  Meanwhile, good luck with the self-teaching but don't feel compelled to "avoid using this forum in the future."

-Kevin P.

Message Edited by Kevin Price on 11-01-2007 10:04 AM

[stilly32]

For timing diagrams and good info on the HW, I like to use the M-Series User Manual  section on counters. The counters on the M-Series are almost identical in operation to the TIO devices and the way we set up counter operations is the same. I noticed we don't have a good timing diagram for Finite Pulse Train generation, I'll see if I can get that fixed. The DAQmx Help is also a good resource.

As Kevin mentioned, don't be afraid to ping the forums, and just searching www.ni.com will usually yield good results from the knowledge-bases (KBs).

Cheers,

Andrew S