Step 7 Rundungsfehler

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Liebe Mitstreiter,

ich möchte einen gleitenden 6h-Mittelwert bilden.
Dieser besteht aus 2160 Realzahlen.
Diese werden in einer Tabelle gespeicht und immer wenn ein neuer Wert kommt wird der in der Tabelle eingetragen und der älteste Wert fällt heraus.
Um nun den Mittelwert zu bilden muss ich alle Werte zusammenzählen und durch 2160 dividieren.
Ich dachte nun, ich kann es mir sparen jedesmal diese Werte in einer Schleife zusammenzuzählen sondern einfach den neuen Wert von der Summe zu addieren und den der rausfällt zu subtrahieren.

Nun die Frage: gleichen sich die Rundungsfehler aus oder wird die Summe beginnen in eine Richtung wegzudriften. Dieser 6h-Mittelwert läuft bis zum Ende der Anlage, dh. der wird nie neu angelegt durch einen Trigger oder ähnlich, dh sollte es einen Drift geben wird der Mittelwert irgendwann bedrohlich falsch sein.

Was meint ihr?

 

[Aventinus]

Zu bekommst also alle 10s einen neuen Messwert. D.h. du hast zur Adition eines Messwertes 4,62ms Zeit. Bei einer angenommenen Zykluszeit von 50ms müsstest du pro Zylus 10 Werte aufddieren um rechtzeitig fertig zu werden bevor die der neue Wert reintrudelt. So musst du nicht alle Werte in einem Zyklus addieren.

Die von dir beschriebene Variante würde ich nicht machen, das wär mir gefühlt zu heiß.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
pauschal lässt sich das m.E. nicht beantworten.
Vom Effekt her müßte das Ergebnis aber gleich bleiben (Addition der 2160 Werte bringt ja auch einen Rundungsfehler).

Gruß
Larry

 

[borromeus]

Larry,
hmm, klar aber da ist der Fehler vermutlich im Promillebereich und im anderen Fall denke ich, könnten es 10er Potenzen werden.... wenn man lange Zeit wartet.

 

[borromeus]

Zu bekommst also alle 10s einen neuen Messwert. D.h. du hast zur Adition eines Messwertes 4,62ms Zeit. Bei einer angenommenen Zykluszeit von 50ms müsstest du pro Zylus 10 Werte aufddieren um rechtzeitig fertig zu werden bevor die der neue Wert reintrudelt. So musst du nicht alle Werte in einem Zyklus addieren.

Die von dir beschriebene Variante würde ich nicht machen, das wär mir gefühlt zu heiß.

Danke, daran dachte ich auch, da das aber im PCS7 abläuft und im Regelfall dort die kleinste Zeitscheibe 20ms ist war mir das zu heiss.
Irgendwer verschiebt den Baustein dann in die 1s Ablaufgruppe und nichts geht mehr.
Normal sollte ein PCS7 Baustein in jeder Ablaufgruppe funktionieren.

 

[Aventinus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich kenne PCS7 nicht. Kannst du auslesenin welcher Zeitschiebe der Baustein läuft? Wenn ja kannst du ja auch dynamisch berechnen wie viele Werte zu pro Zyklus addieren musst - einfach mal so philosophiert....

 

[Ralle]

Wie wäre es, den gleitenden Mittelwert wie oben beschrieben zu berechnen, im "Normalablauf" und zu einer bestimmten Zeit (Schichtwechsel, Mitternacht o.ä.) einen kompletten Mittelwert über alle Werte neu zu berechnen. Dann hält sich der Fehler evtl. in engeren Grenzen.

PS: So viele Realzahlen aufzuaddieren, das macht, je nach Größe, ohnehin einen riesigen Fehler, weil zum Schluß eine große Zahl steht, die dann geteilt wird. Real kann ja nicht allzuviele Stellen (7?) darstellen.

 

[EXOR]

Der mögliche Fehler ist vor allem von der Differenz der Realzahlen abhänig. Grundsätzlich würde ich keine Realzahlen addieren / subtrahieren, wenn die Differenz kleiner als die sechste Nachkommastelle ist.

Z.B. 1.123457 - 1.123456 = 1x10^-6 ist als Realwert 1.1234569549560546875 - 1.12345600128173828125 = 9.5367431640625 × 10^-7

Das ist ein Fehler von knapp 5%.

Gerade wenn du Zahlen der selben Grössenordnung über eine länger Zeit aufsummierst, musst du zuerst berechnen, ab wann der Fehler für deine Anwendung zu gross wird.

Abhilfe bietet in TIA der LREAL oder in Classic der LREAL aus der OSCAT Library.

 

[Aventinus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wäre die Wandlung in DINT nicht eine Möglichkeit? Hängt natürlich von den Zahlenwerten ab, aber da bist du evt. besser dran.

 

[Larry Laffer]

Der Ansatz von Aventinus ist m.E. nicht schlecht - in welchem Zahlen-Bereich bewegen sich denn die Werte, die aufaddiert werden.

Gruß
Larry

 

[borromeus]

Nun, das sind Durchflüsse im Bereich 1500 - 3000 m³/h.
Die Summe wird daher einige 10^6 betragen.
Da zähle ich einen 10^3 dazu- das macht mir also weniger Sorgen. Das muss ja nicht auf die Kommastelle genau werden.

Eine Lösung mit DINT und wie oben beschrieben neuesten Wert addieren, ältesten Wert subtrahieren führt m.E. zum gleichen (befürchteten) Driftverhalten.

@Ralle: Danke, aber wenn ich es um Mitternacht mache kann ich es ja alle 10s auch machen.

Vielleicht hat wer eine Idee wie man so viele Werte zeitoptimiert addieren kann. Mir fällt da fast nichts ein.

 

[Aventinus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn du Zahlenwerte zwischen 0 und 3000 hast macht das bei 2160 Werten maximal 6480000, also für DINT kein Problem. Du kannst sogar noch zwei Kommastellen mitnehemn, also Werte zwischen 0 und 300000. Dann landest du im schlechtesten Fall bei 648000000 und bist immer noch im Zahlenbereich des DINT. Dann funktioniert auch noch die Variange mit dazurechnen und abziehen.

 

[Larry Laffer]

Also bei den Werten sehe ich das genau wie Aventinus.
Die Rechne-Methode könnte dann wieder deine eigene sein (also einmal alles addieren und ab dann remove_oldest und add_newest).
Das sollte im absolut vertretbaren Bereich bleiben ...

Gruß
Larry

 

[borromeus]

Danke meine Herren,

Wenn ich alle 10s so eine Rechnung mache, wo mir die 3te Kommastelle abhanden kommt, habe ich doch nach 3.153.600 Rechnungen in einem Jahr einen Fehler von >3000. In 10 Jahren ist die Abweichung >30.000.
Bezogen auf die Summe wäre das ~1% Abweichung. Ich denke damit kann man gut leben, wenn es wirklich nur so wenig ist.

Ich werde mal schauen wie lange es dauert 2160 Werte in einer Schleife zu addieren oder es eben doch zu staffeln auf zB 10 Zyklen.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

.. Ich werde mal schauen wie lange es dauert 2160 Werte in einer Schleife zu addieren oder es eben doch zu staffeln auf zB 10 Zyklen.

Willst du wirklich deine 2160 Werte jedes mal komplett neu summieren? Was hindert dich daran, die Summe mit jedem neuen Wert einfach nur zu aktualisieren?

 

[Chräshe]

Hallo Borromeus,

wie schnell muss sich dein Wert „aktualisieren“?
Ist der nur für eine Anzeige?

Eventuell kannst du die Mittelwertbildung kaskadieren.
Du bildest den Mittelwert aus 10 Messungen. Dieses Ergebnis nimmst du, für einen zweiten Mittelwert mit den 216 Werten.

Ganz raffiniert wird es, wenn du beim 2. Mittelwert nicht mit 216, sondern nur mit 215 Werten + den letzten 10 Werten aus der 1. Kaskade rechnest…

Gruß
Chräshe

 

[JesperMP]

Der Aufgabe:

Max 3000 m³/h.
2160 Messwerte.
Genaugkeit soll besser als 1% sein.
​

Mein Lösungsvorschlag:
Durchfluss als DINT in FIFO Buffer abspeichern mit Kommaverschiebung von 2 Stellen. (Max L#300000 entspricht 3000.00 m³/h).
Alle 2160 DINT Werte summieren (Max L#648000000). Der Maxwert von DINT (L#2147483647) wird nicht überschritten.
Den summierte Wert mit L#2160 dividieren.
Dann in REAL umwandeln und durch 0.01 multiplizieren.
Der Genauigkeit sollte dann besser als 0.01% sein.

Da addition viel weniger CPU Zeit nimmt als multiplikation oder division, kann viellieicht den gesammte FIFO Buffer in 1 Scan summiert werden.
2160-mal +D dauert 1.7 ms auf ein 315'er, 0.4 ms auf ein 317'er.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Willst du wirklich deine 2160 Werte jedes mal komplett neu summieren? Was hindert dich daran, die Summe mit jedem neuen Wert einfach nur zu aktualisieren?

Weil ich Angst habe, dass der Summenwert im Laufe der Jahre davondriftet- durch Rundungsfehler.
Ich muss das ja eh nur alle 10s machen.... ich habe mal nachgeschaut, eine 416er macht einen Befehl (L,T, +R, etc) in 30-60ns... wenn ich sage in der Schleife sind max 20 Befehle und das ganze 2160 mal sind das schlappe 2ms.
Da sich im PCS7 unter 0,5s aber eh nichts tut sollte das klappen.

Ich bin aber an einer gesicherten Theorie, dass der Wert nicht abdriftet weiter sehr interessiert.
Ich werde das auch ausprobieren mit den DINT, ist ja in 5min programmiert, und dann lasse ich das im Schnelldurchlauf (~10ms) mal einen Tag laufen.

 

[Aventinus]

Weil ich Angst habe, dass der Summenwert im Laufe der Jahre davondriftet- durch Rundungsfehler.
Ich bin aber an einer gesicherten Theorie, dass der Wert nicht abdriftet weiter sehr interessiert.
Ich werde das auch ausprobieren mit den DINT, ist ja in 5min programmiert, und dann lasse ich das im Schnelldurchlauf (~10ms) mal einen Tag laufen.

Du wirst keine Rundunsfehler beim Berechnen haben wenn du mit DINT rechnest. Den einzigen Fehler den du machst ist bei der Wandlung von REAL auf DINT, der fließt in dein Ergebnis ein wenn du den Wert zu deiner Summe addierst und hebt sich wieder auf wenn du ihn nach den 6h wieder abziehst.

 

[Onkel Dagobert]

.. Den einzigen Fehler den du machst ist bei der Wandlung von REAL auf DINT ..

Wobei man auch mal darüber nachdenken sollte, wie genau der Realwert eigentlich ist. Macht es überhaupt Sinn, bei einer Größenordnung von 3000m³/h Nachkommastellen zu berücksichtigen?

Eine ganz andere Möglichkeit wäre es, den aktuellen Mittelwert anstatt des ältesten Wertes von der Summe zu subtrahieren. Dann muss man die einzelnen Werte garnicht speichern und wegdriften kann auch nichts. Allerdings ist das dann auch kein richtiger Mittelwert.