Safe Operation Mastering test issue

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!

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!

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?

Quote from Fubini

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.

Fubini

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

Quote from SkyeFire

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

Quote from Fubini

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!