Additional '10' bits when reading Inputs

    Hi,


    I have a strange problem.


    I try to read 14 bits:


    Code
    SIGNAL I_EL_DLU $IN[1] TO $IN[14]

    I send decimal "1000" to $IN[1-14] by PLC which is '11 1110 1000' binary.

    You can see on the picture attached that it is sent ok.


    But when I try to read variable I_EL_DLU I received decimal number 33768 which is '1000 0011 1110 1000'

    As you can see there is '1' added in the beginning.


    I tried other ranges and this '1' is always added.


    Why is that? How to solve this? I just want to read the bits I select as variable.


    Robot KR C v5.5.13

    GUI version: 2.0.6.7 B75

    Kernel: KS V5.5.75 RTAcc

    #KR2150 2 S C3 FLR ZH150


    Please help.

    What PLC brand? Siemens uses a different byte-swap than KUKA.


    You should find the two bytes in the I/O mapping that contain this 14-bit "word" and swap them.


    Also, treat it as a 16-bit word -- don't use the two "extra" bits for anything, even though you're only putting 14-bit values into it..

    your image is blurry and you don't mention where this signal is declared.


    '1000 0011 1110 1000' is a 16-bit value and should not be possible with signal that is only 14-bit.

    you could strip unwanted bits by B_AND but this should not be needed.

    for example, instead of I_EL_DLU, use


    or put it inside a function


    DEFFCT INT I_EL_DLU_VAL()

    RETURN I_EL_DLU B_AND 'H2FFF'

    ENDFCT


    for test you can map that signal to some unused outputs such as


    SIGNAL TEST_SIGNAL $OUT[501] TO $OUT[514]


    then try to write different values to it. it should not accept values exceeding 2^14-1 or 16383.

    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

    Hm... yes, on second look, the bytes are not swapped. So my previous post is invalidated.


    Panic is right, though -- if a SIGNAL is DECL'd with only 14 $INs, then it should be impossible for that SIGNAL to ever achieve a value higher than 16,383.


    Have you looked at the raw values of $IN 1 - 16? It would be interesting to see if 15&16 match the decimal value you're seeing. It really looks like I_EL_DLU is DECL'd as a 16-bit signal instead of 14.

    The problem of mapping is that I found this problem when I tried to map I_el_dlu to o_el_dlu where o_el_dlu is $out[1] to $out[16]

    Just:

    O_el_dlu = i_el_dlu

    I get error of 'overflow'.

    That's why it is very strange, why there are added some bit in input that give so strange results.


    Normally range $in[1] to $in[16] should be equal to $out[1] to $out[16] but the input has additional two bits before MSB `10`.


    Yes I tried other ranges from 1-8 to 1-16 and always there are added two bits before MSB '10'.



    This is very strange because the same code worked normally on some other robot.

    The difference are that this robot had other kss and is safety (which is disabled) and accurate (which I think is not important).

    Maybe it is something with unsigned/signed integer but how it is correlated with signal?

    Also There at no other programs on the hdd so there is no possible that there is other variable declared as I_el_dlu.


    This signal is declared in the selected program dat file.


    Skyefire:

    Yes it should never be more than 16383 but is is! ('Overflow' error.)

    But bit 15 and 16 is not important because If I change range to for eg. 1-8 it is still 10 bits instead of 8.

    Why there are always added two bits in the beginning '10'?

    Am I missing something?

    Here is the photo of the panel.


    As you can see inputs named I_EL_DLU are maped $IN[1] TO $IN[9] (9 bits)

    As you can see on the Digital Inputs Monitor the number represented is '111101000' which is 488 decimal.

    As you can see on the variable moniutr I_EL_DLU is '10 111101000' which is 1512 decimal.


    On the high side is '10' added...

    It is added regardless the number of bits I used (tested with 8,9,16 bits)


    So when I try to set outputs with the same values as inputs there is OVERFLOW error.

    I know I could use AND to get only bits I want but this is not the ideal solution for the problem.

    I would like to know the root cause.


    Any advice?

    this is not normal or expected behavior so obviously SIGNAL picks up additional bits which are out of declared range. so either there is something corrupt on your system or maybe there is a bug in that specific KSS version.


    if it is the first one, make HDD image (just in case) and reinstall everything.

    if it is the later, other users running KSS5.5.13 could confirm same behavior on their systems


    other than that i can see few things one could possibly try:

    1. validate what KSS tells about your signal, specifically length

    2. try to rename signal to be sure it is not masked by something else and perhaps try to change signal scope (declare it as GLOBAL).


    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

    With OL i did not have any problems.


    What KSS version have the other robots (a later version of KSS 5.5.13)?


    You could check with customer support from kuka to see whether this is a known problem and probably ask for a newer version of KSS V5.5 (if the problem is known)

    I checked after reinstallation of krc and the problem is still there so It looks like a software bug or some feature that I don't know about.

Advertising from our partners