How to easily become a Tool Offset master to save time and impress co-workers

    It's been a while since I've been active on this forum, but I thought I'd come back with a useful tip I've learned about using position registers as tool offsets. In the course of programming these robots, I'm sure many of you have noticed a pattern in the motion when it comes to interacting with fixtures and parts. You may have different terminology for it, but I'm sure it looks the same:
    [list type=decimal]

    • Large move to locate the end effector in the vicinity of the work

    • Moderate move to locate end effector to a "perch" position closer to the work (and sometimes wait)

    • Low speed move to actually do the work (pick, place, whatever)

    [/list]
    And then the reverse when the work is done.

    Now if you're not using offsets at all, that's at least three separate points to be taught right there. Stop doing it this way. If you use nothing else from this post, at the very least start using the Offset,PR[] motion modifier to simplify your life. But, Offset, PR[] is not what this tip is about. Today I'm talking about the Tool_Offset,PR[] motion modifier. In my experience, I have not seen this modifier used nearly as often as the regular user frame offset. This may be due to the slightly confusing requirement to re-orient yourself to the tool's frame instead of the workpiece. It may be a lack of explanation on how to use it in training and documentation. But in my experience, Tool_Offset will be a better choice to use in most situations where an average programmer would deploy just a standard Offset.

    Why? Well because of four major reasons:
    [list type=decimal]

    • Motion will always be in line with the TCP. This may seem trivial, but honestly ask yourself when the last time you had a TCP and a user frame line up perfectly when picking from a fixture. If you're pulling something out of a pocket, chances are your tool is lined up better with that pocket than the three point frame you taught. This means no dragging.

    • It works great with tracking and vision, which can't always be said of the regular offset option.

    • Similarly, tool offsets work on top of regular offsets. So for example, you could be picking from an array with known geometry. Your taught point would be the first position. The offset could be calculated for all of the other positions. You tool offsets will handle your approach, perch and work moves.

    • Lastly, there's an incredibly easy hack to set up perfect tool offsets every single time that doesn't require you to type in any numbers or make a guess at how far to move. And that's what this tip is about.

    [/list]

    Okay enough blathering. Here's the tip. Making sure that you're in the correct tool frame, teach the final point for your work piece. When I say final point, I mean teach the point where the part is fully inserted into the fixture or similar. In other words, the point where the robot will stop going forwards and begin working backwards. This is your reference point and this is the only point you'll ever have to teach or modify again after doing this. With the robot in this position do the following:
    [list type=decimal]

    • Go to your user frame settings. Find an unused user frame. (If they're all being used, temporarily store one in a position register)

    • Switch the method for teaching the frame to direct entry and then record the point as the user frame. (SHIFT + F5)

    • Switch over to that user frame and then check your position in USER. If you did it right, it should all be 0.

    • Staying in those User & Tool frames, go to your position registers.

    • Start jogging the robot out of the workspace/fixture/whatever and record each position as a new PR.

    [/list]

    And that's it. You can now switch back to your regularly scheduled user frame. Each of those recorded PRs will now work as a Tool_Offset,PR[...] to get your robot safely in and out of that fixture without a lot of touchup. You can delete the temporary user frame we created as it won't be needed in the program. (If you ever need it back, just move back to that position and repeat the above process.) Why is this a big deal? Well... an example for you: I just completed work on a job that required assembly to be done while the parts were being tracked on a moving conveyor using PickTool. Each of those assembly steps were programmed as tool offsets. This allowed me to teach the actual assembly motion while the conveyor was standing still in a completely arbitrary location. Then when it came time to run the thing I just had to touch-up PR[59] (you poor bastards who use PickTool will immediately recognize that infamous PR) and the rest of my moves came along with it. Here's how that code looks:

    Nine distinct moves and only one taught point.

    Another good example is if you have a commonly used component that requires the same motions every time you use it. My shop uses ATI tool changers with tool stands. The same tool stands every time. I know that when I lock onto the tool, I have to tilt it in the tool's Y axis slightly, and move a couple mm in the X axis to clear the stand. But I don't have to waste time thinking about it because that's a tool offset that I taught manually using my above method just once, and I've used it on every job thereafter successfully. And If your mechanical engineers like to use aluminum extrusion for tool stands instead of weldments, well I'm sorry. But hey, if you follow my advice then you'll save yourself a ton of work re-teaching them when they inevitably move around on you.

    Hope at least one person out there finds this useful. Cheers!

    Quote from dha


    Good approach. As an integrator I use similar method for routines that don't require end users input.
    I often saw users confused and troubled with questions like "Set new ID", "Subtract offset" ...

    DHA,

    i run into that situation all the time. I came back onto a job site with the place program retaught with points because they did not understand offsets.

    I like it. My most recent project is installed already and working fine, but I have printed this tip out for the next one. Great idea. I used Tool_Offset a lot of places throughout, but hadn't thought of doing what you did.

    I love tool offsets.
    I had to reprogram a robot recently for welding where the welds were mostly linear and simple. Saved me a tone of time when I had to reprogram the whole thing when the client modified their welding devices.

    So much time would be saved if I would be allowed to use Tool Offsets PR at the projects I'm currently on. But the client hates having robots that do any sort of thinking, at all, so I'm stuck with teaching dumb positions...

    Looks useful, don't have a robot to test this right now.

    Only disadvantage I see right now is that you are not able to see which direction you are going with the offsets without looking into the PR[]'s itselves. I did indeed use the normal Offsets and the calculation was visible in the movement program. I also only need 1 taught position, but as you mentioned, it was not always perfect in reference with the user frame.
    By the way, the disadvantage is easily solved with putting comments between the movements.

    81:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[32:1] ;
    82:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[33:2] ;
    83:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[34:3] ;
    84:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[35:4] ;
    85:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[36:5] ;
    86:L PR[59:Dp1 Cv Ref Pos] max_speed CNT100 VOFFSET,VR[2] Tool_Offset,PR[37:6] ;

    The :1,:2,:3 is to count the distinct moves or does this have a function?

    I'm normally much more verbose in my offset comments for that specific reason. The reason I simply numbered these offsets in this particular program is because of how complicated the motions are. They're not simple linear offsets. Usually I'll use something like PR[20:Z -100 Tfst] to indicate a distance and that it's intended to be a tool offset.

    Thank you flatcurve, for excellent post.

    I hope, after 4 years someone will answer to mu doubts :).

    I am quite new in robot programming, but recently, I did quite complicated depalletizing/palletizing FANUC robot program and I need to know what is your opinion for the following.

    One of the aspects of the task was, when robot lift a plastic box from a pallet, to detect at which side is the pocket for labeling (there is small groove /I believe the word I use is correct/ on the top of box side). The label pocket must face the machine, if not, the box must rotates - in my case at -179,98 degrees.

    So the question was, where to store the rotation angle - into the Offset,PR[XX] or into Tool_Offset,PR[XX]?

    At the time I program the project, I store the rotation in Offset position register. No I think the Tool_Offset position register was more appropriate!

    What do you think?

    Best regards,

    Svetozar Yolov

    Hi,

    Let's just for simplicity's sake assume that the rotation you want to accomplish should be made around the World Z-axis.

    Then, if your TCP's Z-axis and your User Frame's Z-axis has the same orientation, your outcome will be the same regardless of which method you use.

    An easy way of showing the difference between Tool Offset and (User Frame) Offset is to jog the robot around one of the selected coordinate's axis in first USER and then TOOL mode.

Advertising from our partners