INFO: Dieses Forum nutzt Cookies...
Cookies sind für den Betrieb des Forums unverzichtbar. Mit der Nutzung des Forums erklärst Du dich damit einverstanden, dass wir Cookies verwenden.

Es wird in jedem Fall ein Cookie gesetzt um diesen Hinweis nicht mehr zu erhalten. Desweiteren setzen wir Google Adsense und Google Analytics ein.


Antwort schreiben 

DSO-2090 LabVIEW 8.5, 8.6



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!

01.07.2010, 20:14
Beitrag #6

rolfk Offline
LVF-Guru
*****


Beiträge: 2.305
Registriert seit: Jun 2007

alle seit 6.0
1992
EN

2901GG
Niederlande
DSO-2090 LabVIEW 8.5, 8.6
' 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. Big Grin

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!

Rolf Kalbermatter
Technische Universität Delft, Dienst Elektronik und Mechanik
https://blog.kalbermatter.nl
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
Antwort schreiben 


Nachrichten in diesem Thema
DSO-2090 LabVIEW 8.5, 8.6 - Y-P - 30.06.2010, 06:39
DSO-2090 LabVIEW 8.5, 8.6 - rolfk - 30.06.2010, 08:15
DSO-2090 LabVIEW 8.5, 8.6 - Y-P - 01.07.2010, 18:12
DSO-2090 LabVIEW 8.5, 8.6 - rolfk - 01.07.2010 20:14

Gehe zu: