NI VIs in dynamischem Aufruf finden?

Hallo zusammen,
ich weiß, dass ähnliche Fragen hier schon mehrfach aufgetaucht sind, aber ich glaube nichts passt konkret zu meinem Problem:

Rufe ich folgendes VI dynamisch aus einer exe auf

   

bekomme ich diesen Fehler:

   

Bei Aufruf aus der Entwicklungsumgebung gibt es kein Problem.
Das Problem tritt nicht mehr auf, wenn ich das VI DAQmx zurücksetzen rausnehme.

Muss ich für Ausführung in der Laufzeitumgebung die DAQmx-VIs irgendwo mit übergeben?

Im Anhang ist mal das ganze Projekt.

Grüße,
Daniel


  CallMain.zip (Größe: 329,13 KB / Downloads: 217)

Anzeige

LV findet die SubVIs nach dem Builden nicht, da es beim builden nix von dem main.vi weiß.

Hab das Projekt inkl. buildspec angepasst.

  CallMain_fix_build.zip (Größe: 2,01 KB / Downloads: 264)

Hallo macmarvin,
erst mal vielen Dank für die Hilfe.
So geht es natürlich. Ist aber nicht ganz das, was ich meinte. Mein Problem ist eher repräsentativ für ein größeres Projekt, in dem ich mit Plug-Ins arbeite, die dynamisch aufgerufen werden sollen.
Daher will ich sie ja gerade nicht mit in die .exe des Aufrufers reinkompilieren.

Der dynamische Aufruf klappt in der Regel aus der Entwicklungsumgebung immer, in der runtime aber nur, wenn ich bestimmte VIs rausnehme wie das DAQmx zurücksetzen im Beispiel.

Daher noch mal die Frage. Wie kriege ich das hin, dass er diese findet, ohne dass ich sie mit in die exe reinkompilieren muss?

Gruß,
Daniel

In dem du für deine dynamischen VIs/Plugins eine Buildspec anlegst.
In dem Beispiel von mir, wird das dynamisch Gerufene eben nicht mit in die Exe mit einkompiliert, sondern mit allen benötigten SubVIs daneben gelegt.

OK. jetzt hab ichs. Lässt sich über das Ziel der zusätzlichen Datei steuern und dann nimmt er die Abhängigkeiten mit

Trotzdem finde ich das noch nicht ganz befriedigend. Prinzipiell sind doch die DAQmx-VIs schon vorhanden und auch in der Runtime drin. Warum findet er die denn nicht? Auf diesem Weg muss ich ja die Exe immer wieder neu kompilieren, wenn sich bei den Abhängigkeiten was getan hat.

Grüße,
Daniel

Ne... die DAQmx VIs sind ja auch bei der Labview Entwicklungsumgebung erstmal nicht dabei. Warum sollten sie dann in der Runtime vorhanden sein?

Anzeige

Noch ein Tipp für PlugIn-Archtitekturen in LV.
Die einzelnen PlugIns jeweils in .lvlibs packen oder noch besser gleich in LVOOP schreiben.
Erleichtert das Handling bzw. erstellen der Buildspecs.

Ja stimmt. Ich bin nur so daran gewöhnt, die Treiber mit draufzuhauen. Deswegen verstehe ich halt immer noch nicht so ganz, warum er sie in einem Fall findet und in dem anderen nicht. Macht für mich keinen Sinn, wenn sie installiert sind.
Hmmm. Es gibt ja noch die Option, einen Installer zu erstellen und da die DAQmx-Treiber einzubinden. Vielleicht sollte ich das mal probieren.

lvlibs verwende ich schon durchgehend.
Ich werde mal warten bis wir LV2010 zugeschickt bekommen. Da gibt es ja auch das neue Format lvlibp für kompilierte Projektdateien. Vielleicht vereinfacht das alles etwas.

' schrieb:Ja stimmt. Ich bin nur so daran gewöhnt, die Treiber mit draufzuhauen. Deswegen verstehe ich halt immer noch nicht so ganz, warum er sie in einem Fall findet und in dem anderen nicht. Macht für mich keinen Sinn, wenn sie installiert sind.
Hmmm. Es gibt ja noch die Option, einen Installer zu erstellen und da die DAQmx-Treiber einzubinden. Vielleicht sollte ich das mal probieren.

Der DAQmx Treiber ist systemweit verfügbar wenn installiert. Die entsprechenden LV VIs werden aber nur bei Bedarf mit in die jeweilige vi.lib installiert. D.h. selbst wenn dein Installer DAQmx installiert, wird die LV Runtime immer noch die DAQmx VIs dazu suchen/finden müssen.
Du könntest da zwar Stunts probieren wie z.B. die vi.lib auf einem Rechner suchen und in den Suchpfad der LV Runtime mit aufzunehmen, aber ob sowas funktioniert... keine Ahnung und "gefühlt" wird's irgendwann gehörig krachen.
Oder du aktivierst per ini-key in der Entwicklungsumgebung, daß du SubVIs durch ihren inhalt ersetzen kannst und ersetzt alle Aufrufe die in die vi.lib gehen (hier alle DAQmx VIs) mit deren Inhalt (rekursiv). Danach kannst du den Code dann aber auch fast schon wegschmeißen

Das LV2010 inlining in Verbindung mit den neuen kompilierten Projektdateien, könnte da tatsächlich einiges bringen.
Edith: Wobei ich vor LV2010 SP1 eher vorsichtig wäre