From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Timed while loop speeding up?

Solved!
Go to solution

@JW-L3CE wrote:

Jeff·Þ·Bohrer wrote:

No I won't post the source I hacked at the OPs stuff without renaming and he would justifiably harm me.


You mean the stuff that's currently zipped and already placed in public view? Heh. Either way, thanks for the discretion. I guess I don't get to justifiably harm you today.  You can "Report to moderator" and have it pulled back.

 

Ok, so the theory is that the ms rollover caused this? That might explain a few discrepencies that have been confusing me. We ran this all weekend and it worked before.  It is a theory with no supporting evidence, unless you did take a look at the ms timer value on the machime that caused the error divided by 1000 and subtracted from current timestamp and found that rollover was proximal to the timing change.  Did you?

 

Finally, on the topic of wait until next ms multiple. Would this would only cause a problem once during the rollover and only cause the next frame to be delayed? So if I'm doing 5000ms, the last iteration before rollover would be at 4.294965e9, it would then run 2296ms and another 5000ms. So I would only be off by 2.3 seconds? That's noise for me if that's the only potential problem.  delayed once every 49.710269 days (about) now you know why I seldom use timed loops- I hate ms timer rollover and try not to depend on timing that has a discontiuity that I know about


 


"Should be" isn't "Is" -Jay
Message 21 of 25
(625 Views)

@JÞB wrote:
 Ok, so the theory is that the ms rollover caused this? That might explain a few discrepencies that have been confusing me. We ran this all weekend and it worked before.  It is a theory with no supporting evidence, unless you did take a look at the ms timer value on the machime that caused the error divided by 1000 and subtracted from current timestamp and found that rollover was proximal to the timing change.  Did you?

 


Just did. Had to compile this.

time.png

686394629 with a timestamp of 10/31/2012 9:47:39.768 AM. This places the last rollover at 10/23/12 11:07 AM

The original test started at 10/23/12 1:20PM and sped up 65.25 hours in. That places the problem at 10/26/12 6:35 AM

 

Unless I'm messing up my excel math... easy to do because I hate managing excel timestamps (No, No, Stop doing that Excel!)

 

 

Josh
Software is never really finished, it's just an acceptable level of broken
0 Kudos
Message 22 of 25
(617 Views)
@JW-L3CE wrote:
Unless I'm messing up my excel math... easy to do because I hate managing excel timestamps (No, No, Stop doing that Excel!)

See here  Time to xl
Don't forget to kudos the idea here

 


"Should be" isn't "Is" -Jay
0 Kudos
Message 23 of 25
(606 Views)
Solution
Accepted by topic author JW-JnJ

Summary:

 

The msTimer Rollover theory has been debunked. unless there are any other ideas it looks like the dt buffer in the timed loop was corrupted.  the always copy will (Should) work.  A loop with timing dependant on a Wait or Wait until next ms multiple would also fill the needs of the system.

 

Whoo... go get em JW


"Should be" isn't "Is" -Jay
0 Kudos
Message 24 of 25
(602 Views)

Works for me. Thanks for the help.


*drum roll* Solutioned!

Josh
Software is never really finished, it's just an acceptable level of broken
Message 25 of 25
(601 Views)