Step 7 Ungenauigkeit beim Rechnen mit REAL-Werten (Simatic Manager 315er CPU)

[Blockmove]

Der Messtaster hat die Auflösung 0,0001mm, den wollte der Kunde extra so genau. Deshalb muss die Berechnung auch bei kleinen Höhenunterschieden funktionieren, was sie derzeit durch die großen Ungenauigkeiten beim Rechnen / Rundungsfehler nicht tut :/

Ich hab auch schon Messtaster mit dieser Auflösung eingesetzt und konnte nur auf1/100mm wiederholgenau damit messen.
Die Anlage gab aufgrund von Mechanik und Umgebung einfach nicht mehr her.

Sollte es die Anlage in deimen Fall wirklich hergeben, dann ist auch der Vorschlag MFreiberger eine gute Idee.
Du verschiebst deinen Zahlenbereich so, dass du mit max. Genauigkeit rechnen kannst.
Also im einfachsten Fall Vorkommastellen weglassen.

 

[sargan26]

hätte man dieses, nicht ganz triviale, Thema nicht etwas eher im Projektverlauf bearbeiten sollen :wink:?

Person A erarbeitet das Konzept
Person B gibt das OK zur Software-Umsetzung
Person C macht die Software-Umsetzung und prüft sie aber nicht
Person D erbt das Projekt, verifiziert die Arbeit der Kollegen und findet den Fehler noch vor der Montage bei Kunden

Insofern würde ich sogar behaupten Person D hat einen guten Job gemacht den Fehler zu finden bevor man zum Kunden fährt...

Schön wäre es, mal eine Rückmeldung zu hören, ob einer der aufgeführten Lösungsvorschläge hilfreich ist.

Ich kann es leider erst nächste Woche beantworten wenn ich die Situation vor Ort gesehen habe und die Wiederholgenauigkeit etc kenne

 

[NBerger]

Zu #26...

Pi kann "etwas genauer" berechnet werden über

Pi := acos(-1)

. Dann braucht's das *4 nicht.

Die Genauigkeit der Realzahlen sind 7 Dezimalstellen da nicht 2^23 (Mantisse) sondern 2^24 (Mantisse + Hidden Bit)!

Das Wandeln von Realzahlen in Integerzahlen etwas addieren und zurückwandeln in eine Realzahl erhöt keine Genauigkeit!!!

Bei der Wandlung in eine Integerzahl verlierst du schon Bit's aus der Mantisse

Nebenbemerkung da ich sowas recht heufig sehe: Realzahlen möglichst nicht durch Konstante Werte dividieren (Das braucht erheblich länger als eine Multiplikation)
Also lieber * 0,00001 als / 100000

 

[MFreiberger]

Moin sargan26,

Person A erarbeitet das Konzept
Person B gibt das OK zur Software-Umsetzung
Person C macht die Software-Umsetzung und prüft sie aber nicht
Person D erbt das Projekt, verifiziert die Arbeit der Kollegen und findet den Fehler noch vor der Montage bei Kunden

Insofern würde ich sogar behaupten Person D hat einen guten Job gemacht den Fehler zu finden bevor man zum Kunden fährt...

Na, unbedingt! Das sollte auch keine Kritik an Dir sein.

Leider ist es so, dass es häufig vorkommt, dass, je früher man in einem Projekt ist, desto weniger akribisch gearbeitet wird.

Manchmal werden die Knackpunkte erst in der Umsetzung und schlimmstenfalls erst in der Realisierung erkannt. Allerdings kann ich mich auch nicht davon frei machen, in der Planungsphase die Komplexität mancher Themen nicht zu erkennen. Ich stelle jedenfalls fest, dass Projekte immer häufiger verschoben werden. Vielleicht liegt es daran, dass die Projektthemen immer anspruchsvoller werden? Jedenfalls ist eine Terminverschiebung nicht schön und mit Planungsaufwand und ggf. auch Kosten (Strafen?) verbunden. Aber, wenn die Anlage nicht funktioniert, ist der Schaden häufig größer. Es braucht einen couragierten Projektleiter, der eine Terminverschiebung ausspricht bzw. einen erfahrenen Projektleiter, der abschätzen kann, ob die Terminverschiebung oder die Anlagenprobleme der größere Schaden für die eigene Firma ist.

Auf jeden Fall wünsche ich Dir viel Erfolg bei der Problemlösung!

VG

MFreiberger

 

[Heinileini]

FUNCTION_BLOCK "Berechnung_Parallelitaet"
...
    // REAL hat nur eine Genauigkeit von 6 Stellen nach dem Komma. 
...
    Messpunkt_2_X := [U]17.32050[/U]81;
...
    Messpunkt_3_X := [U]8.660254[/U]04;
...
    Vektor_r2_r1_X := [U]17.32050[/U]81;
...
    Vektor_r3_r1_X := [U]8.660254[/U]04;
...

Die Formulierung "eine Genauigkeit von 6 Stellen nach dem Komma" ist leider irreführend.
Das gilt nur, wenn das Komma direkt auf die höchstwertige Stelle folgt. Die Position des Kommas ist eigentlich irrelevant.
Ab der höchstwertigen Stelle (ungleich 0) sind noch die folgenden 6 Stellen relevant. Unabhängig davon, ob das Komma links von dieser Ziffernfolge steht oder mittendrin oder rechts davon.
Deine "Konstanten" im Programm für 10 * cos(30°) bzw. 20 * cos(30°) kannst Du also getrost auf 7 [SUP]1[/SUP]) (Vorkomma + Nachkomma) Stellen runden (8.660254 bzw. 17.32051).

Aber mein Einwand ändert leider nichts an Deinem Problem. :-(

Vielleicht hast Du nach Deiner Inbetriebnahme noch Lust und Zeit, einmal zu skizzieren, wie die MessAnordnung aussieht und was es mit der Parallelität auf sich hat?
(Es ist mir einfach zu mühsam, aus Deinen Formeln irgendwelche Rückschlüsse zu ziehen )

Viel Erfolg!
Gruss, Heinileini

[SUP]1[/SUP]) Na ja, 7 relevante Stellen der DezimalZahl [SUP]2[/SUP]) sind leider auch keine präzise Angabe, da die Zahl intern ja eine DualZahl (eigentlich zwei DualZahlen, je eine für Mantisse und Exponent) ist. Allein die Umwandlungen dezimal in dual und umgekehrt machen schon Probleme.

[SUP]2[/SUP]) Die Formulierung "DezimalStellen" habe ich absichtlich vermieden, weil damit oft/meistens nur die NachkommaStellen bezeichnet werden.

 

[Thomas_v2.1]

Nebenbemerkung da ich sowas recht heufig sehe: Realzahlen möglichst nicht durch Konstante Werte dividieren (Das braucht erheblich länger als eine Multiplikation)
Also lieber * 0,00001 als / 100000

Hier ist aber keine Geschwindigkeit sondern Genauigkeit gefordert.
0,00001 ist als Gleitkommazahl nicht genau darstellbar (wird zu 0.00000999...), 100000 hingegen ohne Genauigkeitsverlust

 

[Zombie]

Hi, ich hab mir nicht alles durchgelesen, aber ich hab das Rundungsproblem so gelöst, dass ich die Werte mit 1000 multipliziert, dann in DInt gewechselt und dann mit DInt gerechnet habe.

Ist irre aufwändig, weil die immer einbeziehen musst, wie sich die Multiplikation mit 1000 in jedem Schritt hinterher auswirkt, aber so konnte ich den Fehler kleiner halten.

 

[Thomas_v2.1]

Ich habe mir das mal skizziert, und würde ja selber anstelle des Tangens den Sinus verwenden.
So wie ich das verstehe soll in der mm-Angabe der Abstand herauskommen, wenn das Zahnrad auf einen ebene Fläche gelegt wird, es an einer Seite angehoben wird und wie groß der Abstand am Durchmesser von 46,5 mm ist (die Zähne mal außen vor gelassen). Den Abstand der sich z.B. mit einer Fühlerlehre ertasten ließe.

Dann ist für mich der rechte Winkel zwischen Bodenfläche und gedachter lotrechter Linie zum Zahnradrand. Gegeben ist im Dreieck dann die Hypotenuse mit 46,5 mm, der Winkel zwischen den berechneten Normalenvektoren ist dann der Winkel zwischen Hypotenuse (Zahnrad) und Ankathete (Boden), gesucht ist die Gegenkathete. Also demnach Sinus und nicht Tangens, oder nicht? Macht bei kleinen Winkeln zwar keinen großen Unterschied, aber wenn wir hier schon auf die Genauigkeit achten.

 

[Thomas_v2.1]

Hinzu kommt, dass wenn die Berechnung der Parallelität direkt den Cosinus des Winkels zurückgibt, du ohne trigonometrische Funktionen alles mit Pythagoras rechnen kannst.

 

[Onkel Dagobert]

Wäre es nicht einfacher, anstatt die Konstante Pi zu berechnen, den Fertigungsplan zu ändern und die Zahnräder plan zu schleifen ?

 

[Oberchefe]

Wäre es nicht einfacher, anstatt die Konstante Pi zu berechnen, den Fertigungsplan zu ändern und die Zahnräder plan zu schleifen ?

Du weißt doch, wenn die Konstruktion was verbockt hast, muss es der Programmierer wieder per Software hinbiegen.

 

[Heinileini]

Wäre es nicht einfacher, anstatt die Konstante Pi zu berechnen, den Fertigungsplan zu ändern und die Zahnräder plan zu schleifen ?

Sorry, OT, anscheinend bist Du gar nicht so berechnend, wie ich Dir zugetraut hätte, Dagobert, aber, dass Du Dinge lieber schleifen lässt ... !?!?