Read number of output pulses from "CO Pulse Freq" Task?

[Jed_Davidow]

I am writing code for a 6602 that produces PWM signals using the CO Pulse Output function.

I would like to set this running continuously, but poll it every so often to see how many pulses have been output.

Can I do this without using one of the unused counters to measure it? Is there a property of the task/channel that gives me the number of pulses?

Thanks!

Jed

[Jed_Davidow]

Follow up:  If I do need to use another counter to count those pulses, what's the best way?

Right now I my task produces pulse output on counters 0-3.  Those signals, along with P0.0/PFI0 are routed to RTSI pins 0-4 (For internal connection to another device).

So if, for example, PFI36 (CTR0_OUT) is shunted to RTSI1 using the "Connect Terminals" function, can I also connect it to CTR5_SOURCE to get a count?

[Craig_]

You should be able to connect multiple pins together using the "DAQmx Connect Terminals.vi" (Make sure to disconnect them at the end). With this all you would need to do is read the value of the counter you routed the pulses to.

The other option would be estimating the number of pulses based on the rate that they are being generated and how long has passed since generation started. This would be approximate but could be done if don't need the precision offered by a counter.

[Jed_Davidow]

When you say "Read the counter", you are referring to what I proposed, routing the output of one counter to the SOURCE of another and reading the counts, right?  There's no way to directly read the counts of an output?

[Craig_]

The pulse train generation will use one of the counter resources. Because of this I do not think you can read the value of it as you can with a counter count edges task as it is being used for a different operation. You can definitely route the output to another counter and use it to count the edges instead.

[Kevin_Price]

I can confirm what Craig said.  It *is* (or at least *was*) possible to query the pulse generation counter's count register while the pulses were being generated.  What you'd see there is that the count value keeps counting down to 0 and then reloading the next value that corresponds to either high time or low time.  Each time it hits 0 (terminal count), the output state toggles.

The point is, the pulse train counter's count register is definitely tied up doing other things and can't possibly tell you how many pulses it has generated.  It just has no means for keeping track.

-Kevin P