Unterschied Trunc <--> Round

[Emilio]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

wenn ein wert von 53 an IN im Trunc-Block anliegt, kommt hier an OUT ein Wert von 52 raus. (Diese 53 ist dan ohne nachkommastellen)

Wenn ich eine Wert von 53.0 hier ranschreiben komt auch 53 raus.

Statt dieses Trunc block habe ich jetzt ein Round block benutzt, und das funktioniert. Aber was ist hier dann der Unterschied? (und wieso??)

Emile

 

[zotos]

Bei TRUNC wird die Kommastelle einfach abgeschnitten und bei ROUND wird eben gerundet.

Wenn man nun ein Real hat kommt es zu Ungenauigkeiten die der Datentyp Real mit sich bringt.

Wenn man 0,53 * 100 rechnet kann es bei Real zu eine kleinen Abweichung kommen wenn dann da 52,99999 da steht wird TRUNC einfach 52 draus machen und ROUND würde es auf 53 aufrunden.

 

[Emilio]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe nochmal ein zweites Bild angehängt. Da wird im Status ein 53 an IN gezeigt, und komt ein 52 raus an OUT. Kann diese 53 dann z.B. 52.9999 sein?

 

[Rainer Hönle]

Das kann daran liegen, dass die angezeigten 53 nicht exakt 53 im internen Format sind sondern vielleicht 52.9999999. Bei TRUNC wird jetzt auf 52 gewandelt, RND behandelt das Ganze richtig. Wenn aber vom Prinzip nur die Nachkommastellen abgeschnitten werden sollen und nicht gerundet, dann kann einfach mit

L MD 4711 // Oder was auch immer
L 0.00001 // Oder wie groß der tolerierbare Fehler auch ist
+R

dieses interne Problem beseitigt werden.

 

[zotos]

Ich habe nochmal ein zweites Bild angehängt. Da wird im Status ein 53 an IN gezeigt, und komt ein 52 raus an OUT. Kann diese 53 dann z.B. 52.9999 sein?

Die Anzeige des Staus zeigt doch die 53 ohne Kommastelle an... wenn im MD200 jetzt sowas wie 52.9999 steht macht die Statusanzeige an der Stelle die Du siehst ein 53 daraus.
Real werte haben eben eine gewisse Ungenauigkeit zu solchen Effekten führt.

 

[zotos]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das es an der Ungenauigkeit vom Datentyp Real liegt, war ja eher geraten.
Mit einer anderen Steuerung bekomme ich bei gleicher Funktion als Ergebniss 53 raus.

Interessant ist das wenn man am MUL_R anstelle von:
0.53 * 100.0

53.0 * 1.0

Verwendet und sich dann das Ergebnis Binär anschaut sieht man das die S7 da unterschiedliche Werte liefert.

 

[Rainer Hönle]

Was war die andere Steuerung? Und welche Datenlänge hat dort der Typ Real? Auch 4 Byte oder 8 Byte? Oder wird dort, wie bei PCs in der FPU, bei Rechenoperatinen eine größere Genauigkeit verwendet?

 

[zotos]

Ich habe die Ursprüngliche Berechnung: 0.53 * 100.0 mit der CoDeSys Simulation und der RTE getestet da kommt nach TRUNC 53 raus.

Bei dem gleichen Test mit Step7 (PLCsim) kam 52 raus (wie Emilio es ja berichtet).

Die Anzeige der Binär Werte in Step7 nach MUL_R zeigt das dort eine Abweichung stattfindet. Auch wenn die Darstellung als REAL Wert in PLCsim oder als Gleitpunktzahl (Super das ein Programm verschiedene Namen dafür hat) in der Variablentabelle dies nicht vermuten lässt.