Robot losing its positions over time

    Hi, I have a couple of M-20ib/25 robots doing machine tending operations. Multiple times over the last six months the robots have stopped hitting their taught points accurately. I teach all of the positions, and some time later (sometimes days, sometimes weeks) the robot will be moving to a position which is a few millimeters lower than where a taught it.

    When this happens the Cartesian coordinates of the robot's actual position and the taught position are identical (and is even identical to the coordinates saved in previous controller backups), so it's not caused by a change in the taught coordinates. The robot's payload data is set properly as far as I can tell, and the payload is never more than half of the robot's rated 25kg capacity.

    This is very bizarre to me. It's as if the robot's arm is sagging over time, but the robot is not reporting any mastering errors. Does anyone have any suggestions for what might be the cause or what I should check? Thanks!

    I've seen something like this happen once that wasn't a mechanical issue. It was a 120ib with a RJ3ib controller in a welding application. The robot ever so often would be off in Z. You could adjust the robot back and it would be fine for a week or two and be off in Z again. We tried a lot of different things, replacing parts / electronics including swapping the entire arm out with another robot but the problem remained. Ended up swapping out the CPU board out with a spare and loading the imagine back and it corrected the issue.

    Huh, interesting. Nice to know I'm not the only one that's ever seen this. :smiling_face:

    Does anyone know if this could be caused by not having something configured properly? If it really is a hardware issue, fine, but I'd hate to get Fanuc tech support involved just to find out that it's caused by me overlooking something.

    This may sound funny but, I witness this often in the spring and the fall of the year. There are severe temperature changes from morning to night on A daily basis.
    Most large corporations mount their robots on posts that are buried deeply in the ground. This elimanates movement caused by the expansion, and contraction of the cement floors that happen
    quite a bit these times of the year. The robot may be anchored several feet from where the tools are mounted causing point to seem off, but in reality the tools or the robot are moving.

    Quote from keyboard7


    This may sound funny but, I witness this often in the spring and the fall of the year. There are severe temperature changes from morning to night on A daily basis.
    Most large corporations mount their robots on posts that are buried deeply in the ground. This elimanates movement caused by the expansion, and contraction of the cement floors that happen
    quite a bit these times of the year. The robot may be anchored several feet from where the tools are mounted causing point to seem off, but in reality the tools or the robot are moving.

    Yeah, thermal expansion/contraction is something that crossed my mind, but I'm not sure how I would go about proving that it is the cause of my problem. Have you ever been able to run any tests to prove it?

    Quote from c3ture


    I've seen something like this happen once that wasn't a mechanical issue. It was a 120ib with a RJ3ib controller in a welding application. The robot ever so often would be off in Z. You could adjust the robot back and it would be fine for a week or two and be off in Z again. We tried a lot of different things, replacing parts / electronics including swapping the entire arm out with another robot but the problem remained. Ended up swapping out the CPU board out with a spare and loading the imagine back and it corrected the issue.


    Like c3ture, had one where software reload fixed the issue and the guys in the shop have also seen it before. All the other times have been mechanical/electrical. Does it seem like it's related to a specific axis? Wouldn't hurt to check the lube for metal dust.

    It wasn't the reloading of the software that fixed the robot, we had tried that and it didn't correct the issue. It was actually the CPU change that fixed it. We had aimed to put the CPU board in a different robot and test it but never had the time to do it before the problem CPU was trashed. When it happened every linear point in the robot was about 10 mm low uniformly across all the programs. Normally when a joint is off its not uniform like that across programs, its off in relation to how the robot joint is oriented at that taught point. To check for something mechanical I would teach some points to a couple of reference positions in the cell, making sure they weren't all attached to to something that shares the same floor mount. Teach the point and teach several addition points with the robot in several different orientations but the same x,y,z location. If its something mechanically wrong with the arm you should see the robot off in different directions depending on the robot orientation.

    The only way to test for this I can think of is A laser tracker. We only use one when a large piece need to be documented. I have been told that when large lines are installed, this is documented by laser tracker.
    We outsource this process, because we only need it done once or twice A year. Once measured from known points, the laser tracker would be able to tell you if the tools, or robot base were moving.

Advertising from our partners