03.07.2008, 09:35
(Dieser Beitrag wurde zuletzt bearbeitet: 03.07.2008 09:36 von jg.)
Beitrag #1
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
Fehler bei der Property "ScaleLegend"
Hallo,
ich habe hier noch eine seltsamen Bug auf der Pfanne (getestet mit IntensitiyGraph und WaveformGraph):
ErrorPropertyNodeScaleRange.vi (Größe: 35,87 KB / Downloads: 348)
Zur Fehlerbeschreibung und Reproduktion:
Sehr seltsame Dinge passieren, wenn ich die PropertyNode XScale-Range auslese: Unter bestimmten Umständen kommt beim Wert "Minimum" absoluter Blödsinn raus (s. Screenshot).
Wann funktioniert es richtig:
1. Offset = 0 -> keine Probleme
2. Multiplier ist ganzzahlig (also 1, 2, 3) oder irgendetwas der Art 1/2^n (also 0.5, 0.25, 0.125). => keine Probleme.
In allen anderen Kombinationen wird der Wert Scale.Minimum falsch ausgegeben, wenn er eigenlich Null sein sollte.
Anleitung zum VI (LV 8.5.1):
-VI starten.
-X-Achse autoskalieren -> OK
-Minimum der x-Achse auf 0,00 setzen -> OK
- X-Scale-Muliplier auf einen nicht ganzzahligen oder einen Wert ungleich 1/2^n setzen.
- Autoskalieren der x-Achse -> Ausgabe Range ist OK.
- Jetzt Minimum der x-Skala wieder per Hand auf Null setzen -> ScaleRange -> Minimum ist ungleich Null!
Hilfe! Wieso??
Etwas verwirrend finde ich auch, das der EventCase "ScaleRange" und die PropertyNode Scale unterschiedliche Werte liefern (einmal die unskalierten ohne Offset und Multiplier, einmal mit Offset und Multiplier).
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.
|
|
|
03.07.2008, 10:38
Beitrag #2
|
|
|
03.07.2008, 11:02
Beitrag #3
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
Fehler bei der Property "ScaleLegend"
Au Mann, ich war mal wieder betriebsblind, du hast recht, zwar nicht E-99, aber immerhin E-16 oder E-17:
Trotzdem ist es (finde ich) inkonsistent (und somit wieder mal ein ungeliebtes "Feature"): Wenn der Mutliplier entsprechend gewählt ist, kommt "exakt" Null zurück, wenn nicht, dann etwas, was praktisch Null ist. Und wenn ich es, so wie im Bsp, aus dem Event "Scale-Range" zurückrechne, kommt "exakt" Null raus.
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.
|
|
|
16.07.2008, 08:11
(Dieser Beitrag wurde zuletzt bearbeitet: 16.07.2008 08:11 von rolfk.)
Beitrag #4
|
rolfk
LVF-Guru
Beiträge: 2.305
Registriert seit: Jun 2007
alle seit 6.0
1992
EN
2901GG
Niederlande
|
Fehler bei der Property "ScaleLegend"
' schrieb:
Au Mann, ich war mal wieder betriebsblind, du hast recht, zwar nicht E-99, aber immerhin E-16 oder E-17:
[attachment=40610:Image01.png]
Trotzdem ist es (finde ich) inkonsistent (und somit wieder mal ein ungeliebtes "Feature"): Wenn der Mutliplier entsprechend gewählt ist, kommt "exakt" Null zurück, wenn nicht, dann etwas, was praktisch Null ist. Und wenn ich es, so wie im Bsp, aus dem Event "Scale-Range" zurückrechne, kommt "exakt" Null raus.
MfG, Jens
Schaust Du mal bei Fliesskommaarithmetik und die Probleme die man dabei hat um das in einem binären Computer richtig zu representieren. Wurde hier und auf allen anderen LabVIEW (und C, Pascal, VB, Delphi, .......) Foren schon zum x-ten Mal durchgekaut. Kurz gesagt musst Du bei Fleisskommazahlarithmetik immer von einem Epsilon ausgehen das abhängig von der Representation ist. Bei float (32Bit Fliesskommazahl oder in LabVIEW SGL) ist das irgendwo rund E-9 und bei double (64Bit Fliesskommazahl oder LabVIEW DBL) eben rund E-15. Bei mehrstufigen Berechnungen können sich diese Fehler noch aufschaukeln und daher wesentlich grösser werden.
Allgemeine Lösung besteht nicht, ausser Berechnungen mit Fliesskommazahlen soviel möglich vermeiden. Aber für die Skalierungsparameter ist eine gewisse Berechnung unumgänglich also kann LabVIEW da auch nicht wirklich etwas machen.
Rolf Kalbermatter
|
|
|
16.07.2008, 09:05
(Dieser Beitrag wurde zuletzt bearbeitet: 16.07.2008 09:08 von jg.)
Beitrag #5
|
jg
CLA & CLED
Beiträge: 15.864
Registriert seit: Jun 2005
20xx / 8.x
1999
EN
Franken...
Deutschland
|
Fehler bei der Property "ScaleLegend"
' schrieb:Schaust Du mal bei Fliesskommaarithmetik und die Probleme die man dabei hat um das in einem binären Computer richtig zu representieren. Wurde hier und auf allen anderen LabVIEW (und C, Pascal, VB, Delphi, .......) Foren schon zum x-ten Mal durchgekaut. Kurz gesagt musst Du bei Fleisskommazahlarithmetik immer von einem Epsilon ausgehen das abhängig von der Representation ist. Bei float (32Bit Fliesskommazahl oder in LabVIEW SGL) ist das irgendwo rund E-9 und bei double (64Bit Fliesskommazahl oder LabVIEW DBL) eben rund E-15. Bei mehrstufigen Berechnungen können sich diese Fehler noch aufschaukeln und daher wesentlich grösser werden.
Allgemeine Lösung besteht nicht, ausser Berechnungen mit Fliesskommazahlen soviel möglich vermeiden. Aber für die Skalierungsparameter ist eine gewisse Berechnung unumgänglich also kann LabVIEW da auch nicht wirklich etwas machen.
Rolf Kalbermatter
Hallo, Rolf,
danke noch mal für die "Ermahnung" mit Fließkommazahlen, das ist mir schon alles vollkommen klar. Wie schon gesagt, war mal wieder betriebsblind, dass ich das mit ...E-16 nicht gesehen habe.
Habe das Ganze für mich auch inzwischen als "Feature" zurückgestuft und nicht mehr als Bug.
MfG, Jens
EDIT: Das die Event-Struktur aber andere (unskalierte) Werte herausgibt, ist wohl bei NI als "Bug" akzeptiert, CAR #49882.
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.
|
|
|
| |