KUKA INT to REAL

You will have to either send mantissa and exponent separately (or treat 32 bits as two different numbers) or use modified binary to decimal conversion with decimal places included (depending on the precision you have at the source)

e.g. 32, 16..4, 2, 1, 0.5, 0.25, 0.125

one common workaround is to just convert floating point to a fixed point format:

- when sending multiply REAL by some number such as 1000 and place result into an integer

- when receiving, place value into REAL and divide by same factor (1000 or whatever).

multiplier does not have to be powper of 10 but this makes convreted value directly observable.

that is a bit crude and does mean data loss but... it is simple and often can be used in robotic applications since one can still get acceptable resolution and value range.

functions i posted work fine and do not compromise range or accuracy.

btw. KUKA uses 32-bit integers so although signed, they go past +/-32k limits common to 16-bit SINT.

Good day.

For connection with Siemens S7-1200

To transmit +/- real from Siemens S7-1200 to Kuka KRC2, you need to transmit a dword from Siemens, mirror it(DWORD) and mirror the bits in each byte(in DWORD).

Example:

In S7-1200:

"swapbytes"(real1 := "db1".V9,

dword1 => "V9ToKuka");

+Attached image

In Kuka:

"Variable = INT_TO_REAL(V9)",

where "INT_TO_REAL" consists of (thanks to panic mode

DEFFCT REAL INT_TO_REAL(n:in)

decl int n,ofs

decl char buf[4]

decl real f

ofs=0

cast_to(buf[],ofs,n)

ofs=0

cast_from(buf[],ofs,f)

return f

ENDFCT

bit order is the same but byte order may differ depending on endianness of the platforms and size of the register (16/32 bit). it is something that always comes up when dealing with Siemens products.

normally one would simply swap bytes in WoV while mapping IO. WorkVisual has tools for that.

actually it does not really matter where the swap takes place, it could be in PLC, or in WoV mapping, or in KRL program - as long as data is arranged so that both side can see the same values.

This is what you encountered:

pasted-from-clipboard.png

but note that this is not the only possibility...

therefore it may be necessary to change byte order from 1234 to 3412 or 4321

see more on Siemens FAQ for doing swap on PLC end:

https://support.industry.sieme…ice-versa-?dti=0&lc=en-WW

Read WorkVisual manual for info on doing swap in WoV while mapping IO.

And if one wants to do a swap in KRL, also not a problem. One can simply rearrange bytes in buffer before casting back the data. This is easy since buffer is just a byte array (character array).

example is in attached ZIP file:

Quote from panic mode

normally one would simply swap bytes in WoV while mapping IO. WorkVisual has tools for that.

WorkVisual is unsupported in KRC2, as I know.

I wrote:

Quote from miden

To transmit +/- real from Siemens S7-1200 to Kuka KRC2, you need...

You can swap/reorder bytes in IOSYS.ini.

Inb0=3,3,x1
Inb1=3,2,x1
Inb2=3,1,x1
Inb3=3,0,x1

Or at the PLC end

Hi Panic I was using your function for converting int to real and I got this error - in the picture, the value of SIGNAL(32 bit input) was 7, I declared it in $config file and called your function IntToReal. Do I need to do to something more? KSS 8.7 , Kuka KRC5 compact controller

And with -1052681 I got NaN , In CAST_FROM in IntToReal function panic mode

well... i simply do not know where to begin. frankly, it never seizes to amaze me how some posts are structured, and this happens over and over, despite the repeated hints on how to form a question when asking for support.

so while this should be clear from READ FIRST and many other posts, maybe lets do it yet again, step by step:

how about posting actual code? if you do not share it, how is anyone supposed to recreate your issue? even the screenshot in post #14 shows more empty lines than lines of code. and screenshots are NOT the proper way to share the code. if someone is to reproduce issue, it would take a more effort than necessary - retyping it. post the code as text and surround it with code tags - that is what they are for.

and just because you mention one function that i may have created, how am i supposed to know which exact variant we are talking about? why do you think i created only one? I shared here at least two.

and i may have shared something that works for me, but who is to say that you did not have some sort of a typo in recreating it? maybe double declaration, maybe wrong initialization, maybe something else...?

and - why do you expect me to go and look for it? if you need help, it is you who should be putting in the effort of posting everything relevant to your question.

next, what makes you think that issue is with the function i shared? what have you done to verify and narrow down the problem? maybe the issue is not with conversion but displaying or string conversion. are you sure that function is failing somehow? did you try comparing result with one of online calculators?

for example, signed integer -1052681 is 0xFFEFEFF7 and in REAL this value is represented as NaN. in other words function seem to do what is supposed to...

REALs are encoded using IEEE754 standard. you can read it and write own function. i did that too and it is also shared on the forum.

both variants of the functions are meant as an aid to transfer REAL values (from PLC for example) into REAL values (in the robot). the only reason there are INTs in-between is because KRL does not have SIGNAL representation for REAL.

that does not mean that one can or should skip part of the transfer chain and feed garbage into function. well you can but do not expect something fancy to come out.

what was supposed to be represented by -1052681 or 0xFFEFEFF7?

which REAL number is this value supposed to be according to you?

Quote from panic mode

and screenshots are NOT the proper way to share the code. if someone is to reproduce issue, it would take a more effort than necessary - retyping it. post the code as text

It seems the ancient techniques of transforming code into text are being lost. We maybe the last generation to use such antiquated measures, so stuck to our old ways.

Maybe it's unreasonable to expect the youngsters to go through the harsh training necessary for gaining the skill set.

just trying to help and expecting those looking for assistance - to collaborate. but every day one is reminded that it may be expecting too much. one of the posts i saw today stated MFC article numbers in wrong format - including one in reverse. if that is any indicative of 'new generation' communication skill, then i am clearly not keeping up with the trend.

Hi to all,

I'm sorry, I didn't phrase the question well, and I didn't analyze enough everything written in this post, with a little deeper analysis I realized the following:

The function I used from this post is the IntToReal function (written by panic mode )

DEFFCT REAL IntToReal(n:in)


DECL INT n,ofs
DECL CHAR buf[4]
DECL REAL f


ofs=0
CAST_TO(buf[],ofs,n)


ofs=0
CAST_FROM(buf[],ofs,f)


RETURN f
ENDFCT

it converts from signed int to real -> example (1156681166 convert to 1932.4313)

DECL INT I1
DECL REAL R1
I1=115668116
R1=IntToReal(I1)

and I got the correct value

now I want to understand the logic of how KUKA reads a 32 bit integer (form from 32 Input values) in order to know what needs to be passed:

mathematically when represented in 32 bits as signed int (big endian):

My new question is the following: I declared a 32-bit SIGNAL in config:

SIGNAL DI_Test $IN[106] TO $IN[137]

are this values in KUKA represented as little endian -> is my IN[106] the last bit representing 2^0?

and does the KUKA with the help of SIGNAL declaration read this number as SIGNED INT or am I actually making a mistake there?

Do I need to swap the bytes order 4321 or 3412

I've tried several combinations, I think I'm doing something wrong

Thanks in advance

KUKA used SINT32 for integers and signals. But, if signal is declared as less than 32but wide, it is unsigned. Except of course when it is just 1 bit.... In that case signal is boolean

kuka is little endian encoded. Have a look at workvisual manuals where byte swapping is explained. I generally prefer to do byte swapping directly in io mapping if required, it is the easiest way in my opinion.