Nach Timer.Enable killt sich das Programm

[Rupert]

Liebe Freunde.

Ich habe ein Programm geschrieben, das meine Heizung steuert. Seit 1997 läuft das Programm klaglaos, bis ich vor 6 Monaten die Pumpen- und Mischersteuerung ausgegliedert habe, und mit einer Siemens-LOGO durchführen lasse.

Im Grunde genommen hat sich nicht viel geändert:
- die Steuerbefehle für 4 Pumpen und 4 Mischer werden nicht mehr von der Steuerkarte in meinem PC ausgeführt.
- Daten vom Heizkessel und von der PV werden von einem Server eingelesen
- Die Abarbeitung Hauptschleife dauert nun anstatt 0,8sec. 1,3 sec.
Zu Beginn der Regelung stoppe ich den Timer und am Ende starte ich ihn wieder, damit er die Hauptschleife nicht erneut auslöst.
Der Timer löst jede Sekunde die Hauptschleife aus.
Ich habe schon andere Timerkomponenten ausprobiert, was leider keinen Erfolg gebracht hat

Mittlerweile habe ich zur Fehlersuche eine kleine Datenbank angelegt, die die Routinen vor dem Aufruf einträgt (siehe Bild)
irgendwann -mal nach 40000 Einträgen, dann nach 6000 Einträgen beendet sich das Programm an einem Punkt, wo der Punkt Timer.enable:=true ausgeführt wird.

Ich bin leider mit meiner Weisheit am Ende und hoffe, dass ich auf diesem Wege Ideen erhalte, die dieses Problem lösen.
Vielleicht stehe ich auch nur auf dem Schlauch.
Danke und
lg Rupert

Delphi-Quellcode:

procedure THauptformular.Hauptschleife(Owner: TObject);

Begin

  inc (Hauptschleifencounter,1);

  if Hauptschleifencounter > 10 then Begin
    CounterStop(nil);
    inc(Regel_intervall_ist,1);
    if Regel_intervall_ist >= Regel_intervall then
    Begin
// Abscannen der Raum- und Wassertemperaturen
      Digital_Messwerte_holen(nil);
      Analog_Messwerte_holen(nil);

      Pruefung_der_Vorprogrammierung(nil); // check auf einen Programmwechsel

// Daten der Photovoltaik und des Heizkessels abfragen
      NANO_Daten_vom_Server(nil);
      Fronius_Daten_vom_Server(nil);

      Steuern[Kessel_Port]:=aus;
      Begin
        Regelvorgang_Raeume(nil);

// Kesselbetrieb abfragen
        if ((not Heizung_ausflag)) then
          Abfrage_Kessel_Einschalten(nil);
        If ((not Winterbetrieb_Aktiv)) then
          Abfrage_Kessel_Ausschalten(nil);  // nicht Abschalten, wenn Winterbetrieb

        Ausgeben_auf_Steuerungskarte(nil);

        Istwerte_aktualisieren(nil);

// Speichern der aktuellen Werte zur Statistik
        inc(Speicherintervall_ist,1);
        if Speicherintervall_ist >= Speicherintervall then Begin
          Speicherintervall_ist:=0;
          Memo1.Clear;  //memofeld entleeren um Speicherüberläufe zu verhindern
          Speicherung_Der_Messdaten(nil);
        end; //Speicherintervall
      end; // if Heizung_ausflag 
    end; //Regel_intervall

    Display_aktualisieren(nil);
    CounterStart(nil);
  end; //if Hauptschleifencounter > 10
end;


procedure THauptformular.Counterstop(Owner: TObject);
Begin
  TimerEx1.Enabled:=False;
end;

procedure THauptformular.CounterStart(Owner: TObject);
Begin
    TimerEx1. CleanupInstance;
    TimerEx1.Enabled:=True;
end;

[zeras]

Nach den Infos klingt das für mich komisch. Deine Hauptschleife wird jede Sekunde aufgerufen, dauert aber manchmal mehr als eine Sekunde.
Ich habe jetzt nicht dein Programm angeschaut, aber warum läßt du den Timer dann nicht alle 2 oder mehr Sekunden laufen, damit das Ende immer innerhalb der Zeit fertig ist?

[mmw]

Halo,

laut Online Hilfe soll man

CleanupInstance

nicht direkt aufrufen.

https://docwiki.embarcadero.com/Libr...leanupInstance

Gruß

[Uwe Raabe]

Zitat:

Zitat von zeras (Beitrag 1494177)

Deine Hauptschleife wird jede Sekunde aufgerufen, dauert aber manchmal mehr als eine Sekunde.

Der Timer wird ja innerhalb der Schleife aus- und wieder eingeschaltet. Das Timer-Intervall startet also erst am Ende der Schleife.

Was allerdings auffällt ist, dass der

Delphi-Quellcode:

Hauptschleifencounter

nicht zurückgesetzt wird. Es wird also ab dem 10-ten Aufruf jedes mal der gesamte Zyklus durchlaufen. Ich weiß nicht, ob das so gedacht ist.

[Blup]

Ich vermute auch das "CleanupInstance" da nicht hingehört, kommentiere das mal aus.

Statt den Timer immer wieder aus und ein zu schalten, ist es vieleicht besser die vergangene Zeit seit dem letzen Aufruf zu testen.

Delphi-Quellcode:

    procedure Hauptschleife(Owner: TObject); 
  private
    SteuerungAktiv: Boolean;
    NextStart: TDateTime;
    procedure DoSteuerung;
  end;

implementation

const
  StartIntervall    =  1{s} /24/60/60; 
  Startverzoegerung = 10{s} /24/60/60;

function NowUTC: TDateTime;
var
  SystemTime: TSystemTime;
begin
  GetSystemTime(SystemTime);
  Result := SystemTimeToDateTime(SystemTime);
end; 

procedure THauptformular.Hauptschleife(Owner: TObject);
begin
  if not SteuerungAktiv then
  begin
    SteuerungAktiv := True;
    if NowUTC >= NextStart then
    begin
      NextStart := NextStart + StartIntervall; // alternativ NowUTC + StartIntervall
      DoSteuerung;
    end; 
    SteuerungAktiv := False;
  end;
end;

procedure THauptformular.Counterstop(Owner: TObject);
Begin
  TimerEx1.Enabled:=False;
end;

procedure THauptformular.CounterStart(Owner: TObject);
Begin
  NextStart := NowUTC + Startverzoegerung; 
  TimerEx1.Enabled:=True;
end;

[Rupert]

Zitat:

Zitat von mmw (Beitrag 1494178)

Halo,

laut Online Hilfe soll man

CleanupInstance

nicht direkt aufrufen.

https://docwiki.embarcadero.com/Libr...leanupInstance

Gruß

CleanupInstance ist erst zuletzt hinzugefügt worden, um ev. Puffer zu bereinigen - aus Verzweiflung, weil bisher nichts zur Lösung beigetragen hat.
Wird remarkt - Danke!

[Rupert]

Zitat:

Zitat von Uwe Raabe (Beitrag 1494179)

Zitat:

Zitat von zeras (Beitrag 1494177)

Deine Hauptschleife wird jede Sekunde aufgerufen, dauert aber manchmal mehr als eine Sekunde.

Der Timer wird ja innerhalb der Schleife aus- und wieder eingeschaltet. Das Timer-Intervall startet also erst am Ende der Schleife.

Was allerdings auffällt ist, dass der

Delphi-Quellcode:

Hauptschleifencounter

nicht zurückgesetzt wird. Es wird also ab dem 10-ten Aufruf jedes mal der gesamte Zyklus durchlaufen. Ich weiß nicht, ob das so gedacht ist.

JA, das ist so gedacht.
Die Regelintervalle sind 20 sec. damit die Mischermotoren nicht dauernd auf/zu fahren. Deren Gesamtlaufzeit ist 140 sec.
Die Sericherintervalle sind 30 x Regelintervall also 600 sec.
der Hauptschleifencounter wird auf 0 gesetzt - habe ich beim Löschen der Kommentierung (wegen der Lesbarkeit des Codes) versehentlich mitgelöscht - sorry - aber danke, würde ohne Nullsetzung nicht funktionieren.

Hat sich von gestern auf heute nach 33142 Ereignissen wieder gekillt - an der selben Stelle.
Habe CleanupInstance entfernt und nach inc (Hauptschleifencounter,1); einen Eintrag in die Datenbank gesetzt, um zu sehen, ob der Timer die Hauptschleife auslöst oder er selbst den Kill auslöst.
SW neu gestartet.

Danke für die Tipps!

Delphi-Quellcode:

        Ausgeben_auf_Steuerungskarte(nil);
        Hauptschleifencounter:=0;
        Istwerte_aktualisieren(nil);

[hoika]

Hallo,
was sagt denn FastMM4 zu Deinem Programm?

Ansonsten, wie schon gesagt wurde, mal den Taskmanager mitlaufen lassen
zwecks Kontrolle des Speichers und der Handles.

[Rupert]

Zitat:

Zitat von hoika (Beitrag 1494186)

Hallo,
was sagt denn FastMM4 zu Deinem Programm?

Ansonsten, wie schon gesagt wurde, mal den Taskmanager mitlaufen lassen
zwecks Kontrolle des Speichers und der Handles.

FastMM4 kannte ich nicht. Halte es vorerst im Focus - Danke.
Taskmanager läuft bereits mit.

[Rupert]

Zitat:

Zitat von zeras (Beitrag 1494177)

Nach den Infos klingt das für mich komisch. Deine Hauptschleife wird jede Sekunde aufgerufen, dauert aber manchmal mehr als eine Sekunde.
Ich habe jetzt nicht dein Programm angeschaut, aber warum läßt du den Timer dann nicht alle 2 oder mehr Sekunden laufen, damit das Ende immer innerhalb der Zeit fertig ist?

Es läuft ein Countdown mit, der signalisiert, wann der nächste Regelvorgang startet.
In der Statuszeile werden die jeweiligen "Stationen" - was soeben durchgeführt wird - visualisiert.
Werde ich beim nächsten Crash auf 2 sec. erhöhen und testen. Führt m.e. jedoch nicht zum Verursacher des Problems, wäre aber vlt. eine Lösung - Danke!

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

[jaenicke]

Du kannst dir in FastMM auch live anzeigen was so im Speicher passiert. Dazu findest du im FastMM4 Ordner auch eine Demo, deren Formular du einfach einbinden kannst. Die liegt unter: FastMM\Demos\Usage Tracker

Das hilft in solchen Fällen oft mehr als nur die Leckanzeige beim Beenden des Prozesses.

[Rupert]

Heute um 5:56 passierte zum Zeitpunkt TimerEx1.Enable:=true folgendes:

Zitat:

Ereignistyp: Fehler
Ereignisquelle: Application Error
Ereigniskategorie: Keine
Ereigniskennung: 1000
Datum: 07.09.2021
Zeit: 05:55:31
Benutzer: Nicht zutreffend
Computer: HEIZ-PC
Beschreibung:
Fehlgeschlagene Anwendung heizung2020.exe, Version 11.0.1.1, fehlgeschlagenes Modul kernel32.dll, Version 5.1.2600.5512, Fehleradresse 0x00012aeb.

Daten:
0000: 41 70 70 6c 69 63 61 74 Applicat
0008: 69 6f 6e 20 46 61 69 6c ion Fail
0010: 75 72 65 20 20 68 65 69 ure hei
0018: 7a 75 6e 67 32 30 32 30 zung2020
0020: 2e 65 78 65 20 31 31 2e .exe 11.
0028: 30 2e 31 2e 31 20 69 6e 0.1.1 in
0030: 20 6b 65 72 6e 65 6c 33 kernel3
0038: 32 2e 64 6c 6c 20 35 2e 2.dll 5.
0040: 31 2e 32 36 30 30 2e 35 1.2600.5
0048: 35 31 32 20 61 74 20 6f 512 at o
0050: 66 66 73 65 74 20 30 30 ffset 00
0058: 30 31 32 61 65 62 0d 0a 012aeb..

und

Zitat:

Ereignistyp: Warnung
Ereignisquelle: W32Time
Ereigniskategorie: Keine
Ereigniskennung: 36
Datum: 07.09.2021
Zeit: 05:36:06
Benutzer: Nicht zutreffend
Computer: HEIZ-PC
Beschreibung:
Der Zeitdienst konnte die Systemzeit seit 49152 Sekunden nicht synchronisieren,
da kein Zeitanbieter einen gültigen Zeitstempel anbieten konnte. Die Systemuhr ist nicht synchronisiert.

Der Sync beeindruckt mich nicht wirklich, aber der Fehler im kernel32.dll.
Es ist aber absolut sicher, dass durch das Starten des Timers der Fehler ausgelöst wird (siehe Bild).
Die Fragen sind:
- Gibt es eine andere Möglichkeit - ohne Timer - dei Hauptschleife zyklisch durchlaufen zu lassen
- Wie findet man einen kernel32-Fehler, der praktisch alles sein kann

Das habe ich in einem US-Forum gefunden und werde es probieren:

Zitat:

the problem is something that *particular* program is doing, not something all Delphi programs do.
There's simply no way to even make a wild guess at the problem without debugging it.

My best guesses are either DLL hell or permissions/privileges.

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

[Klaus01]

.. hast Du madExcept zur Verfügung?
Mit den madExcept Daten ist oftmals einfacher den Grund einer Exception zu ergründen.

Grüße
Klaus

[venice2]

Zitat:

Ich habe schon andere Timerkomponenten ausprobiert

Dann mach es doch ganz ohne..

SetTimer, KillTimer

Zitat:

Gibt es eine andere Möglichkeit - ohne Timer - dei Hauptschleife zyklisch durchlaufen zu lassen

repeat.. until in Kombination mit

Thread, CreateWaitableTimer, WaitForSingleObject, PostThreadMessage usw..

[Blup]

Wenn ich tief in meine Glaskugel schau, hab ich diese Hypothese:
Direkte Fehlerursache ist ein Überlauf des Aufrufstapels.
Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen.
So dass Hauptschleife() sich indirekt selbst rekursiv aufruft, immer wieder, bis der Stapel überläuft.
Ein Tool wie madExcept könnte da Klarheit schaffen.

Alternative zum Ab- und Anschalten des Timers hab ich weiter oben gepostet.
Du müsstest halt mal probieren ob das hilft.

[Rupert]

Zitat:

Zitat von Klaus01 (Beitrag 1494238)

.. hast Du madExcept zur Verfügung?
Mit den madExcept Daten ist oftmals einfacher den Grund einer Exception zu ergründen.

Grüße
Klaus

Habe MadCollection implementiert - danke für den Tipp
Die Schleife dauert halt nun 30 sec., aber wenn's hilft ;)

[Uwe Raabe]

Zitat:

Zitat von Blup (Beitrag 1494266)

Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen..

Das kann nicht sein. Das Disablen des Timers ruft intern ein KillTimer auf, was dafür sorgt, dass keine Messages dieses Timers mehr in der Message-Queue landen (da WM_TIMER eine Low-Priority Message ist, sollten auch keine mehr drin sein). Mit dem nachfolgenden Enable wird im Wesentlichen dann ein SetTimer aufgerufen, was den Start des Timer-Intervalls darstellt. Daher kann erst frühestens nach Ablauf dieses Intervalls nach dem Enablen des Timers der Event ausgelöst werden. (Side-Note: Die Zykluszeit ist also mindestens so lang wie das Timer-Intervall plus die Dauer der Routine zwischen Ab- und Anschalten des Timers!)

Ich vermute, der Fehler ist unabhängig von dem Timer.

[Rupert]

Zitat:

Zitat von Uwe Raabe (Beitrag 1494271)

Ich vermute, der Fehler ist unabhängig von dem Timer.

Nach Enable wird aber das Ereignis OnTimer nicht mehr ausgeführt - sollte ich in meiner Ereignistabelle sehen.

Zitat:

--- TimerEx1.Enabled:=True ist der letzte Eintrag

Delphi-Quellcode:

procedure THauptformular.Hauptschleife(Owner: TObject);
var zaehler: shortint;
Begin
 begin
  inc (Hauptschleifencounter,1);
  Ereignis_notieren('HS 1. Start Hauptschleife - '+inttostr(Hauptschleifencounter));
  SchleifenBar.position:=11-Hauptschleifencounter;
  ....
  Display_aktualisieren(nil);
  CounterStart(nil);
  end; //if Hauptschleifencounter > 10
end;

// **** **** **** **** **** **** **** **** **** ****

procedure THauptformular.CounterStart(Owner: TObject);
Begin
  Ereignis_notieren('--- TimerEx1.Enabled:=True');
  TimerEx1.Enabled:=True;
end;

[Rupert]

Zitat:

Zitat von Blup (Beitrag 1494266)

Wenn ich tief in meine Glaskugel schau, hab ich diese Hypothese:
Direkte Fehlerursache ist ein Überlauf des Aufrufstapels.
Wenn der Timer im OnTimer-Ereignis wieder angeschalten wird, wird an dieser Stelle möglicherweise OnTimer sofort wieder aufgerufen.
So dass Hauptschleife() sich indirekt selbst rekursiv aufruft, immer wieder, bis der Stapel überläuft.
Ein Tool wie madExcept könnte da Klarheit schaffen.

Alternative zum Ab- und Anschalten des Timers hab ich weiter oben gepostet.
Du müsstest halt mal probieren ob das hilft.

Das passiert nicht, denn das würde ich anhand der Aufzeichnungen in meiner Ereignisdatenbank sehen!
madExcept ist seit heute implementiert
https://www.delphipraxis.net/attachm...1&d=1631034734

[Rupert]

Keine Mitteilung von madExcept. Nichts...

Auffällig ist, dass die letzte Eintragung immer der Timerist und der Crash stets um 5:56 bzw. 5:58 passiert.

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

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

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

[Blup]

Ist madExcept auch richtig installiert und in die Anwendung eingebunden?
Erzeuge zum Test mal eine Exception in deiner Methode und schau ob und wie diese gemeldet wird.

Delphi-Quellcode:

raise Exception.Create('Test');

[Rupert]

Natürlich wurde MadExcept richtig installiert und auch zuvor getestet
Aufgrund der unterschiedlichen Meinungen zu diesem Problem bin ich mir aber ziemlich sicher, dass es kein Programmfehler ist.

Zitat:

date/time : 2021-09-07, 17:43:07, 294ms
computer name : HEIZ-PC
user name : Erhitzer <admin>
registered owner : Erhitzer
operating system : Windows XP Service Pack 3 build 2600
system language : German
system up time : 32 minutes 17 seconds
program up time : 3 seconds
physical memory : 499/767 MB (free/total)
free disk space : (C:) 26,74 GB
display mode : 1280x1024, 32 bit
process id : $24c
allocated memory : 31,95 MB
largest free block : 1,28 GB
executable : Heizung2020.exe
exec. date/time : 2021-09-07 17:38
version : 11.0.1.1
compiled with : Delphi 5
madExcept version : 4.0.21
contact name : Rupert
contact email : [e-mail]
callstack crc : $9f487409, $90a79116, $90a79116
exception number : 1
exception class : EABSException
exception message : Cannot open file:'C:\Programme\Heizungsregelung\Datenbank\Heiz daten.abs' Error code: 32. ErrorMessage: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird - Native error: 30364.

[CCRDude]

Die Meldung sagt ja aber schon, dass es ein eindeutig Programmfehler ist ;)

Da wird der mögliche Fehlerfall, dass die Datei anderweitig geöffnet ist, nicht behandelt.

Wenn es immer die gleiche Zeit ist: findet zu dieser Zeit evtl. ein Backup statt? Es gibt ja durchaus berechtigte Interessen dritter Programme bzw. des Betriebssystems - sei es ein Backup, ein gründlicher AV-Scan, ... .

Da muss man dann schauen, ob man die Datei dauerhaft offen hält (und auf teilweise sinnvollen Fremdzugriff wie eben ein Backup verzichtet), oder ob man den Fehlerfall behandelt (was man so oder so muss, da die Datei auch schon beim ersten Öffnen anderweitig gesperrt sein kann).

[Rupert]

Zitat:

Zitat von CCRDude (Beitrag 1494306)

Die Meldung sagt ja aber schon, dass es ein eindeutig Programmfehler ist ;)

Da wird der mögliche Fehlerfall, dass die Datei anderweitig geöffnet ist, nicht behandelt.

Wenn es immer die gleiche Zeit ist: findet zu dieser Zeit evtl. ein Backup statt? Es gibt ja durchaus berechtigte Interessen dritter Programme bzw. des Betriebssystems - sei es ein Backup, ein gründlicher AV-Scan, ... .

Da muss man dann schauen, ob man die Datei dauerhaft offen hält (und auf teilweise sinnvollen Fremdzugriff wie eben ein Backup verzichtet), oder ob man den Fehlerfall behandelt (was man so oder so muss, da die Datei auch schon beim ersten Öffnen anderweitig gesperrt sein kann).

Dieser Dateifehler wurde von mir provoziert, um MadExcept zu testen.
Suf duesem Computer läuft nichts. Kein Backup, kein Virenscanner.

[Blup]

Timer werden in fast jeder Anwendung verwendet.
Kommentiere doch mal alles was mit deiner Steuerung zu tun hat aus.
Dann lass das Programm laufen und schau ob der Fehler noch auftritt.

[Rupert]

Zitat:

Zitat von Blup (Beitrag 1494315)

Kommentiere doch mal alles was mit deiner Steuerung zu tun hat aus.

Du meinst das Lesen von und die Ausgabe auf die Steuerkarte.
Das wird diese Woche nicht mehr gehen, aber ab Montag kann ich das probieren.
Danke!

[CCRDude]

[QUOTE=Rupert;1494313]

Zitat:

Zitat von CCRDude (Beitrag 1494306)

Suf duesem Computer läuft nichts. Kein Backup, kein Virenscanner.

Du hast also bewusst den Windows Defender, VSS und weitere Systemdienste deaktiviert? Ist zwar noch ein XP, trotzdem schon ein Multitasking-Betriebssystem.

Zitat:

Zitat von Blup (Beitrag 1494315)

Timer werden in fast jeder Anwendung verwendet.

Timer verwende ich auch gelegentlich, aber nicht nicht in diesem Kontext. Für wiederkehrendes Daten-I/O wie hier verwendet man eher Threads als Timer. Kaum etwas ist nerviger als nicht reagierende UIs, weil der Entwickler Last im Hauptthread erzeugt.

"Timen" kann man dann immer noch mit WaitForSingleObject mit definiertem Timeout auf ein Terminate-Event, um die Schleife im Falle des Programmschließens sofort zu beenden.

Ansonsten, um einen Mehrfachaufruf der Timer-Methode wirklich zu verhindern: mit TCriticalSection wrappen, dann kann er nicht nochmal rein, bevor er raus ist.

Ansonsten hilft es manchmal auch schon, die Logik nicht in der Timer-Methode zu haben, sondern von dort per PostMessage an eine andere Methode die eigentliche Ausführung zu triggern.

[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:

Zitat von Blup (Beitrag 1494361)

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:

Zitat von Blup (Beitrag 1494361)

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:

Zitat von CCRDude (Beitrag 1494413)

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 :wink:

[zeras]

Zitat:

Zitat von Rupert (Beitrag 1494924)

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.

[Rupert]

Zitat:

Zitat von Blup (Beitrag 1494944)

Hauptschleifencounter wird bei jedem Aufruf des Timers erhöht, aber scheinbar niemals zurück gesetzt.

Habe ich berreits hier kommentiert

[Rupert]

Neue Erkenntnisse:

Also die Variablen habe ich vorerst nicht als Verursacher des Absturzes isolieren können.

Deshalb habe ich nun den Processmonitor mitlaufen lassen und dabei festgestellt, dass der Absturz ähnlich damit ist, als würde jemand den Menüpunkt "Beenden" klicken.
Ähnlich deshalb, weil nach dem Processname 17:56:11 1087389 (CloseFile) noch Dinge geschehen, die beim manuellen "Beenden" vom Monitor nicht aufgezeichnet wurden.

Heute um 17:56:11 war es so weit. (siehe Logfile-1.txt)

Wenn man das "X" rechts oben klickt, sieht dass Ende des Programms wie in Logfile-2.txt aus
und beende ich das Programm mit dem Menüpunkt "Beenden" dann ist es identisch mit dem "X"-Click - siehe "Logfile-3.txt".

Resumeé:
Beim normalen Beenden des Programms oder dem "X" ist nach 4 Zeilen Schluss mit allem.
Verabschiedet sich das Programm, dann werden noch hinterher die Datenbanken geschlossen (Heizdaten.abs und Fehlersuche.abs) wie man sehen kann.

Kein Remote-Acccess, der mir einen "Streich" spielen würde:
Der "Windows-Remote-Access" ist deaktiviert - auch den "VNC-Access" habe ich deaktiviert. Der Heiz-PC hat in der Cisco-ASA eine Sperre, damit er nicht ins Internet kann - nur NTC wird durchgelassen. Auch passieren keine TCP-Aktivitäten, das würde der Syslog aufzeichnen.

Ich blick`nicht durch, was da in der Software vorgeht...

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

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

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

[jaenicke]

Zitat:

Zitat von Rupert (Beitrag 1495677)

Deshalb habe ich nun den Processmonitor mitlaufen lassen und dabei festgestellt, dass der Absturz ähnlich damit ist, als würde jemand den Menüpunkt "Beenden" klicken.

Nein, das ist ganz und gar nicht ähnlich, sondern typisch für einen Absturz.

Absturz:

Code:

ReadFile Datenbank.xyz
Thread Exit
Process Exit
CloseFile Aktueller Ordner
CloseFile Datenbank.xyz

Regulärer Exit:

Code:

ReadFile Datenbank.xyz
CloseFile Datenbank.xyz
Thread Exit
Process Exit
CloseFile Aktueller Ordner

Merkst du den Unterschied? Beim Absturz werden die Dateihandles erst nach dem Beenden des Prozesses automatisch durch Windows aufgeräumt. Beim regulären Beenden macht das Programm das vorher.

Der Fehler könnte beim Zugriff auf die Fehlersuche.abs oder in den Events davor (die hier nicht dabei sind) passiert sein.

[Rupert]

Zitat:

Zitat von jaenicke (Beitrag 1495714)

Der Fehler könnte beim Zugriff auf die Fehlersuche.abs oder in den Events davor (die hier nicht dabei sind) passiert sein.

Danke - werde dem nachgehen:)

[Rupert]

Ich finde absolut nichts...

hier sind die letzten 2 Sekunden vor dem Ende
"Process Profiling" in Heizung2020.exe ist der Timer, und ist das letzte Ereignis vor dem Absturz.
Der Absturz passierte um 17:49:21.

vlt. sieht jemand etwas anhand der beiden Logfiles.
Logfile6-10-21-a.txt ist nur der Log von Heizung0202.exe, Logfile6-10-21-alles.txt beinhaltet auch die anderen Programme.

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

[Delphi.Narium]

Findest Du dazu

Code:

"17:49:21,6079279","Heizung2020.exe","1016","Process Exit","","SUCCESS","Exit Status: -1073741819, User Time: 1496.0712448 seconds, Kernel Time: 526.5471376 seconds, Private Bytes: 17.899.520, Peak Private Bytes: 22.761.472, Working Set: 21.819.392, Peak Working Set: 26.808.320"

was im Ereignislog?

Ansonsten Suchmaschine Deiner Wahl mal mit exit status -1073741819 füttern. Meine behauptet, es gäbe rund 48.300.000 Ergebnissen. Keine Ahnung, wie man das jetzt noch sinnvoll für Deine konkrete Problematik eingrenzen kann. Es scheint aber ein grundsätzliches Problem für diverse Software zu sein, das zuweilen auftreten kann.

Hexadezimal entspricht -1073741819 = FFFFFFFFC0000005

Der Betriebssystemhersteller meint dazu:

Zitat:

The exit code -1073741819 in hex is 0xC0000005. If you look up this code in Microsoft's documentation (NTSTATUS Values) you will see that it indicates that your program was terminated due to an access violation. This error can occur for a variety of reasons, including de-referencing a NULL pointer or referencing an invalid address.