Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 12 von 12

Thema: SCL Berechnung wird auf Vielfaches von 20 gerundet?

  1. #11
    Registriert seit
    23.07.2009
    Ort
    Österreich
    Beiträge
    2.367
    Danke
    457
    Erhielt 696 Danke für 521 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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!

    Zitat Zitat von Karabullo Beitrag anzeigen
    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...

    Zitat Zitat von Karabullo Beitrag anzeigen
    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.
    Geändert von RONIN (05.11.2014 um 23:44 Uhr)
    If at first you don't succeed, you're not Van Damme!
    ... or maybe using TIA!

  2. #12
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.316
    Danke
    932
    Erhielt 3.331 Danke für 2.689 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von JoopB Beitrag anzeigen
    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.co...ard&viewreg=WW

    Anhang 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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. Folgender Benutzer sagt Danke zu PN/DP für den nützlichen Beitrag:

    vollmi (06.11.2014)

Ähnliche Themen

  1. Antworten: 106
    Letzter Beitrag: 22.07.2014, 22:12
  2. Berechnung SCL ; WORD oder INT
    Von toto45 im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 16.11.2011, 11:41
  3. CASE-Anweisung von SCL auf KOP
    Von adonismensch im Forum Programmierstrategien
    Antworten: 8
    Letzter Beitrag: 25.09.2009, 12:41
  4. Konverter von SCL auf AWL
    Von nourdine im Forum Programmierstrategien
    Antworten: 4
    Letzter Beitrag: 18.09.2008, 13:48
  5. Antworten: 1
    Letzter Beitrag: 23.09.2005, 13:56

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •