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

  • AD
  • 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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now