Why does "ON TIMER" skip the first time interval?

[hanness]

In the following code sample, I have a DO...LOOP that simply prints out how many seconds have elapsed once per second.

Before that loop is started, I seup a timer to run a subroutine every 5 seconds. That subroutine simply prints out how many times it has been run.

What's odd is that the first timer event does not happen after 5 seconds, it happens after 10 seconds. After the first run it correctly runs every 5 seconds.

If you change the interval, the same thing still happens. For example, if I set the timer to 10 seconds, the first execution of the timed event happens after 20 seconds, not 10 seconds.

Is this expected behavior for some reason?

Test scenario: QB 1.51 (April 9, 2021 Dev Build) on Win 10 20H2

Sample code:

x = 0
y = 0

t1 = _FreeTimer
On Timer(t1, 5) GoSub DoTimedStuff
Timer(t1) On

Do
    _Limit 1
    x = x + 1
    Print "Seconds elapsed:"; x
Loop

DoTimedStuff:
y = y + 1
Print "Timer ticks:"; y
Return

[Cobalt]

There must be some internal clock for QB64 cause if you add a _DELAY, even before you turn the timer on, it changes when the first run is. Also TIMERs and _LIMIT\_DELAY don't seem to like each other very much, if the TIMER value lands on a _LIMIT or _DELAY value it seems to be 50\50 who goes first.

Code: QB64: [Select]

1. DIM SHARED x, y
2. x = 0
3. y = 0
4.  
5. _DELAY 3
6.  
7. t1 = _FREETIMER
8. ON TIMER(t1, 5) DoTimedStuff
9. TIMER(t1) ON
10.  
11. DO
12.  _LIMIT 1
13.  x = x + 1
14.  PRINT "Seconds elapsed:"; x
15. LOOP UNTIL INKEY$ = CHR$(27)
16.  
17. SUB DoTimedStuff
18.  y = y + 1
19.  PRINT "Timer ticks:"; y
20. END SUB
21.  

[Petr]

@hanness  This is probably a deep bug in the ON TIMER statement, because it works just as badly with the ON TIMER (5) statement - the old Qbasic way. I tested it in versions 1.5, 1.1 and 0.954, in all it works badly, as you say.

[FellippeHeitor]

Here it works as expected, since the timer activation happens after the program had time to initialise:

Code: QB64: [Select]

1. t1 = _FreeTimer
2. On Timer(t1, 5) GoSub DoTimedStuff
3.  
4. start! = Timer
5. Do
6.     Cls
7.     Print "Seconds elapsed:";
8.     If timeron Then
9.         Print Int(Timer - start!)
10.         Print "Timer ticks:"; y
11.         Print "TIMER IS ON  - press ENTER to toggle"
12.     Else
13.         Print
14.         Print "TIMER IS OFF - press ENTER to toggle"
15.     End If
16.     If _KeyHit = -13 Then
17.         If timeron = 0 Then
18.             timeron = 1
19.             start! = Timer
20.             y = 0
21.             Timer(t1) On
22.             Color 10
23.         Else
24.             timeron = 0
25.             Timer(t1) Off
26.             Color 7
27.         End If
28.     End If
29.     _Display
30.     _Limit 60
31. Loop
32.  
33. DoTimedStuff:
34. y = y + 1
35. Return
36.  

We're probably looking at some sort of race condition that's happening at startup - that's when the TIMER thread is created.

[Cobalt]

We're probably looking at some sort of race condition that's happening at startup - that's when the TIMER thread is created.

Thats why I added the _DELAY to try and let everything get setup before beginning. Whether the delay was before everything or after the timer declare it still behaved the same.
Whether the timer is 5sec or 2sec it still takes that long before it starts registering.

Probably why I have never noticed this before, most of my timers are fractions of a second. .125, .25 ect. But sure enough it always misses that first run.

So yeah if you have a ridiculous timer cycle rate like 300 seconds you literally have to wait 600 seconds before the first event happens. or wait 300 before turning the timer on.

[NOVARSEG]

Found the same problem but this ON TIMER stuff seems to be clunky.  The code seems to initialize BEFORE runtime. During runtime an ON TIMER statement is ignored. 

Here is some code that works with TIMER

Code: QB64: [Select]

1. DIM t2 AS SINGLE
2. DIM t1 AS SINGLE
3. x = 0
4. y = 0
5.  
6. t2 = TIMER
7. t1 = TIMER
8.  
9. DO
10.     IF TIMER - t1 > 5 THEN
11.         t1 = TIMER
12.         y = y + 1
13.         PRINT "Timer ticks:"; y
14.     END IF
15.  
16.     IF TIMER - t2 > 1 THEN
17.         t2 = TIMER
18.         x = x + 1
19.         PRINT "Seconds elapsed:"; x
20.     END IF
21.  
22. LOOP

Man! talk about a dangerous statement - ON TIMER. It has total disregard to LOOPS. When activated it takes priority over any other code.  We are talking about WW3.

If anyone thought that my programming in common memory with assembler was nuts then this takes the cake.

[Cobalt]

Man! talk about a dangerous statement - ON TIMER. It has total disregard to LOOPS. When activated it takes priority over any other code.  We are talking about WW3.

that is kind of the point, ON TIMER is an EVENT like an interrupt. So say you have a game where you need a message to popup every X ticks until the player completes a task regardless what else is happening in the game. Then you use ON TIMER.

[OldMoses]

I use it in one of my projects as a auto save for crash recovery. Of course, it doesn't really need to catch the first interval as not much of consequence would happen in that time, so I never noticed that glitch.

It saves the state every 60 seconds to an auto save directory. It uses the same SUB as a manual file save, I just send a boolean byte with the sub call that tells the sub whether to do the dialogs or save to "auto" behind the scenes. I coded it to turn the timer off before doing a manual 'named scenario' save, and then back on again after that is done. I don't know if that would be a problem, but reasoned that it shouldn't be calling the same SUB simultaneously.

I suppose it could go off in the middle of an update loop and screw up the autosave data, but then it should catch it a minute later. I figure the chance of a bad save AND a crash within 60 seconds is fairly low. It's just a case of how unlucky one is, I suppose.

[bplus]

Man! talk about a dangerous statement - ON TIMER. It has total disregard to LOOPS. When activated it takes priority over any other code.  We are talking about WW3.

If anyone thought that my programming in common memory with assembler was nuts then this takes the cake.

LOL

Power tools are scary ;-))

You can turn it on and off like any good tool.

[hanness]

Thanks for the all the responses. It's not affecting anything critical for me, I simply wanted to see if I was missing something obvious here :-)

[SpriggsySpriggs]

Yeah I can't quite figure out why it is skipping the first run of the timer. Interesting. Now it shall nag the back of my mind forever.

[hanness]

Yeah I can't quite figure out why it is skipping the first run of the timer. Interesting. Now it shall nag the back of my mind forever.

I get that! Sometimes small things that really don't matter in the grand scheme of things end up occupying way too many cycles of the underpowered central processing unit in my skull.