Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Beim Aufruf eines VIs aus einer in LV erzeugten DLL mit dem Knoten zum Aufruf externer Bibliotheken bleibt LabView an dieser Stelle stehen, bis das aufgerufene VI wieder geschlossen wurde.
Ich möchte nun eine Applikation erstellen, in der beim Start je nach Vorgabe ein oder mehrere VIs gestartet werden. Das Hauptprogramm soll nach dem Start des jeweiligen Unterprogramms aber weiterlaufen.
Kennt jemand möglicherweise eine Lösung für dieses Problem?
(27.03.2012 10:41 )Trinitatis schrieb: Kennt jemand möglicherweise eine Lösung für dieses Problem?
Hallo,
die Aufrufe müssen parallel erfolgen. Alle SubVIs, DLLs., usw, welche weiterlaufen sollen, müssen (ggf. in eigenen Schleifen) eigens und unabhänig von einander aufgerufen werden
Beste Grüße,
NWO
9 von 10 Stimmen in meinem Kopf sagen: Ich bin nicht verrückt,
die andere summt die Melodie von Tetris.
NI schrieb:To use the abort button is like using a tree to stop a car!
Beim Aufruf eines VIs aus einer in LV erzeugten DLL mit dem Knoten zum Aufruf externer Bibliotheken bleibt LabView an dieser Stelle stehen, bis das aufgerufene VI wieder geschlossen wurde.
Ich möchte nun eine Applikation erstellen, in der beim Start je nach Vorgabe ein oder mehrere VIs gestartet werden. Das Hauptprogramm soll nach dem Start des jeweiligen Unterprogramms aber weiterlaufen.
Zuerst mal: warum rufst Du eine LabVIEW DLL in LabVIEW auf? Das ist zwar nicht grundsätzlich falsch aber ein ziemlicher Umweg. Die VIs in der DLL können auch direkt aufgerufen werden.
Zweitens: Wenn Du eine Call Library Node aufrufst ist diese blockiert bis diese Funktion zurückkehrt. Wenn Du die Call Library Node als reentrant konfigurierst kann LabVIEW zwar andere Dinge parallel dazu in Deinem Diagramm ausführen, aber dazu darf keinerlei Datenflussabhängigkeit zwischen Deiner Call Library Node und den anderen Dingen bestehen. Zudem wäre es eine nutzlose (und möglicherweise sogar törichte) Idee um einen DLL Aufruf als reentrant zu konfigurieren wenn diese Funktion ein User Interface öffnet.
Wenn Du die VIs die Deine LabVIEW DLL enthält direkt aufrufst ersparst Du Dir sehr viel Arbeit und wahrscheinlich auch Ärger da Du nicht ein C Interface zwischen diese zwei Welten hineinschiebst, das durch LabVIEW nur sehr bedingt kontrollierbar ist und damit eine ganze Reihe an Einschränkungen im Hinblick auf parallele Ausführung von Teilen in LabVIEW hat.
der Aufruf über den Code-Interface-Knoten war nur eine Krücke. Eigentlich will ich nur logisch zusammengehörende Programmteile in einer DLL an einen Kunden rausgeben. Der bekommt dann eine kleine Start-EXE und 3-4 DLLs.
Die Start-Exe ruft aus der Haupt-DLL das Haupt-VI auf, welches wiederum aus den anderen DLLs verschiedene Komponenten aufruft. Früher (in LV 8.0) habe ich die DLLs einfach wie einen Ordner behandelt und mit der Funktion VI-Referenz öffnen (nicht auf Ende der Operation warten) meine gewünschten VIs aus den DLLs aufgerufen. Das geht in LV 2011 aber nicht mehr. Jetzt brauche ich also nur irgend eine adäquate Möglichkeit, aus der in LV erstellten DLL ein VI aufzurufen, ohne dass mein Hauptprogramm an dieser Stelle wartet. Da erschien mir der einzige Weg der über den Code-Interface-Knoten zu sein.
Die Idee mit 20 Schleifen, die parallel laufen und dann alle hängen scheint mir da nur suboptimal.
Aber vielleicht hast Du ja noch eine andere Idee ?
Vielleicht solltest Du mal nach packed VI libraries schauen. Das ist eine direktere Art om VIs in einem einzigen File zu distributieren dann DLLs und es hat auch denn Vorteil, dass das Aufrufen von VIs daraus heraus auch in neusten Versionen möglich bleibt. Allerdings funktioniert das in 7.1 und 8.0 noch nicht aber Du scheinst ja in 2011 zu arbeiten.
Leider sitze ich in der gleichen Situation. Bis auf bei mir gehört dieses zum Anforderungsprofil, das eine EXE dynamisch DLLs laden kann.
Hinsichtlich der Ausführung ist das ganze auch kein Problem, halt nur nicht performant beim ersten Aufrufens der DLLs.
@Rolf irgendwie wie ist dein Name gefallen: "your are the man" wenn es um DLL und die lvrt.dll also hoffe das ich richtig die Frage addressiere.
auf ni.com steht folgendes:
„Nutzen alle DLLs dieselbe Version der LabVIEW Run-Time Engine und das Laden der DLLs geschieht dynamisch, empfiehlt National Instruments, dass Sie die LabVIEW Run-Time Engine dynamisch durch Laden der Datei lvrt.dll laden, bevor Sie eine der in LabVIEW erstellten DLLs laden. Ein Laden der LabVIEW Run-Time Engine vor dem Laden der DLLs verringert Overhead, indem die Run-Time Engine am Laden und Entladen gehindert wird, wenn die DLLs vom Speicher ge- und entladen werden.“
Leider zur "LVRT.dll" konnte ich keinerlei Infos noch die Headerfile finden. Die Funktionen sind zwar ersichtlich, aber die Inputs/Outputs nicht . Vielleicht mag dieses auch der falsche Ansatz sein.
Ich hoffe mal Du kannst mir hier bei weiterhelfen.
Auch Vielen Dank im vorraus
Gruss Olli
Anzeige
28.03.2012, 19:17 (Dieser Beitrag wurde zuletzt bearbeitet: 28.03.2012 19:19 von rolfk.)
(28.03.2012 10:10 )ofahed schrieb: auf ni.com steht folgendes:
„Nutzen alle DLLs dieselbe Version der LabVIEW Run-Time Engine und das Laden der DLLs geschieht dynamisch, empfiehlt National Instruments, dass Sie die LabVIEW Run-Time Engine dynamisch durch Laden der Datei lvrt.dll laden, bevor Sie eine der in LabVIEW erstellten DLLs laden. Ein Laden der LabVIEW Run-Time Engine vor dem Laden der DLLs verringert Overhead, indem die Run-Time Engine am Laden und Entladen gehindert wird, wenn die DLLs vom Speicher ge- und entladen werden.“
Leider zur "LVRT.dll" konnte ich keinerlei Infos noch die Headerfile finden. Die Funktionen sind zwar ersichtlich, aber die Inputs/Outputs nicht . Vielleicht mag dieses auch der falsche Ansatz sein.
Die Bemerkung zur lvrt.dll wenn man mehrere LabVIEW DLLs verwendet ist zwar scön angedacht aber nicht gut durchgedacht. Denn das Problem ist gerade, die richtige DLL zu finden. lvrt.dll ist jeweils in einem versionsabhängigen Verzeichnis installiert, dessen Pfad man aber nicht hardwiren kann, da die Stelle wo die Runtimes installiert werden benützerdefinierbar ist. Die NI Art um das zu lösen, ist zur Zeit ein Registryeintrag der angibt wo die jeweilige Runtime installiert ist. Aber das ist zwar für alle bisher bestehende LabVIEW Versionen so, aber niemand kann garantieren, dass das in Zukunft so bleibt und wenn Du das in Deine Applikation so einbaust geht es hässlich verkehrt wenn NI das jemals ändert und Du dann auf diese LabVIEW Version upgraden willst.
Eine bessere Variante ist deshalb um eine Dummy DLL mit Dummy Funktion in der selben LabVIEW Version zu machen und diese durch eine Call Library Node im Hauptprogramm zu laden. Wenn das Hauptprogramm in den Speicher geladen wird, wird auch diese Dummy DLL in den Speicher geladen und die lokalisiert die LabVIEW Runtime DLL in der richtigen Weise für die aktuelle LabVIEW Version, in der die DLL gemacht wurde. Wenn Du dann alle anderen plugin DLLs in der selben LabVIEW Version erstellst, brauchen diese die lvrt.dll nicht mehr zu laden, was einiges and Ladezeit spart.
entschuldige die verspätete Antwort, aber ich wollte doch noch ein Lebenszeichen von mir geben.
Ich habe mich mal etwas in das Erstellen von Projektbibliotheken (die ja wohl zwingend erforderlich scheint für das Erstellen einer komprimierten Bibliothek) eingelesen. Jetzt muss ich dann nur noch testen, ob ich aus einer später erstellten komprimierten Bibliothek die VIs einfach so auslesen kann, wie ich das früher in LV 80 mit den DLLs betrieben habe, nämlich so zu tun, als sei diese Bibliothek ein Verzeichnis.
Weißt Du denn auch, wie sich das so mit LLBs verhält, die ich in meinem user.lib-Verzeichnis habe? Dort habe ich so einige VIs in thematisch gegliederten LLBs liegen, auf die ich bei der Programmierung dann unter der Palette "eigene Bibliotheken" zugreifen kann. Müssen diese LLBs mit in die Projektbibliothek eingebunden werden, die dann als Startbibliothek in der komprimierten Bibliothek verwendet wird, oder werden die VIs der LLBs beim Erstellen der komprimierten Bibliothek sowieso mit eingebunden, wenn VIs, die in der Projektbibliothek liegen auf sie zugreifen?
Vielen Dank für deine schnelle Antwort und Ratschläge.
Die Idee mit der Dummy Function hatte ich angewendet, aber vielleicht läuft bei meinen DLLs etwas grundlegendes falsch. Obwohl die Dummy Function geladen wurde beträgt die erste Ladezeit immer noch 5 Sekunden. Zu mindest eine Verbesserung von 2 Sekunden .
Aber da sollte doch eigentlich mehr drin liegen oder nicht?
mhhh ok also ich habe auch rausgefunden warum diese zeitbeansprucht wurde.
Das Problem lag daran das ich einen Enum(Init, Main, Close) benutzt habe, der Enum wurde von der DLL ignoriert und nur das Defaultcase ausgeführt.
Da ich noch nicht soviele Erfahrungen mit dem compilieren und der Dlls in LabView habe, sind Enum is prinzipiell möglich?
Gibt es gewisse Regeln die man beachten sollte beim Compilieren?
wenn es um DLL und die lvrt.dll also hoffe das ich richtig die Frage addressiere.
. Vielleicht mag dieses auch der falsche Ansatz sein.