Wait ms Timer Multiple returning inaccurate timer value

[Emily]

We are using the Wait Until Next ms Multiple Timer value to set the interval that data is recorded to a file. Because of Windows 2000 time indeterminancy, the Wait Until Next ms Multiple Timer value is written to file, along with the data point, and is used to calculate the derivative between two successive points. With a delay of 1 sec (1000 ms), the actual interval ranges from 1025 to 1035 ms. At several (random!) points during the acquisition, the difference between successive ms values is considerably smaller than 1000 ms (e.g. 15-25 ms). The following difference compensates for the previous error e.g. the difference will be 2025-2055ms. The data that we are recording is a smoothly continuou
s function and it appears that the sample is actually recorded at approximately 1000 plus ms. Thus it appears that the Wait Until Next ms Multiple waits the appropriate amount of time to record the data point, but outputs an erroneous ms timer value. We added a ms Timer function to the VI, which also experienced a similar glitch. This glitch does not correspond to the wraparound point; it occurs at approximately 60 to 130 sec intervals. We took the timing code only (no data acquisition, etc) and created a VI that wrote just the time values to a file. This is attached, along with the generated data in a spreadsheet. This consistently executed every 1000 ms but occasionally confused the intervals by 1-57 ms. The pattern was reversed from the previous problem by having a long interval and then a short interval. Any insight would be greatly appreciated!

[Al_S]

There are a couple of things going on that affect your results.
1. Windows is not a real-time operating system. As it multi-tasks, you have little control over when it gives time to your application. Loop times may vary depending on what else Windows decides during that iteration. Especially when doing file I/O: if your disk is busy, a loop interation may take longer. Windows may also be doing some disk buffering, so occasionally a loop interation may take much longer than usual as the buffered data from multiple loop interations gets written to disk.
2. Wait Until Next ms Multiple doesn't garuntee equal loop times. With the millisecond multiple input set to 1000, if one iteration starts with the PC's clock at xx:xx:xx.001, Wait Until Next ms Multiple will wa
it 0.999 seconds. If an iteration starts with the PC's clock at xx:xx:xx.999, Wait Until Next ms Multiple will wait 0.001 seconds.
3. In your main loop, you check to see if the millisecond timer value * 60 equals the desired Length of Data Collection. If your loop doesn't execute every millisecond, you may miss the equals case and then your loop won't stop. You should check >= rather than just =.

[vishi anand]

Agree completely but why can't LV provide access to the windows multimedia
timer like LabWindows does? Provide me a timer, I can start/stop by changing
its properties and run that in a separate thread. Obviously if I have
another thread starving this timer thread, it won't help much but using
multi-media timer, I have seen very good results on a windows2000 machine.
Now win95/98 and derivatives are all other story.

vishi

"Al S" wrote in message
news:5065000000050000001E020100-1042324653000@exchange.ni.com...
> There are a couple of things going on that affect your results.
> 1. Windows is not a real-time operating system. As it multi-tasks,
> you have little control over when it gives time to your application.
> Loop times may vary depend
ing on what else Windows decides during that
> iteration. Especially when doing file I/O: if your disk is busy, a
> loop interation may take longer. Windows may also be doing some disk
> buffering, so occasionally a loop interation may take much longer than
> usual as the buffered data from multiple loop interations gets written
> to disk.
> 2. Wait Until Next ms Multiple doesn't garuntee equal loop times.
> With the millisecond multiple input set to 1000, if one iteration
> starts with the PC's clock at xx:xx:xx.001, Wait Until Next ms
> Multiple will wait 0.999 seconds. If an iteration starts with the
> PC's clock at xx:xx:xx.999, Wait Until Next ms Multiple will wait
> 0.001 seconds.
> 3. In your main loop, you check to see if the millisecond timer value
> * 60 equals the desired Length of Data Collection. If your loop
> doesn't execute every millisecond, you may miss the equals case and
> then your loop won't stop. You should check >= rather than just =.

[Greg_McKaskle2]

> Agree completely but why can't LV provide access to the windows multimedia
> timer like LabWindows does? Provide me a timer, I can start/stop by changing
> its properties and run that in a separate thread. Obviously if I have
> another thread starving this timer thread, it won't help much but using
> multi-media timer, I have seen very good results on a windows2000 machine.
> Now win95/98 and derivatives are all other story.
>

This is equivalent to making a separate loop, preferably in a VI with an
elevated priority. Make the loop have a wait ms or occurrence with a
timeout value.

This is different from having a function callback on a windows timer,
but it is similar. LV has a timer thread that is tied into the same
multimedia timer
. That thread provokes timeouts on occurrences and
reschedules code that has waited the appropriate amount of time based
upon wait ms. Problem is, being scheduled and running are two different
things. If another loop is running at that point, it will get it in the
way if they happen to share the same execution system. If the waking
task is higher priority, the OS should respond pretty quickly to switch
out the threads.

Greg McKaskle

[maymaythar]

Dear AI S,

I would like to use your explaination 'about labVEIW running on window OS' in my project report discussion part. I try to find private message function in this forum and could not find so I post it here.

Thanks and with best regds,

maymaythar

AI S written:

There are a couple of things going on that affect your results.
1. Windows is not a real-time operating system. As it multi-tasks, you have little control over when it gives time to your application. Loop times may vary depending on what else Windows decides during that iteration. Especially when doing file I/O: if your disk is busy, a loop interation may take longer. Windows may also be doing some disk buffering, so occasionally a loop interation may take much longer than usual as the buffered data from multiple loop interations gets written to disk.
2. Wait Until Next ms Multiple doesn't garuntee equal loop times. With the millisecond multiple input set to 1000, if one iteration starts with the PC's clock at xx:xx:xx.001, Wait Until Next ms Multiple will wa
it 0.999 seconds. If an iteration starts with the PC's clock at xx:xx:xx.999, Wait Until Next ms Multiple will wait 0.001 seconds.
3. In your main loop, you check to see if the millisecond timer value * 60 equals the desired Length of Data Collection. If your loop doesn't execute every millisecond, you may miss the equals case and then your loop won't stop. You should check >= rather than just =.

[parthabe]

maymaythar,

Didnt you see the date of the earlier posts ?

Some people in this discussion have left LV it seems...

Why dont you post your question or doubt in a new thread ?

Then only you can get a clear solution.

[maymaythar]

Oh.. yes. coz I like the explaination. he he.

anyway thanks for the suggestion