TIA Subtraktion von 2 Realzahlen

[JesperMP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Fast jede Real-Operation kostet mich in irgendeiner Form Genauigkeit.
[..]
Daher sollte man die klassischen Real eigentlich sehr, sehr sparsam einsetzten.

Denkst du nicht dass beim Integer-Division Genauigkeit verloren geht ?
4/3 = 1 (korrekter wäre 1.33333)

Und beim Integer-Multiplikation geht das Ergebniss sehr schnell in die Sättigung.
123 * 456 = -9448 (korrekt wäre 56088).

Egal ob Ganzahl oder Fliesskomma Aritmetik, man muss wissen womit man arbeitet.

 

[schwimmer]

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.

So mach ich es ja auch, ist halt nur umständlich und für mich nicht verständlich warum Unified sich da so kompliziert verhält.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Denkst du nicht dass beim Integer-Division Genauigkeit verloren geht ?
4/3 = 1 (korrekter wäre 1.33333)

Und beim Integer-Multiplikation geht das Ergebniss sehr schnell in die Sättigung.
123 * 456 = -9448 (korrekt wäre 56088).

Egal ob Ganzahl oder Fliesskomma Aritmetik, man muss wissen womit man arbeitet.

Jesper ich denke du weißt auch, dass man bei Int oder Dint vorher überlegt welche Ergebnisse man in welcher Größenordnung erwartet.
Wenn ich dann halt 4/3 brauche, dann erwitere ich halt und teile 400/300.
Ist halt das gleiche Themen bei den Achsen. Siemens arbeitet da auch mit 1µm Auflösung obwohl es die Hardware oft gar nicht hergibt.
Oder bei den Analogwerten werden die 11Bit -Auflösung auch linksbündig abgelegt.

Dein Fazit, dass man Wissen muss, was man tut ist auf jeden Fall richtig

 

[JesperMP]

Jesper ich denke du weißt auch, dass man bei Int oder Dint vorher überlegt welche Ergebnisse man in welcher Größenordnung erwartet.
Wenn ich dann halt 4/3 brauche, dann erwitere ich halt und teile 400/300.

So habe ich vorher auch gemacht.
Besonders wenn ich von S5 nach S7 kam.
Es wird aber kompliziert, und schwierig bis auf unmöglich vorherzusagen welche Werte ins Spiel kommen.
Heute konvertiere ich sofort auf Engineeringwerte, und arbeite im Programm nur mit die Eingineeringwerte.
Das Programm ist vielmehr lesbar und einfacher zu warten.
Beim Zähler, zähle ich mit Ganzzahlen und konvertiere als letzten Schritt ins Engineeringwert.

 

[JesperMP]

Warte mal ....

Wenn ich dann halt 4/3 brauche, dann erwitere ich halt und teile 400/300.

400/300 = 1 mit Ganzzahlaritmetik.

Du meinst 400/3 = 133, und 2 Nachkommastellen sind implizit einverstanden.
Damit sieht man wie man mit diese Verfahren aufpassen muss.

 

[Stadtranduser]

Zuviel Werbung?
-> Hier kostenlos registrieren

123 * 456 = -9448 (korrekt wäre 56088).

Da is ja (noch) nix falsch, wenn man das Ergebnis in UINT interpretiert.

 

[JesperMP]

Da is ja (noch) nix falsch, wenn man das Ergebnis in UINT interpretiert.

Das ändert nur den verwendbare Zahlenbereich von -32768 .. +32767 auf 0 .. 65535.
123*456 = 56088 wird dann korrekt dargestellt.
Ändert man den Formel ein bisschen hat man wieder Probleme.
1234*56 = 3569 (korrekt ist 69104)

 

[Stadtranduser]

Jesper ich denke du weißt auch, dass man bei Int oder Dint vorher überlegt welche Ergebnisse man in welcher Größenordnung erwartet.

1+

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Warte mal ....

400/300 = 1 mit Ganzzahlaritmetik.

Du meinst 400/3 = 133, und 2 Nachkommastellen sind implizit einverstanden.
Damit sieht man wie man mit diese Verfahren aufpassen muss.

Da hast du natürlich recht.

Was man heute auch ganz selten in Programmen sieht, ist dass mit Brüchen gerechnet wird.
Damit gibt es deutlich weniger Rundungs- und Wandlungsfehler. War zu den S5-Zeiten deutlich mehr verbreitet, da damals die Gleitpunktfunktionen verdammt langsam waren.

 

[xMisterDx]

Weil man es sich früher, zu S5-Zeiten, noch leisten konnte jede Anlage bis zur absoluten Perfektion zu optimieren. Und natürlich auch, weil zu S5-Zeiten die Zahl der Messwerte ziemlich eng begrenzt war.
Da konnte man sich das noch erlauben zu überlegen, in welchem Bereich ein Messwert wohl liegen könnte und das dann in Brüche zerlegen...

Heute? Heute hat man einen, vielleicht 2 Standardbausteine, mit denen man Istwerte einliest, skaliert, überwacht. Und ein System muss für alles funktionieren, egal ob Drehzahl 100 oder Drehzahl 100.000rpm.

Würde mich auch interessieren, welche hochgenaue Sensorik es gibt, bei der in der Fehlerrechnung die Genauigkeit der Real-Verarbeitung in der Steuerung eine Rolle spielt. Hab ich jedenfalls noch nie gesehen, dass das eine nennenswerte bzw. überhaupt eine Rolle spielt.

Ist also wieder viel Theorie und akademische Debatte, weil man einfach irgendwas gesagt haben muss

 

[ducati]

REAL macht schonmal immer dann Sorgen, wenn man was ganz Grosses mit was ganz Kleinem verrechnen muss. Und immer dann, wenn jemand zwei REAL Zahlen auf Gleichheit prüft. Und immer dann, wenn man ein Ergebnis ohne Kommastellen erwartet. Oder wenn man meint, ein Konfigurations-DWORD als Zahl in einem REAL abzulegen. Oder wenn man durch Inkonsistenzen der Datenübertragung auf einmal eine "ungültige" REAL-Zahl erhält. Oder wenn bei Datenaustausch zw. verschiedenen Herstellern unterschiedliche REAL-Formate verwendet werden. Oder wenn der Compiler bei automatischer Datentypkonvertierung irgend nen Quatsch macht....
Also, ja normalerweise sind grössere Berechnungen in REAL einfacher zu händeln, man sollte aber wie immer wissen, was man tut. Die Kenntnisse um Datentypen nehmen leider immer mehr ab.

Der Klasiker bei REAL ist und bleibt halt immer wieder ein Zähler. Ist glaub jeder in seinem Leben schonmal reingefallen...

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Der Klasiker bei REAL ist und bleibt halt immer wieder ein Zähler. Ist glaub jeder in seinem Leben schonmal reingefallen...

Und das nette daran ist, dass es teilweise Monate oder sogar Jahre dauert bis der Fehler zuschlägt.

 

[DeltaMikeAir]

Guten Morgen Dieter,

bis der Fehler

warum Fehler, dass nennt man heutzutage "Systemverhalten"

 

[ducati]

Und das nette daran ist, dass es teilweise Monate oder sogar Jahre dauert bis der Fehler zuschlägt.

Bei der IBN ging doch alles, da muss jemand anderes in der Zwischenzeit was gemacht haben.

 

[DeltaMikeAir]

Zuviel Werbung?
-> Hier kostenlos registrieren

Würde mich auch interessieren, welche hochgenaue Sensorik es gibt, bei der in der Fehlerrechnung die Genauigkeit der Real-Verarbeitung in der Steuerung eine Rolle spielt. Hab ich jedenfalls noch nie gesehen, dass das eine nennenswerte bzw. überhaupt eine Rolle spielt.

Es gibt halt Leute, die haben den Anspruch an sich dass bei Berechnungen nicht fast genau das Richtige rauskommt sondern genau das Richtige. Außerdem summieren sich Berechnungsfehler weiter auf. Gut, jeder hat halt einen anderen Anspruch.

Intel hat es in den 90érn auch mal versucht, das REAL-Problemchen ihres Pentium herunterzuspielen.
Pentium-FDIV-Bug

So behauptete Intel nach Bekanntwerden des Fehlers, er würde bei den meisten Anwendern nie auftreten. In diesem Zusammenhang soll von dem bereits oben erwähnten „statistischen Auftreten alle 27.000 Jahre bei normalen Endusern“ die Rede gewesen sein.

Nicht zuletzt erntete Intel für den Fehler viel Schadenfreude. Witze der Art „Wie viele Intel-Mitarbeiter braucht man, um eine Glühbirne zu wechseln? 1,9999983256“ oder „You mean 2.00000000 + 2.000000000 doesn't equal 3.999998456?“ kursierten damals zuhauf.

Hat leider nicht geklappt.

Intel zog Lehren aus dem Vorfall. Andy Grove, Mitbegründer und CEO von Intel, entschuldigte sich in der Presse für den Ärger, den seine Haltung verursacht hat. Es wurde extra für den Umtausch der fehlerhaften CPUs eine Telefonzentrale eingerichtet. Insgesamt stellte Intel für diesen Vorfall 475 Millionen Dollar zur Verfügung, was über der Hälfte des Gewinns im vierten Quartal des Jahres 1994 entsprach. Am Ende wurden ca. eine Million fehlerhafte Prozessoren umgetauscht.

 

[JesperMP]

Die genannte Verhalten bei REALs und INTs muss von der Programmierer bekannt sein.
Man wählt die Verfahren das am besten passt, und man setzt die Massnahmen ein der die potentiellen Fehler auffangen oder begrenzen kann.
In der Praksis sehe ich dass ich 95% mit REALs berechne. Mit INTs ist die Ausnahme.

Oder wenn man durch Inkonsistenzen der Datenübertragung auf einmal eine "ungültige" REAL-Zahl erhält.

Zugegeben, das ist eine bösartige Fehlerquelle.
Dass muss bekannt sein, und man muss dementsprechend Prüfungen einprogrammieren.

 

[ducati]

Zugegeben, das ist eine bösartige Fehlerquelle.
Dass muss bekannt sein, und man muss dementsprechend Prüfungen einprogrammieren.

Ich hatte mal den Fall, das bei PUT/GET eine REAL-Variable im Byte62/63/64/65 lag... Gab immer mal sporadisch Ausfälle...