Problem mit Real-Eingangsparameter

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Leute,

ich habe ein Problem mit einem Realwert.

Ich bekomme einen Wert im Real-Format als Eingangsparameter einer FC und muss diesem Wert durch Abschneiden der Kommastellen nach DINT wandeln. Nun habe ich bei manchen Werten den Effekt, daß die letzte Stelle durch den Befehl "TRUNC" verändert wird.

Konkret sieht es so aus:

VAR_INPUT
  JULIANISCHER_TAG          : REAL;
END_VAR

VAR_TEMP
  JD                        : DINT;
END_VAR

BEGIN
JD := TRUNC(JULIANISCHER_TAG);
...

// wenn JULIANISCHER_TAG = 2.453065e+006
// dann wird          JD = 2453064 - falsch!

Wenn ich testweise eine Konstante mit dem selben Wert "2.453065e+006" zuweise, wird die Wandlung korrekt ausgeführt.

VAR_TEMP
  JD                        : DINT;
  temp_real                 : REAL;
END_VAR

BEGIN
temp_real := 2.453065e+006;
JD := TRUNC(temp_real);
...

// wenn JULIANISCHER_TAG = 2.453065e+006
// dann wird          JD = 2453065 - korrekt

Wie kann man sich das erklären? Mit SCL hat dieses Problem nichts zu tun, hab's auch mit AWL probiert - gleiches Ergebnis.

Wie komme ich über Umwege am einfachsten und sicher zu meinem DINT?


Gruß, Onkel

 

[Anonymous]

Hallo,

so ein Problem hatte ich auch mal. Ich habs dann darauf geschoben, das (um bei Deinem Beipsiel zu bleiben) 2.453065e+006 eigentlich 2.4530649e+006 sein kann, es werden halt nur 6 Nachkommastellen dargestellt, wobei die letzte gerundet (hier: aufgerundet) ist. Da TRUNC nun hart abschneidet, kommt sowas bei raus.
Vielleicht kann man das durch Verwendung eines größeren Zahlenbereiches (z.B. *10) umgehen?

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Gast,

danke für deine schnelle Antwort. Es ist bei meinem Zahlenbeispiel so, dass tatsächlich der exakte Wert "2.453065e+006" als Eingangsparameter übergeben wird (ohne weitere Stellen). Es liegt also nicht an der gerundeten Darstellung im Editor. In diesen speziellen Fall gibt es keine Nachkommastellen die von "TRUNC" getrunct werden müssten.

Was ich vielleicht noch erwähnen sollte ist, dass ich die Funktion bisher nur im Simulator getestet habe.


Gruß, Onkel


Hab's mal eben mit *10.0 probiert. Jetzt macht er mir aus "2.453065e+006" den Wert "2.453064e+007" - wohl ein klassischer Rundungsfehler. Mit "TRUNC" ergibt sich dann "24530644".

 

[Onkel Dagobert]

Hallo Gast,

:idea: ich muss mich korrigieren, du hast recht! Ich hatte beim Aufruf meiner FC den Real-Paramter nach dem Versorgen über eine Variable mit dem "runden" Wert noch einmal im Programm überschrieben mit einem entsprechenden (errechneten) Wert mit mehreren Kommastellen. Alles klar .


Danke für den Tipp!

Gruß, Onkel

 

[PeterEF]

Hallo,

freut mich, richtig getroffen zu haben. Gibt es denn Unterschiede zwischen TRUNC im Simulator und TRUNC auf der echten CPU?

Schönen Abend noch, Peter!

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Peter,

eigentlich sollte es keine Unterschiede geben. Für einen Moment lang hatte ich jedoch alles mögliche angezweifelt. Da muss man wohl durch :| . Jetzt habe ich die Bits wieder voll im Griff.

Gruß, Onkel