Dj, this isnt a fundamental limitation of windows; while windows is not a RTOS, surely you can use timers that are more accurate than a full second? I dont need millisecond level assured execution, but I do need to know how much time has elapsed (partially because that time is variable because its not a rtos) and more precisely than a second.

Some googling suggests that In .Net you can use timespan to get 100 nanosecond resolution timers:

https://docs.microsoft.com/en-us/dotnet/api/system.timespan?view=netframework-4.7.2

Its not like I need nano second level of resolution, but a thousand milliseconds truly is an eternity and makes it impossible for me to achieve my goals... Im sure youd agree that sleep() uses milliseconds and not seconds for good reason?

As for what I want to do; in a nutshell I want to achieve smooth and "smart" motion tracking, combining eye and neck servos. I am working on some routines that calculate an average absolute position of the tracked face, and estimate its position when the track is lost, and others that steer the head and eyes towards the target or (gu)estimated target. To make the motion smooth and to guess the position when the track is lost, I need to calculate speeds which is distance/time which really doesnt work when time can be off by as much as a full second

You can't use a datetime for that - as you discovered using google. As i previously mentioned, a timespan is the only way. A datetime does not provide the accuracy that fits your requirement. Consider creating a plugin that extends the capability of EZ-Script by adding a timespan command. Timespan is not a datetime.

You will probably get the accuracy you're looking for by using a timespan. A simple class that .Net provides for accurate timespan is System.Diagnostic.Stopwatch. It's good for calculating times between events - which sounds like what you're wanting to do.

Keep in mind that your calculation will not know the physical position of the servo because the real-world and software are different beasts. Instructing a servo to move into a position will take an unknown amount of time. I'm sure you thought of that Have fun!

Thats why Im "stepping" the servos one position at a time, that way I also gain control over their speed.

Looks like Ill need to learn VS and plugins after all... Oh well, its a DIY kit right ?

Here's a plugin example with source code that will get you started: https://synthiam.com/redirect/legacy?table=plugin&id=162

I'd create functions that are something like...

StartTimer( ID )
Reset and start a high resolution timer with the respective ID (identifier). The identifier allows you to have multiple timers running

EndTimer( ID )
Stops and returns the timespan since StartTimer()

GetTimer( ID )
Returns the timespan since StartTimer()

@Vertigo:
I created a simple plugin "Miscellaneous Utility Plugin" with 3 custom functions: Millis, Ticks, TicksToMilliseconds

Sample ez-script:

Code:

#V2 
print("IsHighResolution = " + IsHighResolution())

# a long integer representing the tick counter value of the underlying timer mechanism ***EDITED***.
$start_ticks=ticks()

#The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT), not counting leap seconds
$start_ms=millis()

$start_dt=now()

REPEAT ($ix, 1, 7, 1 )
  sleep(123)

  $delta_ticks=ticks()-$start_ticks
  $delta_ms=millis()-$start_ms
  $delta_dt=TotalSeconds(now()-CDateTime($start_dt))

  print("Ix               :" + $ix)
  print("dt ticks         :" + $delta_ticks)
  print("dt ms(from ticks):" + TicksToMilliseconds($delta_ticks))
  print("dt ms            :" + $delta_ms)
  print("dt seconds(ez)   :" + $delta_dt)
  print("------------------")

ENDREPEAT

Result:


*** EDITED ***

source code:
https://github.com/ppedro74/ezrobot-playground/tree/master/plugins/MiscUtilityPlugin

Are you extracting the ticks from datetime object? I don't think the datetime.now.ticks has enough precision for the OP's needs. The datetime extracted from system clock is not meant for high precision. That's the purpose of System.Diagnostic.Stopwatch

Correct me if i'm incorrect

PS, awesome quick response time on getting that plugin online! Impressive!

Quote:

Correct me if i'm incorrect

You are correct.

For future reference:

Quote:

A good clock should be both precise and accurate; those are different. As the old joke goes, a stopped clock is exactly accurate twice a day, a clock a minute slow is never accurate at any time. But the clock a minute slow is always precise to the nearest minute, whereas a stopped clock has no useful precision at all.

Why should the DateTime be precise to, say a microsecond when it cannot possibly be accurate to the microsecond? Most people do not have any source for official time signals that are accurate to the microsecond. Therefore giving six digits after the decimal place of precision, the last five of which are garbage would be lying.

Remember, the purpose of DateTime is to represent a date and time. High-precision timings is not at all the purpose of DateTime; as you note, that's the purpose of StopWatch. The purpose of DateTime is to represent a date and time for purposes like displaying the current time to the user, computing the number of days until next Tuesday, and so on.

Source:
Eric Lippert
https://stackoverflow.com/questions/2143140/c-sharp-datetime-now-precision

Only later i noticed the OP wanted to track time (accuracy). I assumed he wanted a flat time representation for calculations.

I'll fix the plugin Ticks() will get the accuracy needed and Millis() a flat time representation.

you can calculate a delta between two Millis() values but is not accurate.

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:

Code:

$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:



Indeed, who knew, it turns out you can use floats in sleep() ! I expected to see collisions at >10ms, but when 1ms still didnt trigger a collision, I just tried using fractional numbers expecting an error, but much to my surprise it actually works :). When you reduce the sleep time to below 0.6, then the loop is executed fast enough that millis may return the same time on 2 consecutive iterations and you get a print.

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)

The code is open and the license is Beerware (https://en.wikipedia.org/wiki/Beerware)

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.

I added 2 new functions: DateTimeTicks(), DateTimeTicksToMilliseconds()

The difference is more significant for short/frequent periods.

the difference was more significant a few years ago, although the differences are relative e.g. hardware, operating system, application code optimization.

Code:

$acc_delta_ticks=0
$acc_delta_dt_ticks=0

REPEAT ($ix, 1, 100, 1 )
  $start_ticks=Ticks()
  $start_dt_ticks=DateTimeTicks()

  sleep(10)

  $delta_ticks=Ticks()-$start_ticks
  $delta_dt_ticks=DateTimeTicks()-$start_dt_ticks

  $acc_delta_ticks = $acc_delta_ticks + $delta_ticks
  $acc_delta_dt_ticks = $acc_delta_dt_ticks + $delta_dt_ticks
ENDREPEAT

$ticks_ms = TicksToMilliseconds($acc_delta_ticks)
$dt_ticks_ms = DateTimeTicksToMilliseconds($acc_delta_dt_ticks)
$diff = abs($ticks_ms - $dt_ticks_ms)

print("ticks_ms    = " + $ticks_ms)
print("dt_ticks_ms = " + $dt_ticks_ms)
print("diff        = " + $diff)

if I read your code correctly, it amplifies the difference a 100 fold, so the actual/average discrepancy is on the order of 0.5ms and much if not all of that could be caused by the execution of the code itself. If the code executed instantly (aside from a perfectly timed sleep), shouldnt you be seeing ~1000ms rather then the ~1380-1440ms you get?

FWIW, this is what I get:

@vertigo:
The values are relative.

I can't get less than 50 ms difference, worst case 70 ms.

The script execution: 100 times x 10 ms + script interpretation, overhead etc etc takes between 1300 - 1800 ms.

Well thats my point; looping through the code that is doing the measuring takes almost as long to execute as the time intervals you are trying to measure. So its difficult to conclude where the difference comes from.

Either way, I think we can agree its not an atomic clock, but I also find it difficult to come up with EZB scenarios where a sub millisecond errors per measurement is a big problem.