iRMaster to fix robot drift

    Our 10 identical automation cells with M-20iB/25 robots are "drifting" about 1.5mm over the course of 2 months. After speaking with Fanuc's tech support I have heard different theories on the issues like; lose base bolts, lose end effectors or the joints being knocked out after a crash, or fading due to the arm rubbing in and out of fixtures. Fanuc recommends that we purchase the iRVision and re-master the robot every month or so.


    • If we vision master every month or whenever we notice drift, will it automatically shift all of our program points frames etc?
    • Should we also be looking into robot calibration? A drifing point could either be the robots calibration fading or it's mastering location or both?

    These robots have never been mastered or calibrated since they were put in by the integrator 2 years ago. Calibration would also allow for offline programming and cell mirroring, which could come in handy


    Thanks

    I would map the drift. if the drifting is in an arc to the robot center, then it indicates base bolts.


    An M-20 is a rugged robot, i don't see crashes causing this. (smaller robots utilize harmonic drives which "skip" teeth easier)


    end of arm tools, if not doweled, can cause issues like this, movement around the mounting bolts


    The iRVision mastering is a great option, i would keep that one in my back pocket.

    Good luck

    Tech support mentioned that the majority of axis drive mechanisms in this robot are harmonic reducers and that the potential for slip and or drift after a collision is high compared to rotary vector drives. Could this be a concern with crashes or rubbing in and out of fixtures?


    The drift does not seem to be in an arch to the world frame / center of the robot (our robots are offset 60* in the cells)


    Thanks

    Edited once, last by M3WIN ().

    I know nothing about iRVision…...but from what I'm reading this appears to be recommended to compensate for this...…..a complete waste of money if there are underlying issues mechanically.

    I think this should be investigated a little further.....


    If an industrial robot is 'so called drifting', majority of cases I have come across is down to mechanical or external influences.


    Program code and stored data does not drift, therefore any positional data referenced will always be the same (unless changed manually).

    Taking that into account, the zeroing, mastering, calibration data will not 'drift' either.


    So using that as the 'constant'...….what are the variables that could attribute to 'drifting'.

    - Loose bolts, or the mounting holes wearing on pedestal, robot base, tool flange, tool flange adapter.

    - Bent or non visual forces being applied to the EOAT, causing a 'spring effect' on the EOAT assembly.

    - Gearboxes rotate many times when cycling, and are not linear to the motor position, so sometimes there are periods when the 'drift' could fix itself and periods where it exists.

    - External fixtures and peripherals the robot is servicing are moving not secured.


    I would check for backlash by enabling the motors in T1 and not jogging the joints, as a colleague to apply force to each joint and see if there is movement.


    I would also check in which directions it appears to drift and over what distance.

    Usually mastering, zeroing issues if they are slightly out, will yield greater drift over longer distances, so I would monitor for this also.


    I would consider getting one of the robots serviced too and see if anything appears during the inspection, usually the 'techs' on the ground have more 'real world' experience than a person on the other end of the phone, and the 'tech' may in fact highlight the problem.


    I think it is important to eliminate as much as you can to ascertain where the problem lies before using additional 'tools' to compensate.....this way you can fix the underlying problem for good.


    Just my 2 cents...….:top:

    I had the same problem in a Cell working with 2 robots. Robots never mastered and collisions were never too hard or many to cause a mechanical issue. I also use M710i 50kg payload which is a pretty stiff model with high rigidity. It turned out the mastering on both robots from FANUC was not the best. I used an accuracy enhancement technique by FANUC and problem solved. If you are interested to give it a try I can share the bulletin.


    But before you try this could you share some more info?

    1.How did you check the drifting ?

    2.In which direction does the drift occur ?

    3.did you try rotating the TCP using the tool frame ?

    4.is the TCP taught or manually entered ?

    5.are you sure it was taught precisely ?

    6.Did you put the robot to 0 position and check the marks ?

    7.Put your robot in home position and apply some force by hand on the wrist. Try moving the end effector by hand (like trying to rotate the robot) and up down, this way you can check your reducers for plays.


    To my experience there are only 3 reasons for a TCP to drift: badly taught or inaccurate if directly entered TCP. Inaccurate mastering of the robot, reducer failure causing plays.

    1.How did you check the drifting ?

    The EOAT was measured before and after the points seemed to "shift".

    2.In which direction does the drift occur ?

    Was only able to notice Y+ , X-, and Z+

    3.did you try rotating the TCP using the tool frame ?

    The movement rotates very well about Z, however, when rotating about X or Y it tends to "drift" from side to side. This was noticed before the cell had issues as well. How would an inaccurate TCP cause the robot to suddenly become less repeatable?

    4.is the TCP taught or manually entered ?

    manually entered

    5.are you sure it was taught precisely ?

    No

    6.Did you put the robot to 0 position and check the marks ?

    The marks are close, J3,J4 are about a line thickness off but very close.

    7.Put your robot in home position and apply some force by hand on the wrist. Try moving the end effector by hand (like trying to rotate the robot) and up down, this way you can check your reducers for plays

    Seems very firm and steady


    Thanks!

    Create a program and teach a point in space where your TCP touches a physical top. Be sure to check your J3 axis to be near zero degrees or at least 0-30 degrees and all turn count numbers in the positional data of the point to be zero.
    Without moving the robot, create a second point on the same location and enter in the positional data. Change the configuration from NUT to NDB (or the opposite). Slowly move the robot to the new location. Be carefull not to speed up the robot, the robot will try to reach the same point in space using a different configuration. if the robot drifts away from the point taught when changing configuration then this suggests an inaccurate mastering.


    A line thickness off is a lot !!!!! In my case I corrected 3 axis around + or - 0.2 to 0.5 degrees and it made a huge difference.


    I have attached the Accuracy Enhancement mastering technique Engineering Bulletin. I hope it will help you solve the problem

    This little test to determine if mastering is accurate seems like the perfect test however I am confused on the instructions. Can someone elaborate please?


    Create a program and teach a point in space where your TCP touches a physical top. (Does this mean a pointer?)


    Be sure to check your J3 axis to be near zero degrees or at least 0-30 degrees and all turn count numbers in the positional data of the point to be zero. (How do you turn all count numbers in the position data to zero? Is this the actual degrees for each joint?)

    Without moving the robot, create a second point on the same location and enter in the positional data. (Here I just taught two points in a program to the same position, is this correct?) Change the configuration from NUT to NDB (or the opposite). (I did this however mine is in FUT & FDB, I assume it makes no difference?) Slowly move the robot to the new location. Be carefull not to speed up the robot (Not sure what is meant by speeding up the robot, I just let the program move between the points), the robot will try to reach the same point in space using a different configuration. if the robot drifts away from the point taught when changing configuration then this suggests an inaccurate mastering. (When the points are Joint the robot moves until I have to stop less it would hit a wall, when points are in Linear the robot does not move at all. Does this mean my mastering is acceptable?)

    No, it means your point is to close to the wall.


    Linear moves can't move between configuration changes without a wjnt instruction at the end of the motion instruction, which is why the robot doesn't move at all with a linear move.

    The wrist on those robots are very tight when new. You maybe be experiencing break in. It wouldn't take much at all to be off 1.5mm. The service bulletin provided can dial the mastering in if performed correctly. Probably your cheapest option as it's free. This method is easier to perform if you have a torch tip pointer to mount to the faceplate. Use another pointer that's stationary as your alignment reference. Same as how you teach a TCP.

Advertising from our partners