Nach Timer.Enable killt sich das Programm

[venice2]

Hatte ich ebenfalls drauf hingewiesen
Ob er das in Betracht zieht mag mal dahin gestellt sein.

[Blup]

TCriticalsection hält nur andere Threads davon ab den selben Codeblock aufzurufen.
Innerhalb eines Threads ist der Mehrfachaufruf möglich, deshalb ist das hier keine Option.
Dafür reicht eine Variable, wie oben von mir vorgeschlagen.

Normalerweise würde man eine Steuerung die Tag und Nacht läuft auch nicht auf dem PC implementieren.
Dafür ist zum Beispiel Arduino besser geignet: https://de.wikipedia.org/wiki/Arduino_(Plattform)
Der PC oder das Smartfone zeigt dann im einfachsten Fall nur die Webseite des Controllers an, über die man das Programm steuert.

[CCRDude]

Zitat von Blup:

Innerhalb eines Threads ist der Mehrfachaufruf möglich, deshalb ist das hier keine Option.
Dafür reicht eine Variable, wie oben von mir vorgeschlagen.

Du hast recht!

In diesem Kontext eine Zwischenfrage: verwendet das Programm zufälligerweise Application.ProcessMessages? Das wird ja gerne mal reingehauen, wenn man den UI-Thread viel arbeiten lässt, und hat bei mir schnell dahingerotzten Timerdingern auch schonmal was kaputtgemacht, bevor ich gelernt habe, die Finger davon zu lassen. Deswegen ja auch der Tipp, die eigentliche Funktionalität per PostMessage in ner anderen Methode zu triggern, um aus dem Kontext dieser vom Timer aufgerufenen Methode rauszukommen.

Zitat von Blup:

Normalerweise würde man eine Steuerung die Tag und Nacht läuft auch nicht auf dem PC implementieren.

Aber schau mal am Anfang, wie alt das ganze ist. 1997 gab es noch keinen Arduino. Ein Hutschienen-PC mit Goldcap statt Batterie und EEPROM war's da eher... wobei das dann TP statt Delphi noch gewesen wäre.

[Rupert]

Zitat von CCRDude:

In diesem Kontext eine Zwischenfrage: verwendet das Programm zufälligerweise Application.ProcessMessages? Das wird ja gerne mal reingehauen, wenn man den UI-Thread viel arbeiten lässt, und hat bei mir schnell dahingerotzten Timerdingern auch schonmal was kaputtgemacht, bevor ich gelernt habe, die Finger davon zu lassen. Deswegen ja auch der Tipp, die eigentliche Funktionalität per PostMessage in ner anderen Methode zu triggern, um aus dem Kontext dieser vom Timer aufgerufenen Methode rauszukommen.

ProcessMessages - nein

Zitat:

Aber schau mal am Anfang, wie alt das ganze ist. 1997 gab es noch keinen Arduino. Ein Hutschienen-PC mit Goldcap statt Batterie und EEPROM war's da eher... wobei das dann TP statt Delphi noch gewesen wäre.

-Ich verwende die Arduino NANO's als Temperaturmesser in den Räumen. Sie senden mir seriell die Temperaturdaten auf meine Steuerplatine.
Die Bilder sollen ein wenig den Umfang erkennen lassen.
Wichtig war schon immer der remote Zugriff, weil wir zwei Ferienwohnungen haben, und die Heizung entsprechend aktivieren/deaktivieren.

-es war von Anfang an Delphi 4 und dann 5

https://www.delphipraxis.net/attachm...1&d=1631727774
https://www.delphipraxis.net/attachm...1&d=1631727774
https://www.delphipraxis.net/attachm...1&d=1631728117

[Rupert]

Ich glaube, die Ursache gefunden zu haben.
Die Software läuft nämlich seit Samstag Abend fehlerfrei.

Was habe ich geändert?

Es gibt 3 Variable, die in der Hauptschleife verändert werden.
Hauptschleifencounter, Regel_intervall_ist und Speicherintervall_ist.

Alle drei habe ich, zurück wie bisher, auf Integer geändert.
Ich hatte sie - fragt nicht was mich geritten hat - auf Shortint geändert, da sie ohnedies nur bis max. 60 zählen.
Nachdem ich protokolliere, was ich alles geändert habe, kam ich (während meines Urlaubs) auf die Idee, alle neuen Änderungen der Reihe nach wieder zurückzustellen.
Am Samstag abend habe ich dann über den VPN-Zugriff auf meinen PC neu compiliert und die Software auf den Heiz-PC übertragen - seither läuft sie unentwegt.

Ich hoffe, dass dies der Fehler gewesen ist, da die weiteren Änderungen die Photovoltaik-Daten und die Heizkessel-Daten betreffen und dort wurden die Schleifen stets korrekt abgearbeitet.
Warum ein Shortint zu einem Fehler führt - keine Ahnung, da die Variablen niemals unter 0 oder über 61 gehen.
Aber egal - ich schließe den Thread aber noch nicht - wer weiß...

Vielen Dank für die Tipps, die immerhin zur Eingrenzung geführt haben

[zeras]

Zitat von Rupert:

da die Variablen niemals unter 0 oder über 61 gehen.

Wenn du vielleiht einen Übertragungsfehler hast, könnte es vielleicht sein, dass die Werte außerhalb deines o.g Bereiches ankommen.
Vielleicht ist das eine Ursache.

[Blup]

Mit "killt sich das Programm" ist doch ein Absturz gemeint?
Die Beschreibung hört sich aber jetzt eher nach eine Festhängen in einer Endlosschleife an.

Hauptschleifencounter wird bei jedem Aufruf des Timers erhöht, aber scheinbar niemals zurück gesetzt.
Natürlich läuft der irgendwann über und wird negativ.
Dann dauerrt es natürlich ewig bis der wieder positiv und größer 10 wird.
Im Prinzip könnte das auch mit Integer passieren, dauert halt 65000 mal so lange.