Unterschied LabView Application zu Laufzeitumgebung

Hallo Zusammen,

ich benutze Labview 2017 und bekomme beim Executable nach ca. 24 Stunden die maximale CPU Auslastung (Der Code ist nur für eine CPU programmiert). Wohingegen der gleiche Code in der Entwicklungsumgebung dieses Fehlverhalten nicht zeigt.

Ich erläutere mal genauer welche Hypothesen ich schon überprüft habe bzw. wie es zu dem Fehlverhalten kam.

Die Exe lief ca 6 Monate problemlos. Dies kann ich am Windows Eventlog nachweisen. Danach tritt der Fehler zuverlässig nach der oben erwähnten Zeit auf.

Ok dachte ich mir. Nicht das ein Hardwaredefekt zu diesem Fehlverhalten führt. Ob nun Rechner selber oder irgendeine Hardware mit der Labview kommuniziert.
Pustekuchen, der Tausch sämtlicher Hardware führt zum gleichen Fehler.

Nun gut, vielleicht läuft eine API voll oder Softwareseitig gab es Änderungen an Windows die zum Fehlverhalten der Exe führen. Also die Entwicklungsumgebung mit dem gleichen Code angeworfen um im Fehlerfall besser analysieren zu können.

Siehe da, der Fehler tritt nicht auf.

Nun bin ich ratlos und hoffe einer von euch hat noch eine Idee.


Gruß
Stefan

Hallo stef,

Zitat:Nun gut, vielleicht läuft eine API voll oder Softwareseitig gab es Änderungen an Windows die zum Fehlverhalten der Exe führen. Also die Entwicklungsumgebung mit dem gleichen Code angeworfen um im Fehlerfall besser analysieren zu können.
Siehe da, der Fehler tritt nicht auf.

Und wenn du nun das Executable debugst?
Oder mehr Errorhandling und Logging ins Executable einbaust?

... ein bischen wenig Input, um das Problem eingrenzen zu können.
Bleiben die üblichen Ratschläge:
- Gibt's irgendwo loop mit nicht initialisierten Schieberegistern?
- Werden alle Referenzen und Handles ordentlich geschlossen oder ggf. mehrfach geöffnet?
- Wie verhält sich die Speicherauslastung im Task-Manager?
- Ist das Programmauf funktioierende Netzwerk Kommunikation oder Netzwerkspeicher angewiesen?
- Gibt's Diagnose oder Logfiles mit Angaben zu internen Laufzeiten und Speicherbelastung?

Fragen über Fragen....

[offtopic]
Ist wie beim Autohändler:
"Mein BMW fährt immer 500 bis 600 km zuverlässig und dann bleibt er stehen. Was ist da kaput?"
...
"Nachtanken?"
[/offtopic]

(02.08.2022 12:08 )GerdW schrieb:  Hallo stef,

Zitat:Nun gut, vielleicht läuft eine API voll oder Softwareseitig gab es Änderungen an Windows die zum Fehlverhalten der Exe führen. Also die Entwicklungsumgebung mit dem gleichen Code angeworfen um im Fehlerfall besser analysieren zu können.
Siehe da, der Fehler tritt nicht auf.

Und wenn du nun das Executable debugst?
Oder mehr Errorhandling und Logging ins Executable einbaust?

Dies habe ich bereits über eine Woche probiert. Erfolglos.
Deshalb der Plan den Fehler in der Entwicklungsumgebung in Echtzeit zu debuggen.

Natürlich bleibt mir nach dem sicherstellen, dass die Entwicklungsumgebung diesen Fehler tatsächlich nicht hat nurnoch die Fehlersuche in der Exe. Mir scheint diese Suche wieder aufzunehmen aber sehr zeitintensiv.

Deshalb hoffte ich durch die Unterschiede beim Ablaufen eines Codes zwischen Exe und Entwicklungsumgebung bessere Informationen zu bekommen wo genau ich beim debuggen der Exe weiter machen soll.

Nur welche Unterschiede es dort wirklich gibt, sind mir unklar.

Gruß
Stefan

Nach meinen Erfahrungen wirkt sich "schlampige" Programmierung in der Entwicklungsumgebung wesentlich weniger aus als in der Laufzeit. Deshalb auch der Hinweis auf den Speicherverbrauch und die Resourcennutzung.
Wenn z.B. in der Exe der Speicher über längere Zeit "vollläuft" führt das früher oder später zu seltsamen Verhalten.
In der Entwicklungsumgebung tritt dies wesentlich seltener auf. Möglicherweise wird durch interne Routinen der Speicher dort öfter mal aufgeräumt (ist so einen Vermutung von mir).

(03.08.2022 08:33 )hajos118 schrieb:  Nach meinen Erfahrungen wirkt sich "schlampige" Programmierung in der Entwicklungsumgebung wesentlich weniger aus als in der Laufzeit. Deshalb auch der Hinweis auf den Speicherverbrauch und die Resourcennutzung.
Wenn z.B. in der Exe der Speicher über längere Zeit "vollläuft" führt das früher oder später zu seltsamen Verhalten.
In der Entwicklungsumgebung tritt dies wesentlich seltener auf. Möglicherweise wird durch interne Routinen der Speicher dort öfter mal aufgeräumt (ist so einen Vermutung von mir).

Dies hieß aber auch, dass das Fehlverhalten nicht plötzlich nach einem halben Jahr autreten würde. Sondern bereits von Anfang an in der Exe war. Wie der Benutzer die Software bedient habe ich natürlich nicht in der Hand. Aber das Fehlverhalten tritt reproduzierbar im unbelasteten Zustand der Software auf. In der Entwicklungsumgebung aber nicht.

Auch sämtliche Auswertungen des Speicherverbrauchs und der Resourcennutzung sind unauffällig.

Lediglich steigt mit zunehmender Laufzeit die CPU Last. Trotz unbelastetem Zustand.

Anzeige

Wenn die CPU - Last steigt, dann könnte es an einem rekursiven Aufruf von Routinen liegen, die nicht beendet werden.
Eventuell gibt's hier einen Seitenefekt, dass das Betriebssystem immer mehr Rechenleistung einsetzen will um "aufzuräumen" (Fragmentierter Speicher ect.)

Zum Argument "Es ging monatelang gut": Gab's inzwischen ein Windows update?

Hallo Stefan,

wie hast du dein LabView-Programm aufgebaut?
Welche Vorlage hast du dazu verwendet?

Ich habe mit der Vorlage "Kontinuierliche Erfassung und Protokollierung" für Dauermessungen sehr gute Erfahrungen gemacht.
Auch ist die Frage, was du in das Timeout-Blatt der Ereignisstruktur reingepackt hast, falls bei dir vorhanden.

NI Vorlagen und ihre Beschreibung: https://www.ni.com/de-de/support/documen...jects.html

Gruß
Eugen

Das ganze wird immer kurioser....

Nachdem ich den Fehler in der Entwicklungsumgebung nicht nachstellen konnte um in Echtzeit zu debuggen, habe ich eine neue Exe erstellt um zu Checken ob der Fehler überhaupt aktuell auf dem System auftaucht. Ergebnis: Erstmal nicht.

Also nach 48 Stunden kein Fehler in der Entwicklungsumgebung und nach 24 Stunden auch kein Fehler in der Exe.

So semi gut dachte ich mir... Fehler weg ohne zu wissen warum.

Daraufhin mit der Exe weiter getestet um festzustellen ob der Fehler tatsächlich weg ist. Ergebnis: Nein, ist er nicht. Plötzlich tritt er wieder über Nacht auf.

Sämtliches Nachstellen des Fehlers auf künstlichen Umgebungen sowohl mittels Exe als auch Entwicklungsumgebung führen zu keinerlei Fehlerverhalten. Selbst wenn ich die künstliche Umgebung nach allen Regeln der Kunst belaste.

Jetzt hoffe ich darauf, dass der Fehler in der Entwicklungsumgebung, auf dem Fehlerhaften System, doch auftaucht um dann analysieren zu können.

Gruß
Stefan

Hallo Stefan,

hängt der PC mit der exe denn im gleichen Netzwerk wie dein Entwicklungsrechner? Es gibt in LabVIEW eine Remote Debug Funktion:
   

Da kann man mit Probes auch den Code aus der Exe live anschauen.

MfG Timo