DSO-2090 LabVIEW 8.5, 8.6

Hallo,
habe seit ein paar Tagen das DSO-2090 von Conrad und möchte es mit LabVIEW benutzen. Hab LabVIEW 8.6 und 8.5 zur Verfügung. Leider bekomme ich, wenn ich das auf der Disc hinzugefügte LabVIEW-VI benutzen möchte folgende Fehlermeldung:

Fehler 1097 ist bei Knoten zum Aufruf externer Bibliotheken in DSO2090.vi aufgetreten

Mögliche Ursachen:

LabVIEW: Es trat ein Ausnahmefehler in dem durch den Knoten "Aufruf externer Bibliotheken" aufgerufen externen Code auf. Diese Ausnahme könnte Fehler im Speicher von LabVIEW verursacht haben. Speichern Sie alle Projekte an einem neuen Ort und starten Sie LabVIEW neu.

Die Anweisungen haben wir befolgt, hilft aber nix. Was kann ich tun, um das Programm zum Laufen zu bekommen? Ich vermute, dass es ein Versionsproblem ist, da, gemäß anderen Forumseinträgen das Gerät mit LabVIEW 8.0 und 8.2 kompatibel ist.

VG und danke für die Hilfe,
LV-Praktikant

Anzeige

Ich glaube nicht, dass es an der LabVIEW-Version liegt.
Habt Ihr die DLL auf Eurem Rechner und die VIs richtig angeschlossen, bzw. ausgeführt?

Gruß Markus

Ich stimme mit Markus überein. Die Chance das die LabVIEW Version der Grund ist ist eher klein. Das scheint ein Problem in der DLL selber zu sein, Wahrscheinlich hat die ein Problem mit etwas auf Deinem Computer und macht dann einen Zugriffsfehler. Der andere mögliche Grund, dass das VI einen falschen Parameter oder zu kleinen Buffer an die DLL Funktion gibt ist ja eher unwahrscheinlich da diese VIs angeblich in anderen LabVIEW Versionen "problemlos" laufen, obwohl der zu kleine Buffer bleibt eine Möglichkeit. Das braucht nämlich nicht immer zu crashen, aber ein Fehler wäre es in jedem Fall.

Hallo,

erstmal danke für eure schnellen Antworten.
Der Fehler ist wohl tatsächlich, dass ein zu kleiner Buffer verwendet wird. Jedenfalls erhält man, wenn man Error Checking auf Maximum setzt, die folgende Fehlermeldung :

The method in the DLL overwrote past the end of space allocated for one of its parameters. This may have corrupted memory.


Intern passiert das beim Funktionaufruf von dseGetChannelData.

Hilft das irgendwie weiter?

VG,
LV-Praktikant

Ich kenne mich leider mit Conrad-Oszis nicht aus und schon gar nicht mit den mitgelieferten DLLs und ich verwende auch (zum Glück) so gut wie keine DLLs (nur im Notfall), so dass ich so ein Problem auch noch nicht hatte.
Ich denke aber, dass Dir da rolfk weiterhelfen kann.

Gruß Markus

' schrieb:Ich kenne mich leider mit Conrad-Oszis nicht aus und schon gar nicht mit den mitgelieferten DLLs und ich verwende auch (zum Glück) so gut wie keine DLLs (nur im Notfall), so dass ich so ein Problem auch noch nicht hatte.
Ich denke aber, dass Dir da rolfk weiterhelfen kann.

Gruß Markus

Leider nicht wirklich. Ich kenne die Oszis auch nicht und habe im Moment auch kein Interesse sie kennenzulernen. Grundsätzlich hat wohl derjenige der diese Treiber programmiert hat etwas nachlässig programmiert. Der meistvorkommende Fehler in dieser Hinsicht ist dass die DLL einen Array oder Stringpointer erwartet um irgendwelche Information hineinzuschreiben und dass der Programmierer den dazu nötigen Buffer im LabVIEW Diagram nicht korrekt alloziert hat (Initialize Array). Im Gegensatz zu LabVIEW Code wo LabVIEW selber alle nötigen Speicher alloziert, verkleinert und vergrössert und wieder frei gibt wann immer das notwendig ist, kann das bei einem DLL Aufrug nicht automatisch funktionieren. Die DLL hat keine Möglichkeit um Speicher nach Bedarf anzufordern und an LabVIEW zurückzugeben und LabVIEW seinerseits hat keine Möglichkeit um von der DLL zu erfahren wieviel Speicher sie denn gerne als Parameterbuffer erhalten möchte. Also muss der LabVIEW Programmierer das explizit selber tun, auf Basis der Kenntnis was die betreffende Funktion benötigt (was natürlich irgendwo dokumentiert sein muss).

Im Extremfall wird irgendwo gar kein Speicher vorab alloziert und die DLL schreibt frisch fröhlich in den nicht dafür allozierten Speicher und überschreibt irgendetwas anderes. Das kann crashen aber muss nicht immer gleich und manchmal auch gar nicht, aber überspitzt gesagt kann die Mondfase schon bewirken dass es plötzlich doch crasht. Oder der Programmierer alloziert zwar einen Buffer aber hat sich vertan in der Berechnung wieviel dass sein muss, oder hat gar nichts berechnet sondern einfach einen Wert genommen der bei seinen Tests gut funktionierte aber im echten Einsatz plötzlich zu klein sein kann.

Das zu finden ist meist eine ziemlich akribische Kleinarbeit und verlangt meistens auch ein gründliches Einlesen in die API Dokumentation der DLL und da habe ich im Moment weder die Zeit dazu noch die Lust, schon gar nicht für etwas das ich nicht selbst benötige. Sorry!