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 

Datentypproblem (Bug?)



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!

07.06.2007, 16:24
Beitrag #1

Jörg Offline
LVF-Neueinsteiger


Beiträge: 6
Registriert seit: Aug 2006

8.00
2006
kA


Deutschland
Datentypproblem (Bug?)
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
07.06.2007, 22:02
Beitrag #2

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.696
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datentypproblem (Bug?)
' 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?

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
08.06.2007, 08:39
Beitrag #3

Jörg Offline
LVF-Neueinsteiger


Beiträge: 6
Registriert seit: Aug 2006

8.00
2006
kA


Deutschland
Datentypproblem (Bug?)
' 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.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
08.06.2007, 16:35
Beitrag #4

thomas.sandrisser Offline
LVF-SeniorMod


Beiträge: 1.298
Registriert seit: Sep 2005

xxxx
2005
EN

78759
United States
Datentypproblem (Bug?)
Guckst du:
http://de.wikipedia.org/wiki/IEEE_754
Webseite des Benutzers besuchen Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
08.06.2007, 22:38
Beitrag #5

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.696
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datentypproblem (Bug?)
' 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"

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.06.2007, 08:55
Beitrag #6

Jörg Offline
LVF-Neueinsteiger


Beiträge: 6
Registriert seit: Aug 2006

8.00
2006
kA


Deutschland
Datentypproblem (Bug?)
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


Angehängte Datei(en) Thumbnail(s)
   
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
Anzeige
11.06.2007, 09:23
Beitrag #7

jg Offline
CLA & CLED
LVF-Team

Beiträge: 15.864
Registriert seit: Jun 2005

20xx / 8.x
1999
EN

Franken...
Deutschland
Datentypproblem (Bug?)
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:

   

MfG, Jens

Wer die erhabene Weisheit der Mathematik tadelt, nährt sich von Verwirrung. (Leonardo da Vinci)

!! BITTE !! stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort!

Einführende Links zu LabVIEW, s. GerdWs Signatur.
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.06.2007, 09:24
Beitrag #8

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.696
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datentypproblem (Bug?)
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

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.06.2007, 09:28
Beitrag #9

IchSelbst Offline
LVF-Guru
*****


Beiträge: 3.696
Registriert seit: Feb 2005

11, 14, 15, 17, 18
-
DE

97437
Deutschland
Datentypproblem (Bug?)
' 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. Tongue

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. Unsure

Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
11.06.2007, 16:32
Beitrag #10

Jörg Offline
LVF-Neueinsteiger


Beiträge: 6
Registriert seit: Aug 2006

8.00
2006
kA


Deutschland
Datentypproblem (Bug?)
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
Alle Beiträge dieses Benutzers finden
Diese Nachricht in einer Antwort zitieren to top
30
Antwort schreiben 


Gehe zu: