Fehlersuche in App

Hallo zusammen,

ich habe verschiedene LV-Projekte von LV2012 auf LV2014 umgestellt. Aus den Projeken baue ich Applikationen, die dann auf anderen Rechnern zum Einsatz kommen.
Nun habe ich das Problem, dass wenn ich die Applikation mittels "Fehlersuche in Anwendung oder DLL" laufen lasse, diese nach kurzer Zeit mit "Fehler1: Ungültige Referenz" abbricht. Dabei ist es egal, ob ich die Fehlersuche auf dem selben PC starte, auf dem die Applikation läuft, oder über das Netzwerk von einem anderen PC. Starte ich die Applikation ohne Fehlersuche läuft sie fehlerfrei zu Ende.
Muss ich in der Build-Spezifikation durch die Umstellung auf LV2014 etwas ändern?

Gruß und Danke für Hilfe
Ingo

Anzeige

Hallo Ingo,

Zitat:Muss ich in der Build-Spezifikation durch die Umstellung auf LV2014 etwas ändern?

Wahrscheinlich nicht, denn deine EXE scheint ja bei ausgeschaltetem Debugging wunderbar zu funktionieren!

Was bei solchen Sachen helfen könnte ist das Finden der exakten Abbruchstelle. Von dort dann schauen, warum dieser Fehler erzeugt wird…

Danke für die Antwort,

die EXE ist ein Teil eines komplexen Testsystems. Wie es den Anschein hat, taucht der Fehler das erste mal auf, wenn ein Sub-VI über dessen VI-Referenz und Methodenknoten als Background-Thread gestartet wird. Bei jedem weiteren Start der EXE kommt Fehler1 beim ersten Methoden- bzw. Eigenschaftsknoten innerhalb der EXE. Ich habe schon versucht, das Background-VI in einer parallelen While-Schleife laufen zu lassen. --> Leider ohne Erfolg.
In der LV-Hilfe habe ich gelesen, dass es wohl Probleme mit Eigenschaftsknoten bei Boolschen Werten gibt und wie in der Hilfe vorgeschlagen, alle Boolschen Anzeige- und Bedienelemente in Typdefinitionen umgewandelt. --> Leider ohne Erfolg.

Ingo

Bricht eigentlich das Remote-Debugging mit Fehler 1 ab oder deine Anwendung?
Auf welche Probleme bezieht sich eigentlich deine Aussage mit Boolschen Elemente und Eigenschaftsknoten?
Hast du ggf. einen Screenshot oder sogar Quellcode an dem man den Fehler genauer sehen kann?
Aus deinen bisherigen Ausführungen wird mir leider nicht klar was überhaupt nicht funktioniert.

Hallo Holy,

>> Bricht eigentlich das Remote-Debugging mit Fehler 1 ab oder deine Anwendung?

Der Fehler tritt in der Anwendung auf und zwar beim ersten Start des Debuggings hier:

   

Bei jedem weiteren Start tritt der Fehler hier auf:

   

Bei einer tieferen Untersuchung zeigt sich, das der Fehler beim ersten mal hier auftritt:

   

Dieses Sub-VI wird aus einem VI aufgerufen, welches im Hintergrund als paralleler Thread läuft. Gestartet wird es so:

   


>> Auf welche Probleme bezieht sich eigentlich deine Aussage mit Boolschen Elemente und Eigenschaftsknoten?

Bezieht sich auf die LabView-Hilfe --> Upgrade auf LabView2014 --> Hinweise zur Kompatibilität beim Upgrade

Änderungen an den Eigenschaften "Wert" und "Wert (signalisierend)"

Beim Festlegen des Werts eines booleschen Elements mit Latch-Funktion mit der Eigenschaft "Wert" oder "Wert (signalisierend)" wird in LabVIEW 2012 und älteren LabVIEW-Versionen eine Fehlermeldung ausgegeben. Wenn Sie jedoch das boolesche Element mit Latch-Funktion in eine Typdefinition umwandeln, erscheint keine Fehlermeldung. Um in LabVIEW 2013 Laufzeitprobleme zu vermeiden, wird beim Festlegen des Werts eines booleschen Elements mit Latch-Funktion mit Hilfe der Eigenschaften "Wert" oder "Wert (signalisierend)" immer eine Fehlermeldung ausgegeben.

>> Hast du ggf. einen Screenshot oder sogar Quellcode an dem man den Fehler genauer sehen kann?

siehe oben

>> Aus deinen bisherigen Ausführungen wird mir leider nicht klar was überhaupt nicht funktioniert.

Läuft die Anwendung ganz regulär, gibt es keine Probleme. Nur wenn Ich die Anwendung über Fehlersuche laufen lasse, dann treten die oben gezeigten Probleme auf. Ab und an bin ich aber auf die Fehlersuche angewiesen und es wäre schön wenn man das irgendwie fixen kann.

(03.03.2015 09:27 )Ingo Grüninger schrieb:  Bei einer tieferen Untersuchung zeigt sich, das der Fehler beim ersten mal hier auftritt:



Dieses Sub-VI wird aus einem VI aufgerufen, welches im Hintergrund als paralleler Thread läuft. Gestartet wird es so:

Bist Du Dir sicher dass dieser paralelle Thread sich zu keinem einzigen Zeitpunkt beenden kann (um dann vielleicht wieder irgendwie gestartet zu werden). Alle LabVIEW refnums (mit Ausnahme der VISA refnums wenn das so in den Optionen gewählt wird) werden automatisch geschlossen in dem Moment wo die Top Level Komponente unter der die Refnum geöffnet wurde Idle wird (die Ausführung beendet). Top Level VIs sind all VIs die nicht als SubVIs in einer LabVIEW Hierarchy anwesend sind, das schliesst auch VIs ein die mit der RunVI Methode gestartet wurden und sogar die meisten Asynchronous Calls.

Anzeige

Hallo rolfk,

ja, ich bin mir sicher, dass der parallele Thread nicht vorzeitig beendet wird. Wie schon beschrieben gab es bei LabView2012 oder im regulären Ablauf nie Probleme damit.

Ich habe das Sub-VI in mein Main-VI mit eingefügt (also ein wenig umgebaut und auf das Starten im Hintergrund verzichtet) und jetzt funktioniert die Fehlersuche wieder. Das Problem liegt also an der Übergabe der Referenzen beim Start als paralleler Thread (vierter Screenshot in meiner letzten Antwort).

Für mich ist das Problem gelöst und man könnte den Thread hier schließen, aber verstehen würde ich es trotzdem gerne, warum der Start bei LV2012 noch funktioniert hat und bei LV2014 nicht mehr, bzw. was sich in der Fehlersuche geändert hat, weil es ja im regulären Ablauf problemlos funktioniert.

(03.03.2015 11:10 )Ingo Grüninger schrieb:  Für mich ist das Problem gelöst und man könnte den Thread hier schließen, aber verstehen würde ich es trotzdem gerne, warum der Start bei LV2012 noch funktioniert hat und bei LV2014 nicht mehr, bzw. was sich in der Fehlersuche geändert hat, weil es ja im regulären Ablauf problemlos funktioniert.

, aber dann würde ich das einmal als Bug-Meldung an NI weitergeben!

Gruß, Jens

Der Fehler 1 aus einem direkt verlinkten Eigenschaftsknoten erscheint mir äußerst suspekt. Wie ist die genaue Fehlermeldung? Bei einem solchen Knoten wüsste ich jetzt eigentlich nicht was für eine ungültige Referenz auftreten kann.

Zu deinem Versuch mit dem Boolschen Eingabeelementen und Setzen des Wertes per Eigenschaftsknoten. In diesem Fall wird nicht Fehler 1 sondern 1193 geworfen, daher war mir unklar warum du das versucht hattest. Daher meine Nachfrage nach dem Zusammenhang.

Ich konnte dieses Problem jetzt auch nicht prinzipiell mit einer Minimalanwendung per Remotedebug reproduzieren. Eine Bugmeldung an NI ist evtl. eine Variante aber ich vermuten die Reproduzierbarkeit dürfte wohl etwas schwieriger werden.