LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timing Wait Function Problem (too fast)

I have a little problem with 'Wait until next' functions.  Here is a quick illustration of my problem (image of code attached). 

1. I take initial start time, first frame of flat sequence
2. Loop 30 times at 100ms per loop -- total of 3.00 seconds
3. Take time of finish
4. Compare/subtract start/stop times and display.

My question is; how is it possible that the displayed time is occasionally below 3 seconds?  Am I overlooking something?

0 Kudos
Message 1 of 10
(3,796 Views)

If you only miss by a few msec, it's probably just quantization error due to lower resolution in the 'Get Date / Time' function.   On Windows machines, it typically only advances in ~16 msec increments.

You could get 1 msec resolution by modifying your example to use the 'Tick Count (msec)'  function instead of "Get Date/Time'.

-Kevin P.

ALERT! LabVIEW's subscription-only policy came to an end (finally!). Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.
Message 2 of 10
(3,778 Views)
Brillant.

It appears to be working correctly now.  Thanks.
0 Kudos
Message 3 of 10
(3,776 Views)
I ran your code in a loop for 1000 iterations. I recorded the elapsed time both from the time of day clock and from the tick count. After the runs, I displayed the minimum and maximum times. I did not see your problem.

Min seconds 3.0005
Max seconds 3.00754
Min ticks 3001
Max ticks 3008

Lynn
0 Kudos
Message 4 of 10
(3,760 Views)
I am not sure why yours is not 3 sec. I built you vi and mine runs at 3.015. I think it is system dependent of the OS.



Joe.
"NOTHING IS EVER EASY"
0 Kudos
Message 5 of 10
(3,756 Views)
Lynn,

I don't know why you couldnt get your program to generate the same problem.  But I assure you, I'm not making this stuff up Smiley Tongue

Here is an attachment of how the new and old methods run together.  Maybe it helps.
0 Kudos
Message 6 of 10
(3,751 Views)
Here is my VI (LV 8). I changed the For loop to a While loop and added a Stop button to make it a bit more convenient.

Lynn
0 Kudos
Message 7 of 10
(3,747 Views)
Sorry about the delay, Lynn. 

I ran your code as you posted it, and I got below 3s on the second or third iteration. Here is a screenshot of the eigth iteration. 

I guess it's just a difference between our computers.

Cheers,

Phil
0 Kudos
Message 8 of 10
(3,724 Views)
Does your computer clock run slow? Does the time of day display lose a few seconds or minutes each day (if not connected to a time server)? Or does the tick counter run fast? The Wait functions use the tick counter. The two timekeepers run from different timebase sources so some differnces are to be expected.

Try reading both the time of day function and the tick counter. Wait for some minutes or seconds and read each again. Do the differences between the times match?

Lynn
0 Kudos
Message 9 of 10
(3,703 Views)

I believe it has to do with the operating system timing.  I will try to illustrate with the following timing diagram:
0         16         32          48  
|----------|----------|----------|       --OS Time (16ms update) (Time stamps)
|----------|----------|----|               -- LV Process (1ms)  (tick counters)
0                             40

When the LV process is done, and checks the time, it will return '32' since the OS clock hasnt updated yet.  So this leaves us in our predicament. That we know our process takes 40ms, but the clock only shows 32ms.

To avoid this, just stick with the tick counter. Hope this helps.

Phil
Message 10 of 10
(3,700 Views)