LabVIEWForum.de

Hallo. Ich habe folgendes Problem. (LabVIEW- Version: 8.2)

Ich rufe eine Funktion in einer DLL auf, der ich bestimmte Paramter übergebe . Einer davon ist ein double-Wert. Und genau mit diesem Wert gab es Probleme.
Denn, nicht bei jedem Wert konnte die Funktion aus der DLL erfolgreich ausgeführt werden. Hinter den Werten die nicht gingen versteckte sich auch kein wirkliches Muster, so dass ich daraus nichts ableiten konnte.
Durch Zufall konnte ich das Problem lösen. Aber für mich ergibt dies keinen Sinn.
Folgendes habe ich gemacht:
Von dem eingegebenen double-Wert habe ich den Betrag gebildet und zum nächsten Wert aufgerundet. Damit ging das dann. Aber das Lustige ist, die Werte vor der Betragsbildung und nach dem Nearest sind identisch. Der Datentyp bleibt auch weiterhin vom Typ double.
Bsp: 6000 -> || -> [] -> 6000

Für mich ist das ein unverständliches Phänomen! Hat evtl. jemand schon ähnliche Erfahrungen gemacht oder hat vielleicht jemand einen Rat woran das liegen kann?

Übrigens, an der DLL lag es nicht. Ich hatte eine C-Anwendung geschrieben in der die DLL geladen und die Funktion aufgerufen wird. Da gab es von anfang an keine Probleme. Aber da sehe ich ja auch was mit meinen Variablen passiert oder welchen Datentyp sie haben.

Vielen Dank!

Mit besten Wünschen
Jörg

' schrieb:Denn, nicht bei jedem Wert konnte die Funktion aus der DLL erfolgreich ausgeführt werden.

Wie macht sich denn das Nicht-Erfolgreich bemerkbar? Falsche Berechnungswerte? Programmabsturz?

' schrieb:Wie macht sich denn das Nicht-Erfolgreich bemerkbar? Falsche Berechnungswerte? Programmabsturz?

Bemerkbar macht sich das anhand des Rückgabewertes der aufgerufenen Funktion, der im Fehlerfall !=0 ist.

Guckst du:
http://de.wikipedia.org/wiki/IEEE_754

' schrieb:Denn, nicht bei jedem Wert konnte die Funktion aus der DLL erfolgreich ausgeführt werden.

Kannst du das Problem genauer darstellen?

Fließkommazahlen kann man z.B. normalerweise nicht mit = vergleichen. Eine berechnete Zahl (MyValue=2+2=4; also 4) und ihre Vorgabe (die Zahl "4") müssen nicht zwangsweise bit-identisch sein. Der Vergleich "MyValue=4" kann unter Umständen (aber natürlich nicht immer) zu false führen. Bei ganzen Zahlen kommt das wohl eher sehr selten vor. Bei Zahlen mit 7, 8 oder 9 Stellen kann das schon öfters sein. Daher soll man ja z.B. so abfragen: "abs(MyValue-4)<0,00001"

Hallo IchSelbst,

das Problem liegt nicht an einem Vergleich von Werten. Das mache ich nicht. Worum es geht ist einfach, dass ich einer DLL-Funktion Paramter übergebe und das "Problemkind" ist ein double-Wert. Letztendlich steuere ich eine Messkarte von Acquitek damit an und der Wert gibt an, um wieviel Samples ein Triggerdelay vorhanden sein soll. Jetzt aber nicht wundern das dies ein double-Wert ist, obwohl Samples sowieso nur ganzzahlig sein können, denn mit der Funktion die ich aufrufe, können noch andere Aktionen ausgeführt werden, wo der double-Wert notwendig ist.
Dieses Triggerdelay gebe ich in us an, so dass ich eine Umrechnung machen muss. Ich dividiere den angegebenen Wert durch 1e6 (aufgrund der Basis von us) und multiplizere diesen Wert dann mit der Abtastrate (20e6 Hz) - siehe calcWatisamples.jpg im Anhang. Die Werte die ich erhalte sind auch immer "ganzzahlig".
Noch mal das Bsp. mit den 6000 von oben. Dort übergebe ich 300 us und erhalte letztendlich ein Triggerdelay von 6000 Samples. Dies ist einer der Werte die nicht gingen. Wenn ich jetzt wie oben den Betrag bilde und aufrunde oder wenn ich den Wert in integer konvertiere und daraus wieder ein double-Wert mache funktioniert die ganze Geschichte.
Die Frage die sich für micht stellt ist, was passiert mit dem double-Wert oder wie verwaltet LabVIEW dahingehend die Variablen?
Eine C-Anwendung die ich geschrieben hatte funktioniert auf jeden Fall mit der Umrechnung problemlos.

Gruß
Jörg

Hallo, Jörg,

also bei so einer Umrechnung kann eigentlich gar nicht exakt 6000 rauskommen.

Stell mal die Anzeige entsprechend Screenshot um, dann siehst du, was ich meine:

[attachment=7047]

MfG, Jens

Hallo Jörg,

ich hab dein - respektive das von LV - Problem mal untersucht und bin zu folgendem Ergebnis gekommen.

Ausgehend von deiner Aussage, dass bei "300 / 1000000 * 20000000" nicht genau 6000 herauskommt, also ohne Nachkommastellen ungleich 0, hab ich mir mal den Rundungsmode der FPU angekuckt. Dabei hab ich folgendes festgestellt:
[code]procedure TMyForm.Button1Click(Sender: TObject);
var d1,d2,d3,d4: single;
begin

' schrieb:also bei so einer Umrechnung kann eigentlich gar nicht exakt 6000 rauskommen.

Wenn der Anwender/Kunde sagt, bei C geht das, dann hat er zuerst mal Recht.

Zitat:Stell mal die Anzeige entsprechend Screenshot um, dann siehst du, was ich meine:

Da schließe ich doch gleich draus, dass der Rundungsmode tatsächlich auf Down steht.

Hallo,

alles klar! Die Erklärung ist natürlich korrekt. Darauf hätte ich selber kommen müssen! :angry2:
Vielen Dank!

Mit besten Wünschen
Jörg