From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Read counter value on output task

Forgive me if this seems like a simple question, but how do you find out the current counter value on a counter output task you created? I found a solution for LabWindows/CVI in the forums, but I am using LabVIEW 8.0, and I haven't been able to find an example vi. I have a PCI-6723, and I am simulating an encoder with the two available counters, using the CO_Pulse_Time task. Somewhere in my code, I would like to be able to view the number of pulses output. Is this possible?
0 Kudos
Message 1 of 7
(3,898 Views)

You should just be able to wire an indicator to the iteration node.

 

eric

0 Kudos
Message 2 of 7
(3,890 Views)

You may not realize it, but you actually asked for 2 different things.

The 2nd thing you asked for was the (cumulative total) # of pulses generated.  A counter output task doesn't keep track of this #.  You'd need to program another counter to count the output pulses and then query *that* one.  Or, if you're using your counter to generate the output clock for your board's AO, then you can query the AO task for a property like "total samples generated."

The first thing you asked for was how to find out the current counter value on a counter output task.  This *can* be done, but the count # you get is probably not the one you're looking for.

When you program an output task, what actually happens at the hardware level is that the count register is loaded up with your "low time", then it counts down on every incoming timebase edge (probably 20 MHz by default).  When the count reaches 0, the output state is toggled and the count register value is loaded up with your "high time".  Again, it counts down on every timebase edge, and the output toggles when the count reaches 0.

So the count value is continually decrementing at a 20 Mhz rate.  Each time it hits 0, the output toggles and the value changes instantly to restart at a value corresponding to either the low or high time, as appropriate.

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 3 of 7
(3,886 Views)
Thanks, Eric and Kevin for your replies.
 
Kevin, I appreciate the explanation of what's actually happening. I'm new to all of this, and I was confused as to what was actually being counted. I can see that you are correct in saying that the actual counter value is NOT what I want. It is the total number of pulses output that I want to see. Since the 6723 has only two counters, is there a way to accomplish this without using a counter? Is it possible to detect when the signal goes high on a running task and increment an indicator on the front panel?
 
0 Kudos
Message 4 of 7
(3,880 Views)

Sorry, my brain somehow never registered the part of your initial post describing your use of the counters -- to simulate an encoder.

There's different approaches you might use, depending on the your exact needs.  All have pluses and minuses.

1. Rapidly query the counter task to determine output state in a tight loop.  Pros - no additional hardware or task requirements.  Cons - keeping track of transitions, inaccuracy if software doesn't loop fast enough to catch all transitions, CPU hogging.  Errors from missed transitions will accumulate.

2. Use one of LV's time functions (like Tick Count) to get a snapshot of the system time when you start the counters.  Each time you want to know # pulses generated, calculate it based on output frequency and elapsed time.  Pros - no additional hardware, won't "miss" counts.  Cons - system clock and DAQ board clock will vary by some fraction of a %.  The longer you run, the farther this calculated value deviates from the truth.

3. Oddball idea.  Generate the encoder signal with 2 of your AO channels, assuming they can make 0-->5V transitions fast enough for whatever receives the signal.  Now you can query the AO task for 'total samples generated' to get an exact count.   Cons - I'm assuming you aren't already using the AO for other purposes.  Seems unlikely you'd have a dedicated multichannel AO board if you weren't doing AO though.

-Kevin P.

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 5 of 7
(3,872 Views)

hello, i need that labwindows CVI program, you have found... my email address is orbit@live.se

so you can send me that program, thanks

0 Kudos
Message 6 of 7
(2,974 Views)

Hey venusnajad56,

 

What type of program are you looking for? Are you familiar with the example finder in LabWindows/CVI? You can find it under Help>> Find Examples.

ZK
Technical Support Engineer | NI | Not actually retired but I don't know how to change that
0 Kudos
Message 7 of 7
(2,963 Views)