+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: Abbruchbedingung wird nicht immer eingehalten (/Thread-Abbruchbedingung-wird-nicht-immer-eingehalten)
Abbruchbedingung wird nicht immer eingehalten - myth - 18.03.2013 10:46
Hallo,
ich hab ein kleines Problem mit der Abbruchbedingung einer While-Schleife. In dem Programm wird eine Anfangsspannung, ein Inkrement und eine Endspannung eingegeben. Ziel ist es die Spannung langsam hochzuregeln und den Strom zu messen, bis die Endspannung erreicht ist.
Hier ein Beispiel:
Anfangsspannung: 0,00V
Inkrement: 0,20V
Endspannung: 2,00V
Hier zählt das Programm wie es soll bis 2,00V.
Anfangsspannung: 0,00V
Inkrement: 0,20V
Endspannung: 3,00V
Hier stopt das Programm seltsamerweise bereits bei 2,80V. Aber warum?
Wieso beachtet LV einmal die Abbruchbedingung und dann wiederum nicht?
Gruß myth
RE: Abbruchbedingung wird nicht immer eingehalten - Clyde - 18.03.2013 11:06
Hi myth,
du vergleichst Gleitkommazahlen! 10 mal 0,2 inkrementiert ist für den Computer nicht unbedingt EXAKT 2,0, sondern vermutlich irgendeine Zahl in der Nähe (z.B. 1,99999999295127 oder auch 2,00000000001253 o.ä.).
Dementsprechend muss man bei solchen Vergleichen aufpassen, da genau diese wie von dir beobachteten Phänomene entstehen. Wenn du als Zielspannung 1,99 bzw. 2,99 eingibst, beendet dein Programm bei 2V bzw. 3V.
Gruß
Clyde
RE: Abbruchbedingung wird nicht immer eingehalten - jg - 18.03.2013 11:10
Schon mal was von der "Ungenauigkeit" von Gleitkommazahlen gehört?
0,2 kann im Float oder Double Format nicht exakt dargestellt werden, weswegen es bei mehreren Additionen dann zu "Rundundsfehlern" kommt.
Gruß, Jens
RE: Abbruchbedingung wird nicht immer eingehalten - Lucki - 18.03.2013 13:24
..und die Lösung wäre: Zur "Endspannung" vor dem Vergleich noch 0.001 addieren. Wenn Du dann als Anfansgspannung, Inkrement und Endspannung immer Werte mit nicht mehr als 2 Stellen nach dem Komma eingibst, können solche Zufälligkeiten überhaupt nicht mehr passieren.
RE: Abbruchbedingung wird nicht immer eingehalten - myth - 18.03.2013 15:32
Alles klar, vielen Dank!
RE: Abbruchbedingung wird nicht immer eingehalten - Kiesch - 21.03.2013 14:49
Ich persönlich würds ja vermutlich einfach in mV darstellen und dann I32 benutzen ^^
Spart man sich den Stress mit den Gleitkommazahlen.
RE: Abbruchbedingung wird nicht immer eingehalten - Lucki - 21.03.2013 15:34
Wichtig ist vor allem zu wissen, was man will.
Beispiel: Bereich 0..10, Schrittweite 3
Bereichsende ist 10, Schritte um diesen Wert herum sind 9 und 12.
Wenn, wie hier, das Bereichsende selbst kein Schrittwert ist, will man dann, dass der letzte Schritt innerhalb oder außerhalb des Bereiches liegt? Beides lässt sich machen (endweder vor oder nach dem Inkrementieren die Bedingung abfragen).
Und wie man am Beispiel sieht, wird man diese Entscheidung auch bei Verwendung von ganzen Zahlen nicht automatisch los. Der "Stress" des Entscheiden müssen bleibt also bestehen.
RE: Abbruchbedingung wird nicht immer eingehalten - Kiesch - 21.03.2013 16:50
@Lucki
Oder will man stattdessen als letzten Wert immer 10V messen. ^^ (das entsprechende Bereichsende)
Entsprechend angepasst muss die Auswertung sein. Trotzdem dürfte das verwenden von Integers das etwas erleichtern (da man tatsächlich auf Gleichheit oder größer / kleiner prüfen kann).
Alternativ sollte man bei Real Zahlen entsprechend Gleichheit über Differenzbildung und Betragsbildung und dann Prüfung auf kleiner als ein Schwellwert, zum Beispiel wie weiter oben angemerkt 0,0001) durchführen. Das sollte in aller Regel die Rundungsfehler beim übertragen von "exakten" Zahlen von Dez nach Binär übersteigen.
RE: Abbruchbedingung wird nicht immer eingehalten - Lucki - 21.03.2013 19:37
(21.03.2013 16:50 )Kiesch schrieb: Oder will man stattdessen als letzten Wert immer 10V messen. ^^ (das entsprechende Bereichsende)Dann würde ich das so machen: Nicht Eingabe von:
Anfang, Ende, Schrittweite
sondern:
Anfang, Ende, Anzahl_Samples
Schrittweite wird berechnet, das können dann (bei ungeschickten Vorgaben) allerdings krumme Werte mit vielen Dezimalstellen nach dem Komma sein.
Die Rampenfunktion macht genau das, und die wäre meine erste Wahl. Erzeugt ein fertiges Array, statt While-Schliefe + Abbruchprüfung bei jedem Durchlauf braucht man nur noch eine For-Schleife mit Indexeingang - wenn überhaupt. Das ganze Gedöns wie die Schleife beenden wird hinfällig.