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!
hallo miteinander,
ich habe das folgende problem, dass ich 20 dlls aufrufe, die identisch sind von den funktionen, aber unterschiedlich heissen, also z.b.
A01.DLL
A02.DLL
...
A20.DLL
(an dieser tatsache gibt es nichts zu rütteln, das ist gottgegeben).
beim einstellen des dll-namens "Knoten zum Aufruf externer Bibliotheken" gebe ich ja den bibliotheknamen an, kann dieser aufrufparameter "parametrierbar" gemacht werden, weil momentan muss ich mit einem case 20 mal die einzelnen bibliotheken öffnen, oder bei einem pfadwechsel muss ich 20 mal den pfad anpassen. wenn ich den pfadnamen + dllnamen übergeben könnte, spar ich mir das.
ich hoffe das problem ist verständlich dargestellt, gibt es eine lösung?
stelle gerade fest, dass genau das ab LV8.20 möglich ist.
Was aber schon in LV7 gültig war, ist:
[attachment=34086:Image01.png]
und den Suchpfad kannst du über die INI-Dateien erweitern.
MfG, Jens
Was das Angeben des DLL Pfadnamens zur Laufzeit angeht hast Du recht. Seit LabVIEW 8.2 ist das möglich. Der Suchpfad hat aber mit der ursprünglichen Anfrage nichts zu tun. Vor LabVIEW 8.2 waren die einzigen zwei Lösungen entweder x Mal dieselben VIs mit uterschiedlichem DLL Namen generieren oder was ich bevurzugt tat eine Wrapper DLL, die alle exportierten Funktionen aufruft und zusätzlich einen extra Parameter für den DLL Namen hat und die richtige DLL selber mit LoadLibrary lädt. Ist so von etwa zwei DLLs an wesentlich zeitsparender zu tun dann x identische LabVIEW Libraries zu unterhalten.
Aber eine solche Anforderung wäre jetzt sicher ein typischer Grund um nach 8.2.1 zu upgraden und das Upgrade würde sich schon alleine dadurch bezahlt machen in diesen Fall.
:rolleyes:vielen dank erstmal,
die gemachten vorschläge werden zur weiteren diskussion verwendet, die frage ist eigentlich nur, was am schluss günstiger kommt, LV V8 oder die wrapper-dll.
gruss,
IBR
' schrieb::rolleyes:vielen dank erstmal,
die gemachten vorschläge werden zur weiteren diskussion verwendet, die frage ist eigentlich nur, was am schluss günstiger kommt, LV V8 oder die wrapper-dll.
Hängt ja wohl davon ab wie Du Deine Arbeitszeit einschätzst. Ein Tag Arbeit ist schnell mal verbraten um selbst so etwas Simples zu machen. Natürlich ist es einfach und ist man geneigt zu sagen ach was das tue ich schnell in einer Stunde aber meine Erfahrung zeigt mir dass das am Ende doch immer wesentlich mehr Zeit in Anspruch nimmt. Aber da spielt auch teilweise mit dass "es funktioniert scheinbar" für mich einfach nicht genug ist, wenn ich es in eine richtige Applikation einbinden will. Da müssen schon mindestens ein paar seriöse Tests mit und etwas saubere VIs mit entsprechender Dokumentation der Parameter gehört für mich auch einfach dazu.
Aber mit einem Tag hast Du bei üblichen Kostenansätzen je nach Firma bereits das halbe oder sogar ganze Upgrade bezahlt.
' schrieb:Ich denke schon, das Suchpfad bei den Pfadwechseln helfen kann, wenn man halt den dllnamen nicht inkl. Pfad eingibt.
Also DLL Suchpfade mit der PATH environment variable oder noch schlimmer dem LabVIEW INI file zu lösen ist eine ganz schlechte Idee wenn Du planst eine Applikation auf andere Computer zu distributieren. Am besten hat sich bei mir bewährt solche DLLs entweder in das selbe Directory zu legen wie das Executable, oder eventuel ins Windows Directory obwohl letzteres auf Computern die in Netzwerken eingebunden sind üblicherweise Administratorrechte verlangt und deshalb nicht den Vorzug geniesst.
Nur schnell mal als Referenz! Dies sind die Suchpfade die Windows verwendet wenn eine DLL ohne expliziten Pfad angegeben wird respektieve am angegebenen Ort nicht gefunden wurde:
1) Wenn sie schon in den Prozess geladen ist wird sie direkt verwendet unabhängig von einem eventuel angegebenen Pfad.
2) Im gleichen Directory aus dem der aktuelle Prozess gestartet wurde.
3) Windows Directory
4) System Directory
5) PATH Environment Variable Directories
LabVIEW fügt da noch hinzu:
6) alle Directories die im INI File Suchpfad angegeben sind
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
DLLS (plural) einbinden
Bei LabVIEW 8.2.1 gibt es auch andere, wesentliche Unterschiede gegenüber LabVIEW 7.0. Ich würde da gar nicht lange zögern und mir die aktuelle Version kaufen, am besten mit SSP (Service-Vertrag), dann kriegst Du nämlich immer die aktuellste Version zugeschickt und hast den vollen Support (E-Mail,....) von NI.
Gruß Markus
' schrieb::rolleyes:vielen dank erstmal,
die gemachten vorschläge werden zur weiteren diskussion verwendet, die frage ist eigentlich nur, was am schluss günstiger kommt, LV V8 oder die wrapper-dll.
gruss,
IBR
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
hallo nochmal, vielen dank für die rege diskussion hier
das mit dem "ini" geht nicht, da ich noch einiges verschwiegen habe, nämlich:
es kommt zu den existierenden DLL´s (1-20) noch die dimension projekt hinzu (ca. 10), d.h. jede DLL existiert nochmal in verschiedenen implementationen (aber mit gleicher (funktionaler) schnittstelle!)
also:
pfad01 enthält A01.DLL - A20.DLL
pfad02 enthält A01.DLL - A20.DLL
...
pfad10 enthält A01.DLL - A20.DLL
die pfade "pfad01" bis "pfad10" stehen fest, das projekt wird aber erst zur laufzeit bestimmt.
(nochmal der hinweis: bitte keine DLL-aufbau-diskussion, die sind gottgegeben und werden nicht angefasst)
noch ein hinweis: für mich ist ganz klar LV8 die lösung, doch der geldsack wird von anderen verwaltet die politische einflüsse berücksichtigen müssen.
gibt es eine hochglanzbroschüre (für manager ;-) ), die die vorteile der V8 vs. V7 auf EINFACHSTE art herausstellt?
' schrieb:gibt es eine hochglanzbroschüre (für manager ;-) ), die die vorteile der V8 vs. V7 auf EINFACHSTE art herausstellt?
Ich bin mir sicher dass NI da eine Broschüre hat die sie Dir sehr gerne zuschicken. Wird vielleicht eine allgemeine Version 8 Broschüre sein, aber 8.2 hat da auch noch das eine oder andere Schmankerl mitbekommen (Dein dynamischer DLL Pfad ist eines davon), aber die grossen und wichtigen Veränderungen sind allgemein Version 8 spezifisch. Persönlich finde ich die Projektverwaltung eine wesentliche Verbesserung und mit 8.2 sind auch die meisten Kinderkrankheiten davon behoben.
Interessant scheint mir auch remote-debugging, und andere solche Dinge.