1. DIY-Robotics (Help Center)
  2. Community
  3. Troubleshooting — FANUC

TCP Reteaching

Avatar
Matthew Ungar

Hello,

Last week I was updating some welding consumables on one of our ArcMate 100ic robots. I noticed there was a significant crack through the EOAT's welding torch and we replaced said EOAT. 

The issue I'm running into is that the TCP was apparently taught to the cracked EOAT so my points are now out. First thought I have is to reteach the ToolFrame/Utool to the new EOAT. Now when I did this, and I forward to points, I am exactly the same distance away from where the TCP should be as I was before, but the Cartesian values are different. 

I have tried this multiple times, I have remastered multiple times, yet my TCP keeps going to the same spot (about 2 MM out on the Z axis and 7 MM out on the Y axis) and just showing different Cartesian values.

Does anyone have any advice on how I can fix my TCP without having to go through and touch up every program this robot runs?

Thanks,  

Didn't find what you were looking for?

New post

Comments

3 comments

Sort by Date Votes
  • Avatar
    Gabriel Hallée
    Comment actions Permalink

    Hi Matthew,

    Could you make sure that the programs you are running use the same Tool Frame as the one you retaught?
    You mentionned remastering, do you mean reteaching the TCP or you actually remastered the robot? (Should not be necessary)

    0
  • Avatar
    Matthew Ungar
    Comment actions Permalink

    Yes They are using the same tool frame.

    I did remaster the robot, but also retaught the TCP. 

    0
  • Avatar
    Gabriel Hallée
    Comment actions Permalink

    Hi Matthew,

     

    If the correct UTOOL is selected and you've retaught the TCP based on the new EOAT, the programs should indeed run using this new TCP. That means the robot should move to the same Cartesian positions as before, even though the joint angles will differ due to the geometry of the new EOAT.

     

    However, based on your description, it sounds likely that some or all of the program points may have been touched up or retaught while the EOAT was cracked — meaning the TCP at that time was effectively incorrect. So while the robot was executing motions using what it thought was the correct TCP, the true TCP (e.g., the welding tip location) had shifted due to the damage. Now that you’ve correctly retaught the TCP using the new, undamaged EOAT, the previously recorded points no longer line up — because they were created relative to an invalid TCP.

     

    In this situation, there are two paths forward:

     

    1. Band-aid fix:
      Determine the positional offset between the “expected” TCP (from the cracked EOAT) and the new, correct TCP — for example, measure the difference from the end of the old welding tip to the new one. You can then apply this offset manually to the TCP (UTool) values, which may restore alignment with the previously taught points.

    2. Proper fix:
      Keep the newly taught TCP as it is, and update the program points so they are all based on this correct TCP going forward. This ensures consistent, reliable behavior and eliminates any dependency on offsets from a damaged tool.

     

    Either way, I’d recommend reviewing the program points to see when they were last modified — that might confirm whether they were touched up while the EOAT was already compromised.

    0

Please sign in to leave a comment.