Nonsensical TCP behavior

    so can you please show what you are doing and ... how? which tool and coordinate system is selected? post full screenshot of the HMI

    1) read pinned topic: READ FIRST...

    2) if you have an issue with robot, post question in the correct forum section... do NOT contact me directly

    3) read 1 and 2

    Quote from Wall-E

    In fact, (what I had overlooked) he insists on not changing the angles too much between measurements.

    Werner for shure has big knowledge in Robotics. But in this matter I wanna contradict.

    Moving just a very small amount (only 7 degrees or so) during tool calibration is not the best way to do. As you have seen in your measurent, you get a very small value for the calculated inaccuracy, but this is only half the truth. The small movements also give a small accuracy in the internal calculations but when you check the tcp like you did, you find a big deviation.

    So in my opinion and experience best practice is a movement round about 40 degrees.

    Quote from hermann

    The small movements also give a small accuracy in the internal calculations but when you check the tcp like you did, you find a big deviation.

    So in my opinion and experience best practice is a movement round about 40 degrees.

    I think I have to agree with you on that one.

    OK then, back to calibratin'

    This may be completly useless information, but there is something like $TOOL_CORR that you can use to set temporary tool offsets. (Check bas.src for how it is used) If this tool correction is on and the tool correction frame is something other than nullframe I am guessing you could see some "nonsensical" behaviour.

    just coming back


    in my post #52 I asked for


    Quote from MOM

    My suggestion at the first place would be:

    compare the CAD drawing with your tool defintions


    I also asked asked for more information!


    Your problem as I expect:

    - robot not adjusted correctly

    - table not adjusted correctly

    - not adjusted correctly to each other


    As panic mode mentioned in post #63


    Quote from panic mode

    1. did not show tool as robot is in cannon position. this is a fundamental step needed to ensure correct

    Take check flange set a1=0,a2=-90, a3=90 a4=0, a5=-90,a6=0, take a level and check

    check table to be levelled

    I give up trying to get a proper measurements done by the robot itself.

    This thing seems un-capable of consistency, and errors, play, backlash, etc... keeps adding up to give a shitty result.

    I decided to make a 3D scan of the wrist with the spindle and reverse-engineer my way to get the XYZ and ABC values of the center of the tool's collet chuck.

    As an added bonus, I can model the cable management system to take it into account in my simulations.


    I'll report back my results based on these values.

    First results show that the scan allowed me to define my best XYZ / ABC values yet.

    Rotation around tool TCP still shows unwanted displacements, but much less than what I obtained with the "4 directions" and "ABC world" methods.

    That tracks with my experience. TCP rotation is where robot accuracy gets its worst error.. Keeping a fixed orientation, the robot can be surprisingly accurate positionally, but as soon as TCP orientation changes are added, the error climbs sharply. And the error scales much faster than the rotation.

Advertising from our partners