LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Counter: Why does 'Is Task Done' return True after the HIGH time?

Solved!
Go to solution

Realized my other thread was getting de-railed by..myself.

 

Started testing the "Is Task Done" function on a finite Counter example;

 

Why does it return 'True' after the high time and not high AND low?

 

And more-so, how do I get it to return 'True' after the high AND low time? How can I get this to tell me it is 'done' after 9.1seconds instead of the ~3seconds as now. Is there a better setup I can use? (numbers are arbitrary)

 

 

counter_start_stop.PNG

 

counter_start_stop2.PNG

0 Kudos
Message 1 of 7
(2,765 Views)

If I add a 'DAQmx Timing (implicit)' set it to 'Finite Samples' and the 'sample' number to 2, with parameters such as

 

High Time: 1s

Low Time: 2s

 

The program starts and then finishes 6 seconds later.

Doing the same but with only 1 sample, the program finishes after 1 second..

 

Please help. Thank you.

0 Kudos
Message 2 of 7
(2,759 Views)

Hello belopsky,

 

When a single pulse is generated, the high time is all that really matters. Once it goes low, the single pulse task is done because the signal has returned to its idle state. The low time is only taken into consideration when there is a pulse train and that low time is more meaningful, because it affects the duty cycle. If you really wanted to get the value of the high time plus the low time of a single pulse, you could include an addition function to add the low time from the control to the timestamp before displaying it.

Erin D.
0 Kudos
Message 3 of 7
(2,715 Views)

Erin, 

yes thank you, but what I really needed was a return of "true" after the low time to make my logging work correctly. I do believe I made a workaround, despite it being a bit convoluted ;/

0 Kudos
Message 4 of 7
(2,711 Views)
Solution
Accepted by topic author belopsky

 

A couple of notes, assuming we are dealing with default pulses that are active high with a low idle state.

 

1. In general, a pulse is defined with a "time in idle state" first followed by a time in pulse state.  Thus, by definition a pulse (and therefore also a pulse task) is indeed done at the end of its active (high) state.

 

2. HOWEVER, the very first pulse in any pulse train DOES NOT USE the 'Low Time' input to define its time in idle state prior to the pulse.  Instead, it uses the 'Initial Delay' input for the first pulse while 'Low Time' is used for all subsequent pulses.

 

3. Therefore, when generating a single pulse, 'Low Time' is meaningless.  Only 'Initial Delay' matters.  So wire your desired low idle time into the 'Initial Delay' instead of into 'Low Time.'  

 

 

This kind of convention has always seemed awkward at best to me.  I think the help should have much more prominent emphasis on the idea that 'Low Time' gets ignored for single pulses.  I mean, the info *is* there but it's pretty easy to miss before you know to go and look for it.  Anyhow, hope this helps you in your app. 

 

(Another alternative you could consider is to define the pulse with a high idle state.  Then you'd wire the 'Initial Delay' to set the first high time and your task would end after the 'Low Time' you define.  Just be aware that when you work with reverse-polarity pulses, you should double check the output terminal to see what state it defaults to both before you start your task and after you clear it.   A given board may be biased with counter outputs in a low state, so when your task wants to reverse the polarity you might see a rising edge as the task starts into its high idle state and then a falling edge as the task ends and the board reverts to its default low state.)

 

 

-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).
0 Kudos
Message 5 of 7
(2,661 Views)

Kevin, thank you much!

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

The only issue is that the 'initial delay' occurs before the 'high time', I suppose if I needed it to act the way I desire (high, low) I would have to do it the second way you describe..

0 Kudos
Message 7 of 7
(2,649 Views)