Timer interval increase (SOLVED)

[mse]

@dogriz
the app must read cyclically an external device,
connected through ethernet and update the GUI.
The entire whole process is performed in 20 to 30 msec.

And what is the system load? If it is 100% (also caused by other processes) the timer interval may become inaccurate. Are you sure your process does not hang somewhere?

[ziocharly]

@dogriz
yes, enabled false/true tested:
any change.

@mse
app load around 15-20% of CPU
with 150 Mb ram free...

Last test of this morning:
this issue not affected RBPI 2 card
that work perfectly with same
OS (wheezy 7.8 kernel 3.17)
FPC 2.6.4
Lazarus 1.2.4

[taazz]

Try this test app does it have the same problems?

[ziocharly]

Sorry for the results of RBPI 2 test:
the behavior it's just the same, only delayed on the time...
Afther 8 hours of power up the 200 mSec. interval become 700 mSec....

@taazz
Today I've already implemented a separate thread,
and seems work well !
Tomorrow I'm happy to test your sample app.

Thank you  so much !!!

[User137]

procedure TFormMain.TimerRead(Sender: TObject);
begin

  Elapsed:= MilliSecondsBetween(Now, Interval);
  StatusBar.Panels[0].Text:= 'Timer rate : '+ IntToStr(Elapsed) + ' mSec.';
   
  if Elapsed > myScanRate then
  begin
     ... my GUI update ...
  end;
  Interval:= Now;
end;

The code is wrong. The time it takes from Elapsed := ... to Interval := ... is big enough to in long term cause delay.

Try:

Code: [Select]

procedure TFormMain.TimerRead(Sender: TObject);
var Current, Elapsed: TTime;
begin
  Current:=Now;
  Elapsed:= MilliSecondsBetween(Current, Interval);
  StatusBar.Panels[0].Text:= 'Timer rate : '+ IntToStr(Elapsed) + ' mSec.';
   
  if Elapsed > myScanRate then
  begin
     ... my GUI update ...
    // And also do this inside the IF. Otherwise it can skip ticks.
    Interval:= Current;
  end;
end;

[ziocharly]

Dear all Forum User,

    sorry for the delay in my reply, it was due to the tests carried out :
after dozens of tests, it is not yet clear why the CPU use, after some hours of operation, grows up to 100%
deteriorating both the interval of the timer, or the precision of the running thread.

Only on RBPI environment, the strange thing is that only a single repetitive timer, creates this issue !
More quickly, as is frequently the TTImer interval is called...
With a separate thread this behavior is more or less the same.

To restore the correct timing is enough close and reopen the application!
Note that there are no particular increases in the use of memory...

There is someone who knows this situation and has suggestions,
and/or recommendations to avoid this problems?

[User137]

What do you have in there code-wise? As of now we can't even guess what could be wrong.

But here is 1 testapp i made:

Code: [Select]

type

  { TForm1 }

  TForm1 = class(TForm)
    Memo1: TMemo;
    Timer1: TTimer;
    procedure FormCreate(Sender: TObject);
    procedure Timer1Timer(Sender: TObject);
  private
    LastEvent, Interval, StartTime: TTime;
    Counter: int64;
    procedure TimedEvent;
  public
  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.FormCreate(Sender: TObject);
begin
  Interval:=encodetime(0, 0, 1, 0);
  LastEvent:=Now;
  StartTime:=LastEvent
end;

procedure TForm1.Timer1Timer(Sender: TObject);
var diff: TTime;
begin
  diff:=Now-LastEvent;
  if diff>Interval then begin
    TimedEvent;
    LastEvent:=LastEvent+Interval;
  end;
end;

procedure TForm1.TimedEvent;
var i: integer;
begin
  // Update GUI
  memo1.Lines.Clear;
  memo1.Lines.Add(format('%d:%d',[counter div 60, counter mod 60]));
  memo1.Lines.Add(timetostr(LastEvent-StartTime));
  inc(counter);
end;

[ziocharly]

@User137

your sample, with some minor changement,
work perfectly on RBPI 1.
So, the TTimer interval don't change !

Right now I'm trying to understand where is the real
problem inside my code.

I think it's really important to know where is the problem
for all people that use a complex RBPI Lazarus application...

1.st of all I've limited the uses library in order to locate where is the code that making increasing the CPU use.
Finally, tomorrow, I hope to have the expected answer !

[ziocharly]

Finally the reason of CPU overload has been identified !

 

Sometime simple things are consolidated and are not considered: this was my error !

It is incredible, but responsible for the CPU usage drift was the continuous 'statusbar' updating !   

This instruction :

StatusBar.Panels[X].Text:= '...Some status text... ';    

where X is the destination panel, called each time that TTImer is fireup cause a continuos CPU % increase (around to 1% each 2 minutes).

It was enough remove this statement and the CPU usage is now stable and smooth !!!

I have to do more control, but this issue is not present in Windows environment,
and is not present in other library object, like simple LABEL...

I hope this information will be useful, in the future, to someone.
Thanks to all forum users for support and help.

[ziocharly]

? How to ?

The problem on statusbar text assignement has been confirmed !

In order to fix this issue, on status bar object,
how it's possible to sent the official report to Lazarus
developpers?

Someone have idea how to do?

Thanks.

[Cyrax]

Update status bar only in specific periods, like after 100 or 1000 TTimer events.

[ziocharly]

@Cyrax
your suggestion delay only the problem, don't solve...

From my point of view the 'statusbar' behavior need to be fixed !