S4C+ Irb 6600, Programmed offsets not reliable.

    Good morning all. I'm am in the middle of a new part program with 42 places on each table. New grippers, TCP looks good. Put in the table orientation using Object frame 3 pt. However, (1,1) is a perfect grab (1,6) is off by 1.5-2.0 millimeters at 508mm over? So, its figure out why and fix it or manually find variation on all 42 positions, do the math and change the offsets. Anyone have any idea why the robot will not pick up the proper layouts using the programmed offsets? I really want the PDispSet to be right, it would save a ton of time.


    Thanks in advance for any help.

    I have an array of 42 (6,7) with 2 skips#7 and #35, right to left this time because otherwise #1 would be missing. Using program displacement for each position/next part on load table. I just redefined the table again using 6 pt. 3 User, 3 Obj. Going to see if that helps. Also added the commands to turn off any residual offsets and displacements at the beginning of the routine. Anything else that could be putting additive error that I might be missing?


    Currently the table is laid out as per the machine drawing, each position center (-127,-101.6) from each other.


    Just took a backup, so I'm game for trying a few things. This isn't the first time this has happened, but I feel like I should at least understand Why at this point.

    The load table is the Wobj. The 6 point did not help, it is the same as the 3 pt. I did yesterday. I did not do the Calibration, or have the Pendelum for it.


    1) When you say calibration offsets, are you talking about the motor offsets for each joint?

    2) The robot zero is not perfect, nor has it been since I started here. If I change that, won't it change everything in every routine across the board and screw all of my programs?

    3) I can't even find the base frame in the system parameters. Which file is it usually in MOC?

    1. Yes

    2. Don't change it, it will throw off everything. But that will affect what you are trying to do.

    3. Lookin the system parameters in the pendant for motion. I looked in an moc file from a backup and did not see baseframe.

    Years ago, on one of my first jobs, I was trying to use program displacement. It worked on one robot, but not another. The baseframe on the non working one had been changed.

    If the Calibration is off(not saying it is, it says synchronized), and robot zero is off (visibly so), How does one fix this and still have the old programs work properly? What else could be wrong? Would the calibration change as the machine ages? Could motion supervision be the problem? should I allow it to repo the robot (currently set to no)?

    If you update the rev counter to make it go to zero properly, then all your programs are off. Bets to let it be. Calibration will not change over time. Programs could change due to wear and greater gear play/backlash. Motion supervision would not be a factor.

    Ran ABSJ to zeros and every thing looks good. Home position is where the marks are off, not Calibration. So I am at a complete loss as to what to do next. Think I might have to call ABB. I have absolute accuracy on this thing so it should be doing what I want, but I don't know why it isn't.

    Lemster68 Beautiful code by the way! makes mine look like Neanderthal or Caveman.


    PERS pose AOffs_*****{6,7}:=[[[[0,0,0],[1,0,0,0]],[[0,-127,0],[1,0,0,0]],[[0,-254,0],[1,0,0,0]],[[0,-381,0],[1,0,0,0]],[[0,-508,0],[1,0,0,0]],[[0,-635,0],[1,0,0,0]],[[0,-762,0],[1,0,0,0]]],[[[-101.6,0,0],[1,0,0,0]],[[-101.6,-127,0],[1,0,0,0]],[[-101.6,-254,0],[1,0,0,0]],[[-101.6,-381,0],[1,0,0,0]],[[-101.6,-508,0],[1,0,0,0]],[[-101.6,-635,0],[1,0,0,0]],[[-101.6,-762,0],[1,0,0,0]]],[[[-203.2,0,0],[1,0,0,0]],[[-203.2,-127,0],[1,0,0,0]],[[-203.2,-254,0],[1,0,0,0]],[[-203.2,-381,0],[1,0,0,0]],[[-203.2,-508,0],[1,0,0,0]],[[-203.2,-635,0],[1,0,0,0]],[[-203.2,-762,0],[1,0,0,0]]],[[[-304.8,0,0],[1,0,0,0]],[[-304.8,-127,0],[1,0,0,0]],[[-304.8,-254,0],[1,0,0,0]],[[-304.8,-381,0],[1,0,0,0]],[[-304.8,-508,0],[1,0,0,0]],[[-304.8,-635,0],[1,0,0,0]],[[-304.8,-762,0],[1,0,0,0]]],[[[-406.4,0,0],[1,0,0,0]],[[-406.4,-127,0],[1,0,0,0]],[[-407.1,-252.7,0],[1,0,0,0]],[[-406.4,-381,0],[1,0,0,0]],[[-406.4,-508,0],[1,0,0,0]],[[-406.4,-635,0],[1,0,0,0]],[[-406.4,-762,0],[1,0,0,0]]],[[[-508,0,0],[1,0,0,0]],[[-508,-127,0],[1,0,0,0]],[[-508,-254,0],[1,0,0,0]],[[-508,-381,0],[1,0,0,0]],[[-508,-508,0],[1,0,0,0]],[[-508,-635,0],[1,0,0,0]],[[-508,-762,0],[1,0,0,0]]]];


    PROC TC*****_*****()

    ! Counter for ***** *****

    nLastPart:=42;

    IF nTableCounter>nLastPart nTableCounter:=0;

    Incr nTableCounter;

    IF nTableCounter=1 THEN

    IF diTableA_AtLoad=0 THEN

    nTableCounter:=1;

    Wait_TableB;

    bTableA_AtLoad:=FALSE;

    ELSEIF diTableB_AtLoad=0 THEN

    nTableCounter:=1;

    Wait_TableA;

    bTableA_AtLoad:=TRUE;

    ENDIF

    ELSE

    ! do Nothing

    ENDIF

    nRow:=Round(((nTableCounter+1)/7)+0.3);

    nColumn:=1+((nTableCounter-1) MOD 7);

    IF nRow=1 AND nColumn=7 THEN

    nRow:=2;

    nColumn:=1;

    Incr nTableCounter;

    ELSEIF nRow=5 AND nColumn=7 THEN

    nRow:=6;

    nColumn:=1;

    Incr nTableCounter;

    ELSE

    ! do Nothing

    ENDIF

    RETURN;

    ENDPROC


    PROC PickA_*****()

    CONST robtarget PostPickup_50:=[[821.51,-211.47,445.43],[0.001655,0.674398,-0.738335,-0.006807],[-1,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget PostPickup_40:=[[35.86,-44.26,81.54],[0.080837,-0.877947,-0.465734,-0.075959],[-2,-1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget PostPickup_30:=[[50.6,-59.35,-7.39],[0.080817,-0.877943,-0.465743,-0.075974],[-2,-1,0,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget PostPickup_20:=[[440.37,56.91,432.95],[0.00172,0.674479,-0.73826,-0.006895],[-2,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget PostPickup_10:=[[30.71,698.73,111.92],[0.001718,0.674474,-0.738265,-0.006883],[-2,-1,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget AbovePart_10:=[[33.51,698.61,409],[3E-06,0.674516,-0.73826,-3.6E-05],[-2,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget AbovePart_20:=[[29.29,698.8,-36.98],[1.3E-05,0.674513,-0.738263,-4.3E-05],[-2,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];

    CONST robtarget PickupPart:=[[30.55,697.79,-72.33],[0.000107,0.674601,-0.738183,-0.000111],[-2,0,1,0],[9E+09,9E+09,9E+09,9E+09,9E+09,9E+09]];


    PDispOff;

    EOffsOff;

    PDispSet AOffs_*****{nRow,nColumn};

    MoveJ AbovePart_10,v2000,z40,tGrip_14890\WObj:=wobjA;

    MoveL AbovePart_20,v1000,z5,tGrip_14890\WObj:=wobjA;

    MoveL PickupPart,v40,fine,tGrip_14890\WObj:=wobjA;

    rGrab_*****;

    MoveL PostPickup_10,v400,z10,tGrip_14890\WObj:=wobjA;

    MoveL PostPickup_20,v1000,z20,tGrip_14890\WObj:=wobjA;

    PDispOff;

    MoveJ PostPickup_50,v3000,z50,tGrip_14890\WObj:=wobjA;

    RETURN;

    ENDPROC

    Quote from Lemster68

    Read this: Picking part 2, from a tray of parts.


    Using the six point is probably not helpful. Any inaccuracy in the workobject could be your issue. Check your calibration offsets and robot zero position. Then check the baseframe in your system parameters. If it is not 0,0,0 1,0,0,0 then that will throw you off.

    I found a difference in the calibration offsets for Joint IRB5. The sticker on the robot says 5.672950 and in my file it says 4.28287. I do not know why they are different, it may be that the joint was replaced. What would be the repercussions of changing that number to see what happens? I'm assuming it probably won't work because the robot seems to be calibrated but Its hard to tell just by looking at it.

    The motor may have been changed, but on that model it is common to just change the whole wrist, axes five and six would show different. But changing the cal offsets would also wreck all your programs. Going back to your first post, you said your TCP looked ok. If your offsets were wrong, you most likely would fail to get a good tcp every time. Did you teach it or load data from cad?

    Quote from Lemster68

    The motor may have been changed, but on that model it is common to just change the whole wrist, axes five and six would show different. But changing the cal offsets would also wreck all your programs.

    Regarding this quote. If it fixes the PDispSet going forward and avoids all these manual corrections that need to be done, it may be worth it to try. What would be the odds of it working and if so what would be the order of operations to test.


    Backup, change resolver offset, test? If it doesn't work, restore old backup? Or is it like updating revcounters and there is no going back?

    .18, ?, 3.4 I think. Not great, not terrible. I will retry when I have more time. I figure I can move forward with the rest of the program. Either I can fix the Displacement problem, which affects the load proc with the better TCP or I can't. I'll create a new tool for the load portion then switch back to the old one between procs for the rest. Not great practice, but I need to get back to processing again instead of programming.

    In the program example I encouraged you to look at I calculated the positions into the robtarget array. If there were issues like you are having, I could have built in a "fudge factor" into the calculations. Not only that, but also, one could actually touch up any one of the positions in the array, if necessary.

    Lemster68 Forgive my inexperience, what do the prefixes fo and fi stand for in the code you shared with me? I am trying to better understand how exactly I can apply this to my current setup. We don't have any sensors really, just an LVDT I haven't used yet. As far as error handling, I haven't coded any cause there is nothing to check anything with. Its a very basic no nonsense cell. Luckily, it has collision detect. Very rarely does stuff go wrong, but when it does its usually a quick jog and rollback to where it went awry. It looks like I would code something similar to Your TeachTray routine, but some of the rest is foreign to me. I am also trying to figure out how much of my current code would need to be changed in order to add something like this. I'd like to do it in a way that I could have a Generic Routine I could use on any table regardless of size of the array. So it seems I would need to attach it to my main program and treat it as a kind of supervisory part of the program, or have it as a stand alone that I put in and took out as needed. If its the former, I might have to rethink my entire PDispSet strategy.


    Either way, thanks for sharing and opening my mind up to a better way to use the computer instead of just my noggin. Now I have to do some research on some of these terms and commands and figure out a way to program in some of that "fudge factor" you mentioned. I may have more questions later. Thanks for the homework!:winking_face_with_tongue:

    Fo and fi are just digital inputs and outputs. The controls engineer wanted those names because they are "fieldbus" IO. It was mostly just the teach tray that I wanted you to see, calculating the positions into the array. Also, when using the array it can make for some tidy code in a for next for pick and place.

Advertising from our partners