Stationary TCP setup for dummies

    IRC5, RW 6.12

    Well, time for my next learning experience! Yay! I've set up regular robot-carried TCPs before, but this is my first time ever setting up a stationary TCP, and the manuals aren't terribly explicit on this subject. I think I've mostly figured it out, but I'm looking for a sanity check. This robot is picking up a part and running it under a fixed pedestal sealer.

    What I have so far:

    1. TCP has RobHold set False, and describes the location of the stationary TCP in World coordinates

    2. I then have to create a WObj with RobHold set True, and the WOBj is defined relative to the J6 mounting flange (basically, the same as a carried TCP would be)

    3. When programming or running any points using the Sealer stationary TCP, I must explicitly activate both the stationary Tool and the carried WObj, or else... well, I'm not sure what happens, but I'll bet it's not pretty. Judging from my attempts to far, error messages.

    From my reading in the manuals and old forum posts, it sounds like the Load data is defined differently for a stationary TCP/carried WObj? Defined relative to the carried WObj, instead of the J6 mounting flange? I have to run LoadID on this robot anyway, for the programs that use a carried TCP, but I'm wondering what (if any) special steps are needed to do LoadID for a carried WObj?

    Is there a rule for placing the carried WObj? My first thought is that I could place it on the tip of one of the robot gripper's locating pins, especially since I'm already creating a carried TCP there for my pick&drop programs.

    Also, should I do anything specific between the UFrame and OFrame? From my reading, the Load data for a carried WObj is applied relative to the UFrame, so it seems like it might make sense to keep the UFrame at the J6 flange (0,0,0), and set the OFrame to the actual coordinates of the locator pin. Or am I overthinking this?

    In fact, I have two grippers and two locator pins -- the robot picks up two different parts and runs them both under the stationary sealer. If I create a carried WObj on each locator pin, do I just keep the stationary TCP active and switch WObjs when I switch from sealing one part to the other? I assume that the analog flow control for the Dispense outputs is generated from the relative velocity of the carried WObj and the stationary TCP, so I'll want my carried WObj to be fairly close to the point of contact.

    From what I've stumbled through so far, it seems as if, between the active TCP and WObj, one has to have RobHold True, and the other False, or else the robot throws errors. Am I correct?

    Are there any particular "gotchas" that Old ABB Hands all know, when it comes to stationary TCPs, that I should be aware of before I dive into this?

  • Go to Best Answer

    Fixed pedestal sealer--I expect that means that it is pointed down. You can go through the teaching of the tcp, but I usually just jog my held tcp to the fixed, take note of the world coordinate values and plug those in manually for its tcp. If you are fortunate in that the fixed tip is directly opposite to the robot and not rotated, the quaternions are 0,0,0,1. Otherwise you can calculate the quaternions.

    2. Having the wobj same as tcp is fine, it could even be 0,0,0. Don't worry about oframe, leave it no change.

    3. Since the tip is fixed, the speed (and consequently your analog for flow control) is calculated from workpiece moving across the tip, not held tcp. I have had to follow up on programmers who did not used fixed tcp for sealing, it was a nightmare. Reorienting was jacked up. Much nicer to use that fixed tcp, especially for reorienting, because no matter where it is on the workpiece, it will not walk away from (or crash into) the tip.

    For the LoadID, just activate the fixed tcp and held wobj, and run LoadID as otherwise normal.

    Correct that both tool and wobj both cannot be robhold or both not robhold at the same time. It used to be that when you switch in the jog window you immediately get the robhold confusion error. AT times, you had to be real quick to acknowledge the error and quickly change the other component before it threw that error back up again.

    Quote from Lemster68

    Fixed pedestal sealer--I expect that means that it is pointed down. You can go through the teaching of the tcp, but I usually just jog my held tcp to the fixed, take note of the world coordinate values and plug those in manually for its tcp. If you are fortunate in that the fixed tip is directly opposite to the robot and not rotated, the quaternions are 0,0,0,1. Otherwise you can calculate the quaternions.

    That's exactly what I did, and it seems to jog just fine (if the orientation is off 1-2 deg, I don't care :pfeif: ). I won't be able to try it out until the sealer gets set up, so it's nice to have a outside sanity check.

    Quote from Lemster68

    For the LoadID, just activate the fixed tcp and held wobj, and run LoadID as otherwise normal.

    Ah! Okay, stupid me, I was thinking of elaborate ways to run the LoadID with the carried tool, then convert/copy the results into the fixed tool. Definitely overthinking it. :uglyhammer2:

    So, the load data is still "attahed" to the Tool, just like for a carried tool, correct? That is, activating a Tool activates that tooldata's Load settings, correct? Regardless of whether the tool is carried or stationary?

    Yeah. In this case, the payload picked by the robot will be less than 0.1% of the mass of the gripper, so there won't be any point to the "payload" setting -- the difference between a "with part" and "without part" LoadID run will almost certainly be less than the "noise" in the LoadID measurement. But it's part of the end customer's checklist anyway, so I'll do it anyay.

    And just for any poor schmuck who makes the mistake I did in future: when changing manually between a Carried Tool and a Stationary Tool, I kept getting this error: 41446, "Argument Error," "It is undefined if the robot holds the tool or the work object".

    Of course, I had to also switch Work Objects. But the error pops up immediately when changing the active tool from the Jog screens, and kitting Acknowledge just makes it pop up again. So I have to change Tool, ignore the error and go back to the Jog screen, change WObj, and then Acknowledge the error. Gave me a bad turn at first, but now it's just annoying.

    • Best Answer

    Since you said that you are doing sealer, I will throw in this tip for ABB. The parameter event preset time, part of the motion planner, often needs to be increased to make the process work best. It anticipates the equipment lag time. I.e., time for pressure to build, start flowing and especially increasing or decreasing flow rates as the robot speeds up and slows down. Often overlooked.

    Quote from Lemster68

    Since you said that you are doing sealer, I will throw in this tip for ABB. The parameter event preset time, part of the motion planner, often needs to be increased to make the process work best. It anticipates the equipment lag time. I.e., time for pressure to build, start flowing and especially increasing or decreasing flow rates as the robot speeds up and slows down. Often overlooked.

    Thanks. In this case, the robot is using the UAF set of option packages from ABB, and that has a set of parameters that handle this for me. But I'll keep that in my notes against future need.

Advertising from our partners