LabVIEWForum.de

' schrieb:Dem ist nicht so, da bin ich auch mal drauf reingefallen.

Ich sogar mehrmals, jetzt schon wieder ..

Okay dann macht diese Einstellung keinen Unterschied für mich, aber an anderen Stellen kann ich sie sehr gut gebrauchen.

Danke für die Infos und Pfui an die LabVIEW Hilfe die mich irgendwie völlig im Stich gelassen hat.

' schrieb:Ich antworte mir mal kurz selbst in Verbindung mit einer konkreteren Frage:

Zunächst ist es möglich, den gewünschten Pfad zu einem VI über einen Eigenschaftsknoten zu erhalten. Dieser Weg ist allerdings deutlich komplexer. Das wollte ich eigentlich vermeiden, da ich mich in der Fehlerbehandlung befinde und eigentlich nur Grundfunktionen benutzen wollte, die keine neuen Fehler werfen können.

Das Problem liegt wohl an der Art der Referenz. Referenzen auf Text-Dateien behandelt die Funktion problemlos. In der Hilfe wird ja auch erwähnt, dass nur Referenzen auf Dateien erlaubt sind.

Aber was genau ist eine Dateireferenz und was ist eine Konfigurationsdateireferenz? Und worunter fallen Referenzen auf VIs?

Wenn mir da jemand ein bißchen Theorie an den Kopf schmeißen könnte, wäre ich dankbar.

Also LabVIEW verwendet für Refnums eine Technik die sie Magc Cookies nennen. Für jeden Refnum Typ wird ein sogenannter Magic Cookie Jar erzeugt. Dort werden neue interne Objekte (meist sind das dann eigentlich Pointer) überreicht und der Magic Cookie Jar gibt dann eine Refnum zurück die zum Teil aus einem Magic Value und einem Array Index besteht. Wann immer eine Funktion dann eine Refnum erhält, geht sie auf Basis des Refnum Typs den dazugehörigen Jar fragen um das zur Refnum gehörende Objekt zurückzugeben.

Das Prinzip der Magic Cookie Jars ist in LabVIEW mindestens so alt wie es auf mehreren Platformen läuft. Aber die verschiedenen Objekthierarchien sind organisch gewachsen. Zuerst waren da nur File Refnums. Die verwenden einen Cookie Jar. Dann kamen VI und Application Refnums, die verwenden einen anderen Cookie Jar. Dann kamen Netzwerk Refnums und VISA und andere IO Refnums. Die verwenden jeweils einen eigenen Cookie Jar. Zuletzt kamen die LabVIEW Objekt Refnums die die ganze interne Objekthierarchie von LabVIEW auf dem Frontpanel und dem Diagram representieren.

Die meisten Funktionen in LabVIEW (ausser den Property Nodes und Method Nodes und seit einigen Versionen auch Not A Refnum?) beschränken sich auf die Behandlung einer Sorte Refnums, d.h. es wird nur in jeweils in dem von der Funktion behandelten ookie Jar nach einer internen Referenz gesucht.

Die File Refnum nach Path Funktion ist spezifisch nur für File Refnums gültig. Und zwar könnte man natürlich argumentieren dass eine VI Refnum eigentlich auch ein File darstellt, aber es ist eine andere Refnum Sorte und die Application Refnum die in dieselbe Klasse gehört hat keinen File Pfad.

' schrieb:*smile* genau danach habe ich gearde gegoogelt um zu schaun was das genau macht. auftretende Fehler ignorieren ist ja auch nicht der weisheit letzter schluss oder?

Aber warum denn nicht!! Ein Funktionsfehler in LabVIEW ist keine Katastrophe. Das ist ganz einfach Daten. Was Du mit diesen Daten tust ist ganz dir überlassen. Manchmal sind Fehler nunmal eine ganz normale Erscheinung in einem Programm. Zum Beispiel wird es Dir wohl nie gelingen eine robuste TCP/IP Kommunikationslibrary zu programmieren wenn Du nicht ganz gezielt Fehler behandelst und manchmal auch einfach ignorierst.
Der Server der auf neue Anfragen wartet, wird nicht umhin kommen um alle bestehenden Verbindungen regelmässig mit einem sehr kleinen Timeout zu pollen um zu sehen ob neue Anfragen reinkommen. Aber normalerweise wird die entsprechende Readfunktion einen Timeout error geben. Den gilt es nun zu ignorieren da das nichts anderes bedeutet, als dass der Client im Moment keine Anfrage geschickt hat. Auch kann Read mit einem anderen Fehler zurückkommen wie etwa Connection Closed by Peer. Das kann sein weil der Client sich ohne nette Verabschiedung beendet hat, oder weil das Netzwerkkabel rausgezogen wurde. In diesem Fall muss man die Connection abschliessen und darauf warten dass sich der Client mit einer neuen Verbindung wieder anmeldet.

Gute Fehlerbehandlung ist manchmal nicht einfach nur das Durchschleifen des Error Clusters (obwohl das in vielen Fällen schon ein grosser Teil davon ist und auch viel besser ist als den Error Cluster überhaupt nicht zu verwenden) sondern kann manchmal auch das Ausführen von spezifischem Code im Fehlerfahl sein, oder das gezielte ignorieren eines bestimmten Fehlers.

In Deinem Fall kann diese Property Node eigentlich keinen Fehler zurückgeben wenn Du eine gültige VI Refnum hast und dann wäre Open VI Reference fehlgeschlagen und hättest Du ohnehin nicht soweit kommen sollen wenn Du richtiges Error Handling machst. Was allerdings passieren kann, ist dass der Pfad leer ist wenn Du eine VI Referenz auf ein VI hast dass noch nicht auf Disk geschrieben wurde.

Wegen der Fehlermeldung, die gibt es nur wenn ein Error Cluster nicht angeschlossen ist und in den VI Properties des entsprechenden VIs die Option Execution->Enable Automatic Error Handling angewählt ist. Für meine VIs schalte ich diese Option normalerweise aus, respektieve habe ich LabVIEW so konfiguriert dass es diese Option für neue VIs default disabled.

Also vorausgesetzt Du hast davor gutes Error Handling (abfangen von Fehlern in Open VI Reference) solltest Du keine Probleme haben um den Error Cluster einfach durch diese Property Node durchzuschleifen. Du könntest Dich gar dafür entscheiden für diese Node den Error bewusst zu ignorieren also keinen Error Cluster am Ausgang anzuschliessen (und zur Sicherheit die Option in den VI Properties zu disablen). Falls die Funktion selber doch mal einen Error generieren sollte würde der Pfad leer sein, aber das musst Du eigentlich sowieso abfangen, da das auch ein gültiger Pfad für dieses Property ist, wenn die VI Referenz ein VI betrifft das noch nie abgespeichert wurde.

Rolf Kalbermatter

okay, das nenn ich mal infos,.. ich werd das am montag mal so richtig verinnerlichen. für nen verkaterten samstag ist das dann doch too much!

Auf jeden Fall schon mal vielen Dank.

@Rolf: woher haste die ganzen LabVIEW internen Infos? alles Erfahrung oder gibts da auch irgendwo literatur zu?

LG
Torsten und allen ein schönes Wochenende

' schrieb:okay, das nenn ich mal infos,.. ich werd das am montag mal so richtig verinnerlichen. für nen verkaterten samstag ist das dann doch too much!

Auf jeden Fall schon mal vielen Dank.

@Rolf: woher haste die ganzen LabVIEW internen Infos? alles Erfahrung oder gibts da auch irgendwo literatur zu?

Vor allem viel Erfahrung, ich arbeite seit 1992 mit LabVIEW zuerst im technischen Support bei NI Schweiz und seit 1997 als Alliance Member. Danach habe ich in meiner Zeit bei NI die Gelegenheit gehabt um einen Blick hinter die Kulissen von LabVIEW zu werfen und zwischen meiner Zeit bei NI und bevor ich bei meinem heutigen Arbeitgeber CIT Engineering anfing, hatte ich einiges an Zeit die ich dazu verwendete um mittels verschiedener Techniken auch die Dinge in LabVIEW zu ergründen die von NI nicht wirklich dokumentiert werden. Damals durfte man das noch :-)

Das hat mir alles einige Einblicke in LabVIEW gegeben, die soweit gingen dass ich eine LLB Viewer Shell Extension für Windows schreiben konnte und diese Idee wurde dann in LabVIEW 6 durch NI aufgegriffen aber ist inzwischen durch NI wieder fallen gelassen worden und an Stelle davon wird in LabVIEW der File Manager geöffnet ;-).

Rolf Kalbermatter

okay,.. das erklärt einiges,.. spannende karriere. danke dass du uns dran teil haben lässt.

Wußte ich doch, das Rolf wieder Hintergrundinfos zu diesem Thema hat.

Wie üblich, vielen Dank für die Insights.

Gruß, Jens