Pattern in Timed While Loop elapsed time

[ekabo]

Hello NI Community,

I am attempting to use a timed while loop to run a simulated controller for a mechanical system test. I need the time while loop to run at an even 50 Hz to simulate the controller that will eventually be driving the mechanical system. To verify the rate at which the loop is running, I made a VI that gets a clock value at every loop, and subtracts the current iteration's clock value from the previous iteration's clock value. I have eliminated all other code from this VI except for the clock fetch, to ensure there is no issue with other code in the VI. I'm finding that the elapsed time between iterations is not constant, but is consistent. That is, the elapsed time can change with every loop, but it changes in a specific pattern such that the average of the elapsed times is equal to the setting I'm using for the timed loop. The loop will run faster than asked for several cycles, then slow down for one cycle to even out the time. Here are some examples:

Running at 5 Hz: elapsed time switches between 0.203125 seconds and 0.187500 seconds

Running at 8 Hz: elapsed time is consistently 0.125 seconds.

Running at 10 Hz: elapsed time switches between 0.109375 seconds and 0.093750 seconds

Looking at the differences between the elapsed times and the stability of the 8 Hz setting, it seems like there is a minimum time division of 0.015625 seconds (64 Hz). This is much worse than the 1 ms accuracy claimed in the documentation. What could be causing this?

I am running Windows XP with LabVIEW version 8.5.1, and have observed this behavior on more than one computer using different VIs.

Thank you!

Erik

[Mark_Yedinak]

You will never get perfect timing running on a Windows machine. Windows is not a real-time deterministic OS.

[ekabo]

Thanks for the reply, but this isn't a question about imperfect timing in the millisecond range, but a question of what appears to be an 64 Hz oscillation in the loop execution. I would be happy with accuracy in the millisecond range as the documentation claims is possible with a Windows machine. What I'm observing is a much more predictable timing pattern than what I would expect from inaccuracies caused by Windows.

That said, your theory that Windows is at fault is plausible, this pattern is just too predictable for it to be a simple problem. Is there something more systemic that could be causing this? Is there an interface to the system clock somewhere that only allows communication of the current time to the 1/64th of a second?

Thanks!

Erik

[crossrulz]

Have you seen this on another computer with different OS, CPU, etc.?  Care to share your benchmarking code.  Then we can see if it is local to your machine or if there really is something there.

[ekabo]

I have observed this on more than one computer:

- NI PXI-8106 (Core 2 Duo T7400 2.16 GHz)

- Dell laptop (Core 2 Duo T5600 1.83 GHz)

These are both running Windows XP with Labview 8.6.1.

Perhaps the similarities between these two machines is driving the root problem; I would appreciate observations from other computers. I will run down to the lab and grab that VI when one of these computers has some down time.

Thanks!

Erik

[ekabo]

Attached is the simplest VI I used to show this issue. For me, the elapsed time is not a constant number as I would expect, but swaps back and forth between two numbers as described above. I would really appreciate testing other machines to see if this issue can be duplicated.

Thank you!

Erik

[JarleEkanger]

Hi,

I tried your VI (Win7, Labview2012, Intel Core i7 @ 2.2GHz). Had constant dt to 1e-7.

I would recommend replacing the local variable with a shift register initialised to start time:

best regards 

Jarle

[ekabo]

Thanks for the shift register suggestion; I always forget that's an option.

Also, thank you for verifying that the pattern I'm seeing is specific to my test equipment, and not a problem with the VI. That gives me a path forward to fixing it.

Do you happen to have a Windows XP machine you can try it on? I want to continue narrowing down the potential culprit so I know what I have to change to fix this problem.

Thanks!

Erik

[JarleEkanger]

We don't run XP on any of our computers, sorry.

Have you tried substituting the Get Timestamp VIs with Tick Count VIs? (At least for testing, they have a maximum output value due to the output number representation).

[RavensFan · Accepted solution]

Your problem is the function you are using to get the current time.  It just gets the time from the Windows clock which has a resolution of 16 msec.

You need to use the Tick Count function like Jarle had pointed out.