LabVIEWForum.de

Hallo Leute,

ich habe ein Problemchen mit DLL, die ich selber gebastelt habe.
Und zwar:
Ich kommuniziere über PCanUsb-Dongle mit einem externen Gerät. Peak liefert Quellcode, aus dem man sich DLL basteln kann und z.B. in LV einbinden kann. Genauso habe ich es gemacht und es funktioniert auch auf dem Rechner mit LV. Nun habe ich aus dem ganzen Projekt EXE erstellt und auf dem anderen Rechner installiert. Leider will er nicht. Er schreibt folgenede Fehlermeldungen (siehe Bilder).
1) Wo kann das Problem stecken?
2) Warum brauche ich Runtime von MS-Visual Studio (msvcr80d.dll) ?
3) Ich habe übrigens Debug-Modus für EXE aktiviert, aber es hat nichts gebracht. Was kann ich mit dem Debug-Modus alles machen?

Grüsse, Eugen

Waahnsinn - diese Fehlermeldung hab ich noch ueberhaupt nie gesehen :-(
Das einzige was mir an der Stelle einfaellt ist, dass du die DLL von PCanUsb-Dongle NICHT als Supported File in die EXE eingebaut hast. Sollten in der DLL Abhaengigkeiten drinnen sein, kompiliert er diese normalerweise automatisch mit (diese werden standardmaeßig im data Ordner abgelegt).

Wenn eine EXE mit der Option Debugging erstellt wird, bleibt das Blockdiagramm eines jeden VIs in der Exe erhalten, sodass vom HOST Vi aus das Blockdiagramm im Highlightmodus verfolgt werden kann.

Wenn das Debuggen und etwaige Fehler ausgemerzt sind (z.B. fehlende VIs die dynamisch aufgerufen werden, DLLs oder auch relative Pfade die nicht korrekt sind), muss die EXE unbedingt neu kompiliert werden mit dem deaktivierten Debugging Parameter.
Dadurch wird die Performance der EXE wieder gesteigert UND Sie benoetigt weniger Speicherplatz.

So habe Debug weggeklickt, die DLL ist in Supportd Files eingefügt. Trotzdem bekomme ich diese Meldungen.

Hat noch jemand Ideen?

Grüsse, Eugen

<div align="left">

' schrieb:So habe Debug weggeklickt, die DLL ist in Supportd Files eingefügt. Trotzdem bekomme ich diese Meldungen.

Hat noch jemand Ideen?

Grüsse, Eugen

</div>
<div align="left">nicht wirklich. sieht nach einem richtigen problem aus, interessant

Vorweg: ich hab keine Lösung, ich hab nur ein paar Tips, was man probieren könnte

ich würde nun mal folgendes versuchen:
wenn du Visual Studio hast, kannst du mal versuchen eine kleine exe zu schreiben, die eine Funktion in deiner DLL aufruft um zu sehen, ob die DLL auf dem Zielsystem lauffähig ist. Zur not reicht auf VBA, aber da kann ich nur auf die MSDN verweisen, ich hab keine Ahnung, wie man DLLs in VBA aufruft, haber aber schonmal irgendwo gesehen, dass es geht. ... [Visual C++/C# 2005 Express gibts ja für lau ...]

ich würde mir mal eine "Dummy DLL" bauen, mit den gleichen Funktionsaufrufen, etc, die nix weiter macht, als leere Methoden aufzurufen. Mit der DLL würde ich dann mal auf dem Zielsystem testen, ob der Fehler immer noch auftritt.

Wenn ich das jetzt richtig verstehe, hast du die DLL ja selber gebaut. Gab's dabei irgendwelche Warnungen?

Generell, selber eine DLL bauen und mit LabVIEW laufen lassen ist immer schwierig. Man hat ja immer 2 Fehlerquellen: LabVIEW oder die DLL, wo fängt man an zu suchen?

Fehlerquelle Nr. 1, die mir einfällt:
die meistenr Treiber-Hersteller haben ihre Treiber mal irgendwann zu Zeiten von LabVIEw 5.1 entwickelt und speichern einfach nur die alten VIs mit der aktuellen LV-Version ab, und verkaufen das dann als "aktuelle" Treiber ...
Wenn nun die DLL auf Speicher von LabVIEW zugreift, und der Quellcode entsprechend alt ist, dann ist es gut möglich, dass der Hund da begraben liegt. In der Zwischenzeit hat sich das Speicher-Modell von LV mehrfach geändert ...

Man erkennt das u.a. an folgenden Code-Zeilen</div>

[code][left]#include "extcode.h"

// zum Beispiel
typedef struct {

Also Leute,

ich habe das Problem gelöst.

Es liegt an der dynamischen Einbindung der RunTime von MS Visual Studio. Die RunTime soll bei der Erstellung der DLL statisch gelinkt werden!!!, sonst ist man von der Version der MS Visual Studio abhängig und die msvcr80d.dll soll ins System32-Verzeichnis. Danach Systemstart, also alles zu umständlich gemacht.

Wenn man aber die RunTime statisch dazulinkt (und nicht dynamisch, wie im PDF-Dokument "Using external code"!!!), dann ist die DLL zwar ein wenig grösser, aber man hat keine weiteren Probleme.

Das gleiche gilt nicht nur für LabVIEW, sondern für andere Entwicklungsumgebungen, in denen man fremde DLLs einbindet.

Grüsse, Eugen