VI mit DLL exportieren

Hallo,

ich habe hier ein VI erstellt, welches abhängig von einer DLL ist. Das VI soll jetzt auf einem anderen Rechner weiterbearbeitet werden.

Ich habe also den Projektordner auf den neuen Rechner kopiert und wollte loslegen. Aber so geht das nicht!

Auch mit der Option 'Build Specification' habe ich es versucht. Leider werden die Abhängigkeiten zur DLL nicht mit verwurstet. Wie auch immer, ich bekomme immer wieder Projektfehler.

Wenn ich dann hergehe und die DLL auf dem Zielrechner neu in LabVIEW einbinde und die DLL-Funktionsblöcke in dem VI austausche, dann geht alles wunderbar. Aber ich will die Geschichte gerne so hinbekommen, dass das Projekt bei der Übertragung schon läuft - ohne Nacharbeiten.

Wer weiss wie das geht? Stichworte und kurze Anleitung wären toll!

Danke schonmal im Vorraus. Gruß Potter.

Anzeige

Solange die DLL relativ zu den VIs nicht ändert habe ich nie irgendwelche Probleme gehabt!

Also erkläre doch mal in viel mehr Details wo das Problem liegt.

Dann mal ganz ausführlich:

Ich erstellen auf PC1 eine DLL über Werkzeuge->Importieren->DLL. Als Verzeichnispfad gebe ich ein Verzeichnis in meinem Projektordner an (den Ordner, den ich dann auf PC2 kopiere -> also relative Pfade). Danach füge ich in mein Haupt-VI ein paar DLL-Funktionen ein. Alles klappt!

Jetzt kopiere ich diesen ganzen Ordner (Haupt-VI incl. DLL-Sub-VI's) auf einen anderen Rechner (PC2) und starte dann das Haupt-VI. Alles was kommt ist eine Fehlermeldung: 'Knoten zum Aufruf externer Bibliotheken: MachWas_Init(): Funktion in Bibliothek nicht gefunden.".

Klar ist die Funktion in der Bibliothek! Vorher ging es doch auch und warum jetzt nicht mehr? Die Pfade stimmen auch (relativ zum Projekt-Ordner). Ich frag mich nun: was ist zu tun?

Gruß Potter

---

Nachtrag:
PC1 ist 64 Bit und PC2 32 Bit. Allerdings kopiere ich die 32 Bit Version meiner DLL in den entsprechenden Ordner (im Falle von PC2) anstelle der 64 Bit DLL.
Das sollte dann ja so passen. Bei C++, C# oder Visual Basic geht das jedenfalls genau so.

Gruß Potter.

(16.04.2013 08:48 )potter68 schrieb:  Dann mal ganz ausführlich:

Ich erstellen auf PC1 eine DLL über Werkzeuge->Importieren->DLL. Als Verzeichnispfad gebe ich ein Verzeichnis in meinem Projektordner an (den Ordner, den ich dann auf PC2 kopiere -> also relative Pfade). Danach füge ich in mein Haupt-VI ein paar DLL-Funktionen ein. Alles klappt!

Jetzt kopiere ich diesen ganzen Ordner (Haupt-VI incl. DLL-Sub-VI's) auf einen anderen Rechner (PC2) und starte dann das Haupt-VI. Alles was kommt ist eine Fehlermeldung: 'Knoten zum Aufruf externer Bibliotheken: MachWas_Init(): Funktion in Bibliothek nicht gefunden.".

Klar ist die Funktion in der Bibliothek! Vorher ging es doch auch und warum jetzt nicht mehr? Die Pfade stimmen auch (relativ zum Projekt-Ordner). Ich frag mich nun: was ist zu tun?

Gruß Potter

---

Nachtrag:
PC1 ist 64 Bit und PC2 32 Bit. Allerdings kopiere ich die 32 Bit Version meiner DLL in den entsprechenden Ordner (im Falle von PC2) anstelle der 64 Bit DLL.
Das sollte dann ja so passen. Bei C++, C# oder Visual Basic geht das jedenfalls genau so.

Gruß Potter.

Die Fehlermeldung sagt deutlich dass er die Funktion in der DLL nicht gefunden hat, nicht dass er die DLL nicht gefunden hat. Das heisst LabVIEW versucht die DLL zu laden und die Funktion zu referenzieren. Das kann jetzt aus zwei Gründen falsch gehen:

1) Die Funktion besteht tatsächlich nicht in der DLL. Diese Variante scheidet aber aus da es auf dem ersten PC schon ging.

2) Die DLL konnte nicht geladen werden! Und hier liegt wohl das Problem. Deine DLL macht wahrscheinlich Gebrauch von anderen DLLs, ziemlich sicher zumindest von der C Runtime Library des Compilers mit dem sie generiert wurde. Und diese "Dependencies" sind auf der Zielmaschine nicht geinistalliert!

Da kann LabVIEW nichts tun, denn LabVIEW kann nicht mal wissen dass diese DLLs Dependencies haben. Das ist Sache der DLL alleine und die kommt dann wohl auch mit einem Installer der halt nicht einfach ein lustiger Zeitvertreib des Entwicklers war sondern ein absolut notwendiges Übel, um die DLL auf einem willkürlichen Rechner lauffähig zu bekommen.

Erstmal Danke für die Hinweise.

Aber das passt alles nicht, da ich die DLL selbst erstellt (Visual C++, statisch gelinkt gegen die C-Runtime Lib) und auch ausführlich (mit C++, C# VB, Vista32, Vista 64, Win7 ... , 32/64 Bit) getestet habe.

Gruß Potter

(16.04.2013 13:22 )potter68 schrieb:  Erstmal Danke für die Hinweise.

Aber das passt alles nicht, da ich die DLL selbst erstellt (Visual C++, statisch gelinkt gegen die C-Runtime Lib) und auch ausführlich (mit C++, C# VB, Vista32, Vista 64, Win7 ... , 32/64 Bit) getestet habe.

Und auch alles schön auf dem anderen Computer probiert hast? Die von Dir selber erstellte Visual C Library macht AUCH Gebrauch von minimal der MS C Runtime Library. Die ist default NICHT in der DLL mitkompiliert sondern benützt die DLL Version die in genau der richtigen, sprich selben Version als auf Deinem Entwickelcomputer auf der Zielmaschine installiert sein muss.

Einen anderen Grund warum LabVIEW die Funktion in der DLL nur auf dem Entwickelcomputer finden kann bin ich in meinen unzähligen eigenen DLL Projekten noch nie über den Weg gelaufen.

Wie stellst Du denn sicher dass zum Beispiel die richtige .Net Runtime, oder im Falle von VB die entsprechende VB Runtime auf dem anderen Rechner installiert ist? Wohl nur auf Rechnern getestet wo die VB Entwickelumgebung und all das andere MS Zeugs voll installiert ist? Aber dann erwarten dass die MS VC DLL in LabVIEW auf einem jungfräulichen PC einfach laufen soll? Da muss minimal die VC Redistributable Runtime Installation die mit Deinem VC Entwickelsystem mitkam installiert werden und je nachdem was Deine DLL noch an anderen Dingen tut möglicherweise noch viel mehr!

Wenn Du tatsächlich die statische C Runtime linkst dann auch sicherstellen das nicht doch noch irgendwie ein Manifest aus einem Überbleibsel von einer früheren dynamischen C Runtime übriggeblieben ist. Zudem einmal nachgehen welche Funktionalität du alles ansprichst. Sind es wirklich nur Standard Win32 APIs und C Runtime Funktionen? Ein einziger unglücklicher Import kann das schon alles kompliziert machen.

Ist es Standard C oder C++? Ich programmiere fast nur in Standard C. Ist zwar weniger komfortabel da man vieles noch selber machen muss, aber man hat dann auch eine viel bessere Kontrolle was wirklich getan wird und wieviel vom Compiler/Linker mitgelinkt wird. Bei C++ kann es sehr einfach sein dass ein einziges harmlos aussehendes Makro plötzlich riesige Dependencies nach sich zieht.

Hallo Rolf, also an der DLL liegt es nicht. Wie gesagt: ausführlich getestet, auch auf dem Zielsystem mit einer C#-Anwendung.

Aber etwas weiter bin ich schon. Es scheint mit dem Wechsel von 64 auf 32 Bit zusammen zu hängen. Auf einer anderen 64-Bit Plattform läuft die LabVIEW-Applikation nämlich auch. Nur eben auf der 32 Bit nicht. Vermutlich reicht es nicht, einfach nur die DLL auszutauschen. Das lässt mich darauf schließen, dass es am automatisch erstellten Wrapper von LabVIEW liegen muss. Der beinhaltet wohl Bit-spezifische Derfinitionen.

Ich teste jetzt noch ein wenig und dann schaun wir mal.

So es funktioniert nun .

Es hing mit der Aufrufkonvention zusammen. Bei der 64 Bit Version hat es LabVIEW geschluckt, bei 32 Bit nicht.

Danke an Rolf für die Hilfe.