KRC4 "Controller Ready" of Auto External interface is not Asserting

  • A robot that has been running for years has stopped asserting the Controller Ready bit as part of the Automatic External interface with the PLC. Does anyone understand the conditions required by the KSS to assert the signal? I checked of the hardware inside the cabinet looks normal and the perimeter gates and safety devices are in a good state.


    The faulted robot is a KRC4 NA UL controller, KSS 8.3.17 with Tech Packages Safe Operation 3.2 and RSI 3.3.


    The second robot in the cell interfaced to the same PLC is working fine.


    Any ideas on what to check would be appreciated!

  • Place your Ad here!
  • A robot that has been running for years has stopped asserting the Controller Ready bit as part of the Automatic External interface with the PLC.

    There is no signal named "Controller Ready" in the standard KUKA Auto-External signal table. To be of any help to you, we need to know the actual system variable name in the KRC for the output that is not being set. You can see the entire set of Auto-Extern signals by going to Display>I/O>Automatic External, and selecting the Outputs tab.


    Also, what messages are shown on the SmartPad when this happens? What status is shown (ie, Drives On/Off, SPS running or not, which program is selected, etc).

  • there is "Controller ready", it is signal $RC_RDY1 at the top of start conditions page.


    and unfortunately it is "documented" but obviously not properly as it does not tell the most important thing - what one can do if it does not come on:


    so the question is what changed? any hardware added/removed? any WoV project deployed? safety configuration activated? what is the safety interface? if DRIVES OFF signal true? that is a pesky one that does not show any messages.

    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

  • I checked of the hardware inside the cabinet looks normal and the perimeter gates and safety devices are in a good state.


    common mistake.. "i checked it and it is good".

    not really. something is obviously not right or there would be no topic asking for help.


    so why not show what the controller status and messages are? if asking for help, why not let forum members see for them selves if something is ok or not?


    one can monitor start condition.

    an example here is missing interface active:

    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

  • The variable name is $RC_RDY1 but I no longer think this is the correct question to ask. I forced $Move_Enable to 1025 and drives active drives in T1.


    I noticed that $StopMess is asserted. Likely this is asserted because the PLC has dropped $Move_Enable to the robot.


    So I am now thinking that the real issue has to do with something external to the robot.


    Here are is a screen shot of the "Start Condition" Auto External outputs. The only ative messages are:

    1. KSS 00203 General Motion Enable

    2. KSS 27004 Brake Test Required (Safe Operation is loaded on the robot)


    Thanks

  • I no longer think this is the correct question to ask.

    yes, often people ask for help without supplying tangible info. things that may be glaring obvious, can be not discovered until topic has grown a lot. so statements like "i checked XYZ and it is ok" are usually the problem because we do not know the experience level of the user.

    I forced $Move_Enable to 1025 and drives active drives in T1.

    this signal is displayed and easy to see - usually. sometimes PLC logic is bad and signal is not stable (glitches or oscillates). in that case setting to fixed value like 1025 can help identify the problem, specially when access to PLC is not available so forcing PLC output is not possible.

    I noticed that $StopMess is asserted.

    that is an important clue. original post reads as if everything is fine. it is clear now that robot not running is not a mystery. screenshot of pendant (program screen and all messages) would be enough to sort this out.

    So I am now thinking that the real issue has to do with something external to the robot.

    That is correct, PLC need to keep $MOVE_ENABLE on all the time unless there is a severe issue.


    The only ative messages are:

    1. KSS 00203 General Motion Enable

    2. KSS 27004 Brake Test Required (Safe Operation is loaded on the robot)

    messages also display effect they have on the robot.

    for example this message does not stop robot:

    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

  • there is "Controller ready", it is signal $RC_RDY1 at the top of start conditions page.

    ...derp. I've not sure I've ever even noticed it being called that. I only paid attention to $RC_RDY.

    Here are is a screen shot of the "Start Condition" Auto External outputs. The only ative messages are:

    1. KSS 00203 General Motion Enable

    2. KSS 27004 Brake Test Required (Safe Operation is loaded on the robot)

    Have you performed the Brake Test? The PLC might be programmed to block the robot from running in Auto External until the Brake Test has been carried out.


    Also, setting $MOVE_ENABLE to $IN[1025] is normally only allowed for T1/T2/AUT modes, not EXT mode. Normally any attempt to set EXT mode with $MOVE_ENALE set to 1025 results in an unclearable fault and the robot is inoperable.

  • missing brake test should only prevent operation after some time (2h). but missing move enable stops immediately...

    That was why I said the PLC might be blocking $MOVE_ENABLE if the BrakeTest Request output from the robot was on. It's a long shot, since usually systems are set up to allow the Brake Test in EXT mode, but it's worth checking.

  • I'm not sure I've ever seen $I_O_ACT set to anything but $IN[1025] (always True) in any KUKA I've ever worked on.


    $MOVE_ENABLE should be True except when the PLC needs to prevent the robot from running without causing an E-Stop or other safety fault. $MOVE_ENABLE has much the same effect as the E-Stop, except that $MOVE_ENABLE is not a safety-rated signal, and the robot does not throw a safety fault when $MOVE_ENABLE is reset.


    Most of the time you can leave $MOVE_ENABLE True and have it act in parallel with the safety signals.

  • I made an assumption that that $I_O_ACT was only required for EXT mode. I see this is incorrect and it is required always for all modes T1/T2/AUTO and EXT. Thanks for the clarification.

  • I made an assumption that that $I_O_ACT was only required for EXT mode. I see this is incorrect and it is required always for all modes T1/T2/AUTO and EXT.


    Hmmm... what? What made you conclude that?

    It was just said that nobody seem to bother to modify the value from factory setting... It was not stated that it is impossible to change it or that it also applies to other modes.


    Why not simply check the manual?

    Where does it say that this is needed or required for other modes?


    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

  • I was "checking the manual" and thought if there is an $I_O_ACTCONF checkback signal that must mean the Robot needs to receive a $I_O_ACT from the higher level controller. Is it really such a stupid leap?

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