Wie funktioniert Einbindung eines dynamischen VIs in eine EXE wirklich?

Obwohl,.... Ich kapiere noch nicht ganz, wieso ich dann in Bsp. 4 den Pfad so exakt angeben muss........ Das müsste doch dann auch richtig in die EXE mit kompiliert werden. Bei den anderen beiden Bsp. sind die VIs doch auch durch die EXE im Speicher, d.h. der Pfad wurde automatisch angelegt.

Gruß Markus

' schrieb:Ich auch.

Gruß Markus

' schrieb:Ich kapiere noch nicht ganz, wieso ich dann in Bsp. 4 den Pfad so exakt angeben muss........ Das müsste doch dann auch richtig in die EXE mit kompiliert werden.

Im Bild in Beitrag 4 ist es ja eben so gewollt, dass das VI tatsächlich erst genau zu dem Zeitpunkt geladen wird, wenn der Eigenschaftsknoten (Methodenknoten?) abgearbeitet werden soll.

Ein applikationsspezifischer Ablauf könnte so sein: Programm fragt Benutzer, wo denn ein VI zu finden ist, das jetzt gleich abgearbeitet werden soll. Das VI kann z.B. eines sein zur Berechnung einer Passwortes. Der Benutzer sagt dem Programm dann: benutze jetzt genau dieses eine VI, das du in dieser Library findest. Dann holt sich das Programm (respektive die RT-Umgebung) erst die Library (LoadLibrary) und dann aus dieser Library die Referenz auf das gewünschte VI. Da der Benutzer erst zur Laufzeit festlegt, welches VI verwendet werden soll, kann es zur Kompilierzeit nicht eingebunden werden. So ein Verfahren müsste mal halt anwenden, wenn der Kunde das Verschlüsselungs-VI einfach nicht herausgeben will.

Danke Euch für die Infos.
Jetzt ist mir manches klarer geworden, auch wenn ich es noch nicht 100 % kapiert habe, aber die Hauptsache ist, man weiß, wie man es anwenden muss.

Gruß Markus

' schrieb:Eine LV-EXE ist eigentlich eine erweiterte LLB. Du kannst deine.exe in deine.llb umbennen und mit LV die LLB öffnen.

zur Info:
Da ich im Moment alles von 7.1 auf 8.2.1 konvertiere (wegen Vista), habe ich bemerkt, dass das in 8.2.1 nicht mehr geht.

' schrieb:So genau weiß ich das auch nicht. Aber:

Es gibt solche dynamische und solche. Die einen, siehe dein rechtes Bild oben, werden per "Always included" eingebunden und sind daher praktisch ohne Pfad aufrufbar. Solche VIs sind eigenlich nicht richtig dynamisch. Dynamisch sind sie eigentlich nur deswegen, weil sie applikationsspezifisch explizit über "VI-Server" (für SubPanel etc.) aufgerufen werden. Solche VI's werden zur Kompilierzeit eingebunden.

Dann gibt es aber auch solche dynamische VIs, die tatsächlich erst dann eingebunden werden, wenn sie im Programmablauf eben genau jetzt aufgerufen werden sollen. Solche VI's werden dann zur Kompilierzeit eben nicht eingebunden. Dann aber ist der Pfad wichtig. Für was man dieser Verfahrten braucht, weiß ich jetzt nicht. Ich hab sowas noch nie gebraucht.

Für DLL's in C++/Delphi gilt ähnliches: Linken zur Programmstartzeit und Linken per Programmbefehl LoadLibrary.
Ich glaube wir warten mal auf RolfK.

Also das Ganze ist nicht so komplex. Wenn die Open VI Reference Funktion ausgeführt wird macht sie ungefähr folgendes:

Wenn der VI Name nur ein String ist:

1) Schauen im Speicher ob so ein VI schon geladen ist.
2) Schauen im EXE ob da ein solches VI besteht
3) Schauen im Search Path (normalerwise leer in einer Build App aber man kann die entsprechenden INI keys in das zugehörige INI File tun).

Wenn's dann noch nicht geht dann gibts halt einen Error.

Wenn der VI name ein Path ist:

1) Für absolute Pfade zuerst mal schauen ob das VI am ensprechenden Ort liegt.
2) das selbe tun was bei einem String Namen passiert wobei der Filename ohne Pfad als Suchkriterium gilt.

Und jetzt kommts:

In LabVIEW 8.5 bekommt man einen ganz spezifischen Fehler wenn man einen Pfad benützt während das VI schon im Speicher ist. Der Fehler besagt dass es nicht mehr zulässig ist ein VI mit Pfad zu laden wenn es schon im Speicher anwesend ist. Ich denke mal dass das ein Feature ist das hinzugefügt wurde um das Crosslinking in LabVIEW schwerer zu machen und als Hilfe für das entsprechende neue Tool in LabVIEW 8.5 um das Auflösen solcher Crosslinks zu erleichtern.

Rolf Kalbermatter

Wenn ich aber bei dem Bsp. in Beitrag 4 nicht den richtigen Pfad angebe, klappt es nicht.
Darum habe ich ja die Cases für Entwicklungsumgebung und für die EXE.
Wie ich Dich verstanden habe, müsste LabVIEW doch einfach suchen.

Gruß Markus

Anzeige

' schrieb:Wenn ich aber bei dem Bsp. in Beitrag 4 nicht den richtigen Pfad angebe, klappt es nicht.
Darum habe ich ja die Cases für Entwicklungsumgebung und für die EXE.
Wie ich Dich verstanden habe, müsste LabVIEW doch einfach suchen.

Gruß Markus

Wenn ich das Problem von Dir richtig verstanden habe, vor 8.5 ja, jetzt aber nicht mehr.

Rolf Kalbermatter

Musste ich vor 8.5 richtig anschließen und jetzt nicht mehr, oder was meinst Du?

Gruß Markus

' schrieb:Wenn ich das Problem von Dir richtig verstanden habe, vor 8.5 ja, jetzt aber nicht mehr.

Rolf Kalbermatter

' schrieb:Musste ich vor 8.5 richtig anschließen und jetzt nicht mehr, oder was meinst Du?

Gruß Markus

Andersum! Ein Kollege von mir der das LuaVIEW Toolkit entwickelt hat, hatte damit Probleme. Dort werden teilweise Hintergrundtasks dynamisch geladen. Im Entwicklungssystem ist das kein Problem da die VIs physisch auf der Disk sind von wo sie auch per Pfad geladen werden. In einem Executable gings aber nur wenn statt einem Pfad nur der VI Name als String angegeben wurde, da 8.5 sich weigert VIs von anderswo auf der Disk (hier innerhalb der LLB im EXE) zu laden dann was der Pfad angibt. In dieser Hinsicht ist es wahrscheinlich auch nicht mehr einfach wahr, dass bei Übergabe eines absoluten Pfades und wenn das VI dort nicht wirklich besteht, die Searchpaths automatisch durchforstet werden.

Und die andere Differenz ist dass wenn Du ein VI in 8.5 per Pfad laden willst das schon im Speicher ist, dies nur funktioniert wenn der angegebene Pfad mit dem wirklichen Pfad des bereits geladenen VIs übereinstimmt.

Rolf Kalbermattter

Alles klar. Jetzt hab' ich's kapiert.
Vielen Dank für die Infos.

Gruß Markus

' schrieb:Andersum! Ein Kollege von mir der das LuaVIEW Toolkit entwickelt hat, hatte damit Probleme. Dort werden teilweise Hintergrundtasks dynamisch geladen. Im Entwicklungssystem ist das kein Problem da die VIs physisch auf der Disk sind von wo sie auch per Pfad geladen werden. In einem Executable gings aber nur wenn statt einem Pfad nur der VI Name als String angegeben wurde, da 8.5 sich weigert VIs von anderswo auf der Disk (hier innerhalb der LLB im EXE) zu laden dann was der Pfad angibt. In dieser Hinsicht ist es wahrscheinlich auch nicht mehr einfach wahr, dass bei Übergabe eines absoluten Pfades und wenn das VI dort nicht wirklich besteht, die Searchpaths automatisch durchforstet werden.

Und die andere Differenz ist dass wenn Du ein VI in 8.5 per Pfad laden willst das schon im Speicher ist, dies nur funktioniert wenn der angegebene Pfad mit dem wirklichen Pfad des bereits geladenen VIs übereinstimmt.

Rolf Kalbermattter