LabVIEW bleibt in der Ausführung stehen

Hallo Allerseits

Ich habe eine Anlagensteuerung programmiert und die läuft und funktioniert soweit ganz gut.
Ich habe nur ein großes Problem. In unregelmäßigen Abständen bleibt das Programm einfach stehen.
Das passiert meist dann, wenn keiner am PC ist oder wenn man in ein anderes Programm wechselt.
Aber sobald ich mir mein Programm wieder anschaue (d.h. mal auf das Fenster klicke) läuft es weiter, als ob nichts gewesen wäre. Ich verwende mehrere While-Schleifen (5) nebeneinander, die über lokale Variablen miteinander verbunden sind. In 2 Schleifen erfolgen Hardwarezugriffe über AktiveX und RS232. Das Programm kann über Stunden stabil laufen und dann im nächsten Moment bleibt es stehen. Es scheinen alle Schleifen stehen zu bleiben.

Weiß vielleicht jemand woran das hängen könnte? Ähnliche Erfahrungen?
Ich verwende LabVIEW 7.1

Als erstes beobachte die CPU Auslastung (mit Windows Task Manager). 5 parallele While-Schleifen und lokale Variablen passt irgendwie nicht zusammen, aber na ja, jeder hat seinen eigenen Programmierstil.
Dein Problem kann viele Quellen haben. Du musst das Programm halt debuggen und besonders die Race-Conditions überprüfen.

eg

In meiner Steuerung habe ich 2 Prozesse, die mit unterschiedlicher Geschwindigkeit ablaufen (2 Schleifen).

Eine Schleife habe ich, um ein Versuchsprogramm einzulesen und zu bearbeiten, um die Daten dann in die 2 Schleifen oben über lokale Variablen zuzuweisen.

2 Schleifen habe ich zum Abspeichern der Istwerte (unterschiedliche Taktung).

Die extra Schleifen habe ich gemacht, dass die 2 Hauptschleifen durch Dateidialoge und manuelle Eingaben in ihrem Fluss nicht unterbrochen werden.

Die CPU-Auslastung liegt im Normalfall bei maximal 65% wobei LabVIEW nur 5% (im RAM 46MB) in Anspruch nimmt (der Rest sind ander Programme) . Das Debugen ist etwas schwierig, weil der Fehler immer dann auftritt, wenn ich nicht im Programm selber bin, wenn das Programm wieder den Fokus bekommt läuft es normal weiter.

Ich habe mal das Programm angehängt. Ihr werdet mich schlagen, aber ich habe es nicht abgespeckt, weil ich ja nicht weiß wo der Fehler liegen könnte. Schaut euch bitte mal die Struktur an, ob die ok ist.
Ich programmiere auf LabVIEW erst seit etwa 3 Monaten, habe aber lange Erfahrung mit anderen Programmiersprachen.
Ich habe momentan eine Version am Laufen, in der ich nochmal eine vollkommen unabhängige Schleife eingebaut habe, die mir die aktuelle Systemzeit in eine Datei schreibt. soweit ich weiß, müsste die ja dann unabhängig von den anderen Schleifen laufen, aber selbst die bleibt stehen.

(VIs LV 7.1)

Uff, ich habe etwas schlimmeres erwartet, es sieht aber ok aus. Nur sehe ich deine Schleifen nicht. Ich habe Versuchsprogramm.vi geöffnet.

eg

Oh, sorry

Das Schlimmere befindet sich unter Hauptpanel.

Ich hatte vorhin wieder ein Stillstand. War 30 min in der Mittagspause, das LabVIEW lief dann noch etwa 4 min und ist dann stehen geblieben. CPU-Auslastung von LabVIEW 0%. Die anderen Programme und der Taskmanager (war im Vordergrund) sind ohne Probleme weitergelaufen. Dann die Maus angeschuppst und LabVIEW lief wieder. Die Energiesparfunktionen sind ausgeschaltet.

' schrieb:Ich hatte vorhin wieder ein Stillstand. War 30 min in der Mittagspause, das LabVIEW lief dann noch etwa 4 min und ist dann stehen geblieben. CPU-Auslastung von LabVIEW 0%.

Ich hab mir's noch nicht angekuckt, wage aber trotzdem einen Versuch: In den While-Schleifen der Blockdiagramme fehlt eine Wartezeit oder ist zu klein - daraufhin wird das Frontpanel nicht mehr refreshed.

' schrieb:Ich hab mir's noch nicht angekuckt, wage aber trotzdem einen Versuch: In den While-Schleifen der Blockdiagramme fehlt eine Wartezeit oder ist zu klein - daraufhin wird das Frontpanel nicht mehr refreshed.

Ich hatte das ganze vorher mit Zeitgesteuerten Schleifen programmiert. Da lief es auch nicht. Hatte früher mal, dass die Ausführung zu lange gedauert hatte (lag an der Kommunikationsgeschwindigkeit mit der Hardware), da hat er die Zyklenzeit von 5 auf 10 Sek. verdoppelt und dann lief es weiter. Ich bau nochmal das ganze in Zeitgesteuerte Schleifen und überprüfe nochmal die Ausführungsdauer.

Hab ich gemacht...
Bei einer äußeren Schleife von 5000ms braucht der innere Code in der großen Schleife etwa 4200ms. Wenn der Code länger braucht (zb durch zusätzliche Wartezeit) verlängert er um die nächste Schleifenzeit. D.h. damit es zum Stillstand kommt, muss der Programmfluss irgendwo fest stecken bleiben, was aber wiederum seltsam wäre, wenn die Blockade durch Mausbewegung wieder gelöst werden würde....

Mal ein paar generelle Punkte (die dir sicher auch schon klar sind):

1. Räum dein BD mal auf: zu groß, zu viele nicht gerade gezogene Linien, zu unübersichtlich.
2. Du macht sehr starken Gebrauch von Build-Array-Aufrufen, teilweise vollkommen unnötig. z.B. hier:
   
Hier kann ich einfach nicht nachvollziehen, wieso du deine Zeiten in einem 2D-Array speicherst?:hmmu stapelst hier völlig unnötig Informationen auf.
3. Express-VI's sind langsam!!! Wieso 2D-Arrays erst transponieren, dann an dieses "Convert to Dynamic Data"-Express VI übergeben (indem du gleich Spalten anstatt Reihen auswählen könntest) und dann an Express-XY übergeben? So als Anregung, geht auch so:
   
Das obere 1D-Array ist dabei ein nun nur noch 1-dimensionales Zeitarray.
4. Nochmal zurück zu Build-Array: Wie groß werden denn so deine Arrays? Bei wirklich sehr vielen Aufrufen wird der Speicher immer mehr zerlegt, da jeder Build-Array-Aufruf zu einer neuen Speicher-Allozierung führt.

So, mehr Lust habe ich nicht, mich durch dein Haupt-VI zu wühlen.

MfG, Jens

Die FP Updates sind unabhaengig von der Schleifeniterationszeit und der Prioritaet des VIs unter Windows, somit ist das sicherlich unabhaengig von den Aussetzern.
Ein Speicherproblem ist es auch nicht, weil LabVIEW nach 2GB kontinuierlich allokiertem Speicher mit der Fehlermeldung "Memory Full" aussteigt.

Was machst du mit dem ActiveX Zeugs?
Wenn du mit der Maus klickst -> klickst du in eine LabVIEW Oberflaeche oder klickst du außerhalb (das macht einen Unterschied)
Wenn in der obere Frage mit "LabVIEW" beantwortet werden kann, dann versuche folgendes:
Nachdem du "vorbildlich" den ErrorCluster nicht konsequent durchgezogen hast, koenntest du die Initialisierung von ActiveX gegen eine DummyRef austauschen, sodass die Funktionen mit ActiveX mit Sicherheit nicht ausgefuehrt werden. Wenn LabVIEW nach X Stunden noch immer laeuft, ist mit Sicherheit die ActiveX Ref das Problem

Wenn die Frage mit dem Mausklick mit "Windows" beantwortet wird, dann liegt es wohl an der ActiveX Klasse, dass diese net klar kommt wenn der User pennt. Die einfachste Abhilfe waere mittels der WindowsDLL Library alle X Minuten einen Mouse Event auszuloesen...

Ja, jetzt hab ich mir's auch angekuckt.

Ich selbst bin ja nun nicht gerade ein Kind von Traurigkeit - was die Blockdiagrammgröße betrifft. Auch bei der Anzahl lokaler Variablen, While-Schleifen und was es sonst noch alles Gutes und Schönes gibt (sprich: was man nicht machen soll: DF ignorieren), bin ich eher großzügig. :PAber was ich hier gesehen habe, ist selbst mir zu viel.

Ich würde hier die Ratschläge von Jens G. beherzigen. Bezüglich der "Aussetzer" hat wohl freedive mit den ActiveX recht (eigentlich kenne ich mich da allerdings überhaupt nicht aus).