Interpolation Error using External Axis

Robot Controller IRC5
1

Hello all,

We are using the IRC5 with RW 5.15.15, using an extruder set up as an external (7th) axis. Robot is 6640.

Unfortunately we are getting frequent “Geometric Interpolation Error” 50376. This only occurs when there is an instruction to the 7th axis, but doesn’t occur in the same place in the program, sometimes it will run fine and other times fail, so a bit random. We can see the robot struggling/shuddering on some movements, other times the movements are perfectly smooth.

The programs use generated coordinates and values placed in extax_a. Some of these programs will be large, but we see the same behaviour on simple programs too.

Docs tell us to change coordinates (not possible), increase zone size (tried), change tool orientation (will try) or interpolation method (how?).

This appears to be a known issue with RW5 although it would be great to figure out a workaround.

Appreciate any thoughts!
Tom

2

Hi…
Have you tried using CalcJoint()?
I believe that when you’re calculating “generated coordinates and values placed in extax_a,” the robot can’t reach its destination.
When an external axis is used, it becomes part of the robot’s positioning calculation. Changing it is the same as changing the position of a robot axis. If done incorrectly, it will result in an error.

Try the following; it might help:

VAR robtarget P_ReturnPositionL;
VAR jointtarget jt;
! ...
jt.extax.eax_a:=100;
P_ReturnPositionL:=CalcRobT(jt,yourTool\WObj:=yourObj);
MoveL P_ReturnPositionL,v1000,fine,yourTool\WObj:=yourObj;

Good Job

3

If it is indeed a known issue, get the release notes for 5.16 to see if it addresses that issue.

4

Thanks Mandolas and Lee,

The external axis is a rotating motor, and we are using MoveL commands. I understand the robot is attempting to calculate all axes to reach the desired coordinates in each movement. I can’t see a pattern for when it fails and when it doesn’t.

Our programs look like this (simplified), it seems quite close to what Mandolas has suggested, but there might be some key differences for our case.

ActUnit M7DM1;

targetPos := CRobT(\Tool:=Extruder \WObj:=PrintBed);

extruderCurrent := targetPos.extax.eax_a;

MoveL [[x,y,z],[0.00483665,-0.69795641,-0.71610888,-0.00464094],[0,0,-1,1],[extruderCurrent+x,
9E9,9E9,9E9,9E9,9E9]],v100,z100,Extruder,\WObj:=PrintBed;
MoveL... as above

x is a value calculated to give the correct rotation of the external axis for our set up, based on extrusion values from a 3d printing slicer. This value (x) gets larger, accumulating on each line and added to extruderCurrent.
The same thing happens on simple 3 line program as it does with much larger ones.

Today I have tried increase z to z200, Accset to 20,20, Configuring High Interpolation Priority to ON, Additional Interpolation Object to 1, and 2. Also played with PathResol a bit,

Thanks for the suggestion Lee, unfortunately I haven’t been able to find the release notes for that RW version (sigh).

Many thanks,
Tom

5

Is this process one in which the robot moves slowly?

6

Hello,
Can you check your [x,y,z] values compared with targetPos ?
Can you show your PrintBed values ?

7

Hello both,
Lee, this is not a program that fails, just an example for readability. It happens on many different types of movements, but is not consistent in when it fails, i.e. the same MoveL will work sometimes and not others, even on the same program. I would say it is consistent in that you can tell it is struggling whenever instructions are given to the 7th axis, but some movements are performed perfectly. We ran a large program with no 7th axis instructions and there was no stuttering or stopping.

Denis, the PrintBed values are below. This is the center of the print bed.

PERS wobjdata PrintBed := [FALSE, TRUE, “M7DM1”, [[1964.000,20.000,430.000],[0.70710678,0.00000000,0.00000000,0.70710678]],[[0,0,0],[1,0,0,0]]];

I’m not sure what you mean by checking xyz against targetPos? The xyz values are generated by software using gcode coordinates, and there are many of them.
TargetPos is only used to get the current extruder position so we can add onto it on each MoveL line.

Hope that makes sense and appreciate your time.
Tom

8

You mentioned that sometimes the error occurs and sometimes it doesn’t.
CRobt() captures the robot’s current position, so for accuracy, the previous movement must be FINE.
Check this.
If the movement preceding the instruction cannot be FINE, I recommend using CalcJoint().

9

Did you ever get that servo tuned?

10

Thanks again,

Mandolas, your comment made sense and today we tried quite a few things:

  • Preceding MoveL lines with MoveAbsJ and “fine” zoning
  • Various combinations of CalcJointT, CJointT, and CalcRobT to set positions initially (always fine zone) and return current positions. All had the same result, an error.

Lee, the servo is brand new but I can’t say with any detail how it was set up. Our cell was put together in Europe and shipped to New Zealand. One of the key companies in set up has gone bust, so we are struggling to get any information.

Perhaps there is something not set right in the config file, and our next avenue to explore is using the extruder as an independent axis - this is set up on the system (610-1) but we get an error telling us ‘50156 Not an Independent Joint’.

I appreciate your time guys,
Tom

11

Hi…
Test it like this and check if there was an error.

MODULE ModuleMoveOffs
    PERS tooldata Extruder:=[TRUE,[[0,0,0],[1,0,0,0]],[0.001,[0,0,0.001],[1,0,0,0],0,0,0]];

    PERS wobjdata PrintBed:=[FALSE,TRUE,"",[[0,0,0],[1,0,0,0]],[[0,0,0],[1,0,0,0]]];

    VAR robtarget rt;
    VAR robtarget rt2:=[[100,200,300],[1,0,0,0],[0,0,0,0],[9E9,9E9,9E9,9E9,9E9,9E9]];

    VAR jointtarget jt;

    VAR pos offsP:=[0,0,0];

    VAR num extruderCurrent;

    PROC MoveOffs()
        ! rt2 == Your reference point ...
        jt:=CalcJointT(Offs(rt2,offsP.x,offsP.y,offsP.z),Extruder\WObj:=PrintBed);
        jt.extax.eax_a:=extruderCurrent+offsP.x;
        rt:=CalcRobT(jt,Extruder\WObj:=PrintBed);

        MoveJ rt,v100,z100,Extruder\WObj:=PrintBed;
    ENDPROC

    PROC main()
        MoveOffs;
    ENDPROC
ENDMODULE

Use your position, tool, and object to test in RT2.
Good Job

12

I should have asked if the servo is an ABB servo. In either case, it needs to be properly tuned. Tunemaster is located in the Robotware files under tools or utilities folder. I would try that or get an ABB technician to come tune it.