Laser Touch Sense Accuracy issue

    Hey everyone,


    I have a Keyence il-300 laser hooked up sidecar to a welding torch. We're looking for Robot Input 1 (or 9 in Robot 2's case) to come ON when it is in the GO Range. TCP's are set for the torch and the laser. The issue I"m seeing is the laser is finding the seam fine, but the Torch TCP is not going to that spot. It's consistently off by a couple mm's on both of my robots...On my duplicate cell, the lasers and torches work flawlessly. I cannot find any major difference between these two and have run out of ideas of what to look for. I've rechecked/retaught TCP's, mastering, checked reflection (turned lights in the cell off).


    The weld seam looks something like a V, but one side of the V is straight, so more like this... I/ if you're looking at Robot 1 or \I if you're looking at Robot 2's. I'm doing a -X to look for the straight vertical drop. Then I'm going to a flat surface behind the angle and doing a -Z. This way I can get positional data of where the Seam is and send the torch TCP there. Customer wants to rely on the use of the laser to find the weld seam, so switching to a V-Groove pattern and doing a 1_D search isn't going to fly.


    So when I take the Laser TCP to the saved positional data (lets say PR[8]), the laser shines right at the inside edge of the vertical drop and at the bottom of the angle, where it should be. But when I switch to Torch TCP and take it to the same PR[8], the wire is usually off in -X from where the laser is.


    I cannot wrap my head around WHY or WHAT is causing this. Especially since Welder A is working fine and I've taught the lasers and torches the same way (using Six Point (XY)).


    Any ideas out there?


    Edit: Forgot to include that I also thoguht it was a scanning time/speed issue, so I turned the search speed down to .5mm/sec and was still not able to bring Torch TCP to Laser TCP/Laser found seam....but the difference between Torch and Laser always seem to be consistent. I can't think of what that is actually telling me.

    Hm. Your X search direction, I'm assuming that's in UFrame, not UTool, correct?


    The easy, obvious answer, is that there's something off in the relationship between the TCPs. If you activate the laser TCP and rotate around UFrame Z, does the dot stay in place, or does it drift around circularly? If you rotate the tool 90deg around Z, then try the search again with that orientation, does the error remain consistent, or does it change?

    Quote from SkyeFire

    Hm. Your X search direction, I'm assuming that's in UFrame, not UTool, correct?


    The easy, obvious answer, is that there's something off in the relationship between the TCPs. If you activate the laser TCP and rotate around UFrame Z, does the dot stay in place, or does it drift around circularly? If you rotate the tool 90deg around Z, then try the search again with that orientation, does the error remain consistent, or does it change?

    Yeah so, with how simple this welding system is, I didn't bother using any User Frames. The robots ship on the platform that all the welding is being done on, so no need to bring anything back into place after installation. Everything being done is in UFrame Zero, or World. I have UTool 1 = Torch and UTool 2 = Laser.


    I thought that the TCP's being off was the easy answer too, but I have retaught and rechecked TCP's both individually between laser touch senses and then teaching both and trying another laser touch sense and the error is always there. But once again only on Welder B. Welder A is working flawlessly between both robots.


    I have checked rotation around my TCP's multiple times and they are as accurate as I can make them. Rotating around Z does give some circular error, but it's about the same as Welder A. This last time I taught the laser's I used a 2-4-6 block, leveled it with the robot's world frame and then shined the laser down the X, then the Y side, so that the laser shines down the side of the block as best as possible. This way I got rid of any X and Y leaning when doing my Six Point XZ TCP. At least I believe that's what I did.


    You did bring up a good point of trying to rotate my tool 90° around Z and trying it that way to see if the error repeats. I do like that idea and will give it a shot when I can.

    Quote from HawkME

    Is the laser sensor perpendicular to the edge drop off?


    Can you apply a correction factor and it is consistently good?

    The edge that drops off sometimes has a burr, so when I'm doing my -X check I have the laser sat back -7° in P (Y Rotation). When I do my Z- check, the laser is perpendicular to the flat surface it is checking (because that's when Y, W, P and R are recorded to the Search PR).


    I have applied a correction factor and it seems to be consistently good. Not that you're implying it, but I could leave that in there and run with it, but as we both know it's not the right way of doing things.

    Quote from SkyeFire

    Hm. Your X search direction, I'm assuming that's in UFrame, not UTool, correct?


    The easy, obvious answer, is that there's something off in the relationship between the TCPs. If you activate the laser TCP and rotate around UFrame Z, does the dot stay in place, or does it drift around circularly? If you rotate the tool 90deg around Z, then try the search again with that orientation, does the error remain consistent, or does it change?

    SkyeFire,


    It seems like Robot 1 came in to place with the search spun around on Z 90°. Robot 2 is better but still off by a mill and a half to two. For some reason my brain isn't allowing me to comprehend what this means for my situation. That I do have X error between my two TCP's, but less error in my Y?


    Quote from HawkME

    Are you sure it's not that 7 degree Y rotation? Have you tried with that set to 0?

    Yes I am sure. On Welder A we are running the same parts that have the same burr, so the 7° rotation on Y is needed on that cell as well. Welder A has been working flawlessly. I haven't been taking enough notes, but I believe I have tried a perpendicular search for Search 1 and Search 2 already due to geometry of one of the model's weld seams. I can't accurately say whether or not the error repeated. I will do a search now with the tool being perpendicular and see what I get.


    I did wonder what would happen if I put Welder A's TCP values in to Welder B, but after comparing the two - their values are fairly close to one another. I guess that's why I'm slightly biased against it being a TCP issue.


    EDIT: Update for HawkME: I did a -X and -Z search with the laser perpendicular to the part and my error in X is present on Robot 1 again as well as Robot 2. The amount of error on Robot 2 is ridiculous. The laser shines in the corner where it should be and the laser is all the way at the TOP of the ANGLE (this has been consistent).


    EDIT2: I've put the cell and attached the torch/laser cad model to the robot. Going to get perfect world TCP's and put them in the robot. Not sure what it'll prove, but interested to see if perfect TCP's based upon CAD models will change anything.


    EDIT3: After placing the Roboguide CAD Model values into R1 and R2's Torch and Laser TCP's I can happily say Robot 2 seems to have fallen in line. Robot 1 is still having an issue in X though. It looks like this issue is related to TCP after all. I figured it was, but after multiple times reteaching TCP's and checking TCP's seeing them rotating around well I didn't think it was TCP related. I will figure out why the Six Point XZ/XY methods I was using wasn't giving an accurate TCP check and write a well documented work instruction for the customer.

    Well, how are you performing the 6-point TCP for the laser? It's very hard to create a non-physical TCP using this process accurately. There's a lot of non-obvious errors that can creep in.


    When I've had to do this in the past, I usually did my physical TCP as precisely as possible, then copied that TCP to my non-physical TCP as a starting point. Then I would program the physical TCP to a fine point on my tooling, and begin adjusting the non-physical TCP's XYZ values (not the RPY, unless really necessary) until the non-physical TCP lands on the same mark, moving to the same point with the non-physical TCP active.


    It also helps to use anti-backlash techniques to while doing this -- always back the TCP off a healthy distance (10mm or so) and come back at the target from the same direction every time. If you "hunt" back and forth over the target, you'll be injecting the entirety of the robot's backlash issues into the TCP accuracy.

    The 6 point method has to be done a particular way to be accurate in w,p,r. Most people I see do it wrong and end up with the same result as a 3 point TCP or incorrect w,p,r angles. A laser sensor would not be easy, but Skyfire's method sounds like a great way to do it.

    Quote from SkyeFire

    Well, how are you performing the 6-point TCP for the laser? It's very hard to create a non-physical TCP using this process accurately. There's a lot of non-obvious errors that can creep in.


    When I've had to do this in the past, I usually did my physical TCP as precisely as possible, then copied that TCP to my non-physical TCP as a starting point. Then I would program the physical TCP to a fine point on my tooling, and begin adjusting the non-physical TCP's XYZ values (not the RPY, unless really necessary) until the non-physical TCP lands on the same mark, moving to the same point with the non-physical TCP active.


    It also helps to use anti-backlash techniques to while doing this -- always back the TCP off a healthy distance (10mm or so) and come back at the target from the same direction every time. If you "hunt" back and forth over the target, you'll be injecting the entirety of the robot's backlash issues into the TCP accuracy.

    I'm going to have to read over your comment a few times to understand your method of setting up the TCP as described, but I did want to add to your point about the backlash - that is something I've definitely noticed and have accounted for. I've found there's at least a 2mm change in the laser distance when changing directions.


    *I've read over your comment again before posting everything above and below and I think I understand what you are saying now...Program my Torch TCP (at the wire stickout of 15mm for example), then copy that value over to the Laser TCP T.Frame, program the physical TCP at a known point, then adjust the Laser TCP to land at the same spot the Torch TCP is landing at. This helps to line them up...That makes a lot of sense (if I understood it correctly).


    It's a fine method and I'll give this a shot today or early next week...The customers for this job are first time robot users, so I'm trying to keep everything as simple and to the point as possible for their first dive...If that method works better than the method I used below, then I'll include the method in the instruction manual.


    Note: This is my first digestion of your comment in the early morning here and I've only had a few sips of coffee so far! I'll read over this later today or this weekend to get a better understanding I'm sure.


    Quote from HawkME

    The 6 point method has to be done a particular way to be accurate in w,p,r. Most people I see do it wrong and end up with the same result as a 3 point TCP or incorrect w,p,r angles. A laser sensor would not be easy, but Skyfire's method sounds like a great way to do it.

    So i've found out! Ha. I ended up using position popup to set WPR to perfect 45° angles for Approach 2 and Approach 3. I think that definitely helped dial in the TCP. Before I would just throw the robot somewhere left front from Approach 1 and right front from Approach 1. Apparently I was not creating an accurate TCP. I was taught a while back that the more crazy data you give the robot the more accurate the TCP will be - I have learned that is NOT true!!


    Anyways I'll revisit if need be here, but I want to thank SkyeFire and HawkME very much for your time and responses. I very much appreciate you two taking your time to help all of us here on the FANUC Robot Forum! Stay SAFE and stay HEALTHY!

    Quote from Yakub

    Could it be due to the natural curvature of the welding wire compared to a nominal TCP?

    Nah, I have a contact tip from each manufacturer/torch I've come in contact with (great pun, eh?) that has a pointed dowel pin placed into it. I don't rely on weld wire for TCP's anymore - always use the "teach tip" I have made.


    Thanks for the suggestion though. The project is complete and awaiting shipping (whenever COVID goes away at the customer's facility I guess). Having an accurate TCP was all I needed.

Advertising from our partners