Absturz beim Aufruf eines SubVIs

Guten Morgen zusammen,

ich weiß, ich kann euch nicht viel Input liefern (scheiß Datenschutz und co). Aber Das Problem ist ohnehin nicht gut zum testen. Trotzdem ein kurzer Abriß zur Programmstruktur:

In meinem Projekt läuft ein Main VI in dem diverse SubVIs aufgerufen werden, die jeweils eine Schleife enthalten. Unter anderem werden dadurch folgende Aufagben erledigt:
- Kommunikation mit der Hardware
- Logging
- Berechnung von Stellwerten
- UserEvents
- usw.
Die Kommunikation der einzelnen Schleifen läuft über globale Variablen. Z.B. "Kommunikation" liest Daten ein und schreibt sie in eine Variable. "Logging" liest die Variable aus und schreibt die Daten in eine Datei. Das funktioniert soweit alles genau so wie es soll. Nach ca. 2 Stunden bleibt allerdings die Kommunikations-Schleife hängen. Alles andere läuft noch weiter (Auch die GUI ist noch ansprechbar und alle Funktionen machen, was sie sollen). Es wird kein Fehler ausgegeben.
Wenn ich nach Absturz im entsprechenden SubVI die Highlight-Funktion zum Debuggen aktiviere, sehe ich, dass immer ein bestimmtes SubVI aktiv ist (grüne Pfeile auf dem SubVI-Symbol). Schaue ich nun in dieses Sub(sub)VI rein, hängt dieses im Status "Wartet auf Ausführung". Es bleibt also irgendwo zwischen Aufruf und beginn der Ausführung hängen.

Sorry, dass ich nicht mehr Input liefern kann, aber vielleicht weiß ja jemand, wie sowas zustande kommen kann. Bin für jeden Tipp dankbar.

Vorab schon mal vielen Dank,
Totti

P.S.: Das SubVI ist Teil unserer hauseigenen Bib und ist an vielen anderen Prüfständen im Dauereinsatz!

Anzeige

Ist da evtl. ne Queue vollgelaufen und es ginge erst weiter, wenn was entnommen wird?

A.

Keine Queues, Melder/Rendevouz oder Ähnliches. Alle Unterfunktionen haben zwar waits und timeouts aber ich habe das grade mal aufsummiert und es müsste nach ca. 10 Sekunden weiter laufen. Damit es dazu kommt müssten allerdings sämtliche Verbindungsversuche (TCP/IP) schief gehen. Desweiteren habe ich grade auch geschaut, ob irgendwelche Referezen offen bleiben und den Speicher sprengen. Der LabVIEW-Prozess braucht laut Taskmanager zwar relativ viel, bleibt aber konstant bei ca. 230.000 K.

Hi

Hat das SubVi evtl eine Timed-Loop? Ich hatte mal das Problem mal das sich mehrere Timed Loops in einem Projekt nicht vertragen haben... ich habe denen dann jeweils einen anderen Namen gegeben dann gings... bis ich die ganz entfernt habe ....

T

Kannste mal nen Screenshot posten? Oder evtl. doch das VI? Evtl. abgespeckt? Kannst das abgespeckte VI ja auch selbst mal testen...

Soooo geheim wirds schon nicht sein, oder?

Auf dem Screenshot den ich posten dürfte siehste auch nix weiter, als ein Haufen SubVIs die der Reihe nach mit dem Errorcluster verbunden sind und aus einer Variable (Cluster) mit Daten gefüttert werden.

Welche Art von Test schwebt dir vor? Was kann ich testen? Wenn ich die Kommunikation alleine teste, läuft sie. Aber da das Problem erst nach ca. 2h auftritt, ist das mit dem Testen auch so ne Sache!

Was würdest du für einen Test vorschlagen?

Anzeige

(28.05.2013 09:56 )TSchAC schrieb:  Wenn ich die Kommunikation alleine teste, läuft sie. Aber da das Problem erst nach ca. 2h auftritt, ist das mit dem Testen auch so ne Sache!

Ach so...aber alles deutet darauf hin, dass irgendwo was überläuft. Mehr fällt mir dazu nicht ein...

Hallo,
Tipp1 : Desktop Execution Trace Toolkit for Windows
Tipp2 : Um die TimedLoop auszuschließen - umwandeln in While.

Gruß
Ralf

Das Toolkit ist mir ehrlich gesagt zu teuer oder steckt es irgendwo in meiner Lizenz schon drin?
-> Das prüfe ich später mal nach!

Sind TimedLoops denn so anfällig? Habe da bisher gute Erfahrungen mit gemacht! Alternativ jede TimedLoop durch eine While-Schleife ersetzen und manuell ums Timing kümmern? Sprich "Warten auf Vielfaches von Xms" verweden?

Bin ehrlich gesagt bissl überfragt, was noch so überlaufen könnte? Der Speicher sieht wirklich stabil aus! Schwankt um +/-5K. ASCII-Dateien die ich verwende erreichen ne maximale Größe von knapp 3MB.

Vielleicht sollte ich mal alles kompilieren und schauen was in der Runtime so passiert. bisher läuft alles noch in der Entwicklungsumgebung.

Ach man, bis zu dem Fehler war alles soooo schön!

(28.05.2013 13:49 )TSchAC schrieb:  Bin ehrlich gesagt bissl überfragt, was noch so überlaufen könnte? Der Speicher sieht wirklich stabil aus!

Hm...wie ich anfangs schon mal erwähnt habe...evtl. ist ein ÜBERlauf nicht das Problem, sondern ein "VOLLlauf", d.h. ein reservierter Speicherbereich ist belegt und es geht erst weiter, wenn mal wieder was abgeholt wird.


A.