Step 7 SCL Berechnung wird auf Vielfaches von 20 gerundet?

Karabullo

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

ich habe eine Frage zu einer Berechnung in SCL.
Der Quellcode lautet

di_GearIn := REAL_TO_DINT(r_Grad_pro_Takt * 1000.0 * (1.0 - r_GearFaktor));

r_Grad_pro_Takt ist fest auf 360.0
Der r_GearFaktor ist laut Onlineansicht 3.897116e-004, dieser ändert sich (aber in dem Bereich bleibt er, also sehr klein)

Wenn ich das ausrechne komme ich auf 359859,703824
Siemens kommt auf 359860

Mit ist bekannt das ich scheinbar bei einer Real-Berechnung nur 6 Dezimalstellen zur Verfügung habe.
Aber warum rundet Siemens das Ergebnis zu geschätzen 90% auf ein Vielfaches von 20?
Denn ich bekommen als Endwert der Zahl zu 90% Werte 00, 20, 40, 60, 80.
Und nein, einen solchen Wert ausgerechnet wäre ien absoluter Zufall, das kann eigentlich kaum passieren (Logischerweise nur in 5% der Fälle)
Nur sehr selten ist dieser Wert mal z.B. 16 oder 41, also deutlich genauer.

Kann mir das jemand erklären?

Danke!
 
Wieso denkst du es wird immer auch ein Vielfaches von 20 auferundet? Wenn du auf 359859,703824 kommst und S7 auf 359860 ist das ja nur auf die nächste Ganzzahl aufgerundet?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Korrekt, war ein unglückliches Beispiel, aber das einzige zu dem ich konkrete Daten per Screenshot hatte.
Warum ich das denke?
Ganz einfach, weill ich es beobachten kann im SCL.
Beispielwerte die ich sehen kann
359860
359820
359880
359920
359900
359940
359820
359840
359860
359880

Und dann, ganz selten mal sowas wie 359841
 
Ich sags mal mit der Step7-Hilfe:

REAL_TO_DINT
Runden des IEEE-REAL-Wertes auf DINT.
Wenn der Wert kleiner als -2_147_483_648 oder größer als 2_147_483_647 ist, dann wird die OK-Variable gleich FALSE gesetzt.


DINT ist ja nun mal eine Zahl ohne Komma, also was soll Step7 da machen --> Komma abschneiden und entsprechend runden.

Ich meine, das liegt eher Wert deines Input und/oder der ausgeführten Umrechnung.
 
Deine Tabelle:

Interessant wäre mal der Input-Wert, der Gera-Faktor und der dazu passende Output-Wert.
 
Wo kommt denn r_GearFaktor (die einzige Variable in der Berechnung) her? Von einem Analogeingang? Welche Auflösung hat der?
Möglicherweise ist r_GearFaktor ja schon "gequantelt".

Harald
 
Hi, der r_GearFaktor komt aus einer anderen Berechnung von zwei Real-Werten.

r_GearFaktor:= (r_Ausgleich / REAL_TO_DINT((r_AVGof20_DM) * 10));

r_Ausgleich ist ein Real-Wert zwischen 0 und 20, ohne Werte hinter dem Komma (wird so belegt)
r_AVGof20_DM ist ein Real-Wert mit 3 beliebigen Stellen hinter dem Komma, kommt aus dem FB433 MC_MeasuringInput (T-CPU)

Kann ein Problem hier das casten REAL_TO_DINT der zweiten Real-Variable sein? Denn Sinn macht das für mich nciht, scheint eine Leiche meines Vorgängers zu sein.

Danke, Daniel
 
Ich kann Dein Problem nicht nachvollziehen.
Irgendwas muß mit Deinem r_GearFaktor nicht stimmen.
Von r_GearFaktor haben wegen der angesprochenen REAL-Auflösung zwar nur die ersten 2 bis 3 Ziffern 3.89xxxxe-004 Einfluß auf das Ergebnis, doch es können auch "unrunde" Ergebnisse 359861, 359862, 359863 ... 359869 'rauskommen.

Harald
 
Joop hat recht, lies dir das mal genau durch.

Es wäre an dieser Stelle auch sehr hilfreich wenn du uns ein "falsches" Ergebnis samt aller dazugehörigen Berechnungsparameter (Zahlenwerte) posten würdest... dann könnten wir besser sagen ob und wo ein Rundungsfehler auftritt.
Values! Or it didn't happen! :wink:

r_GearFaktor:= (r_Ausgleich / REAL_TO_DINT((r_AVGof20_DM) * 10));
Da hebt sich bei mir auch die Augenbraue. Ich arbeite zwar selber nicht mit SCL, aber...
Wenn man den REAL-Wert r_AVGof20_DM * 10 (nicht 10.0) rechnet, dann in einen DINT rundet und
den zweiten REAL-wert r_Ausgleich dann noch durch den erhaltenen DINT dividiert....
Da frag ich mich schon wie da überhaupt was rauskommen kann... :confused:

r_Grad_pro_Takt ist fest auf 360.0
r_GearFaktor ist laut Onlineansicht 3.897116e-004, dieser ändert sich (aber in dem Bereich bleibt er, also sehr klein)
di_GearIn: Wenn ich das ausrechne komme ich auf 359859,703824
r_Ausgleich ist ein Real-Wert zwischen 0 und 20, ohne Werte hinter dem Komma (wird so belegt)
r_AVGof20_DM ist ein Real-Wert mit 3 beliebigen Stellen hinter dem Komma, kommt aus dem FB433 MC_MeasuringInput (T-CPU)
r_GearFaktor:= r_Ausgleich / (r_AVGof20_DM * 10);
3.897116e-004 = 0..20 / (r_AVGof20_DM * 10);
r_AVGof20_DM müsste demnach zischen 0 für (r_Ausgleich = 0) und 5132,0001765 (r_Ausgleich = 20) liegen
Damit hätten wir einen Überblick über die Wertebereiche.

Du könntest jetzt (wie von Joop vorgeschlageen) versuchen die Formeln anzupassen und die Zahlwerte (am Zahlenstrahl) näher aneinander zu bringen.
di_GearIn := r_Grad_pro_Takt * 1000.0 * (1.0 - (r_Ausgleich / (r_AVGof20_DM * 10) ); -----Beide Formeln
359859,703824 = 360 * 1000 * ( 1 - (20 / (5132,0001765*10) ) ------In Zahlen
359859,703824 = 360000 * (1 - 0.0003897116) --------Keine gute Kombination

Du könntest die Formel aber zb so umformen, damit die Werte näher beieinander liegen
Nur ein Beispiel für eine mögliche Umformung.
359859,703824 = 360 * (1000 - (2000 / 5132,0001765))
di_GearIn := DINT_TO_REAL(r_Grad_pro_Takt * (1000.0 - ((r_Ausgleich*100.0) / r_AVGof20_DM) ) );

Versuch mal ob du damit genauer bist.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Die rundungfehler sitz in(1.0 - 3.897116e-004) sie beilage
Seihe auch die hilfe in Step7 bei das format REAL.
Hier ein link nach Siemens support : http://support.automation.siemens.c...objaction=csview&extranet=standard&viewreg=WW

Anhang anzeigen 26057
Die Ursache für das Rundungs-Phänomen des TE ist NICHT der Rundungsfehler wegen der beschränkten REAL-Auflösung. Bei der Subtraktion gehen zwar 3 Ziffern von r_GearFaktor verloren, der Rundungsfehler müßte aber das 500-fache betragen, damit das Ergebnis am Ende um 20 springt.

Für die beobachteten 20-er Sprünge müssen Quantelungen bzw. Sprünge in r_GearFaktor die Ursache sein.

r_GearFaktor müsste sich um ca. 0.00006 (von 0.000389xxxx zu 0.000333xxxx) verringern, damit sich das Ergebnis um 20 (von 359860 zu 359880) erhöht.

Ein Umformen der Formel erhöht nicht die Rechengenauigkeit oder Auflösung, es ist ja schon jede Ganzzahl in 1-er Schritten als Ergebnis möglich, wenn r_GearFaktor sich nicht in so großen Sprüngen ändern würde.

Nach meiner Meinung liegt die Ursache der Ergebnis-Sprünge in der Berechnung von r_GearFaktor oder in Sprüngen von r_AVGof20_DM. Dazu fehlen uns aber Zahlenwerte vom TE. Wenn man die hätte, dann könnte man über evtl. mögliche andere Rechenwege nachdenken.
Code:
di_GearIn := REAL_TO_DINT(r_Grad_pro_Takt * 1000.0 * (1.0 - r_GearFaktor));

          1.0000000
-         0.0003897116  // r_GearFaktor = 3.897116e-004
=         0.9996103
*    360000.0           // r_Grad_pro_Takt * 1000.0
=    359859.7
RND  359860             // di_GearIn


          1.0000000
-         0.0003335xxx  // r_GearFaktor = 3.335000e-004
=         0.9996665
*    360000.0
=    359879.9
RND  359880             // di_GearIn

Harald
 
Zurück
Oben