ERROR Handler not catching overload error: 50055 Joint Load too high

RAPID Programming
1

Hello,

I have an application where the robot arm is pulling on something under tension. If something goes wrong, the tension gets too high and it should run my error handler.

At low speed, it works fine and catches the error as 1070 ERR_COLL_STOP.

But when I increase the speed to my production level, the same code doesn’t catch the error, instead it ends being handled by the system error handler which stops execution and displays an event message 50055 Joint Load too high.

My ERROR handler is not conditional, it catches everything (even div by zero and bad array index). Can someone explain why this changes from a collision to a joint overload and tell me how to catch and handle it.

Any help is much appreciated,
Dave

2

The problem here is mostly that the program has stopped executing. The error handler does not work if the program is not executing. Maybe you can try to put that error for the main routine’s error handler. Do you have multitasking?

3

Thank you for the fast response Lemster68.

Yes, I have multitasking. One motion task and some background stuff for cameras, socket comms, etc. Does that change anything?

As you suggested, I moved the error handler to my main routine but nothing changed. At low speed, it handles it as a 1070 collision and runs my recovery commands, but at high speed it doesn’t catch it. Instead, it shuts down and throws a system error 50055 Joint Load too high. My understanding was that an error handler would catch any error, but apparently I’m wrong.

My test is quite simple: I have a main Proc that is a continuous While loop. Then I have a another Proc ErrTest that simply grabs a fixed object and starts to pull, which results in an error when the tension gets too high. ErrTest is called in the main loop by a boolean.

WHILE TRUE DO

IF testError THEN
testError:=FALSE;
errTest;
ENDIF
ENDWHILE
ERROR

TPWrite(“error handler test - main”);
TPWrite(NumToStr(ERRNO,0));

here:=CRobT(\Tool:=grip_B,\WObj:=wind_fixture);
StorePath;
reset outCloseGripper;
set outOpenGripper;
waittime 1;
MoveL offs(here,0,0,40),v100,fine,grip_B,\WObj:=wind_fixture;
WaitRob\InPos;
RestoPath;
StartMove;

ENDPROC

I’m not too clear on how to structure the error handler so feel free to comment on that too. But my main concern is catching the error and recovering.

4

It really might just not work because the program has stopped. However, since you have multitasking you could at least deal with the gripper in a background task if there is a collision. As far as the error handler goes, use a TEST CASE ENDTEST, and include a default CASE. Put a program stop or placeholder, to stop program execution. I usually use

5

I don’t see how the background task will be aware of a collision event in the motion task. An error handler there only catches errors caused by routines from its own task. Are you suggesting that I try to set a PERS variable as a signal before main execution stops?

And thank you for the general error handling tips.

6

Have you activated “CollisionErrorHandling” in the system parameters?
Configuration → Controller → General Rapid

I think @lemster68 is thinking about the system output “Motion Supervision Triggered” that maybe it can notify the background task’s that a collision has occurred.

In that case you can either force an interupt in the maintask from a background task with system inputs.
Or you can set a bool in the background task, and then check that bool in a event routine at program startup. And you can start the robottask with a simulated I/O system input.

7

Yes, I double checked my configuration and I do have CollisionErrorHandling=Yes. I also noticed in Control Panel > Supervision there is a setting for Non motion execution. Do you know what this does?

So it looks like I need to accept that there is no way to directly handle this fault because the system fault is shutting down the main routine - is that correct?

Now to figure out the solution suggested by you and lemster68:

  • Configure a system output MotSupTrigg and connect it to a digital output.
  • In a background task, connect a trap to ISignalDO.

This works, but maybe I shouldn’t assume a trap is necessary, I can just watch for the digital output to go high.

I might need some help with the next step:
You said, “force an interrupt in the maintask from a background task with system inputs”.

How can I do this if the main task was stopped by the system error?

Your other suggestion, “Or you can set a bool in the background task, and then check that bool in a event routine at program startup.”

Are you referring to a configured event routine like Start or Restart, or do you just mean that my main routine should check for this boolean? Then if I see this boolean true, I take care of cleaning up the collision before starting the normal business of the main routine?

Assuming I’m still with you up to here, can you provide more detail for: “start the robottask with a simulated I/O system input”? Is this the background task setting a digital input that is configured to a system input like “Start at Main”?

Now, taking a step back, am I missing something obvious that gotten me this deep into a fairly complex solution? Other than preventing the collision from ever happening. Seems like a very common thing to recover from a motion supervision event without manual intervention . How am I getting into something that’s so hard to recover from?

Thanks to both of you for jumping in to help.

8

Non-motion execution puts the robot into simulated motion mode. Servo power is off and even jogging is simulated. Great tool for cell startup and debug sometimes.
It is odd that you say collision error handling is already enabled. But, then again, the error is joint load too high, not a collision. Perhaps is you make your motion supervision setting to be more sensitive, it will trigger a collision before you get to the joint load too high.

9

It looks like I don’t have the Collision Detection option, unless it is included in Path Recovery, or SoftMove. According to the manual, Manipulator supervision level is only active if the option Collision Detection is installed.

10

You can also try to set a higher mass to your tool and see if the system behaves differently?

I think you understood me correct, it is a complex workaround for sure but as said before, the fault is not recognized as a collision.

11

I have never been able to recover from a joint collision with the error handler. Usually the only way I get the error handler to catch the collision is by lowering the speed. In my case this often occurs when picking rolling parts from vision camera.

But as lemster68 said, try to lower the supervision trigger level e.g. “MotionSup\On\TuneValue:=50;” But that only works if you have option Collision detection.

12

Some years ago I coded a background task to open the gripper if there was a collision. At that point, the robot was given a startmain system input and needed to run a homing/recovery routine at the beginning if it was not at home.

PROC Main()
    WHILE (TRUE) DO
      IF  fiNewTray_11_1=1 ResetTray_1MD11;
      IF  fiNewTray_11_2=1 ResetTray_2MD11;
      IF  fiNewTray_13_1=1 ResetTray_1MD13;
      IF  fiNewTray_13_2=1 ResetTray_2MD13;
      IF bInstallMotion AND DOutput(foMotionSupTrig) = 1 THEN
      	Reset doClampJet;
      	Set doUnclampJet;
      	Set foPartRejected;
      	bInstallMotion := FALSE;
      ENDIF
      WaitTime 0.5;
    ENDWHILE
  ENDPROC

In the motion task the boolean, bInstallMotion, was set to true in the final motion to install a part, this was where the collision would occur, if at all.

13

@DaveCleveland If it is really that critical to what you are doing, you could contact ABB to purchase the motion supervision and collision detection option. With my limited experience with getting quotes for options, they seem to usually fall in around $1200 USD.

14

I checked with my reseller and he said both were included in my purchase. I told him it did not appear when I list options from Control Panel > Installed Systems. He thinks they don’t appear as options because they are part of the system and don’t need to be added. I’m not sure about that.

Would I get motion supervision errors like I do (at slower speeds anyway) if I didn’t have Motion Supervision? Or is there some baseline functionality that will always catch some errors?

And would my configuration screen allow me to edit the values for Manipulator supervision and supervision level?

I tried a whole range of values for supervision level but noticed no change. Could it be that the settings are enabled even without those options but they are non-functional?

15

Try opening installation manager and check that the options are selected.

Make a backup before because when changing options the system can get restored.

Installation manager is available in the controller tab in robotstudio.
Unless it’s a omnicore system you should use installation manager 6 :victory_hand:

16

You can look in the backinfo text file from a backup. It will show your options listed. You can still get motion supervision without the option. If you do have the option you will be able to insert the instruction MotionSupOn or Off \tunevalue:=xx (might not be exact correct sysntax).

17

It is not listed in the backinfo file. And trying to use MotionSup \On in a program brings up an error saying the system does not have that option.

Do you think adding this option might enable error handling for joint overloads?

18

Well, possibly. I had mentioned earlier that I think that if you tuned the supervision to be more sensitive, then you could catch it as a supervision error, rather than let it escalate to the joint load too high error.

19

Have you checked installation manager as i suggested ?

20

If you are still willing to help, I have a follow-up question.

I am using IError to successfully trap the joint overload errors that seem to evade the Error handler. The motion task still gets shut down but I am catching them in a background task as recommended by several responses here.

But this leads to another question: How can I recognize the errors I want to trap? The reported error number from IError drops the first digit for some reason which leads to ambiguity because I need to trap 50052:Joint speed error. But when the first digit is missing, I can’t differentiate between 50052:Joint speed error and 10052:Regain start. This causes problems because I am restarting the motion task from the background task which causes the trap to see 52 again (as Regain start) and creates an endless restart loop.

I am working around this by using ReadErrData to get the error title, then parsing that string to look for some text that is unique to the joint overload errors. This is not a very robust solution. Can anyone show me a better way to identify the error?