LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Wait Until Next Millisecond Taking longer than it should

Good day all,
My questions is as follows, i was running a LabVIEW app. that used the Wait until Next Millisecond timer function in a while loop. The loop was taking longer than expected so i did some investigating and wrote a small while loop function that took the start time, ran through 1000 interations, with the Wait Until Next Millisecond having a 1 as its wait. Now, 1 milli x 1000  interations should give you 1 sec. After subtracting the times, the full loop time was 1.953 seconds. Using tick count at the beginning, and as the loop exited, is how I got the time.  I proceeded to try it on three other machines. All running LV 7.1, and one with LV 8.0. They all ended up with the same result. I did not have this problem with LV 6.1 and i'm just curious to know if anyone else has seen this issue, or a solution has been found.
 
0 Kudos
Message 1 of 38
(3,579 Views)
You're not using a timed loop are you?

Can you post a jpg of the diagram?

Shane.
Using LV 6.1 and 8.2.1 on W2k (SP4) and WXP (SP2)
0 Kudos
Message 2 of 38
(3,559 Views)
This is my first post so I'm not sure of the process to post pic. I tired a few things, and used a Timed while loop, which is in a menu under the structures menu. In this VI, i had the Timed while loop and the Loop i used with the Wait till Next milli multiple. Both loops are identical in functionality, with the start and stop times. The Timed while loop worked, with a run time of 1.031 seconds, and the other remained 1.953 seconds. If you would like me to post a pic, let me know of the proceedure of doing so. I'm looked in the help and it doesn't give a process, only that it needs to be hosted on another site.
0 Kudos
Message 3 of 38
(3,550 Views)
With your while loop, about all that you are guaranteed with Windows is that the iteration time will not be any less than 1 sec. The OS is not deterministic and the Windows clock is simply not very accurate to begin with. The OS is always doing things in the background and when the wait time is over, the while loop may simply be paused by it before it iterates again. If you were able to time it to 1 second in a previous version of LabVIEW, my guess you simply were lucky when you did the timing but probably couldn't repeat it reliably. The timed loop is the way to go. When it does finish late, at least you will get notification.
0 Kudos
Message 4 of 38
(3,542 Views)


@Guyver wrote:
Good day all,
... so i did some investigating and wrote a small while loop function that took the start time, ran through 1000 interations, with the Wait Until Next Millisecond having a 1 as its wait. Now, 1 milli x 1000  interations should give you 1 sec. After subtracting the times, the full loop time was 1.953 seconds.


It is very unusual for an empty test loop to be off by almost a factor of two. This is not my experience.

The example below consistently gives me a time within less than 2% of 1 seconds.

What is your OS? What else is running on your machine? Do you have some fancy hardware (dual core, dual CPU, etc)?

Message Edited by altenbach on 03-23-200610:38 AM

0 Kudos
Message 5 of 38
(3,526 Views)

Alt,

I implimented your example to see if it would come out with the same result. It did in fact have a resulting time of 1954 ms. Or 1.954s. I did however try a timed while loop instead of a for loop with "wait till next milli multiple" and my time was 1031 consistently. I will probably use the timed while loop for the sake of getting the job done.

There are no other processes going on. I ran this small VI after rebooting. OS is winxp pro, on a dell dimension 9100. I also placed it on a BSI Lunchbox pc, (a built pc with Asus motherboard running win2000) with same results. The orignal did work on one computer correctly, but its an odd case due to the PC being totally pieced together. I.E its running a mobile motherboard, with flash memory and winxp embedded. (i'm not 100% sure of the specs, i only used it as a test case and was not part of the building of this PC)

Thanks for the help.

0 Kudos
Message 6 of 38
(3,517 Views)

This is actually a known issue and it is actually a Windows limitation. The issue is described in detail in this KB.

Kind Regards,

E. Sulzer
Applications Engineer
National Instruments
Message 7 of 38
(3,501 Views)
Thanks for all the help. It coincides with all the factors, all tests were done on Pentium 4 machines. I did one test on a mobile pentium computer, and did not have the problem. Thanks again for the information.
0 Kudos
Message 8 of 38
(3,470 Views)

Bringing this old post back as recent windows updates have made a huge impact on timed loops.  Both LV2017 environment or .exe build has the issue. Windows 7 and Windows 10 both have the issue.  Wait, wait until ms, timed loop, ect all run slow at least once within 2hrs, tried everything I can think of.  I know this is not real time in windows, but talking seconds of delay here.

 

So.... I made this do nothing loop (below) to show the issue I am encountering on a program.  I call a DAQ bit to toggle every 125ms being read by a piece of hardware to gauge the software is still running, no issue for 3 years, but in the last month the hardware interlock keeps releasing (on several PC's, so not the hardware).

 

Investigating I found the loop itself was slow, normally within +/-5% of value, but I can get close to 7 seconds execution from this test loop below that really does nothing and uses no resources!  It does not matter if I use 1ms or 5000ms as the delay, I still get at least one >6 second loop in a 24 hr period and if i get more than 1000ms the interlock drops out and my test stops.  I track the largest delay, thats it, by morning I get 6.2414s on the "time" indicator.  No screensaver, no monitor off, no HDD spin down, just started running slow.

image.png

CLD Retired 2016
0 Kudos
Message 9 of 38
(2,408 Views)

The basic problem is that while Windows tries to let programs run on schedule, in the end it just runs stuff "whenever", and WILL defer your program if it thinks it needs to. 

 

If timing really is that critical, you need a "Real-Time" operating system.

 

The best thing I can offer you to try without switching operating systems and see if it helps is to go to the VI properties of the VI where this loop is, and set the "Priority" drop-down to "Time-critical priority (highest)" and hope that helps.  

 

You could also try uninstalling as much bloatware that comes with Windows 10 as possible and see if that helps.  I did it mostly to clean up my Start menu, but it seemed to help a bit.

0 Kudos
Message 10 of 38
(2,396 Views)