Palletizing

    Hello !

    Last week , we had a feasibility test with the an external supplier ( they will build a machine for us ) , and I have seen a very strange issue .

    Subject of a test :
    - Pick up a part ( rectangle shaped) from a plastic tray
    - Drop the part into the Jig. ( Placing is really tight, only 0,1 mm per side)

    The supplier said, the palettizing function was not worked , so they tuoched up all positions ..

    Pick : 60 positions
    Drop : 36 positions

    It is not seems so good if someting is going wrong...

    Pallettizing code :

    9: FOR R[2: Y]=0 TO 5 ;

    10: FOR R[1: X ]=0 TO 1 ;

    16: PR[2,1]=R[1: X ]*(-118) ;

    17: PR[2,2:]=R[2: Y]*(-45.3) ;

    PR2 is used for Offset .
    Like this :
    L PR[6:POZ1] 2500mm/sec FINE Offset,PR[2]

    Issue :
    The Robot was not going into the exact position , which was written in the PR[6] .
    For example :
     
    PR[ 6] value with the offset :

    X 100 W -90
    Y 100 P 0
    Z 100 R -45

    PR[6] reached position

    X 99.8 W -90.1
    Y 99.6 P 0.2
    Z 100.1 R -44.8
     

    Do You have an idea why ?

    Robot : LR Mate 200iD/7L R-30iB Mate Plus

    Thanks for Your answers

    Have you set the payload settings for the robot with and without the part being palletized? You should have different payload schedules set up for each EOAT + Part combination, and switch between them as needed in the program by using the Payload[n] instruction.

    I would suggest trying that first, and maybe decreasing the acceleration/deceleration speeds using the ACC motion option (try ACC 50, for example, for double acceleration and deceleration time; this will make the moves slightly slower but should help smooth them out).

    Edit: Beat me by a minute or two :grinning_squinting_face:

    Quote from moln4r

    Just an idea, but have you checked the payload settings?

    One thought, verify the robot isn't changing config when it reaches the point. We do a lot of calculated matrices and I have fought this before. The robot can reach the same point in space with a different joint configuration. Theoretically it should be the same point but from what I've seen it will introduce an error.

    Just my 2 cents.

    Quote from domo_arigato

    Have you set the payload settings for the robot with and without the part being palletized? You should have different payload schedules set up for each EOAT + Part combination, and switch between them as needed in the program by using the Payload[n] instruction.

    I would suggest trying that first, and maybe decreasing the acceleration/deceleration speeds using the ACC motion option (try ACC 50, for example, for double acceleration and deceleration time; this will make the moves slightly slower but should help smooth them out).

    Edit: Beat me by a minute or two :grinning_squinting_face:

    Yes, we checked the gripper payload, the part is roughly 5 gramm , so we did not make an additional payload for it ...
    The speed was reduced so much
    Thanks for your ideas

    Quote from rumblefish

    One thought, verify the robot isn't changing config when it reaches the point. We do a lot of calculated matrices and I have fought this before. The robot can reach the same point in space with a different joint configuration. Theoretically it should be the same point but from what I've seen it will introduce an error.

    Just my 2 cents.

    I will check this config changing in roboguide !
    Actually I do not really understand, why it can happen ? If all the point is teached it is working well, if try to pallettizing, it is not...

    I don't remember specifically if it is due to crossing an axis or lack of turn data, maybe someone else can better explain it. It still reaches the cartesian point, however (for example) J4 could flip. The tcp is still at the position, just with a different config.

    When you say "not going to exact position", do you mean the calculated position vs the displayed position are different? Or is it the robot didn't line up with a part/fixture?

    If it is the latter, you need to verify stack up tolerance on the trays/fixtures. If the destination has 20 spots and they were built +/-50um, you could have up to a mm in error at the end. You can't expect a robot to pick +/- .5 mm if the tray is +/- 2mm.

    Here's a good example of how the config values (N,U,T) work. Pick up a pen, pencil, etc and point it straight out in front of you with your elbow high in the air. Then, without moving the tip of the pen or rotating its orientation, drop your elbow down.

    The pen's location in space and orientation hasn't changed, but your elbow and wrist joint "values" have. In the case of 6 axis robotics, there's 3 main scenarios that can cause this:

    Non-Flip or Flip: Joints 4, 5, and 6 rotate to "flip" the wrist over, maintaining the Tool Center Point in the same location and orientation. This would be like rotating your wrist and somehow being able to rotate your fingers separately in the opposite direction to maintain the pen in the same location and orientation; this one is physically impossible for a human to replicate naturally.

    Up or Down: Joints 2, 3, and 5 rotate to raise or lower the "elbow" of the robot (similar to the above example I mentioned, maintaining the Tool Center Point in the same location and orientation.

    fronT or Back: The robot rotates J1 roughly 180 degrees, flips Joints 2 and 3 above over the back of the robot, and rotates Joints 4, 5, and 6 to maintain the same Tool Center Point location and orientation. This is like turning around with your back to your target, reaching behind your back over your shoulder, and rotating your wrist to bring the pen to the same location and orientation.

    Quote from rumblefish

    I don't remember specifically if it is due to crossing an axis or lack of turn data, maybe someone else can better explain it. It still reaches the cartesian point, however (for example) J4 could flip. The tcp is still at the position, just with a different config.

    When you say "not going to exact position", do you mean the calculated position vs the displayed position are different? Or is it the robot didn't line up with a part/fixture?

    If it is the latter, you need to verify stack up tolerance on the trays/fixtures. If the destination has 20 spots and they were built +/-50um, you could have up to a mm in error at the end. You can't expect a robot to pick +/- .5 mm if the tray is +/- 2mm.

    The calculated and the displayed positions are different :frowning_face:
    I already checked the NUT values (from backup) , the robot makes changes ( From NUT 0 0 -1 to NUT 000 ) while moving to the palletizing position ...
    I spoke with the supplier, but I still did not get answer...

    How did you determine:

    Quote

    PR[ 6] value with the offset :
    X 100 W -90
    Y 100 P 0
    Z 100 R -45

    and

    Quote

    PR[6] reached position

    X 99.8 W -90.1
    Y 99.6 P 0.2
    Z 100.1 R -44.8

    Maybe you move the robot with an active userframe but you calculated the target position in world coordinates?

    Also if you look at Fanucs own Palletizing function they would require 3 points to be taught for what you want to do. Maybe that helps with accuracy? Wouldn't change the fact that the robot doesn't move to the calculated position though.

    Quote from TomTom

    How did you determine:

    and

    Maybe you move the robot with an active userframe but you calculated the target position in world coordinates?

    Also if you look at Fanucs own Palletizing function they would require 3 points to be taught for what you want to do. Maybe that helps with accuracy? Wouldn't change the fact that the robot doesn't move to the calculated position though.

    Supplier tried the Fanuc own Paleletizing function, and it is working fine !

Advertising from our partners