Apologies in advance, I don't have all the details I would like as the error is cleared and can't be reproduced easily, so I may not be able to detail things as much as I should.
Basically we have a Kuka (KR60 on a KRC4) doing a task in which it can push on a surface with the end-effector. When this happens, very rarely, a joint (4 and 6 it has occured on) can torque out. Now I cannot recall the exact message, and I can't recreate it on demand, so apologies. If it occurs again I will take a screenshot.
I'm not conerned about the limit itself (it will, and should, happen as it is making contact with a surface it shouldn't touch). However while it stopped the robot moving, it didn't trigger an eStop. This meant that the rest of the system (connected via ProfiNet/ProfiSafe) couldn't tell it had torqued up and stopped, you could only tell by reading the teach pendant. I had a quick look at the various safety and control signals sent to the PLC over Profinet (like Drives Enable, AF, and Motion Enable, FF, StopMess and such) and couldn't see anything that changed state when the axis hit it's limit (although admittiedly this was only a quick check as I had to get the error cleared and move the robot off the part).
Is there a signal that changes state if an axis hits a limit, or a signal that says the robot has torqued out an axis?
how exactly did you implement this limit? if you do something yourself you need to take care of everything including corner cases. also there is a difference (and clear separation) between standard and safety signals. safety signals require safety circuits (hardware or software). what safety device you use to determine force or torque limit? do you have that device wired into EStop circuit? if not, why do you thing robot should react the way you expect?
I think that they are talking about the built in robot torque limit. Axis 4 and 6 were mentioned.
Yes, apologies is hard to explain without images of the issue.
As Lemster guessed, I meant the built in limits (on the axes specifically) triggering due to an unwanted collision, not a limit we've implemented in any way (the robot doesn't have ForceTorque or similar setup).
We don't want to hit this limit, as it means the tool has hit the part (which is incorrect for the process). But if it does happen to hit the part, the current behaviour from the robot (robot stops moving) is what we want and is fine (entering estop state would be preferred!); what I'm missing is a signal out form the robot controller I can monitor to inform other parts of the system that the robot has stopped due to this axis torque limit. (As would happen if an e-stop was hit or similar)
In terms of signals, we are using Profinet M/S 3.2 with ProfiSafe (and SafeOperation): the safety signals are pre-determined by the Profinet device and SafeOp (74 safety booleans; such as estop state, mode, active tool etc); the controls signals are regular profinet bools/words etc. linked to either AutoExternal signals (like $StopMess for example) or to process signals for the program that we've made (that aren't relavent to this).
What I really need is an internal KUKA signal we can send out to the PLC (safety or regular) that tells me this axis over torque limit has happened. For example: if someone hits the pendant estop, a local estop (KRC_NHL) is sent as part of the kuka safety signals. As part of auto external there are signals like stop mess that tell the PLC it needs to do the next bit of the handshake (conf_mess).
However, when the axis torque out/limit error occured, I couldn't see any signal telling me this was the case. I've tried to search for it in the manuals, but had no luck.
I'm afraid I can't detail the message exactly unless it happens again (which is not desired, but could happen), in which case I'll put a picture up.
when kuka robot reaches some design limit it displays messages and program is stopped. this is stressful on the robot and shall be avoided. also in such event several signals change state to reflect the situation.
$STOP_MESS goes TRUE
$PRO_ACT goes FALSE etc.
such signals need to be mapped to external systems of course.
again those are not the safety signals. they would be exchanged in standard block.
safety signals are grouped in 64 bit block (not 74). this is predefined and cannot be changed.
but there is also standard block which is meant for standard signals.
you can choose size of the block as well as map anything you need there.
i strongly recommend to check pinned topic READ FIRST and specially key manuals:
programming manual for system integrators, System variables manual etc.
Hi panic_mode, sorry clicked key, yes 64 pre-defined/determined safety signals, and I know about the standard block signals (and have configured it for signal exchange for a bunch of things we do, as well as running programs Auto External).
What I can't find in the manual is exactly what signals change state to reflect this situation of a joint hitting a torque limit (and as you pointed out , I want to avoid causing again to check!).
When it happened I had a look and I couldn't see Pro_act, stop_mess, alarm_stop etc change state as this was where I first looked (although I could have missed it as was trying to recover the robot). I was wondering if a joint hitting a hard limit like this had a particular signal or set of signals that change (and it felt like an event that should trigger an internal estop, although it appears not?)
you can check logbook for past messages : menu Diagnosis, Logbook, Display
if that does not help you can try to find the right message in documentation : menu Help, Messages, System Software, KSS
messages have numbers and there is a function that can be used to check if specific message is displayed. for example KSS00209 is displayed when system is running in EXT mode but someone presses stop on smartPad.
the key here is the message number. you can use function ISMESSAGESET(message_number) to sense it...
perhaps something like this could work for you:
$OUT = ISMESSAGESET(209)
That would be ideal, never thought to check the log for the message, thanks! If it happens I'll check the logs and give that message catch a go (I've also setup a rotating trace on the PLC for those Pro-act, stop-mess, alarm-stop etc signals so I can confirm how they behave).
If it collides with the part again, I'll update this forum post with what message number and signal behaviour is.