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!
ich habe das Problem das bei jedem LabVIEWneustart die DLL einfach nicht mehr ausgeführt wird. Erst nachdem ich die Call Library Function Nodes neu Konfiguriere in dem ich einfach den Dateinamen neu angebe. Merkwürdig ist ist daß die Pfad und Dateiangabe vorher schon richtig dastand - aber scheinbar doch nicht richtig erkannt wurde.
ich habe das Problem das bei jedem LabVIEWneustart die DLL einfach nicht mehr ausgeführt wird. Erst nachdem ich die Call Library Function Nodes neu Konfiguriere in dem ich einfach den Dateinamen neu angebe. Merkwürdig ist ist daß die Pfad und Dateiangabe vorher schon richtig dastand - aber scheinbar doch nicht richtig erkannt wurde.
Weiß jemand Rat???
Danke im voraus.
Gruß
Benny
Hallo Benny!
ich persönlich werde nicht ganz schlau von welcher Dateiangabe du sprichst? Meinst du in der Konfiguration den Pfad auf die DLL oder einen Pfad als Eingabeparameter der DLL?
' schrieb:Ich meine den Pfad auf die DLL. Ich hab mal versucht die DLL ins VI-Verzeichnis zu kopieren aber daß wars irgendwie auch nicht?
Hast du vielleicht vergessen im Bedinpanel nach dem Einstellen des Pfades, mit einem Rechtsklick -> Datenoperationen -> Aktuellen Wert als Standard zu übernehmen?
Gruß, Rob
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
' schrieb:Hast du vielleicht vergessen im Bedinpanel nach dem Einstellen des Pfades, mit einem Rechtsklick -> Datenoperationen -> Aktuellen Wert als Standard zu übernehmen?
Gruß, Rob
Ich glaube, er meint nicht den Pfad, den er als String an die DLL übergibt. Er hat glaub ich ein Problem mit dem Namen der DLL, der ja beim Konfigurieren des Knotens angegeben werden muss.
@benny:
Kann es sein, dass sich die DLL ändert, während LV geschlossen ist - z.B. weil sie programmtechnisch angepasst wird?
Kann es sein, dass der DLL-Name ungünstige Zeichen enthält - z.B. Spaces und mehrfach Punkte ? (ich kann zwar nicht glauben, dass das was ausmacht, aber man weis ja nie)
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ich glaube, er meint nicht den Pfad, den er als String an die DLL übergibt. Er hat glaub ich ein Problem mit dem Namen der DLL, der ja beim Konfigurieren des Knotens angegeben werden muss.
@benny:
Kann es sein, dass sich die DLL ändert, während LV geschlossen ist - z.B. weil sie programmtechnisch angepasst wird?
Kann es sein, dass der DLL-Name ungünstige Zeichen enthält - z.B. Spaces und mehrfach Punkte ? (ich kann zwar nicht glauben, dass das was ausmacht, aber man weis ja nie)
Ich habe das gleiche Problem.
Es reicht auch nicht aus unter "Konfigurieren" den Pfad mit "OK" zu bestätigen, sondern die DLL muss über "Suchen" geöffnet werden, obwohl der Pfad immer richtig ist.
Auch nach dem Abspeichern tritt das Problem beim nächsten Neustart von LV (7.1) auf.
Der Dateiname ist nach folgendem Format: xxxx_xx.dll
Mein Vorgänger hat bereits ausprobiert die Datei in verschiedenen Unterverzeichnissen von LabVIEW zu kopieren.
Würde mich sehr freuen, wenn mir jemand weiterhelfen kann. Danke!
Es reicht auch nicht aus unter "Konfigurieren" den Pfad mit "OK" zu bestätigen, sondern die DLL muss über "Suchen" geöffnet werden, obwohl der Pfad immer richtig ist.
Auch nach dem Abspeichern tritt das Problem beim nächsten Neustart von LV (7.1) auf.
Der Dateiname ist nach folgendem Format: xxxx_xx.dll
Mein Vorgänger hat bereits ausprobiert die Datei in verschiedenen Unterverzeichnissen von LabVIEW zu kopieren.
Würde mich sehr freuen, wenn mir jemand weiterhelfen kann. Danke!
Gruß, Torsten
Hmm, ich werde da echt nicht schlau draus. Mache sehr regelmässig Dinge mit DLLs und habe das noch nie gesehen. Welche LabVIEW Version ist das?
Kannst auch mal versuchen nur den DLL Namen selbst anzugeben und die DLL(s) in das Verzeichnis zu kopieren in dem LabVIEW.EXE steht. Wenn das hilft und Du willst später eine Applikation machen musst Du sicher stellen dass der Applikation Builder die DLL mit einbindet. Normal tut er das automatisch und legt sie dann default im data Unterverzeichnis innerhalb des Verzeichnisses in dem die Applikation zu stehen komt ab. Das sollte so gehen obwohl ich alle DLLs die in meinen LabVIEW Applikationen gebraucht werden vorzugsweise im gleichen Verzeichnis zu haben in dem auch das Executable selber ist.
' schrieb:Ich meine den Pfad auf die DLL. Ich hab mal versucht die DLL ins VI-Verzeichnis zu kopieren aber daß wars irgendwie auch nicht?
Ich kenne ein ähnliches Problem aus LV6:
Ich hatte ein Program MAIN.vi entworfen, in dem für verschiedene Treiber
gleichlautende VIs für gleiche Funktionen verwendet werden sollten,
nur der Verzeichnisname sollte geändert werden.
Bsp:
<blockquote>Verzeichnis Hardware1 enthält: open.vi, close.vi, send.vi ...
Verzeichnis Hardware2 enthält: open.vi, close.vi, send.vi ...
...</blockquote>
Dann wollte ich die VIs programmgesteuert mit "Open VI Reference.vi" auswählen und ausführen.
LV6 hat dann aber immer die VIs aus dem Verzeichnis (z.B. Hardware1) ausgewählt,
das beim letzten Abspeichern von MAIN.vi in LV6 verwendet worden war: keine Fehlermeldung oder so..
Mein Workaround bestand darin, die VIs in den Verzeichnissen unterschiedlich zu benennen:
Bsp:
<blockquote>Verzeichnis Hardware1 enthält: open1.vi, close1.vi, send1.vi ...
Verzeichnis Hardware2 enthält: open2.vi, close2.vi, send2.vi ...
...</blockquote>
Seitdem klappt das programmgesteuerte Ausführen mit "Open VI Reference.vi" problemlos
Was für ein Zufall. Hab mich heute erst wieder damit befasst
Gelöst hab ich das Problem leider immer noch nicht. Es scheint so als ob die DLL andere DLLs verwendet. (geht das? Ich kenn mich da gar nicht aus). Auf jedenfall funktionierts wenn ich daß VI in einem Verzeichniss ausführe in dem sich auch die DLL befindet (nicht umgekehrt). Allerdings darf dass nicht die Lösung sein da ich nicht meine Programme woanders abspeichern möchte. Wenn das jemand löst - bitte Posten.
' schrieb:Was für ein Zufall. Hab mich heute erst wieder damit befasst
Gelöst hab ich das Problem leider immer noch nicht. Es scheint so als ob die DLL andere DLLs verwendet. (geht das? Ich kenn mich da gar nicht aus).
Ja das geht nicht nur sondern ist ausser für extrem triviale DLLs beinahe unvermeidbar. Meist geht es minimal um ein paar WinAPI DLLs die aber bei Windows sowieso schon dabei sind. Aber eine DLL kann beliebig viele andere DLLs referenzieren und wenn das statisch gemacht wird, kann das Laden der primären DLL durch LabVIEW nur funktionieren, wenn auch alle abhängigen DLLs von Windows gefunden werden. Hier hat LabVIEW aber eben überhaupt keinen Einfluss darauf. Alles was LabVIEW tun kann ist Windows sagen dass es DLL XYZ laden soll und Windows versucht dann alle Abhängigkeiten aufzulösen. Wenn eine davon nicht auflösbar ist für Windows dann sagt Windows zu LabVIEW einfach Ätsch! und verweigert das Laden der DLL und basta.
Es ist denkbar dass das daher kommt dass im gleichen Verzeichnis Deiner DLL die Du in LabVIEW benützen willst noch andere DLLs die von dieser DLL benützt werden liegen. Nachdem Du im Windows FileDialog die DLL angewiesen hat, speichert dieser FileDialog das zuletzt benützte Directory für Deinen Prozess ab und möglicherwiese benützt Windows zusätzlich zu den dokumentierten Pfaden um DLLs zu finden auch noch diesen zuletzt benützten Pfad (Current Directory) um Abhängigkeiten aufzulösen. Das könnte erklären warum es bei Dir immer nach dem Starten zuerst einmal falsch geht da beim Starten einer Applikation das Current Directory durch Windows auf den Ort gesetzt wird wo das Executable sich befindet (und Deine DLLs sich eben nicht befinden).
Das ist aber alles Windows spezifisch und LabVIEW hat da absolut keinen Einfluss darauf.
