Precise clock

[croivo]

I'm making a clock that counts miliseconds... But the problem is that it's not precise enogh (compared to Windows clock, mine delays about 200miliseconds every second). Is there any way to fix this to be more precisely?
To update clock, I use this:

Code: Select all

send countUp to me in 0.001 seconds

[dunbarx]

Hi.

There are several threads along these lines. You might search for "clock" in this forum as a start.

I am not sure what your "countUp" handler does. Does it do its own counting, or does it pull system clock data? Anyway, the trick is not to count at all inside a handler (pseudo):

Code: Select all

on countUp millisecondsCounter
add 0.001 to millisecondsCounter

but rather to pull system timing (pseudo):

Code: Select all

doYourCountingStuff
get the milliseconds
put it whereEver

Now this will still not create a true millisecond display, but you cannot see that in any case. But it will pull the correct time whenever you invoke it. Is that adequate?

Craig Newman

[croivo]

Hm... I didn't understand what you wrote.

Here is my code:

Code: Select all

on DoCountUp   
      set the numberformat to 00
      add 1 to field ClockMilisec
      if the field ClockMilisec is "1000" then
         put "0" into field ClockMilisec
         add 1 to field "clockSec"
         if field ClockSec = 60 then
            add 1 to field ClockMin
            put 00 into field ClockSec
         else
         end if
      end if
      send "DoCountUp NewTime" to me in 0.001 second
end DoCountUp

What should I change in my code?

[dunbarx]

Hi.

You are doing what I mentioned in the first part of my post, which is to create an self-contained counter within a handler. But the overhead to run that counter will cause, and accumulate, delays in the true rendering of the timed output. Do you see? Only if ALL your code took zero time to execute would it be accurate.

On a new card, make a button and two fields. In the button script:

Code: Select all

on mouseUp
   updateCounter
end mouseUp

on upDateCounter currentValue
   if the optionKey is down then exit to top
   put the milliseconds into fld 1
   put the long time into fld 2
   send "upDateCounter" to me in 0 millisec
end upDateCounter

Now this is just stuff, you know. I hope you can change it to suit your purposes. But when each field displays a value, that value is the current time, as best the computer can render it, and does not depend on anything you do, whether good, bad or indifferent.

Craig

[croivo]

I customized the code a little bit:

Code: Select all

on mouseUp
   updateCounter
end mouseUp

on upDateCounter currentValue
   if the milliseconds is the field "systemMiliseconds" then
      add 1 to field clockMilisec
      if the field clockMilisec is "1000" then
         beep
         add 1 to the field clockSec
         put "0" into field "clockMilisec"
      end if
   end if
   put the milliseconds into fld systemMiliseconds
   send "upDateCounter" to me in 0 millisec
end upDateCounter

But the delay is even bigger than the code in first post in this topic...

[dunbarx]

Hi again.

When I said, "will not create a true millisecond display" I meant that it will not count, millisecond by millisecond, in order, accurately, one-by-one, by milliseconds. To do that you need a faster routine. Try this with a button and a field on a new card. In the button script:

Code: Select all

local temp
on mouseUp
put "" into temp
   put "" into fld 1
   updateCounter
end mouseUp

on upDateCounter
   lock screen
    put the milliseconds & return after temp
   if the optionKey is down then
      put temp into fld 1
      exit to top
   end if
   send "upDateCounter" to me in 0 millisec
end upDateCounter

Now you can see that the code runs faster than milliseconds expire. Is this useful? Maybe. Is it cool? Definitely.

Craig

[dunbarx]

Hmmm.

But the delay is even bigger than the code in first post in this topic...

Without going into your latest handler, which still adds a value to a counter that is inherently decoupled from the actual time, what do you think of my earlier middle post, the one with the two fields and a button?

There is nothing wrong with experimenting with the things you are playing with. It is a great learning experience. But do know that there is a fundamental issue with trying to represent real time events with the results of handlers playing out their actions. There is no way to "time" those internal processes in step with an entirely external process, that is, the passage of independent, universal time.

Craig

[croivo]

Hm I just pasted your code, and it's not showing anything...

[Klaus]

Hi croivo,

take a look at the actual handler and guess why nothing is shown in field 1, unless you hit the SHIFT key

Code: Select all

on upDateCounter
   lock screen
    put the milliseconds & return after temp
   if the optionKey is down then
      put temp into fld 1
      exit to top
   end if
   send "upDateCounter" to me in 0 millisec
end upDateCounter

If you dont see it, step through the lines mentally and you will see


Best

Klaus

[dunbarx]

What Klaus said, except it is the "option" key.

But that is not important. I only wrote that extra gadget to help you see how, even when the code runs at full speed, faster than milliseconds actually pass, there is no coupling between real time and computed time. Change the wait period to 1 mS. Now you miss certain slots. You just cannot sync...

So you have to figure out what you are really seeking. If a representation of the actual time, use my code. If a running process that can be used perhaps in other ways, then some variant of your current work might well do.

Craig

[croivo]

Hi croivo,

take a look at the actual handler and guess why nothing is shown in field 1, unless you hit the SHIFT key

Code: Select all

on upDateCounter
   lock screen
    put the milliseconds & return after temp
   if the optionKey is down then
      put temp into fld 1
      exit to top
   end if
   send "upDateCounter" to me in 0 millisec
end upDateCounter

If you dont see it, step through the lines mentally and you will see


Best

Klaus

Its actually ALT key on Windows

What Klaus said, except it is the "option" key.

But that is not important. I only wrote that extra gadget to help you see how, even when the code runs at full speed, faster than milliseconds actually pass, there is no coupling between real time and computed time. Change the wait period to 1 mS. Now you miss certain slots. You just cannot sync...

So you have to figure out what you are really seeking. If a representation of the actual time, use my code. If a running process that can be used perhaps in other ways, then some variant of your current work might well do.

Craig

Thanks.

[Klaus]

Hi Craig,

What Klaus said, except it is the "option" key.

...
if the optionKey is down then
...

getting old, Craig?


Best

Klaus

[dunbarx]

What is "Windows"?

Craig

[dunbarx]

Klaus,

take a look at the actual handler and guess why nothing is shown in field 1, unless you hit the SHIFT key

getting old, Craig?

Yes. But it is still the "Option" key. Let me try one of yours...

Craig

[Klaus]

OUCH! How embarrassing, I thought you were talking about the script all the time...

So sorry, Craig, HONESTLY!

honestly.jpg (30.23 KiB) Viewed 8265 times