TCP not setup. To set up now or not?

    Hello,

    Some of our Robots have never had TCP setup nor any tool weight/gravity information.

    I'm not concerned about the Weight and Xg, Yg, Zg data since the robot will just assume worst case scenario for this to avoid internal damage. I will avoid setting this up since this change could change how the robot moves, affecting existing programs, and would traditionally require verification of all programs before continuing in Auto mode. This wouldn't be as big of a concern in automotive, but my cycle times here range from 45 minutes to 5 hours. The programs are very large and there are close to 100 programs in each Robot (High mix- Low Volume environment). Please correct me if I'm wrong here.


    I am seeking opinions on whether I should set up TCP on these Robots that have been running programs for a few years now without TCP set up at inception of the cell. So far things run decent as I use TAST and searches. There is usually daily reteaching since parts are fit up a bit differently by each man, parts are cut and formed inconsistently too. No fixturing is used for fitment but this is changing next year.

    If I set up TCP, all existing programs will need to be verified fully (this takes easily 4-8hours per program). It's maybe possible to use the PMT function to speed things up here to bring the Robot closer to the mark, but will likely still require re-teaching?

    What action would you take in this situation?

    This is a tough one. I'm assuming you are arc welding. How are the programs taught, pulse counts or XYZ?

    Assuming pulse counts the position is the position, it could care less if there was tool data or not. The controller will calculate the path of the TCP in a MOVL, MOVC, or MOVS. So with new tool data (assuming default flange vs a torch) the path could change slightly. Assuming also that you are not doing coordinated motion. Programs taught in XYZ are a whole different ball game.

    Since you mentioned weight, Xg, Yg, and Zg I'm assuming this is a XRC or newer. The tool data is also used interference areas that are XYZ, possibly the functional safety unit depending on what features are used, etc... So you have to do all your homework before changing the tool data. You mentioned searches and TAST (I don't know what that is), so you're probably shifting. The coordinate system for shifting needs to be verified. Shifting in tool before vs after.

    Assuming default tool data vs a torch with an angled gooseneck I would NOT use PMT. PMT will basically convert your jobs to XYZ based on the old tool data, apply the new tool data, then convert the jobs back to pulse. With an angled gooseneck the arm is going to rotate 45 degrees (assuming 45 degree gooseneck) and then some. Currently, your positions are the encoder count position. You have the position.

    I know a thing or two, because I’ve seen a thing or two. Don't even ask about a third thing. I won't know it.

    95devils

    We run with YRC1000's and are exclusively arc welding. We have a mix of Relative jobs and Pulse jobs within most robots due to a previous issue causing set positioner values to flip polarity after pressing "Modify -> Enter" during program modifications.

    Due to this, I send only Pulse count jobs to some robots, and relative jobs to others that didn't have the issue.

    Yes, unfortunately I do run coordinated motion (R1+S1:S1) jobs on all robots. This would definitely make things more complicated.

    TAST = Thru Arc Seam tracking.

    doomedblue

    Sounds like it may not be worth while to make any changes at the moment. If anything, I will start sending Pulse count jobs to every robot.

Advertising from our partners