LabVIEW 6.1 Hängt – Bezug zu User Interaktion / Möglicherweise File I/O

Hallo Zusammen

Wie man am Titel schon sieht, benutzen wir eine archaische LabVIEW Version. Daran wird sich auch nichts ändern, da 6.1 zur Zeit der Inbetriebnahme unserer Anlage neu war und unsere philosophie lautet „never touch a running system“.

Die Sache ist die, dass unser System gar nicht so perfekt ist, wie zuerst angenommen. Es geht um folgendes:

Wir verwenden LV in einem Triebwerksprüfstand. Es ist so, dass ein normaler Testlauf eine bis maximal zwei Stunden dauert; je nach anzuwendender Test Sequenzen. Dieser Zeitrahmen hat in der Vergangenheit die meisten Tests abgedeckt und so sind wir von unserem relativ neuen Problem verschont geblieben. Seit einiger Zeit jedoch, häufen sich Fälle von Problemtriebwerken und die Tests können schon mal vier bis fünf Stunden dauern. Und damit hat alles angefangen…

LabVIEW läuft also ganz normal, bis nach einer längeren Zeit eine User Interaktion einen unvermittelten Freeze / Hänger auslöst. Es sieht so aus als könnte dies einen Bezug zu einem File I/O haben, wenn z.B. Testdaten in ein *.xls File geschrieben werden („Save“). Es kann jedoch nicht mit 100%iger Sicherheit ausgeschlossen werden, dass dieser Eindruck falsch ist. Die entsprechenden Daten jedoch, werden in diesen Fällen nie gespeichert.

Um zu sehen was geschieht, haben wir die Applikation vergangene Nach laufengelassen und haben ein paar Daten und einen Zeitstempel in eine Textdatei geschrieben um zu sehen ob und wann sich LabVIEW aufhängt. Es ist während über 15 Stunden gar nichts geschehen, offensichtlich weil es keine User Interaktion gab.

Es mag hilfreich sein zu wissen, dass wir LabVIEW unter Windows XP SP3, 32Bit betreiben. Das Betriebssystem als solches friert nicht ein und alles andere läuft wie gewohnt weiter. Nur LabVIEW hängt sich auf und zwar vollständig (also nicht nur ein paar *.vi’s oder loops). Normalerweise ist die Applikation nach ein paar minuten zurück, nur dass dann die TCP und *.xls Referenzen (refnum, abgelegt in einer globalen Variablen) geschlossen sind und von Hand neu gestartet werden müssen.

Ich bin mir bewusst, dass diese Infos etwas mager ausfallen. Bitte betrachtet sie als einen Startpunkt.

Für jegliche nützlichen Hinweise bin ich sehr dankbar!


Linuxx

Anzeige

Ich persönlich brauche da wirklich noch mehr Informationen, da ich dieses Fehlverhalten nicht kenne (und Fehlverhalten, die "plötzlich" auftreten, eher auf eine Änderung der "Umgebungsbedingungen", sprich Dateipfade, Netzwerkzugriffe, Speicherplatz, etc. schließen lassen)
Meine Fragen:
Wird eine bereits bestehende xls-Datei geöffnet und beschrieben?
Ist der Dateipfad vorher festgelegt?
Wird die Referenz für die Datei über die komplette Programmlaufzeit gehalten?
Wie wird die Userinteraktion abgefragt? (wahrscheinlich gab's bei 6.1 nur Polling...?)
Wie stark ist der Arbeitsspeicher während der Programmlaufzeit im Mittel beschrieben?
Ist genug Festplattenspeicher vorhanden? (jaja, ich weiß - nur zur Sicherheit)
Besteht die Möglichkeit, dass zusammen mit der Nutzereingabe ein "gleichzeitiger" programmseitiger Zugriff auf die Datei erfolgen kann?

Vielen dank für die schnelle antwort!

Die umgebungsbedingungen haben, wie eingangs beschrieben, nur insofern geändert als die dauer der tests ausgedehnt wurde. Am programm selber wurden eigentlich keine änderungen vorgenommen.

(05.04.2013 12:58 )Kasi schrieb:  Wird eine bereits bestehende xls-Datei geöffnet und beschrieben?

Jein. Die datei ist bereits im hintergrund geöffnet und wird erst bei beenden des programms geschlossen.

(05.04.2013 12:58 )Kasi schrieb:  Ist der Dateipfad vorher festgelegt?

Ja.

(05.04.2013 12:58 )Kasi schrieb:  Wird die Referenz für die Datei über die komplette Programmlaufzeit gehalten?

Ja, wird am anfang festgelegt.

(05.04.2013 12:58 )Kasi schrieb:  Wie wird die Userinteraktion abgefragt? (wahrscheinlich gab's bei 6.1 nur Polling...?)

Weiss nicht ob du das meinst... Einmal pro zyklus.

(05.04.2013 12:58 )Kasi schrieb:  Wie stark ist der Arbeitsspeicher während der Programmlaufzeit im Mittel beschrieben?

Marginal. Es werden etwa 60MB von 2GB verwendet.

(05.04.2013 12:58 )Kasi schrieb:  Ist genug Festplattenspeicher vorhanden? (jaja, ich weiß - nur zur Sicherheit)

Kein kommentar... ;-)

(05.04.2013 12:58 )Kasi schrieb:  Besteht die Möglichkeit, dass zusammen mit der Nutzereingabe ein "gleichzeitiger" programmseitiger Zugriff auf die Datei erfolgen kann?

Das kann man ausschliessen. Die nutzereingabe besteht eigentlich nur im "befehl" an das programm, nun auf die datei zuzugreifen.

Es wäre möglich, dass das problem hauptsächlich nach längerem ausbleiben von user interaktionen auftritt. Dann aber erst wenn der user wieder mit dem programm zu arbeiten beginnt.


Linuxx

Hallo,

mit LabVIEW6.1 wurde die Eventstruktur eingeführt...

Ansonsten kann ich auch nur sagen: zu wenig Informationen für eine ordentliche Aussage...

@Linuxx:
Ist deine Tastatur kaputt? Eine neue ist nicht teuer...

Hallo Linuxx,

mir kommt da eine Idee, die zu deiner Beschreibung, das System wäre nach einer Zeit des Hängens wieder ansprechbar, bis auf die geschlossenen TCP-Referenzen.

Kann es sein, dass während der Messung sehr viele Daten akkumuliert werden, die dann beim Druck auf den Knopf "Speichern" ggf. sehr umständlich (also zeitintensiv für LV) gespeichert werden. Dabei müsste nicht das eigentliche Speichern ein Zeitproblem darstellen - es könnte sein, dass das Händling einer ungeeigneten Datenstruktur das Problem darstellt.

Diese Begründung würde mir dann auch erklären, dass TCP-Verbindungen geschlossen werden, möglicherweise vom Sender, der seine Daten nicht mehr loswird (bestätigt bekommt), da dein Programm gerade in der Datenverarbeitungs-/speicherschleife hängt. Und es passt auch zur Korrelation mit der Testdauer. Das einzige, was nicht passt, sind die geschlossenen Exceldateireferenzen.


Gruß, Marko