LV-Besonderheiten beim dll-Auruf?

Moin,

ich stehe gerade vor der Aufgabe, eine CAN-Karte aus LV anzusprechen und das in einer vorhandenen SW unter zu bringen. Mir liegt dafür eine Delphi-dll als Interface für die Treiber-dll vor. Mit der Vorgängerversion und einem XP-Rechner funktioniert die Kommunikation. Nun habe ich einen Win7/64-Rechner und da bekomme ich Probleme, dass sich der CAN-Port nicht öffnen lässt.
Die dll lässt sich problemlos in LV einbinden, ich kann auf alle Funktionen zugreifen und auch Debugmeldungen auslösen. Es gibt auch ein Delphi-Testprogramm, welches mit dieser dll unter Win7/64 funktioniert und den Port korrekt anspricht.
Die Delphi-Version (2009) spricht schon Unicode und läuft unter 32 bit.

Edit: Alternativ habe ich noch eine .NET-dll samt dazugehöriger funktionierende Testsoftware inCc#, die bekomme ich aber nicht ins LV eingebunden.


Die Frage: gibt es irgendwelche besonderen Anforderungen beim Ausführen von dlls unter Win7/64?

Grüße, Messie

(16.05.2014 14:05 )Messie schrieb:  Moin,

ich stehe gerade vor der Aufgabe, eine CAN-Karte aus LV anzusprechen und das in einer vorhandenen SW unter zu bringen. Mir liegt dafür eine Delphi-dll als Interface für die Treiber-dll vor. Mit der Vorgängerversion und einem XP-Rechner funktioniert die Kommunikation. Nun habe ich einen Win7/64-Rechner und da bekomme ich Probleme, dass sich der CAN-Port nicht öffnen lässt.
Die dll lässt sich problemlos in LV einbinden, ich kann auf alle Funktionen zugreifen und auch Debugmeldungen auslösen. Es gibt auch ein Delphi-Testprogramm, welches mit dieser dll unter Win7/64 funktioniert und den Port korrekt anspricht.
Die Delphi-Version (2009) spricht schon Unicode und läuft unter 32 bit.

Edit: Alternativ habe ich noch eine .NET-dll samt dazugehöriger funktionierende Testsoftware inCc#, die bekomme ich aber nicht ins LV eingebunden.


Die Frage: gibt es irgendwelche besonderen Anforderungen beim Ausführen von dlls unter Win7/64?

Grüße, Messie

Die Frage ist sehr undeutlich. Da Du Delphi 32 Bit benützst wird die DLL wohl auch eine 32 bit DLL sein und da Du die DLL von LabVIEW aus aufrufen kannst scheinst Du auch LabVIEW 32 Bit installiert zu haben. Weiter sind mir keine besonderen Anforderungen bekannt die eine DLL erfüllen kann, damit LabVIEW sie aufrufen kann.

(16.05.2014 14:52 )rolfk schrieb:  Weiter sind mir keine besonderen Anforderungen bekannt die eine DLL erfüllen kann, damit LabVIEW sie aufrufen kann.

Hallo Rolf,

gibt es irgendwo eine Liste, welche Datentypen LV von der dll erwartet? Delphi hat so ein paar Besonderheiten mit Widechars etc.

Grüße, Messie

(16.05.2014 15:12 )Messie schrieb:  

(16.05.2014 14:52 )rolfk schrieb:  Weiter sind mir keine besonderen Anforderungen bekannt die eine DLL erfüllen kann, damit LabVIEW sie aufrufen kann.

Hallo Rolf,

gibt es irgendwo eine Liste, welche Datentypen LV von der dll erwartet? Delphi hat so ein paar Besonderheiten mit Widechars etc.

Grüße, Messie

widechars unterstützt LabVIEW nicht direkt. LabVIEW Strings sind grundsätzlich ANSI Strings, präziser sind es MBCS (MultiByte Codes) aber ausser für Sonderzeichen hat das keine Bedeutung.

Moin,

ich muss das nochmal aufwärmen. Ich habe die Delphi-dll jetzt soweit angepasst dass ich sie mit Debugausgaben versehen konnte. Aufrufe funktionieren mit Win32 und Win64 (Delphi-Testprogramm).
Es gibt eine Init-Funktion in der dll, die keine Parameter bekommt und nichts zurück gibt. Sie lädt nur die Treiber-dll. Die Handles gebe ich als Message aus.

Wenn ich die dll in einer leeren VI einbinde und laufen lasse, kommen die Debugausgaben, aber die Treiber-dll wird nicht geladen. Da dies ja eigentlich Sache der Delphi-dll ist, frage ich mich, was beim Aufruf der dll aus LV anders ist.
Oder gibt es noch irgendwelche Rechtegeschichten, läuft die dll in einer Sandbox oder Vergleichbares?

Grüße, Messie

(26.05.2014 15:21 )Messie schrieb:  Moin,

ich muss das nochmal aufwärmen. Ich habe die Delphi-dll jetzt soweit angepasst dass ich sie mit Debugausgaben versehen konnte. Aufrufe funktionieren mit Win32 und Win64 (Delphi-Testprogramm).
Es gibt eine Init-Funktion in der dll, die keine Parameter bekommt und nichts zurück gibt. Sie lädt nur die Treiber-dll. Die Handles gebe ich als Message aus.

Wenn ich die dll in einer leeren VI einbinde und laufen lasse, kommen die Debugausgaben, aber die Treiber-dll wird nicht geladen. Da dies ja eigentlich Sache der Delphi-dll ist, frage ich mich, was beim Aufruf der dll aus LV anders ist.
Oder gibt es noch irgendwelche Rechtegeschichten, läuft die dll in einer Sandbox oder Vergleichbares?

Nun, TreiberDLL ist sehr ungenau. Wenn es eine gewöhnliche DLL ist dann gibt es grundsätzlich nur zu beachten dass eine 32-bit DLL nur andere 32-bit DLLs laden kann. Und die DLL muss natürlich auch dieselbe Bitgrösse haben wie die Applikation (hier LabVIEW Umgebung) die diese DLL anspricht.

Wenn es ein Kerneltreiber ist, der installiert und/oder gestartet werden muss, funktioniert dass nur mit speziellen Rechten. Grundsätzlich werden solche Treiber dann auch während der Installation auch registriert und gestartet, denn der Installer läuft meist sowieso mit Admin Rechten. Die Applikation (User Level DLL) braucht den Treiber dann nur zu öffnen, was mit normalen Userrechten funktionieren sollte.

Mehr lässt sich mit der wenigen Information die Du tröpfchenweise preisgibst nicht sagen.

Anzeige

(26.05.2014 19:25 )rolfk schrieb:  Mehr lässt sich mit der wenigen Information die Du tröpfchenweise preisgibst nicht sagen.

Hallo Rolf,

wenn ich einen Informationsschwall hätte, würde ich den hier auch ausschütten

ich taste mich gerade dran. Ich habe das Delphi-Testprogramm nicht vorsätzlich mit Adminrechten versehen. Die dlls sind in irgendein Verzeichnis kopiert. Ich gehe davon aus, dass die von der Delphi-dll aufgerufene dll keine Kernel-Zugriffe hat (vermutlich eher virtuelle ComPorts unter der Haube).

Wenn es an den Rechten liegt, kann ich dann über eine .exe weiter kommen? Bei den nativen Windowsanwendungen kann man dann "als Administrator ausführen" wählen falls irgendwelche Rechte im Aufruf vererbt werden.

Grüße, Messie