-> Hier kostenlos registrieren
Ah, da ist jemand mit einer Goldwaage unterwegs?! Dem Mann kann geholfen werden.
Es wäre noch anzufügen, daß sich bei meiner weiteren Recherche herausgestellt hat, daß, obwohl es im zuvor geposteten Ausschnitt den KUKA-Handbuches nicht explizit erwähnt wird, KUKA sich scheinbar auch daran hält. Zumindest stimmen die im Handbuch angegebenen Grenzen mit denen in der IEEE angegebenen Werten (1) exakt überein: 1.1E-38 bis 3.4E38.
Ich setze in der SPS eine REAL-Variable, die zusammen mit einem DWORD in der oben geposteten UNION steht, auf den Wert 18.4. In dem DWORD steht dann das korrekte Bituster dieses Wertes drin: 01000001100100110011001100110011.
Das DWORD aus der UNION wird dann via Schnittstelle an den KUKA geschickt. Beim Roboter kommt es auf einem Gruppensignal (SIGNAL GI_Signalname $in[...] TO $in[...] ) an. Im Gruppensignal ist das Bitmuster korrekt, d.h. die einzelnen binären Eingänge sind korrekt gesetzt: 01000001100100110011001100110011. Als INT interpretiert entspricht das dem Wert 1100165939. Wenn ich jetzt der REAL-Variable (REAL R_realname ) diesen Wert zuweise, dann steht nicht 18.4 in der REAL, wie man es erwarten würde, sondern "ein verdammt großer INT", genauer gesagt die INT-Repräsentation des Gruppensignales, der oben genannte Wert von 1100165939, in REAL-Darstellung, d.h. 1.1006589E+09.
An diesem Punkt wäre das Thema für mich - eigentlich - beendet, da ich aber auch KUKA programmiere und ich auch schon ab und an über dieses Problem gestolpert bin, war es mir ein Anliegen es auch zu lösen. Völlig ohne Eigennutz natürlich.
Das Problem konnte inzwischen auch dank der tatkräftigen Hilfe eines KUKA-Technikers gelöst werden. Um wieder die 18.4 in die REAL-Variablen zu bekommen, wird der Gruppeneingang als stream betrachtet und in einer kleinen Funktion (ein 5-Zeiler) mittels cast_from auf eine temporäre Variable geschrieben, welche wiederum mit cast_to, beide Bestandteil von CREAD/CWRITE, in die real-Variable geschrieben wird. Im Programm sieht das dann so aus:
Es wurde sich hier im Forum auch schon bei mir entschuldigt.
Scheinbar wird die Netiquette hier gepflegt. Zusammen mit der i.d.R. sehr schnellen und kompetenten Hilfe, die man hier bekommt, auch, wenn man mal "noob"-Fragen stellt, macht das dieses Forum äußerst sympatisch. Einzig der facepalm-Smiley fehlt mir zur vollkommenen Glücksehligkeit.
Ein "bißchen was" verstehe ich vom programmieren übrigens schon, bei TwinCAT 3 bin ich aber tatsächlich "noob".
Ich hoffe ich konnte alle Klarheiten beseitigen und gelobe zukünftig größere Sorgfalt bei meinen Fragestellungen und meinen Antworten walten zu lassen.
Gruß
Jörn
(1) https://de.wikipedia.org/wiki/IEEE_754
Wie in dem weiter oben von mir verlinkten Artikel bei Wikipedia zu lesen ist, halten sich z.B. einige Systeme von IBM nicht daran, welche, nebenbei bemerkt, ab 2000 am Markt sind. Ich sagte nicht, was wohl aus meiner Aussage herausgelesen werden konnte, daß Beckhoff und/oder KUKA sich nicht daran halten. Diese missverständliche Formulierung bitte ich zu entschuldigen.Klingt unglaublich. Hättest Du mal ein Beispiel wer sich nicht an die IEEE hält?
Es wäre noch anzufügen, daß sich bei meiner weiteren Recherche herausgestellt hat, daß, obwohl es im zuvor geposteten Ausschnitt den KUKA-Handbuches nicht explizit erwähnt wird, KUKA sich scheinbar auch daran hält. Zumindest stimmen die im Handbuch angegebenen Grenzen mit denen in der IEEE angegebenen Werten (1) exakt überein: 1.1E-38 bis 3.4E38.
Auch hier entschuldige ich meine unklare Ausdrucksweise. Genauer gesagt passiert folgendes:Da kommt ziemlich sicher nicht ein "verdammt großes INT" an, sondern 32 Bits in 4 Bytes, die sich irgendjemand fälschlicherweise als Ganzzahl anschaut. Dabei muß man sich das Bitmuster der 4 Bytes einfach nur als REAL anschauen, dann sieht man, daß das tatsächlich ein REAL ist.
Ich setze in der SPS eine REAL-Variable, die zusammen mit einem DWORD in der oben geposteten UNION steht, auf den Wert 18.4. In dem DWORD steht dann das korrekte Bituster dieses Wertes drin: 01000001100100110011001100110011.
Das DWORD aus der UNION wird dann via Schnittstelle an den KUKA geschickt. Beim Roboter kommt es auf einem Gruppensignal (SIGNAL GI_Signalname $in[...] TO $in[...] ) an. Im Gruppensignal ist das Bitmuster korrekt, d.h. die einzelnen binären Eingänge sind korrekt gesetzt: 01000001100100110011001100110011. Als INT interpretiert entspricht das dem Wert 1100165939. Wenn ich jetzt der REAL-Variable (REAL R_realname ) diesen Wert zuweise, dann steht nicht 18.4 in der REAL, wie man es erwarten würde, sondern "ein verdammt großer INT", genauer gesagt die INT-Repräsentation des Gruppensignales, der oben genannte Wert von 1100165939, in REAL-Darstellung, d.h. 1.1006589E+09.
An diesem Punkt wäre das Thema für mich - eigentlich - beendet, da ich aber auch KUKA programmiere und ich auch schon ab und an über dieses Problem gestolpert bin, war es mir ein Anliegen es auch zu lösen. Völlig ohne Eigennutz natürlich.
Das Problem konnte inzwischen auch dank der tatkräftigen Hilfe eines KUKA-Technikers gelöst werden. Um wieder die 18.4 in die REAL-Variablen zu bekommen, wird der Gruppeneingang als stream betrachtet und in einer kleinen Funktion (ein 5-Zeiler) mittels cast_from auf eine temporäre Variable geschrieben, welche wiederum mit cast_to, beide Bestandteil von CREAD/CWRITE, in die real-Variable geschrieben wird. Im Programm sieht das dann so aus:
Code:
; So geht es nicht:
R_realname = GI_Signalname
; Aber so geht es. stream2real ist eine kleine Hilfsfunktion:
R_realname = stream2real(GI_Signalname)
Du trittst mir nicht zu nahe. Besonders nicht, wenn Du die Aussage "Du bist imkompetent" durch einen so großen und hübschen Strauß Blumen sagst.Ich will Dir nicht zu nahe treten, aber sorry: Was hast Du eigentlich für einen Job, daß Du für die Lösung simpler Standard-Probleme mehrere Tage verdaddeln kannst? Vielleicht sollte Dein AG Dich mal zu einem guten Programmier-Lehrgang schicken? Wenn andere Leute etwas für Dich unverständliches tun, dann heißt das nicht automatisch, daß "die Anderen" etwas falsch machen...
Es wurde sich hier im Forum auch schon bei mir entschuldigt.
Scheinbar wird die Netiquette hier gepflegt. Zusammen mit der i.d.R. sehr schnellen und kompetenten Hilfe, die man hier bekommt, auch, wenn man mal "noob"-Fragen stellt, macht das dieses Forum äußerst sympatisch. Einzig der facepalm-Smiley fehlt mir zur vollkommenen Glücksehligkeit.
Ein "bißchen was" verstehe ich vom programmieren übrigens schon, bei TwinCAT 3 bin ich aber tatsächlich "noob".
Ich hoffe ich konnte alle Klarheiten beseitigen und gelobe zukünftig größere Sorgfalt bei meinen Fragestellungen und meinen Antworten walten zu lassen.
Gruß
Jörn
(1) https://de.wikipedia.org/wiki/IEEE_754
Zuletzt bearbeitet: