Hallo,
ich möchte eine DLL einbinden. Der Prototyp der Funktion lautet
CRCDLL_API unsigned short fnCRCDLL(unsigned short ui16_CRC16, char *pucBuf, unsigned short ui16_NumberOfBytes)
[
attachment=48013]
Ich bekomme aber folgende Fehlermeldung, wenn ich das Konfigurationsfenster für den Aufruf der Bibliothek verlasse.
[
attachment=48014]
Die DLL wurde auf Windows 7 mit
Visual Studio 2010 64bit geschrieben aber als 32 bit gespeichert/gewandelt.
LabVIEW 2013 32 bit ist auf Windows XP. Als Aufrufkonvention habe ich sdtcall gewählt.
Ich habe daraufhin "Microsoft Visual C++ 2010 x86 Redistributable" installiert, in der Hoffnung, die nötige Dateien zu erhalten. Nach Runterladen von der geforderten Datei kommt diese Fehlermeldung (msvcr110d.dll wurde in den Ordner System32 von Windows XP kopiert, da gehören die DLLs ja hin):
[
attachment=48015]
Als Fehlermeldung zeigt mir LabVIEW, dass die angegebene Bibliothek nicht gefunden oder nicht geladen werden kann, also meine eigene erstelte CRCDLL.dll.
Eine der Test-DLLs von "Einbinden einer DLL in LabVIEW.pdf" vom Tutorial dieses Forums klappt => Copy and paste. (lvPointer.dll)
[
attachment=48016]
Was übersehe ich?
Gruß von
Klausenwirt.
(13.01.2014 17:49 )Klausenwirt schrieb: [ -> ]Hallo,
ich möchte eine DLL einbinden. Der Prototyp der Funktion lautet
CRCDLL_API unsigned short fnCRCDLL(unsigned short ui16_CRC16, char *pucBuf, unsigned short ui16_NumberOfBytes)
Die DLL wurde auf Windows 7 mit Visual Studio 2010 64bit geschrieben aber als 32 bit gespeichert/gewandelt. LabVIEW 2013 32 bit ist auf Windows XP. Als Aufrufkonvention habe ich sdtcall gewählt.
Ich habe daraufhin "Microsoft Visual C++ 2010 x86 Redistributable" installiert, in der Hoffnung, die nötige Dateien zu erhalten. Nach Runterladen von der geforderten Datei kommt diese Fehlermeldung (msvcr110d.dll wurde in den Ordner System32 von Windows XP kopiert, da gehören die DLLs ja hin):
Nein, die Visual C Runtimes sind SxS assemblies und gehören ganz wo anders hin! Wo, überlässt Du am Besten dem Installer, alles andere wird garantiert Murks und Chaos!
Aber! Es wäre sinnvoll um beim Erstellen der DLL darauf zu achten NICHT die Debug Version zu builden!!!! Das D in msvcr110
d.dll weist darauf hin, dass Deine DLL als Debugversion kompiliert ist und demgemäss auch die Debugversion der C Runtime haben will.
"Microsoft Visual C++ 2010 x86 Redistributable" enthält nur die Releaseversion der Runtime Library und die Debug Version kriegst Du nur auf den Computer wenn Du die ganze Visual C Umgebung installierst. Das kann nicht Sinn der Übung sein und wäre zudem illegal.
Ich habe jetzt die DLL als Releaseversion vorliegen. Damit lieferte mir die Funktion bei einmaligem Aufruf den richtigen Rückgabewert. Allerdings kam die Fehlermeldung 1097 (Es trat ein Ausnahmefehler im externen Code auf, der vom Knoten "Aufruf externer Bibliotheken" aufgerufen wurde. Diese Ausnahme kann Fehler im Speicher von LabVIEW verursacht haben. Speichern Sie alle Projekte an einem neuen Ort und starten Sie LabVIEW erneut. Überprüfen Sie die Werte, die an den Knoten zum Aufruf externer Bibliotheken übergeben wurden.).
Wenn ich die Aufrufkonvention zu C ändere, dann kommt keine Fehlermeldung. Ich hab gelesen, dass mit dieser Aufrufkonvention LabVIEW die Daten aus dem Stack holt, mit stdcall macht das die DLL (wenn sie so programmiert wurde). Ich lass das Programm jetzt mal ne Stunde laufen, vielleicht kommt es ja zum Stackoverflow.
Es ist jetzt wirklich so, dass LabVIEW immer wieder abstürzt. Dabei muss ich das Programm nicht mal debuggen, schon beim Bearbeiten stürzt es ab. Wenn ich die DLL aber mit der anderen Konvention aufrufe, kommt gleich die Fehlermeldung.
Was kann ich da tun?
(15.01.2014 14:32 )Klausenwirt schrieb: [ -> ]Es ist jetzt wirklich so, dass LabVIEW immer wieder abstürzt. Dabei muss ich das Programm nicht mal debuggen, schon beim Bearbeiten stürzt es ab. Wenn ich die DLL aber mit der anderen Konvention aufrufe, kommt gleich die Fehlermeldung.
Was kann ich da tun?
Die DLL sehr gut anschauen, vor allem den C Source Code. Wenns beim Aufrufen einer DLL crasht und kracht, dann macht die DLL Dinger die sie nicht tun sollte. Da kann LabVIEW nichts daran tun, und Dir erzählen was Du falsch machst ist auch nicht drin. Du darfst mir aber glauben dass das Aufrufen von DLLs in LabVIEW ohne Crash sehr gut möglich ist, wenn die DLL gut debugged ist und keinen Pfusch macht. Die Call Library Node selber tut was man ihr sagt und wenn das stimmt mit dem was die DLL erwartet geht es ganz einfach und gut.
Aber statt mit calling Conventions zu probieren, solltest Du das Headerfile anschauen und ganz einfach feststellen welche es sein sollte. Die Konfiguration der Call Library Node hat viele Variablen und diese durch Trial und Error zu eruieren ist ziemlich zeitraubend und nur sinnvoll wenn du 110% sicher bist dass die DLL selber keinen einzigen Fehler enhält. Das scheint mir aber nicht gewährleistet und ist auch etliche Male schwerer dann die Call Library Node gemäss den Headerinformationen korrekt zu konfigurieren.
Eine Variable in der DLL war int, seit sie auf uint16 geändert wurde, gehts. LabVIEW ist seitdem nicht mehr abgestürzt.
Vielen Dank!