TCP accuracy issue

    Hello,

    I’m conducting a test in Roboguide where I am using a CAD model of a table I teach the table’s vertex as the User Frame in Roboguide. In Roboguide when I move the TCP to 0,0,0 position the robot accurately goes to 0,0,0 in all robot orientations.
    I repeat the same on the real robot. I teach the same vertex of the table using the 3-point method. When I run the program on the real robot and move it to the 0,0,0 position, I get unexpected results.

    When I move the robot to 0,0,0 with the same tool orientation used during teaching, it reaches the correct position. However, if I change the tool orientation, the TCP is significantly off. I've attached an image for reference. While I suspect a potential 1-1.5 mm error in TCP teaching, I'm unsure if this could cause such a deviation.

    robot-forum.com/attachment/41054/

    The robot is an R1000-iA /80F. It has a history of collisions, and joint 4 was replaced. The spherical wrist's accuracy is questionable; measurements with a laser tracker show a discrepancy of up to 3.5 mm between the robot's claimed and actual positions in certain orientations.

    Given the robot's history and the test results, what might be causing the TCP to be so far off when changing tool orientations?


    Thank you in advance.

    Your picture is not showing up.

    First, I would verify mastering by running to zero and checking the witness marks.

    Second, I would verify that the tool is mounted the same way in the real as it is in your sim. Run the real robot and the sim robot to the same position (I usually use zero position) and cross check them.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    Also, just jogging the robot around the TCP is kind of a worst-case scenario for the robot's accuracy. If you really want to test the TCP error, what I've had to do in the past is programmatically run the robot to the test location at different rotation angles, using anti-backlash moves at each stop to remove backlash from the test results.

    Nation
    I confirmed that the marking don't align when I move to zero degree. I also checked that my reference count (under DMR group ) is all zero. I suspect that someone had accident did a zero mastering and removed the data.
    I have a backup that shows me what the reference count before it was all zeros.

    Question:
    Why did the robot is behaving still accurately relatively accurately if the reference counts is all zero?
    If I input the old reference count values, will I get the same accuracy of the robot before it was accidently zero mastered?

    Thank you

    If you have a backup with a working mastering, then you could just load the sysmast.sv-file (need to be in CTRL Start to load it).

    Reference count is only used when performing a Quick Mastering.
    Maybe someone made an INIT Start (wipes clear everything) and then made a bad Zero Position mastering afterwards?

    Either load the old (working) mastering data file, or manually punch in the numbers in Ref Count (make sure that Ref position is set to 0° on all axes), then move all axes to 0° and perform a quick mastering.

    But if you're unsure of what you are doing, then I would recommend seeking help from FANUC Service or an experienced technician.

    Quote from Shubham Malhotra

    SkyeFire
    I am fairing new to industrial robots. Can you explain what do you mean "anti-backlash moves"

    Additionally can you also explain that why and how does using the "anti-backlash moves" at each stop removes the backlash from the test results?

    https://blog.appliedmfg.com/blog/robot-accuracy-mcmillan is a halfway-decent precis of the subject.

    Short version: on a 3-axis manual mill that has an axis with backlash problems, one way to counteract the backlash is to only use that axis from one direction -- that is, cutting paths might only use the X+ direction, and X- would only be for air moves. This doesn't "fix" the backlash, but it does make it consistent, so the hand-wheel dials can be trusted to measure the relative motion of the cut, even if the absolute position cannot be trusted.

    A DRO added to a manual mill often fixes this problem almost entirely, but robots (outside of certain special modifications) don't have DRO-equivalents, just the equivalent of the hand-wheel dials (specifically, the encoders on the driveshaft of each servomotor).

    In robots, the anti-backlash techniques might be to ensure that every "contact" motion only uses all the axes in one direction, and includes a pre-contact anti-backlash motion that "twitches" all axes (say, +1 deg, then -1 deg) such that the backlash on each axis has been "taken up" to a consistent "side".

    Quote from Shubham Malhotra

    Why did the robot is behaving still accurately relatively accurately if the reference counts is all zero?

    I'd be curious as to the TCP values it found. I bet they are wildly off, compared to simulation. I would guess that the two problems kind of "canceled" each other out.

    Quote from Shubham Malhotra

    If I input the old reference count values, will I get the same accuracy of the robot before it was accidently zero mastered?

    Ideally, it would be better. This assumes your original counts are still good.

    Check out the Fanuc position converter I wrote here! Now open source!

    Check out my example Fanuc Ethernet/IP Explicit Messaging program here!

    Restore your original $MasterCount values, restore the same exact same values on your $RefCount, and set your $RefPos all to 0s.

    The way calibration data works is that the real calibration data is stored on the $MasterCount variables, the $RefCount+$RefPos variables are linked toguether, so if you do a SetQuickMasterRef with per example, axis1 rotated 90°, the $RefCount[1] value will change and the $RefPos value will also change and it will store the "90° offset from calibration" on the $RefPos[1]. I think it is stored in radians.

    If you then move the robot again to all axis 0dg except axis1 at 90°, when performing the quickmaster it will take into account these values to "offset" the calibration pulses and make them coincident on where the real 0 of that axis should be.


    About accuracy and movement, if calibration is bad you will notice it while performing linear motions the most. Also, any calibration error on axis1 will be negated if you measure the frame again, any calibration error on axis6 will also be negated if you measure yout tool again. At least this is what I've read on some document from fanuc where it explains how to improve calibration data with some manual methods.

Advertising from our partners