LabVIEW 2009 Absturz ohne Fehlermeldung

Sehr geehrte LabView-Gemeinde,

im Rahmen eines Messystems, das nachts für mehrere Stunden den Himmel beobachtet, verwenden wir eine VI, die einen Schrittmotor ansteuert, sowie Daten aus dem LabJack U12 ausliest.

Leider kommt es zu Abstürzen von LabView ohne irgendeine Fehlermeldung. Das Programm ist einfach weg, wenn man am nächsten morgen nachsehen geht, mal lief es 3 Stunden, mal 6 Stunden, aber es ist auch schon einmal drei Tage durch gelaufen, ohne Absturz.
Nach dem erneuten Starten von LabView erhält man keinen Report über einen vorangegangenen Absturz. Einen Error-Log konnte ich bislang auch nicht finden.

Es ist sehr wichtig, dass dieses Programm stabil läuft, da es sich hierbei um Langzeitmessungen handelt.

Ich würde mich über jedwegen Input freuen!

Mit besten Grüßen
Niklas Correnz

_________
LabVIEW 2009 9.0f3

  GRIPS_0.8.vi (Größe: 236,48 KB / Downloads: 222)


  GRIPS_constants.vi (Größe: 10,21 KB / Downloads: 230)


  GRIPS_time.vi (Größe: 17,99 KB / Downloads: 214)


  GRIPS_unixtime.vi (Größe: 14,96 KB / Downloads: 228)

Anzeige

Hallo Niklas,

Zitat:Es ist sehr wichtig, dass dieses Programm stabil läuft, da es sich hierbei um Langzeitmessungen handelt.

Und dann verwendest du ExpressVIs?

Außerdem rufst du noch 3rd-party-HW per DLL auf und greifst wiederholt auf den Windows-Kernel zu (hier würde auch ein einmaliger Aufruf reichen!). Vielleicht liegt der Fehler ja auch im LabJack-Treiber?

P.S.:
Manches Konstrukt in deinem VI finde ich etwas umständlich:
- Eine zweifache Stunden-/Minuteneingabe über vier ENUMs?
- Den gleichen Timestamp mehrfach in Strings umwandeln und diese dann in Zahlen? Wozu gibt es "Sekunden nach Datum/Zeit"?
- Wochentags- und Uhrzeit-Vorgaben gehören in (einen?) Cluster - schon bekommst du ein subVI mit einer übersichtlichen Anzahl von Ein- und Ausgängen...
- Warum Pfade als String-Konstanten vorgeben? Es gibt auch Pfad-Konstanten!
- Je nach Datenaufkommen könnte auch das "Build XY-Graph"-ExpressVI einen "Out of Memory"-Absturz provozieren...

Hallo Gerd,

vielen Dank für deine schnelle Antwort! Ich werde deine Tipps mal versuchen umzusetzen und dann heute nacht noch einmal die Messung probieren!

Die Express-VI des Stepper-Motors ist leider nicht von mir. Die hat die Firma des Motors bereitgestellt.

Wenn das Problem im LabJack Treiber liegt, kann ich momentan nichts dagegen tun. Wir haben uns allerdings eine IEEE-Karte von NI bestellt, die wird das LabJack bald ersetzen.

Besten Dank schon mal,
Niklas Correnz

- Je nach Datenaufkommen könnte auch das "Build XY-Graph"-ExpressVI einen "Out of Memory"-Absturz provozieren...

Was würde dann dagegen sprechen, wenn du erst alle Werte speicherst und wirklich erst nachdem alle Werte gespeichert sind du diese anzeigen lässt, oder ist das essentiell das du dir die aktuellen Werte angezeigt werden?

Was du dir auch angewöhnen solltest ist eine übersichtlichere Programmierung, das heißt Datenweitergabe der Wires zum Beispiel von links nach rechts und von oben nach unten. Dadurch fallen zum Beispiel Fehler einfacher auf und man kann einfacher nachvollziehen, was das Programm machen soll/tut...
Was mir auch auffällt. das du unheimlich viele Dateien speicherst. Kann mir eventuell vorstellen, das das auch ne Ursache von nem Absturz sein kann. Hierzu kannst du dir vielleicht ein paar andere Speicherkonzepte anschauen, die auch für Langzeitmessungen geeignet sind (Datenbanken etc.)
Was auch fehlt ist das Schließen des Com-Portes vor Beendigung des Programmes.

Wieso wird eine Position in einem File gespeichert, um sie dann im nächsten Schleifendurchlauf zu lesen? Per Shiftregister weitergeben!

Außerdem würde ich mal den Speicherverbrauch/Handles usw. mit einem Programm wie z.B. dem Sysinternals Process Explorer überprüfen.

Gruß, Jens