Fanuc 7th Axis with Irvision

    Hello all


    I am working with a R2000ib/150u robot, with a R30iA controller.


    I'm wondering if anyone has any experience with vision error when the robot is finding a part at different positions on the 7th axis(robot is mounted on a rail).

    If I find a part and teach the pickup position, and say move the robot 1 meter over to find the same part on another stack, there is about 20mm error in the same direction as the rail movement.


    any ideas what could be causing this, or how to fix it?


    thanks in advance.

    Thanks Doctor_C


    I did just that 3000mm away and it seems dead on. I believe you are right though that it is a rail issue, after doing many tests today, I finally noticed when I have my gripper right above the part and I select jog mode either world or user and jog the 7th axis(when I hit group It says G1 S) in the X direction the rail moves and the TCP is supposed to stay in the same spot, well it move by the exact same amount as my error. So the question is what could possibly cause this? The robot X+ and the rail + which is in the X direction of the robot, point in opposite directions, which I assume is not an issue.

    In my head this makes sense, but I may be incorrect. Could someone with more experience chime in if I'm wandering down the wrong rabbit hole.


    On a linear rail, the gear ratio could be off; accounted for by the pinion's tooth engagement. If your pitch diameter is larger than what is expected because the pinion is not fully engaged, your theoretical gear ratio would be off.


    It would be off by a constant if the engagement is the same over the distance of the gear rack.


    Is there any backlash?


    Do you have access to a laser tracker or interferometer?

    Quote from HawkME

    Maybe your rail x axis is not perfectly aligned with the robot.

    Yeah, of course, that too. But I would hope that would have been checked.


    Every linear setup I've ever seen has had dowel pins to match the J1 rotation to be square to the rail.


    Squaring the rail to the world isn't trivial, but it isn't rocket science either. A 3 x 4 x 5 triangle can get it really, really close, if scaled appropriately to the application.


    I might take some of the basics for granted though, I work with some really good millwrights.


    I do usually have to adjust the gear ratio if absolute accuracy is required. I've got a system that is no worse than +/-.001" over 45m of its Y rail travel (sorry for mixing units). I didn't believe it until I saw it with my own eyes. Wittenstein gear reducer plus IKO rack and pinion.


    Plus, most importantly, a spot on installation team. I wasn't part of it, I just got to appreciate their dedication to doing the job right. It's amazing what the right team can do when they won't accept rushing it. Too often, there's never enough time to do it right, but always enough time to do it twice. Kudos to those that will put their foot down to that nonsense. Once the grout is poured, it's hard to go back.

    Thanks pdl and HawkME for the replies


    Alignment with the Rail is definitely the obvious question, I thought I had it done correctly, but it is my first time working with a rail. what is a good method for checking it's installed square to the rail? there is no alignment dowel unfortunately.

    It's made by Fanuc in the USA, the robot is hanging up side down on it. I am not even sure which direction the robot was pointing originally, we bought the robot used and I oriented it the way that would work best for the application.

    If you can't find a dowel, I would mount a dial indicator on the end effector and have it touch on the rail. Then move the rail axis an exact amount and see the difference. Then using trig, calculate the error angle. Then remaster j1 by that same amount to correct.

    The pin holes would be located on the RTU itself. They are interference fit to hold onto the pins when the robot is installed and removed.


    The Fanuc has reference datum's machined into the cast base. They are on the +X and +Y side of the base when the robot is not inverted. You can just barely make them out in your picture. Unfortunately, they are on the back side of your picture in this case. I've highlighted them in your picture below:



    As the robot is installed, force is applied from the side to justify them next to the pins.


    At least this is how I have seen it on every commercial RTU I have ever come across.

    thanks guys, your help is much appreciated.


    pdl, it looks as if on this setup those blocks that stick out are what the robot is meant to square against, it also seems that the robot was meant to be rotated 90 degrees on the RTU because there a gap there. I could potentially make spacers and square it that way, but I happen to know the robot is no longer factory mastered so even if it were perfectly squared it would not correct the issue.




    So when I realized the mastering was bad I vision mastered the robot, but vision master doesn't effect J1 so I did what HawkME is suggestion, just not in such a precise sounding method :thinking_face:


    So HawkME I really like your idea of using a dial indictor and trig to correct this, so can you just clarify how I should move the robot when doing the measurement. Should I have the robot move along the rail in World coord in the X direction, or should I have the robot TCP stationary and just change the axis 7 position in a program by lets say 1 meter and check the difference?

    I don't think so.


    After rereading the thread I am wondering if is a Z Height issue in the vision process. Have you set that correctly. Is it physically the same at both locations?


    If it's not the same you will need you create sperate vision processes.

    I now have J1 mastered to within 0.06mm over 1 meter of track, which is about 0.0034 degrees


    I think it has improved the drifting issue.



    I am pretty sure the vision process is not at fault because I can see the robot TCP "drift" in the X direction if I have a point set and then only adjust the 7th axis position by lets say 1 meter so the TCP should remain stationary. This is without any vision process involved.



    I was a little worried it was the vision process because I am actually in a way depalletizing sheets off a stack, so every time I take a piece I adjust my user frame down by its own Z axis with the matrix program. the reason is, this way I can snap 2 pictures if I need to, if I use the depalletizing process I can only snap 1 picture. I didn't want to say this part because I think it will lead us down another rabbit hole.

Advertising from our partners