Posts by Mate_271

    Thanks to your help guys, it looks like things are slowly working out.

    The picture show, if i comment out: INB128=7, 3 every single byte can be used.(expect that obviously)

    The log says 31 input and 32 output is useable.


    if I leave it in, the picture show what's wront. At this time the iosys.log says only 3 inputs and 0 output is useable. I tried to search what can be the problem, but i find nothing.

    Why doesn't the system allow me to map to that zone?

    Okay, let's back up a bit here. Try just using a single byte mapping first, and see what happens. Like INB63=7,0. Just that, nothing else.

    If that works, try adding INB64=7,1 and so on. Using INWs and x-multipliers is convenient but not necessary (and in fact, IIRC there were some versions of KSS where using Ws and x-multipliers could cause problems).

    Thank you very much for your help guys!( hermann, SkyeFire ) I will try it as fast as i can!:)

    I can attach only 2 pictures. I didn't want to spam the post, therefore i made a zip. Sorry!:/

    In this picture show one of my variable bits. This variable(INT) first bit is my 0.bit of 10.byte.($IN[585]) Which means my first bit of 0.byte is $IN[505]. Which is the intermediate value of 0 and 1009. If mapping values didn't match(i mean in robot side and plc side), maybe the system "puts" the ios in an intermediate position. Is it possible?

    Nope, it's kind of inconsistent what kuka does here.

    The number direct behind INB / OUTB / INW / OUTW / INDW / OUTDW always are counted as bytes.

    The reason would be, that if it was depending on kind of IN / OUT you can't map it bytewise.

    In kuka i changed the mapping what you see upper, but in my turck hmi the 0.bit of 0.byte start from 0.
    I think i have to change the mapping in PLC. Should start from 127.byte. The 0.bit 0.byte should be 1009(Which should be the 0.bit of 127.byte).

    The robot will take an intermediate value between 0 and 1009. I think that could happen here.

    Is it possible?

    $MOVE_ENABLE does not change addresses when you switch between EXT and T1. Therefore, whatever device you have sending the KRC $MOVE_ENABLE needs to be adjusted to send $MOVE_ENABLE when the KRC is in T1.

    I thought i made a mistake, cause changing a sys io is not allowed.(if move enable is sys io😅)

    When i wrote back the move enable input value to 1015 and press ack, the robot start moving. Thats why i would like to change the mapping: wrote back every sys variable to factory value and cover those IOs with my 256bit.(which i have)

    $IN[585] should be in the middle of INB73, or INW36, if my math is correct.

    Yes..:( Thats what i calculated too. Thats why i dont understand what is happening and why is it happening (with INW63…)😓

    Thanks for your spreadsheet. I will try to figure out what can be the problem😊

    Firstly, appreciate your quick answer!:)

    Check the system variable $SET_IO_SIZE.

    INT $SET_IO_SIZE=1 ;SETZEN EA-BEREICH (1=1024, 2=2048, 4=4096)

    I Found it, i will change it to 4096. Thanks!:)

    i would like to clarify why i ask it.

    First integration mapping in iosys.ini was:

    INW0=7,0,x16 ; $IN[1]-$IN[256]

    OUTW0=7,0,x16 ; $IN[1]-$IN[256]

    After that every thing worked like it had to(almost).

    I changed a SYS IO (i think it is sys io), which name is $MOVE_ENABLE. From $IN[1015]( Im not sure right now) to $IN[255], because my mapping area was that, what i wrote upper.

    In EXT everything worked correctly, the PLC sand move enable etc... but when i changed mode to T1, then i could not move the robot, because robot wait for move enable.
    What can you recommend for me?

    How should do it normally(the communication and mapping))?

    $IN[1008] is the end of INW 62, not the start of INW63. $IN and $OUT "blocks" always start with an odd number, and end with an even number which is also a multiple of 8.

    Ohh your right! Then can you tell me please what should be the range of this?

    I had a bit which was the 0.bit of 10.byte and when i changed the mapping to this(what i wrote earlier):

    INW63=7, 0, x16
    OUTW63=7, 0, x16

    Then the 585. bit turned to TRUE

    If we make a quick calculation, then the 0.bit of 0.byte is $IN[505]?

    How is it possible? :O

    Appreciate your help! Thank you in advance!

    Hello guys!

    If i would like to start my inputs from $IN[1008] is this the correct form?

    INW63=7, 0, x16

    OUTW63=7, 0, x16

    I have 32 bytes IN and 32 bytes OUT with profibus communication.(i would like to reserve inputs and outputs from 1008 to 1264)

    And i would like to ask one more thing. If i know rigth i have 4096 digital in and outputs in the robot. If i go view-> digital inputs, i see only 1026 inputs. Why?

    Thanks in advance!

    Is it a solution to copy KRC4 MsgLib to krc2 System folder?

    Will i get any error?

    I am working in home office right now and i don't have here a kuka robot krc2 to test it :D

    Thanks for your help in advance!:)

    Thanks for your help JoanM !

    I just would like to know what happen if i just reconfigure I/O driver…and it was only 5 sec.

    After i tried to start aut ext, it is started working appropriate🤷🏼‍♂️😅

    Thank you!


    Are the errors persistent, or can you clear them using Acknowledge All?

    There it is…

    I tried it earlier in T1-T2 and i could ackn every single error message, but in Automatic external i could not!(i mean the plc CONF_MESS could not)

    If the errors persist, then you may have a hardware failure.

    What can i do with this?

    In T1 i could use sometimes the IOs and i could use the vacuum gripper with press the appropriate button!

    It’s weird.. sometime good sometimes bad…sometimes error field bus🤷🏼‍♂️

    Thanks for your reply panic mode!

    After these poweroutage, I asked our electricians to check the condition of the batteries. We caused a power failure and then measured the battery voltage. In their opinion, when the power was turned off and the system began to hibernate, the meter showed adequate voltage (between 12 and 13 volts).

    you mention power outage so the batteries are prime suspect and resulting file corruption.

    Can is ask please what do you mean by file corruption?
    Can the IO card be damaged in the event of a power failure?(if the batteries are appropriate(undamaged))

    Thanks for your answer in advance!


    that is a very common experience when bus is wired by someone not qualified. so check wiring and terminations

    The wireing and the configuration was completely reliable until last week. It was working about for 5months…so it doesn’t make sense. I think the KUKA worked perfectly(when power outage happened)…after power outage the system started hibernating.(i think this can’t cause problem like this, because it did what it have to)

    Are the errors persistent, or can you clear them using Acknowledge All

    I can clear it with ackn, and i can start moving with the robot(with some stuckked IOs and some of them is working correctly)

    I noticed i forgot someting...
    I don't get any message in the user message part, which would mention this problem(like profibus error). After power outage i restarted the system and i got a QUIT Local Protective STOP (QE) (Message number:3024) and an Under voltage A1 "error". Can it cause problem?

    Moreover, i got an information message, which says error on reading, driver: CP561DRV(number 1033).

    I think this is just mentioned, cause of i restarted the system!?

    As i said i got stucking IOs sometimes, even i did nothing.(just walk away for 20 minutes and nobody touched the pendant)

    Hello guys,

    I searched lots of about my problem and this one is look similar.(but reversed)

    We have a KRC2 KUKA robot with profibus communication between turck HMI PLC.(And we have a profinet communication between HMI visualization program and PLC program) The full program not finished yet. Everything worked fine until yesterday. We ha some power outage and thefore the kuka switched to hibernate. After the power came back some signals get stuck(retained). I switched off the PLC(with HMI) and IOs refreshed. Everythings worked fine.. Interrupt on when input arrived, vacuum on etc. I pressed the emergency stop and gripper off and go away for 20 minute. I came back and try to continue the process. Gripper doesn't response, some IOs get stuck when i moved the robot from there etc.(IOS don't refresing) We never had this problem before and i don't know what happened. We checked the batteries and it's working full properly(adequate voltage and charging). I thought it's battery problem and kuka can't reach the memory properly because of low voltage or something, but we refute is, when we test those. Summed up, sometimes we getting stuck IOs, when the system work "properly" and sometimes we get some signals from HMI, but don't get signals from sensors.(i connect my PC to hmi PLC and everything worked properly, but in the kuka pendant-controller some signals don't appears) IT IS SO WEIRD....

    Can someone help us please?

    Thanks in advace,


    Thank you for your quick reply.

    AS i think right if i choose $TOOL=TOOL_DATA[1], i should choose $LOAD=LOAD_DATA[1] and this is my load data[1] probably:

    I just write the valuse into the system from CAD and this will be LOAD_DATA[1] if i am right.

    Thanks for your help in advance!


    Don't forget load:

    $TOOL = TOOL_DATA[1] ;selecting right tool
    $LOAD = LOAD_DATA[1] ;selecting right tool
    $BASE = BASE_DATA[2] ;selecting right base
    PTP XHOME ;point to point movement to home

    Dear panic mode,

    I Made a movements folder with the following parameters and i got error message.

    Moreover, i determined several other lines... example.:$VEL.CP,ACC.ORI1,APO.CDIS... and so on.

    When the robot arrived to $ORI_TYPE=#VAR i got the same error message.(I could reach this, cause i commented out the $LOAD_DATA line. I know i should not, i just wanted to test it)

    Can you tell meg please why i get these messages?