(24.05.2016 22:14 )jg schrieb: [ -> ]Edit: Tritt der Fehler mit dem 2. Case auch bei der Variante mit einer Refnum, so wie du es gepostet hast, auf? Anderenfalls wird es dringend Zeit, dass du ein VI hochlädst, welches näher an deiner wahren Umsetzung ist.
So ein VI gibt es nicht, das hochgeladene VI ist die Grundlage weiterer Arbeiten und enthält genau die Stelle wo ich mit meinen LV-Kenntnissen nicht mehr weiter komme.
Noch einmal zur Erklärung, der Case "Init" läuft ohne Probleme, "id02" fragt die Maschinennummer des Klimaschrankes ab und gibt auch den korrekten Wert zurück, mit "id05?" die Projektnummer. Die führende Null zeigt den Fehlerstatus "kein Fehler" der Klimakammer. In diesem Case kann ich auch, nach der Portinitialisierung, 10x schreiben/lesen ausführen und alles läuft.
Egal, wie ich die Connection-Id in den "lesen"-Case übergebe, ich bekomme sofort den Fehler. Ursprünglich war die Id in einem Variant, weitere Übergabeversuche waren lokale Variable und Eigenschaftsknoten und diese Varianten noch in Clustern oder Array versteckt. Das Ergebnis bleibt gleich.
(25.05.2016 06:53 )Woodeye schrieb: [ -> ]Egal, wie ich die Connection-Id in den "lesen"-Case übergebe, ich bekomme sofort den Fehler.
Was passiert denn bei "Ausführungssystem = Wie Aufrufer"?
Entschuldigung bitte, diese Einstellung steht normalerweise auf "wie Aufrufer", ich hatte dort auch verschiedene Einstellungen probiert und diese Einstellung nicht zurückgenommen.
(25.05.2016 09:47 )Woodeye schrieb: [ -> ]Entschuldigung bitte, diese Einstellung steht normalerweise auf "wie Aufrufer", ich hatte dort auch verschiedene Einstellungen probiert und diese Einstellung nicht zurückgenommen.
Wenn ich dein Forum.vi runterlade und mit 2015 öffne, steht "Instrumenten-IO" drin.
Ich glaube, die Timeout-Zeit von 1 Sekunde ist viel zu kurz.
Außerdem besteht die Möglichkeit, dass die Verbindungs-ID nach beim Restart des VIs noch vorhanden ist, aber die Verbindung im OS nicht mehr. Wenn ich alle drei Cases in einem VI-Aufruf (mit Localhost und aufsteigenden Ports) mache, kommt der Fehler nicht.
Lad doch auch mal bitte ein übergeordnetes VI hoch, in dem du dein "Forum.vi" verwendest! Oder rufst du das immer manuell auf? Sprich erst Befehlsart auswählen, dann Start-Button in der Taskleiste drücken? Dann ist klar, dass der "Lesen"-Case nicht funktioniert!!! Nach Beendigung des VI ist die TCP-Refnum ungültig!
Gruß, Jens
Hallo Jens,
jetzt hast du wahrscheinlich die Lösung entdeckt, das "Forum.vi" wird immer wieder geschlossen! Ebenso, wie ich bis jetzt FGVs verwendet habe. Im Init des Main.vi wird das Forum.vi geöffnet, der Schrank initialisiert und dann wieder geschlossen. An einer ganz anderen Stelle des Main.vi soll die aktuelle Schranktemperatur abgefragt werden, dazu öffne ich das Forum.vi erneut und wollte mit der vorherigen Refnum nur die Temperatur abfragen (Lesen_Case), ohne ein neues Init.
Die Abarbeitung im Main.vi und auch per Hand geschieht also wie von dir beschrieben, Befehl einstellen >Run, nächsten Befehl einstellen >erneuter Run. Wenn durch den FGV Neustart die Refnum nicht mehr stimmt, ist mein Fehler sicherlich erkannt. Ich muss also die Netzwerk-IP übernehmen und die Verbindung immer wieder neu initialisieren.
Habt vielen Dank für Eure Hilfe.
Was verstehst du unter aufgerufen und wieder geschlossen? Wenn du das richtig verwendest, dann funktioniert das schon mit FGV und Speichern der geöffneten Verbindung im Schieberegister.
Gruß, Jens
Das war aber eine schwere Geburt! Ich habe noch kurz vor Feierabend einen Test mit deinem Vorschlag gemacht und siehe da es funktioniert. Ich kann mein ursprüngliches VI wahrscheinlich unverändert übernehmen, da das Forum.Vi grundsätzlich gleich funktioniert.
Das es zwischen den Ausführenknopf und dem softwaremäßigen Aufruf eines VIs einen derartigen Unterschied gibt, war mir bis heute nicht bewusst.
Jens, vielen Dank noch einmal für deine Geduld und Hilfe.
(25.05.2016 19:58 )Woodeye schrieb: [ -> ]Das es zwischen den Ausführenknopf und dem softwaremäßigen Aufruf eines VIs einen derartigen Unterschied gibt, war mir bis heute nicht bewusst.
Wie du jetzt erkannt hast, gibt es da sehr wohl einen wichtigen Unterschied. Beim manuellen Start über den Ausführungsknopf werden Hardware-Resourcen, DLLs, Refnums wie z.B. FileIO oder TCP nur solange reserviert, wie das VI selber läuft. Beim zweiten Aufruf in einem anderen Case, bei dem die Initialisierung der Resource fehlt, kommt es dann zu einem Fehler. Bei VISA und COM-Schnittstelle war dir das vielleicht nicht aufgefallen, da ein VISA-Read/Write implizit ein möglicherweise notwendiges VISA-Open selber durchführt. Anders bei Aufruf als SubVI, da wird erst am Ende des Prozesses (also des Main-VI) eine mglw. nicht geschlossene Resource wieder freigegeben.
Gruß, Jens
(25.05.2016 06:53 )Woodeye schrieb: [ -> ] (24.05.2016 22:14 )jg schrieb: [ -> ]Edit: Tritt der Fehler mit dem 2. Case auch bei der Variante mit einer Refnum, so wie du es gepostet hast, auf? Anderenfalls wird es dringend Zeit, dass du ein VI hochlädst, welches näher an deiner wahren Umsetzung ist.
So ein VI gibt es nicht, das hochgeladene VI ist die Grundlage weiterer Arbeiten und enthält genau die Stelle wo ich mit meinen LV-Kenntnissen nicht mehr weiter komme.
Noch einmal zur Erklärung, der Case "Init" läuft ohne Probleme, "id02" fragt die Maschinennummer des Klimaschrankes ab und gibt auch den korrekten Wert zurück, mit "id05?" die Projektnummer. Die führende Null zeigt den Fehlerstatus "kein Fehler" der Klimakammer. In diesem Case kann ich auch, nach der Portinitialisierung, 10x schreiben/lesen ausführen und alles läuft.
Egal, wie ich die Connection-Id in den "lesen"-Case übergebe, ich bekomme sofort den Fehler. Ursprünglich war die Id in einem Variant, weitere Übergabeversuche waren lokale Variable und Eigenschaftsknoten und diese Varianten noch in Clustern oder Array versteckt. Das Ergebnis bleibt gleich.
Fehler 1 besagt dass ein Parameter (und das ist bei TCP-IP meist die Connection ID) nicht gültig ist. Kann es sein dass Du die Init Methode Deiner FGV in einer anderen VI Hierarchy aufrufst dann die anderen Methoden. Denn LabVIEW Refnums werden automatisch garbagecollected wenn das Toplevel-VI in wessen Hierarchy die Open Funktion aufgerufen wurde Idle wird. Das kann sehr einfach geschehen wenn Du zum Beispiel ein Startup-VI hast das die Init Methode aufruft und dann mit Run VI das eigentliche Haupt-VI als zweite Hierarchy started und sich selber dann beendet. Diese Garbagecollection kann für VISA Referenzen in den LabVIEW Optionen ausgeschaltet werden aber das gilt nicht für alle anderen Referenzen in LabVIEW.
Zudem gibt es Schiebergister in Schleifen. Das ist die bessere Art um Daten zwischen verschiedenen Methoden Deines FGVs zu teilen. Verwendung eines ValueProperty Nodes ist hässlich, ineffizient und undurchsichtig.