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.
Posts by Marvin_PA
-
-
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?)
-
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. -
Hi there,
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? -
But doesn't the MasRef position only care about the E6AXIS position? I'm missing how the Abs-Acc Cartesian positioning would affect that.
Would changing the MasRef position from E6POS to E6AXIS help resolve this issue?
We did try this, but it didn't make a difference.
I think it does check XYZ catesien as well as the axis positions (as this is what it stores for the reference postion on the safety configuration screen, and in the Logs we can see it make a pass/fail check on A1-6 and XYZ position).
Doing a little bit of experimentation, it seems to be much less picky on the value of the XYZ (+/-1mm of target is fine, any greater in a direction triggers a failure when mastering); , but it does also need each axis to be correct to the target (and far enough from the mastering position for that axis). The frustrating thing is using the "touch up reference" function in the Safety Configurator on the pendant sets the Axis values fine, but the XYZ values set aren't what it wants to see when reference (but they are what the "display position" on pendant reads out, and what the .dat contains if you set the position to be in tool0/base0).
In absolute Accuracy Robots you have always two different Cartesian positions. The one with absolute accuracy active and the one without absolute accuracy. If I remember correctly the reference position inside the safety configuration is always without consideration of absolute accuracy (the safety controller never uses absolute accuracy). On the other hand $pos_act and on the smart hmi actual value page is with consideration of absolute accuracy. If you want to test this you can temporarily deactivate absolute accuracy by setting $deactivate_abs_accuracy to #TRUE. The reference position in safety configuration therefore should stay the same if you do a touch up once with absolute accuracy activated and without moving the robot with deactivated absolute accuracy. Hence when you do a mastering test always two Cartesian positions without absolute accuracy are compared and the test success should not depend on the load data.
I'd like to test this as it sounds like a likely reason, and would be good to know the root cause even if we have it working (currently am using the X and Z values from the KRCDiag as ref pos targets, rather than teaching it using "touch up"). However I can't seem to find "$deactivate_abs_accuracy"? (It defineitly is active, as $abs_accur is set to #ACTIVE and not #SUPRESSED; however that is read only)EDIT: apologies, found it at $suppress_abs_accur; will read the documentation properly before posting next time! Will test and get back with result.
Thanks so much for all the replies! I've used ABB and KUKA robots for research for a near a decade, and had no idea how good this site was for informal support on short notice! -
So you probably have an absolute accuracy robot. Then this position difference is normal. But it would be advisable to check if load data is set correct because position differs for different loads and best match to real position is with correct load data.
FubiniAs a heads up, have kind of solved and I think this might be the reason. It is a KR60 HA robot, and the KRcDiag logs showed that it was wrong by 3mm in X and 1.5mm in Z. What was werid was the taught position was still what it read out, so I assume there is some other measure of position internally with a HA robot? The load data is a bit off, so will be looking at that to see if that is the reason for the discrepency.
-
Sounds like I should check the approach is completely level so both channels change at once, I'll go over it on Monday and see how it goes, thanks!
On the reference postion, I did teach it in both MasRef_User and Safety Configurator. As an aside, there was a odd mismatch though. Using the "touch up reference point" (looking at Reference point in Safety Configuration) the axes angular values were correct, but the XYZ cartiesien position that updated was very rough (1 or no decimal places) and was different in some axes (Y and Z in our case) by 1-1.5mm to the actual Tool0/Base0 position read out. However I tried both the taught "touch up" values and typing in the cartesien position read-out ones and the results were the same, so I don't think it's relevant to this issue? -
It is roughly aligned and looks pretty close, but it might not be perfect and I was running slow-ish: I try adjusting the angle and upping the approach velocity (keeping in T1 for now, but could move to T2 if that doesn't work) and get back on if it works!
-
Hi there,
We're having an issue with the mastering test using Safe Op on one of our KR60s on a KRC4 (KSS V8.8.13), and while it seems similar to other issues posted on the forum, none of those threads had a solution that worked for us sadly.Basically we get "Mastering test position not reached" (KSS15051) during a mastering test. However as far as I can tell from going over the SafeOp manual and my old training notes, all the aspects required are there. We have the sensor setupas at cabinet and going into X42 (and can see it "actuate" when triggered on the Diag screen), and we have taught the reference position in the Safe Operation config and checked it is correct (all far enough from mastering to be acceptable, and all correct on axis values and XYZ position).
The fork comes in and the lights go out on the switch. The moves there are quite complex and take a while (it is a robot working in tight confines with a big end effector, so we have to rotate a bit before approaching), but it runs them with no issue from MasRef_User and gets to the reference point. When it sets the $MasteringTest_Group to nGrpNr (1 in our case, as no external axes) in MasRef_Main the error pops up.
Is there something obvious I might have missed in the setup? It says in the manual that the error means referencing process was interrupted, but it ran through without pause until that point fine...it did have BCO on the very first move (as I'm running manually for now, selecting MasRef_main and running it in T1), could that be related? (apologies if I'm waffling or clutching at straws a bit here, been trying to get it to master for 2 days!)
Thanks!