Fixed! Source code updated.

BTW, either would have worked I think. The stopwatch will deviate from the clock on the order of a few seconds per week I read somewhere, which is absolutely no problem, and datetime ticks would be updated every ~15ms, which is also fast enough.

Vertigo - no, that's the whole point to the conversation is that you cannot use the system clock (datetime) for accuracy. As you even stated earlier, a TimeSpan is the only way to receive that accuracy

They're different beasts

datetime ticks are not accurate enough for performance counters or other special tasks, say stepper motors, but if they are indeed updated every ~15 milliseconds, then that is good for "60FPS smoothness" and 66x better than what we currently have in ezscript due to the integer rounding to the nearest second. It should be accurate enough for my use as I could probably live with 50 to even 100ms. There is a limit to what you can do with servos anyway.

I will test to see if that actually works, but ironically the tests I did already showed that it probably is: if you deduct the x times 100ms rounding-up-to-integer error in each iteration of my 100ms loop test, you get believable results for measuring the execution time that vary no more than a few dozen ms, if that.

Did a quick test to try to find out how often the datetime object is updated - call it resolution instead of accuracy as absolute accuracy isnt important here, I am not trying to calibrate an atomic clock.

Its apparently not 15 millisecond like I read somewhere, its significantly better than that:

$prev = Millis()
$start_ms = Millis()
$resolution=50 # 5 milliseconds

REPEATWHILE(true )

  REPEAT ( $i, 0, 100, 1 )
    sleep($resolution/10)
    $elapsed=  Millis() -$start_ms
    IF ($elapsed==$prev)      
      print("collision, timer resolution limit reached at " +	$resolution/10 + " milliseconds")
      goto(end)
    ENDIF
    $prev =$elapsed
  ENDREPEAT
  print("No collissions at "+	$resolution/10 + " milliseconds")
  $resolution--

ENDREPEATWHILE

:end

Result:

So millis() is indeed updated at least every ms, and the underlying datetime object possibly every 15 microseconds and someone, maybe even me, just confused µs with ms.

Whatever the underlying resolution, 1ms is WAY better than what I need, literally 1000x better than what we had, and there is no point even messing with ticks, unless I want to measure how long it takes to execute some piece of code.

Thanks again PTP!

@DJ

Consider including PTPs plugin in ezb (if he allows it), I cant be the only one needing timers that are more accurate than counting out loud. And even if you dont need the sub second resolution, it is much more convenient to use to determine elapsed time compared to the existing date/time string conversions and custom functions- certainly if you dont need to compare it to the time of day or a date.

Secondly, I would still modify TotalSeconds. The problem is not datetime accuracy, its now() casting strings and the conversion to integer seconds. At the very least make TotalSeconds return an integer rather than float so people dont get confused as I did in to thinking it returns sub second results, when in reality it returns whole seconds plus a random decimal fraction.

Lastly, I mentioned the talk servo plugin. I stand by that, I would check its code, I really suspect there is a similar integer second time rounding issue lurking in there causing the lipsync to be delayed randomly by up to 1 second.

Quote:

Consider including PTPs plugin in ezb (if he allows it)

No rocket science code

@DJ: Plugin functions are only available for the desktop, adding them to the ARC core will be useful to mobile applications.