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

Quote from UpperLeft

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.

Quote from UpperLeft

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:

Quote from UpperLeft

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.

Quote from UpperLeft

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.

Quote from UpperLeft

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.

Quote from UpperLeft

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.

Quote from UpperLeft

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:

Quote from panic mode

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.

Quote from UpperLeft

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

Quote from panic mode

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.

Hello,

Q1: Under what conditions should the PLC change $I_O_ACT to FALSE?

Q2: Under what conditions should the PLC change $MOVE_ENABLE to FALSE?

-thanks in advance

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.

Quote from FugTwad

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?

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?