Step 7 Rundungsfehler

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habs mal mit roher Gewalt gelöst: Schleife zum verschieben, Schleife zum Addieren.
Da es im PLCSIM läuft kann ich allerdings nichts über die Laufzeit, die es auf der 416er haben wird sagen.
Ich werde das ausprobieren.

@Onkel:
Es geht nicht darum wie genau der Mittelwert ist, da reichen vermutlich 2%, weil genauer misst der Durchflussmesser ohnehin nicht, es ging um das wegdriften wenn man millionenmale nur Werte abzieht und dazuzählt.
In einer ersten Schleife wird das Speicherfach mit den 2160 Werten gefüllt. Dabei könnte man ja schon mitaddieren. Und von da an weg nur mehr: ältester Wert subtrahieren, neuester Wert addieren.

Deinen Gedanken mit: "den aktuellen Mittelwert anstatt des ältesten Wertes von der Summe zu subtrahieren." verstehe ich leider nicht.
Das Ergebnis soll ein gleitender 6h Mittelwert sein.

 

[LargoD]

Ich habs mal mit roher Gewalt gelöst: Schleife zum verschieben, Schleife zum Addieren.

Das Verschieben kannst Du Dir doch sparen, wenn Du das ganze als Ringpuffer anlegst.
Gruß
Erich

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Verschieben kannst Du Dir doch sparen, wenn Du das ganze als Ringpuffer anlegst.
Gruß
Erich

Mann bin ich dämlich!
Danke dass Du mich darauf hingewiesen hast.

 

[PN/DP]

Wenn Zeit für eine Verschiebe-Schleife war, dann ist auch Zeit, dabei gleich die Addition mit zu erledigen, wenn sowieso jedes Element angefasst wird.

Also ich würde "vorsichtshalber" "regelmäßig" eine komplett-Addition der Werte machen, weil der Puffer nicht vor Zugriffen von außen geschützt ist. Es reicht, daß ein Wert im Puffer versehentlich/unbemerkt verändert wird - ab dann würde das Weiterrechnen mit nur In-Wert und Out-Wert einen bleibenden Fehler haben.

Harald

 

[borromeus]

Danke Harald, aber im PCS7 schreibt keiner auf die Instanz.
;-)

So meine werten, ich habe Ergebnisse.
Ich habe es schön auf Ringpuffer umgebaut und gleich mal einen Baustein der die REAL x 100.0 in DINT wandelt und laufen mitaddiert/subtrahiert.
Es driftet auseinander.
Warum weiss ich noch nicht, einen Programmierfehler schliesse ich fast aus, weil man ja kaum was falsch machen kann.

Wen es interessiert, ein paar Screenshots.

Man sieht auf Seite 6 des PDF's schön, dass die Werte exakt gleich sind, nur die Summen auseinandergehen.

Zu den Zeiten: das ganze ist um den Faktor 100x schneller, also ein Umlauf im Puffer braucht 216 Sekunden (statt 6h).

Hat wer eine Erklärung - aus der Entfernung?

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

verwendest Du die APL? da gibt's doch nen Baustein MEANTIME ...

ansonsten bietet Wikipedia ja auch gute Nachhilfe
https://de.wikipedia.org/wiki/Gleitender_Mittelwert



Mittelwert = Mittelwert_alt + Istwert / Anzahl - Istwert_erster / Anzahl

Mittelwert_alt = Mittelwert im letzten Zyklus
Anzahl= Anzahl der zu mittelnden Werte
Istwert_erster = erster Wert des Zeitraumes

dafür spricht die einfachere Berechnung, dagegen ein evtl. auftretender Fehler... bzw. wie Wikipedia auch schreibt:

Da es sich hierbei um eine rekursive Berechnung handelt, entspricht dies einem Filter mit unendlicher Impulsantwort. In der Praxis kann solch ein Filter nur mit Werten endlicher Genauigkeit implementiert werden, sodass durch Effekte wie Rundungsfehler oder Auslöschung das Filter instabil werden kann.

aber ausprobieren würd ichs mal

PS: der MEANTIME speichert intern nur 32 Werte:

Der Baustein kann intern maximal 32 Vergangenheitswerte speichern. Bei einem längeren Zeitfenster wird eine Datenreduktion vorgenommen.

also vermutlich nicht so das, was Du suchst.

 

[ebt'ler]

Wie schon richtig gesagt wurde gilt:

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.

Daher: Wenn du bei der Summenbildung über Real-Werte bereits 7 Vorkommastellen erreicht hast, können die Nachkommastellen nicht mehr berücksichtigt werden. Sie fallen raus und führen zu Fehlern.

Bei DINT sollte der korrekte Wert errechnet werden.

 

[PN/DP]

aber im PCS7 schreibt keiner auf die Instanz.
;-)

Man soll nie "Nie" sagen...
Du weißt nicht, welche anderen Programmierer sich noch in dem Firmennetzwerk tummeln und im Netzwerk 'rum-PUTen oder mit HMI 'rumspielen, bevor sie ihre S7-Kommunikation im Griff haben. Ich würde nicht wollen, daß meine Anlage von sowas bleibende Schäden davonträgt.

Außerdem: Instanz! Ich würde den Puffer nicht in einem IDB unterbringen - da dürfte man ja nie mehr was am FB ändern bzw. den IDB in die SPS einspielen ohne die Aktualdaten und damit die letzten 6 Stunden zu verlieren. Wichtig: die Summe muß in dem selben DB liegen wie der Puffer, damit die wenigstens zusammen genullt werden, wenn der DB neu geladen wird.

Harald

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hat wer eine Erklärung - aus der Entfernung?

wie machst Du denn die Rundung vom REAL auf DINT ?

Gruß

 

[borromeus]

verwendest Du die APL? da gibt's doch nen Baustein MEANTIME ...

ansonsten bietet Wikipedia ja auch gute Nachhilfe
https://de.wikipedia.org/wiki/Gleitender_Mittelwert

ohne diese ganzen Schleifen, Ringspeicher, sonstwas kommt folgende Formel aus:

Mittelwert = Mittelwert_alt + Istwert / Anzahl - Istwert_alt / Anzahl

_alt = Wert im letzten Zyklus
Anzahl= Anzahl der zu mittelnden Werte

dafür spricht natürlich die wirklich einfache Berechnung, dagegen ein evtl. auftretender Fehler... bzw. wie Wikipedia auch schreibt:



aber ausprobieren würd ichs mal

PS: der MEANTIME speichert intern nur 32 Werte:



also vermutlich nicht so das, was Du suchst.

Servus Ducati.
Das Wiki nützt da nichts, weil ich einen 6h Mittelwert brauche (Behörde schreibt das vor).

 

[borromeus]

Wie schon richtig gesagt wurde gilt:



Daher: Wenn du bei der Summenbildung über Real-Werte bereits 7 Vorkommastellen erreicht hast, können die Nachkommastellen nicht mehr berücksichtigt werden. Sie fallen raus und führen zu Fehlern.

Bei DINT sollte der korrekte Wert errechnet werden.

Das ist so nicht richtig.... abgesehen davon geht es ja um 2 verschiedene Methoden der Summenbildung. Einmal in einer Schleife mittels REAL, einmal durch Addition / Subtraktion von DINT Werten von der aktuellen Summe, siehe #1.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

wie machst Du denn die Rundung vom REAL auf DINT ?

Gruß

einfach RND

also genaugenommen:

      L     #Summe_DI
      L     D [AR1,P#0.0]
      -D    
      T     #Summe_DI                   //alten Wert von Summe abziehen

      L     #PV_IN
      L     1.000000e+002
      *R    
      RND   
      T     D [AR1,P#0.0]
      L     #Summe_DI
      +D    
      T     #Summe_DI                   //neuen Wert zur Summe dazuaddieren

 

[ducati]

gelöscht wegen Quatsch...

 

[ducati]

einfach RND

jo... naja also beim Runden nach DI machst Du Fehler und beim Rechnen mit REAL auch... welcher Fehler größer ist, kann ich schlecht abschätzen.

zu Deinem Problem stellt sich die Frage, ist es nur eine Abweichung zwischen den beiden Varianten oder läuft eine Variante wirklich dauerhaft immer weiter davon?

Gruß.

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nun bei einem 6h Mittelwert fällt immer der Wert von vor 6h raus....
Also stellen wir uns vor wir haben

10.000.000 im ältesten Wert
und alle anderen sind 1
Dann ist der 6h Mittelwert 10.002.159 / 2160 = 4630

einen Zyklus später ist er aber 1 weil der 10.000.000 Wert rausgefallen ist.

 

[borromeus]

jo... naja also beim Runden nach DI machst Du Fehler und beim Rechnen mit REAL auch... welcher Fehler größer ist, kann ich schlecht abschätzen.

zu Deinem Problem stellt sich die Frage, ist es nur eine Abweichung zwischen den beiden Varianten oder läuft eine Variante wirklich dauerhaft immer weiter davon?

Gruß.

Es läuft die DINT Variante davon, ich befürchte ich habe doch einen Fehler im Code.
Das traue ich mich ja fast nicht posten.... ich glaube die Schleife ist um einen Wert zu lange.

 

[ducati]

Es läuft die DINT Variante davon, ich befürchte ich habe doch einen Fehler im Code.
Das traue ich mich ja fast nicht posten.... ich glaube die Schleife ist um einen Wert zu lange.

Dann würde ich sagen, Feierabend machen und morgen geht's weiter

 

[ebt'ler]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das ist so nicht richtig.... abgesehen davon geht es ja um 2 verschiedene Methoden der Summenbildung. Einmal in einer Schleife mittels REAL, einmal durch Addition / Subtraktion von DINT Werten von der aktuellen Summe, siehe #1.

Dann füge doch noch eine dritte Variante hinzu. Und zwar Schleife mittels DINT. Wenn der ursprüngliche Realwert nicht mehr als zwei Kommastellen besitzt und du diesen mit 100 multiplizierst, dann begehst du keinen Rundungsfehler.
In diesen Fall sollte die Berechnung unabhänig vom Rechweg sein. Ob nun via Schleife oder via Addition / Subtaktion, beides sollte das gleiche Ergebniss liefern.

Wie man bei deiner PDF auf Seite 3 und 6 sieht, ist bei Real-Werten der Genauigkeitsbereich bereits ausgeschöpft. 1903784,0 und 1895165.0 haben bereits 7 Vorkommastellen. Ab dem Zeitpunkt in dem die Stellen ausgenutzt sind wird beim Addieren (in der Schleife) der Nachkommaanteil nicht mehr richtig Berücksichtigt. Daher Läuft der Wert weg. (EDIT: zu kleineren Werten hin)
Das siehst du auch daran, dass der Real-Summenwert kleiner als der Vergleichswert wird.

Bei DINT hast du hingegen alle Stellen berücksichtigt. Du musst nur aufpassen den maximalen Wertebreich nicht zu Überschreiten, falls der Mittelwert mal über einen längeren Zeitrahmen gebildet werden soll.

Korrigier mich, wenn ich jetzt falsch liege. Aber so denk ich mir das erstmal, nach den vorliegenden Informationen.

 

[ducati]

Nun bei einem 6h Mittelwert fällt immer der Wert von vor 6h raus....
Also stellen wir uns vor wir haben

10.000.000 im ältesten Wert
und alle anderen sind 1
Dann ist der 6h Mittelwert 10.002.159 / 2160 = 4630

einen Zyklus später ist er aber 1 weil der 10.000.000 Wert rausgefallen ist.

Ja, da hast Du recht...

ich hab bei Wiki auch mal wieder Tomaten auf den Augen gehabt. Istwert_alt ist verkehrt, es muss Istwert(t-n) heissen, also quasi genau das,was Du auch machst...

ich lösch mal den Quatsch aus meinen letzten Posts

Trotzdem ist die Formel noch etwas einfacher...
hier jetzt hoffentlich richtig:


Mittelwert = Mittelwert_alt + Istwert / Anzahl - Istwert_erster / Anzahl

Mittelwert_alt = Mittelwert im letzten Zyklus
Anzahl= Anzahl der zu mittelnden Werte
Istwert_erster = erster Wert des Zeitraumes


Gruß.

 

[borromeus]

Meine Herren, Danke, das Problem ist gelöst.
Die Schleife war um einen Wert zu lang. Ich habe im InstanzDB gesehen, dass der "letzte" Wert auf 0.0 blieb und dachte die Schleife ist zu kurz, das war aber der Sample-Time Zähler. :-(
habe ich vor Stunden also falsch geändert- jetzt stimmt es wieder.

Also Ergebnis aller Bemühungen von euch:

Der DINT - Summierer, der den ältesten Wert subtrahiert und den neuesten addiert funktioniert perfekt.
Der reale Fehler ist minimalst.

Somit kann man sich das aufaddieren in einer Schleife wirklich ersparen.


Für den Fehler schäme ich mich, kann aber Spott ertragen.
;-)