TIA Subtraktion von 2 Realzahlen

buddelboehme

Level-2
Beiträge
34
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich versuche im Programm zwei Real-zahlen zu subtrahieren. Leider bekomme ich immer ein sehr merkwürdiges Ergebnis, sobald das Ergebnis annähernd null sein sollte.
Hat jemand eine Idee wie ich dieses Problem umgehen kann?
 

Anhänge

  • NW1.png
    NW1.png
    16,6 KB · Aufrufe: 116
32-Bit Realzahlen haben ca. eine Auflösung von 7 Zahlen (vor+nach Komma). Wenn es dann noch exakter werden soll, wirst du um LREAL (also 64-Bit) nicht herum kommen. TIA zeigt dir in deinem Fall die Zahl in Exponentialschreibweise an, die weiteren Zahlen hinter ...2 kommen dann durch die Ungenauigkeit von Real zustande.
 
Naja, ich hatte meine letzte Mathestunde 1994 und bis jetzt nicht mehr wirklich viel damit zu tun. Aber danke für die Aufklärung.

Ich denke E-05 bedeutet ich muss noch 5 Nullen vor dranhängen!;)
 
Wenn du das Problem umgehen möchtest kannst du je nachdem welche Genauigkeit du erreichen möchtest deinen Wert mit 10^X multiplizieren zu INT umwandeln und anschließend wieder zurückwandeln und wieder dividieren.
(Damit würdest du die Ungenauigkeit, welche durch den Datentyp kommt umgehen.)

Das hängt aber natürlich auch davon ab, was du weiterführend mit der Variable machen möchtest.
Prüfen auf Gleichheit ist bei einer REAL-Variable generell nie zuverlässig.
 
Wenn du das Problem umgehen möchtest kannst du je nachdem welche Genauigkeit du erreichen möchtest deinen Wert mit 10^X multiplizieren zu INT umwandeln und anschließend wieder zurückwandeln und wieder dividieren.
(Damit würdest du die Ungenauigkeit, welche durch den Datentyp kommt umgehen.)
Nö, nicht wirklich. Die Genauigkeit oder Ungenauigkeit bleibt dieselbe. Oder wird sogar schlechter, besonders wenn zwischendurch nach INT gewandelt wird. (Vermutlich meintest du DINT?)
 
Kommt ganz drauf an, wie genau mein Messwert sein muss.
Wenn mich da nur ein tausendstel interessiert, dann kann ich entsprechend Runden.

Ist bei Addition/ Subtraktion halb so wild.
Wird aber interessant, wenn man Multiplizieren/ Dividieren möchte.
Da ist real nicht immer optimal.
Kommt wie gesagt aber immer darauf an, was man mit dem Wert machen möchte.
Habe da eher mit Wiegezellen bei ner Inline-Kontrolle zu tun.

War vielleicht aber auch ein bisschen übers Ziel rausgeschossen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn mich da nur ein tausendstel interessiert, dann kann ich entsprechend Runden.
Naja, mit runden erhöht sich nicht die Genauigkeit.
Ist bei Addition/ Subtraktion halb so wild.
Kommt auf den Anwendungsfall an. Pauschal würde ich nicht sagen, dass ein gerundeter Wert in Kombination mit Additionen / Subtraktionen "halb so wild ist".
 
Is das Problem dass den Wert auf ein HMI dargestellt wird ?
In ein Siemens HMI wird automatisch eine Rundung verwendet damit wenn z.B. 2 Nachkommastellen eingestellt ist, sieht man nicht 0.00002164 und nicht 2.164E-05 sondern 0.00.
 
Zuletzt bearbeitet:
Real ist eine Crux.
Die meisten Messwerte kommen nicht im Real-Format in die Steuerung.
Meist sind es INT oder DINT.
Fast jede Real-Operation kostet mich in irgendeiner Form Genauigkeit.
Und die Fehler sind nicht konstant, sondern abhängig vom Zahlenwert.
Daher sollte man die klassischen Real eigentlich sehr, sehr sparsam einsetzten.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Kommt ganz drauf an, wie genau mein Messwert sein muss.
Wenn mich da nur ein tausendstel interessiert, dann kann ich entsprechend Runden.
Runden erhöht nicht die Genauigkeit, im Gegenteil
Bitte beachten: Genauigkeit, Auflösung, Anzeige-Auflösung/Darstellung sind 3 verschiedene Dinge

Ist bei Addition/ Subtraktion halb so wild.
Wird aber interessant, wenn man Multiplizieren/ Dividieren möchte.
Wahrscheinlich Begriffe verwechselt und was anderes gemeint?
Es ist genau umgekehrt: Addition/Subtraktion sind problematisch, wenn die beteiligten Werte um einige Größenordnungen auseinanderliegen, z.B. 1234567.0 + 0.01 = 1234567.0 ( ! typischer Programmierfehler bei Verbrauchszählern)
Multiplikation/Division ist immer möglich ohne wesentlichen Genauigkeitsverlust (im Rahmen der Genauigkeit des Datentyps) - dafür ist REAL/FLOAT erfunden worden. Bei Division durch "scheinbar" "glatte" Werte entstehen aber auf einmal "unerwartet" viele Nachkommastellen - weil das Ergebnis immer zum nächstliegenden in REAL darstellbaren Wert gerundet wird, z.B. 2.0 / 10.0 = 0.200000002980...
 
Daher sollte man die klassischen Real eigentlich sehr, sehr sparsam einsetzten.
Problem gibt es dann wieder mit Unified. INT oder DINT mit Nachkommastelle anzeigen ist nur über Skripte für die Ausgabe und auch für die Eingabe von Werten möglich. Einfach mal eine Variable mit Nachkommastelle anzeigen, nur bei Real-Werten möglich. Vielleicht hat sich das ja mit V20 geändert, das kann ich nicht beurteilen.
 
Problem gibt es dann wieder mit Unified. INT oder DINT mit Nachkommastelle anzeigen ist nur über Skripte für die Ausgabe und auch für die Eingabe von Werten möglich. Einfach mal eine Variable mit Nachkommastelle anzeigen, nur bei Real-Werten möglich. Vielleicht hat sich das ja mit V20 geändert, das kann ich nicht beurteilen.
Manchmal macht es auch Sinn für das HMI eine eigene Variablen zu verwenden.
Da kannst du Wandeln wie du lustig bist und kannst aber in der SPS mit dem "richtigen" Wert weiterarbeiten.
 
Zurück
Oben