TTimer question

[BLL]

Hi, Can someone answer this question?

I have a TTimer component on my main form, with an interval set to 1000ms.
As I understand it, every second the TTimer OnTimer function will be called and the instructions therein executed. Then, after the remainder of the 1000ms has elapsed, it will be run again.

What happens if the time taken to execute the OnTimer instructions takes longer than 1s, due to delays?

Does it cut it off at the knees and call it again or does it stop executing?

I am experiencing occasional lockup in my application and wonder if this could be the reason, as lockups seem to be totally at random, with no obvious cause.

Thanks

Brian

[Mando]

Hi...

Try this:

Code: Pascal  [Select][+][-]

1. procedure TForm1.Timer1OnTimer(Sender: TObject);
2. begin
3.   Timer1.Enabled:=false;
4.  
5.  
6.   // your code here
7.  
8.  
9.  
10.   Timer1.Enabled:=true;
11.  
12. end;

[BLL]

Hi, Thanks for the suggestion. I have tried it, but it does not cure the problem!
Brian

[rvk]

I have tried it, but it does not cure the problem!

In that case your lockup-problems have a different cause.

With Timer1.Enabled:=false; the timer is disabled and with Timer1.Enabled:=true; the timer starts again with the set interval as begin-value.

Without further information/code what you do in the timer we can't know what's causing the lockups.
(it might not even be related to the timer at all)

[User137]

I am experiencing occasional lockup in my application and wonder if this could be the reason, as lockups seem to be totally at random, with no obvious cause.

What is happening inside that timer then? Any possible UI components that are misbehaving, threads, loops? I mean it is very unlikely that the cause is TTimer.

[BLL]

Hi both
I am quite sure that the problem is not with the TTimer, but rather what is going on inside the loop. There are calls to 2 serial ports as well as screen switching. I suspect it may be occasional slowness in gathering the serial port data, which I do by using TProcess to call an external little C program, which actually talks to the port. I had to do this as the sdpo serial routines were just so flaky, even at low baud rates. All I have discovered so far is that when lockup happens, the timer function stops, but the rest of the program is fine. I am now disabling the port calls, one at a time to see if it  is one of those. Problem is, it's a slow process as lockup often doesn't happen for many hours!
Brian

[rvk]

... which I do by using TProcess to call an external little C program, which actually talks to the port.
I had to do this as the sdpo serial routines were just so flaky, even at low baud rates.
All I have discovered so far is that when lockup happens, the timer function stops, but the rest of the program is fine.

So your little C program is flaky too when it comes to communicating with the ports   

[tr_escape]

Global var:

  tmrWaiter : TDatetime;

.
.
.
in Timer event:

Code: Pascal  [Select][+][-]

1.   if now>tmrWater then
2.     begin
3.       tmrWaiter := Now+((1/24/60/60)*3);  // you have got 3 seconds for yourcodes;
4.       yourcodes;
5.     end;
6.  

[BLL]

Hi, Thanks for the tmrwaiter function. Linux/lazarus never ceases to amaze me as to what it provides and how hard it to find what there is! I shall try it.
As to the other comment about flaky serial:
sdpoSerial is very rough around the edges. It frequently drops characters sending or receiving; if the serial device isn't found, it raises an exception! It randomly gives sigsegv errors too!
However, there doesn't seem anything else.
I have come from CBuilder and have used TComPort routines which were absolutely bombproof and I didn't have problems talking to serial devices. Shame these aren't available for lazarus.
The C routines are wiring serial ones, which are very good. My wrapper program does need some further work as at the moment, TProcess gets what is sent to stdout, but not stderr, so if the port doesn't exist, I don't get the "Unable to..." message, which does appear if one runs the C prog from the command line.

I just wish I could find a decent serial component for lazarus.

Brian

[rvk]

I just wish I could find a decent serial component for lazarus.

Did you try TLazSerial which is based of SdpoSerial of Synapse?

[tr_escape]

I just wish I could find a decent serial component for lazarus.

Did you try TLazSerial? It is written for cross platform mean you can use in Linux too.

Serial communication is related about hardware and if you working just for Windows TComPort or TCiaPort is enough for you but if you plan to use Linux TLazSerial is real deal.

Also you can use PascalScada too it is written purely pascal and can use Lazarus and Delphi (some versions) too.
PascalScada is a component pack for to using Lazarus/Delphi as a scada designer as possible as IDE do (!)

[User137]

Code: Pascal  [Select][+][-]

1. var:tmrWaiter : TDatetime;
2. ...
3.   if now>tmrWater then
4.     begin
5.       tmrWaiter := Now+((1/24/60/60)*3);  // you have got 3 seconds for yourcodes;
6.       yourcodes;
7.     end;

Just a note, the time between "yourcodes;" with above code is not exactly or averaging 3 seconds, it is always a little longer. If you need to average 3 seconds, then:

Code: Pascal  [Select][+][-]

1.   if now>tmrWater then
2.     begin
3.       tmrWaiter := tmrWaiter+((1/24/60/60)*3);  // you have got 3 seconds for yourcodes;
4.       yourcodes;
5.     end;

With this, if there 1 delay was 4 seconds, then the next time it will wait just 2 seconds to catch up.

And obviously to use such code, one would use a TThread or TTimer with interval around 50-100ms.

[Angus]

I would recommend, if possible, only using the TTimer to fire the OnTimer event to signal that the time is up.  Put the code that you want to execute when the OnTimer event fires in its own thread, you could set some Boolean to true at this point.  If the timer fires again before your worker thread has terminated then you can set the thread to ignore any instruction from the TTimer. At least this way you can be certain as to the status of the timer and of your thread as you have separated the two.
In my experience dealing with serial ports (windows) can be problematic due to the may that ports get bound at quite a low level. Indeed many applications such as Hyper-terminal are 'clumsy' just because of this binding/blocking.