"Real_to_String" unter Beckhoff/Codesys

Flo

Level-1
Beiträge
133
Reaktionspunkte
2
Zuviel Werbung?
-> Hier kostenlos registrieren
Servus,
ich hoffe das Bild ist selbsterklärend, wo mein Problem liegt.
Kann mir jemand von euch erklären warum das so ist, und was ich dagegen tun kann?

mfg,
 

Anhänge

  • K1024_SPS.JPG
    K1024_SPS.JPG
    68,1 KB · Aufrufe: 140
Servus,
ich hoffe das Bild ist selbsterklärend, wo mein Problem liegt.
Kann mir jemand von euch erklären warum das so ist, und was ich dagegen tun kann?

mfg,

Das liegt in der Natur der Gleitkommazahlen, da die Zahl 354.2 in dieser nicht genau dargestellt werden kann.

Kannst hier mal nachlesen:
http://de.wikipedia.org/wiki/IEEE_754

Unten ist auch ein Link zu einem Java Applet, da kann man sich die Bit-Darstellung verschiedener Zahlen ansehen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
servus thomas,
hab mir jetzt die Seite zum Link nicht durchgelesen (heute keine Lust mehr), aber warum kann der "Compiler?" die im Programm direkt geschriebene Realzahl richtig umsetzen, und die selbe Zahl in der Variable nicht?
 
Problem erkannt, Problem gebannt???

Hi Flo,

Dein 1. Problem ist, daß Dein Screenshot so klein ist, daß man ihn nur teilweise lesen kann.

Daraus resultiert Problem Nr.2: ich kann Dein Problem nur schemenhaft erkennen :confused:

Falls ich richtig geraten habe, möchtest du die Real Zahl so darstellen, wie sie eingegeben wurde,
ohne die ganzen Nachkommastellen.

Hierzu hat mir vor kurzer Zeit folgender Beitrag sehr geholfen.

http://sps-forum.de/showpost.php?p=137880&postcount=13

Gruß,
Gundula
 
servus thomas,
hab mir jetzt die Seite zum Link nicht durchgelesen (heute keine Lust mehr), aber warum kann der "Compiler?" die im Programm direkt geschriebene Realzahl richtig umsetzen, und die selbe Zahl in der Variable nicht?

Weil der Compilier die Zahl nach der entsprechenden Anzahl "tragender" Stellen einfach abschneidet.
Eigentlich ist die andere Darstellungsart sogar richtiger, weil die Zahl 354.2 eben nicht genau darstellbar ist (periodischer Bruch).

Bei 32 Bit hast du 7 tragende Stellen, die musst du mit den Funktionen die Gundel verlinkt hat entsprechend abscheiden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Flo,

Dein 1. Problem ist, daß Dein Screenshot so klein ist, daß man ihn nur teilweise lesen kann.

Durch anklicken des Screenshot sollte er eigentlich in Lesbarer Größe wiedergegeben werden. zumindest bei mir.
nichts desto trotz ist das ("real_to_strf" Funktion) wohl die lösung meines Problems.
Vielen Dank!


Aber die Frage bleibt: warum gehts als "programmierte" Zahl, aber als "deklarierte" Zahl nicht?
Edit:bin zu langsam für euch.Danke
 
Zuletzt bearbeitet:
Aber die Frage bleibt: warum gehts als "programmierte" Zahl, aber als "deklarierte" Zahl nicht?
Edit:bin zu langsam für euch.Danke

Ich geh hier mal stark von aus, das:
a) Zahl steht im Programm
Der String wird als Konstante zugewiesen, die Wandlung hat der Compiler gemacht,
die PLC hat damit überhaupt nichts zu tun.
Heißt kompiliert wird eigentlich: sReal := '354.2'

b) Zahl ist Variabel
Der String wird zur Laufzeit mit voller Genauigkeit des REAL-Formats erzeugt.

Mfg
Manuel
 
Es gibt allerdings was, was ich bei deinem Screenshot wirklich überhaupt nicht verstehe.

Eine "normale" REAL, also 32 Bit Lang, hat eigentlich im IEEE-Format nur ~ 8 Dezimalstellen,
als String werden bei dir aber deutlich mehr gewandelt.

Mfg
Manuel
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Flo,

Die Lösung des Problems ist ganz einfach!
Benutze einfach die Funktion LREAL_TO_FMTSTR. Da kannst du angeben wie viele Nachkommastellen die Zahl haben soll und ob die Zahl gerundet werden soll.
Das sieht dann so aus:

Code:
real_test := 354.2;
sreal1 := LREAL_TO_FMTSTR(realtest, 3, TRUE);
Als Ergebnis kommt dann raus:
354.200

Hier noch der Link dazu:
http://infosys.beckhoff.com/content...es/html/tcplclibutilities_lreal_to_fmtstr.htm
Ich hoffe Dir damit weiter geholfen zu haben.

Gruß Scrat
 
Zurück
Oben