verschiedene DLLs über ein Libary Fct Node

Moinsen,

ich kämpfe gerade mit dem Thema DLL's. Erstellen und wieder auslesen ist prinzipiell kein Problem, allerdings möchte ich gerne das der User den Pfad auswählen kann wo er seine DLL gespeichert hat und die dann eingelesen wird. Ist es möglich dafür lediglich nur einen einzigen "Call Libary Function Node" zu verwenden? Wäre zwecks Erweiterbarkeit am besten.

Gruß

Anzeige

Hallo M@rRy,

guck dir mal die Hilfe zur LV2010-Version der CLF-Node an... Da ginge das (vielleicht).

Aber du hängst ja noch bei LV7.1 fest - da wird das schwieriger. Üblicherweise werden DLLs auch nicht zur Runtime eines Programms ausgewählt (ist dir ein solches Verhalten bei anderen Programmen bekannt?). Evtl. kannst du ja eine CaseStruktur aufbauen, die alle möglichen Optionen an DLL-Aufrufen abdeckt...

(18.08.2011 08:05 )GerdW schrieb:  Aber du hängst ja noch bei LV7.1 fest - da wird das schwieriger. Üblicherweise werden DLLs auch nicht zur Runtime eines Programms ausgewählt (ist dir ein solches Verhalten bei anderen Programmen bekannt?). Evtl. kannst du ja eine CaseStruktur aufbauen, die alle möglichen Optionen an DLL-Aufrufen abdeckt...

Leider habe ich keine andere Version von LV zur Verfügung - obwohl ich gern würde - desalb muss ich damit arbeiten. Ich hatte schon überlegt gehabt ein Drop-Down-Menü zu machen und dann die Case, also genau so wie du es jetzt auch angesprochen hast. Die DLL's sehen auch immer gleich aus aber es werden unter Garantie Neue dazu kommen, die den selben Aufbau, nur ander Informationen, enthalten, deshalb möchte ich es gerne, am besten für einen Unwissenden, es so einfach wie nur möglich halten seine Datei einzubinden und mit der Anlage arbeiten zu können.
Wenn ich den reinen Pfad über das einlesen einer Datei an den Call Libary Function Node gebe geht es so nicht? Also ich habs schon so versucht aber mit den verschiedenen Arten von Pfaden bin ich ein wenig durcheinander gekommen.
Alternativ, ist hier vielleicht eine config (.ini) einfacher?

Hallo M@rRy,

erstmal: dein Name tippt sich echt umständlich. Kannste dir nicht einen einfacheren zulegen?

- Deine Anfrage wird immer unverständlicher. Willst du nun verschiedene DLLs aufrufen oder willst du einer festen DLL einen Pfad übergeben?

- Wie willst du DLL-Aufrufe durch Ini-Dateien ersetzen???

- Was spricht dagegen, eine WrapperDLL zu erstellen, die ebendiesen Pfad entgegennimmt und damit die anderen DLLs aufruft (die lt. deiner Aussage alle den gleichen Aufbau haben)?

Ich bin nicht so der Windows-DLL-Spezi, vielleicht sollte RolfK hierzu noch einen Komentar abgeben...

(18.08.2011 08:32 )GerdW schrieb:  Hallo M@rRy,

erstmal: dein Name tippt sich echt umständlich. Kannste dir nicht einen einfacheren zulegen?

Tut mir Leid, man kann sich seinen Spitznamen leider nich aussuchen, aber wenn dir das lieber ist kannste auch Daniel sagen, fühle ich mich genau so angesprochen.

(18.08.2011 08:32 )GerdW schrieb:  - Deine Anfrage wird immer unverständlicher. Willst du nun verschiedene DLLs aufrufen oder willst du einer festen DLL einen Pfad übergeben?

Während das Programm läuft, oder bei Programmstart, möchte ich das der User die Maschine auswählt mit der er arbeiten möchte / an die das System angeschlossen ist. Dazu soll eine DLL geladen werden, die dann die nötigen Information, wie Leistung, Wellenlänge, Duty Cycle usw. enthält. Welche von den verschiedenen DLL geladen wird soll der User entscheiden, daher habe ich dann ca. 5 DLL's wovon immer nur eine eingelesen wird was sich im besten Fall über die komplette Laufzeit des Programms nicht ändert.

Bisher habe ich eine DLL immer aufgerufen indem ich auf den Call Libary Function Node geklickt habe und dort dann die Datei mit Pfad ausgesucht habe. Wenn ich das nicht tu und dem Knoten lediglich den Pfad der DLL übergebe, werden dann die selben Einstellungen getroffen wie als wenn ich das per Hand mache?

(18.08.2011 08:32 )GerdW schrieb:  - Wie willst du DLL-Aufrufe durch Ini-Dateien ersetzen???

Für jede Maschine eine Config schreiben und die dann einlesen. Dann bräuchte ich die DLL natürlich nicht mehr.

Hallo Daniel,

langsam kommt Licht ins Dunkel...
Du benutzt dieses DLLs also nur, um Konfigurationsdaten zu speichern? Warum so umständlich: immer erst eine DLL erstellen, um einmal festgelegte Daten per Aufruf bereitzustellen?

LV bietet:
- Standard-Dateioperation (z.B. für Textdateien)
- Standard-Dateioperationen und String-Befehle (für CSV-Dateien)
- Config-Fileoperationen (für INI-Dateien)
- XML-Fileoperationen (zumindest in neueren LV-Versionen)
- ActiveX (um Excel fernzusteuern und dort Daten abzugreifen)
- ... (eine Menge weiterer Möglichkeiten, um den User vor eine Daten-Auswahl zu stellen)
- alle genannten Optionen bieten die Möglichkeit, mehrere Datensätze in einer Datei (!) zu verwalten

Du nimmst den Weg über eine extern zu erstellende DLL. Geht auch, hat seine Fallstricke (wie die anderen Wege auch) - aber du bist der Programmierer und wählst deine Optionen nach Lastenheft eigenverantwortlich aus...

Zitat:Du benutzt dieses DLLs also nur, um Konfigurationsdaten zu speichern? Warum so umständlich: immer erst eine DLL erstellen, um einmal festgelegte Daten per Aufruf bereitzustellen?

Ja genau. Oke, es war einfach der erste Weg der mir so in den Sinn kam. Bei den INI-Dateien fand ich es gut das man direkt nach den Namen suchen kann und damit direkt die Werte hat (über das Read Key.vi meine ich jetzt). Aber eine Txt würde mir natürlich am besten in den Kram passen, damit sollte ja jeder um können.

Vielen Dank auf jedenfall! Hat mir sehr geholfen und nun lese ich mir mal ein wenig zu dem Thema einlesen mit Txt oder halt INI an.

Also wenn ich die Wahl habe zwischen INI- und txt-Datei, dann INI-Datei.
txt-Datei heißt, ich muss den Parser selber programmieren, mglw. muss das Format exakt festgeklopft sein, und und und...

INI-Datei ist bei sinnvoller Vergabe von Bezeichnern auch für jeden lesbar, die Schreib- und Lese-VIs sind fertig, die Reihenfolge innerhalb des INI-Files ist egal, usw. usw.

Gruß, Jens

(18.08.2011 08:25 )M@rRy schrieb:  Leider habe ich keine andere Version von LV zur Verfügung - obwohl ich gern würde - desalb muss ich damit arbeiten. Ich hatte schon überlegt gehabt ein Drop-Down-Menü zu machen und dann die Case, also genau so wie du es jetzt auch angesprochen hast. Die DLL's sehen auch immer gleich aus aber es werden unter Garantie Neue dazu kommen, die den selben Aufbau, nur ander Informationen, enthalten, deshalb möchte ich es gerne, am besten für einen Unwissenden, es so einfach wie nur möglich halten seine Datei einzubinden und mit der Anlage arbeiten zu können.
Wenn ich den reinen Pfad über das einlesen einer Datei an den Call Libary Function Node gebe geht es so nicht? Also ich habs schon so versucht aber mit den verschiedenen Arten von Pfaden bin ich ein wenig durcheinander gekommen.
Alternativ, ist hier vielleicht eine config (.ini) einfacher?

Dynamisches Verändern des DLL Paths in der Call Library Node ist ein LabVIEW 8.5 Feature. Davor ging das nicht. Soweit Pech für Dich.

Was Du aber tun könntest ist eine DLL zu schreiben die neben den Funktionsparametern auch einen DLL Path bekommt. Dann kannst Du in Deiner DLL Funktion mit LoadLibrary(), GetProcAddress() und FreeLibrary() Deine eigentliche DLL selber laden und ausführen so wie Du das willst.

Eine andere Variante die das Problem nach LabVIEW verlagert, wäre um mittels Call By Reference jeweils die DLL spezifischen VI's aufzurufen. Dann musst Du zwar für jede DLL noch stets ein neues VI schreiben, aber die können ausserhalb Deiner Applikation in einem bestimmten Ordner plaziert werden. Damit kannst Du die Applikation erweitern ohne dass Du sie jeweils neu kompilieren und distributieren musst.

Selber würde ich für die DLL Variante gehen aber das ist nicht ganz trivial. Du musst nämlich auch noch bestimmen zu welchem Zeitpunkt Du jeweils eine DLL wieder aus dem Speicher werfen willst und das korrekt managen.

Und um Konfigurationsdaten zu laden benütze ich immer die INI Files, ausser der Kunde hat bereits ein anderes File Format definiert. Dazu DLLs herbeizuzerren ist wie einen Nagel mit dem Presslufthammer einzuschlagen.

Hallo nochmal und danke euch beiden für die Tipps!

Die Sachlage hat sich, man muss schon fast sagen leider, ein wenig geändert. Zunächst habe ich das ganze mit der Textdatei probiert und das geht super. Leider ist mir dieses Problem was Jens bereits angesprochen hat, das das Format immer gleich bleiben muss, ein wenig zu heikel, weshalb diese Lösung nun raus ist. Die INI wäre weiterhin eine Option gewesen - bis gestern Abend - Schade!

Es wird doch eine DLL sein müssen und zwar aus folgendem Grund. Beim Programmstart soll die Maschine ausgewählt werden und die "Treiber" für genau diese dann auch geladen werde, bis dahin alles wie gehabt. Um Ressourcen zu sparen möchte ich aber nicht alle theoretisch denkbaren Outputs definieren sondern dann auch nur die die ich brauche. Bisher habe ich Anlagen gefunden die entweder mit einem Counter, einem reinen Analogsignal oder einem digitalen Signal angesteuert werden. Ich möchte aber nicht am Programmstart alle drei Tasks starten um dann nur den wirklich benötigten benutzen während die andern beiden so nebenher laufen. Deshalb war die Idee eine Wrapper-DLL zu schreiben die lediglich einen String (also die benötigte DLL als reinen Namen) bekommt und danach dann die eine DLL lädt mit den Daten.

Ich finde ja schon selbst das das sehr umständlich ist, aber so gehe ich sicher das ich garantiert nur das starte was ich auch brauche.

Ein wenig zum Thema DLL in DLL aufrufen und so hab ich schon gelesen und dabei bin ich auch genau über die drei von rolfk bereits angesprochenen Funktionsaufrufe gestoßen. Doch wie kann ich den bereits in der unter DLL, also die die von der Wrapper-DLL aufgerufen wurde, gestartete Task an mein LV-Programm übergeben? Kennt C einen Datentyp wie Task oder Thread?

Die Wrapper-DLL versuche ich in C ++ zu schreiben. Falls noch jemand einen Tipp für mich hat bin ich da sehr dankbar.

Gruß
Daniel