KUKA INT to REAL

  • Hello,


    I was looking for a solution on data type conversation, like i have krc4 connected via ProfiNet, i have defined a variable for data like

    SIGNAL VAR $IN[X]  TO $IN[X+32] in a length of a type REAL so i receive a bits of a number ak(01111110 00101011 01010100 00100010) in a signal view i see the value of INT like 2116768802 i just don't know how to define it like REAL to get ak (354.325)

  • Place your Ad here!
  • 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

  • 1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • Thanks for additional informations, yes but there was a problem with multiplayer option because of signed var you have limited range if you have a 432,54 number you can get out a 43256 and is over a range of a max 32757. Upper code looks like a thing to try. Tnx

  • 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.

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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:frowning_face:


    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:

  • 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?

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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. :face_with_tongue:

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

  • 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 )

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

    Code
    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

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners