10-02-2014 10:24 AM
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)
Solved! Go to Solution.
10-02-2014 10:48 AM
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.
10-03-2014 01:44 PM
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.
10-03-2014 01:46 PM
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 ;/
10-06-2014 08:09 AM
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
10-06-2014 08:15 AM
Kevin, thank you much!
10-06-2014 08:57 AM
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..