Counting with FANUC Pick and Place

    1. I attempt to tally the pick and place cycles up to a specific count, as the arm may reach singularity after a certain number of picks. To prevent this, I must reconfigure the arm after a set number of cycles, as shown in picture 2. I have been attempting to utilize a counter for this purpose, but I am unsure of where to insert the code. Could someone guide this matter? Thank you.

    2. I have included a pseudo code for reference.

    R[counter] = 0

    initial position

    ini data
    R[7, x]=0
    R[7, y]=0

    y loop (from top origin to Bottom)
    FOR R[2]= 1 to 4

    x loop (from left origin to Right)
    FOR R[2]= 1 to 5

    pick
    grind
    place

    x Offset (X parts in apart from 110 distance)
    PR[7,1] = (PR[7,1]+110)

    END FOR

    reset x to 0
    PR[7,1] = 0

    y Offset (y parts in apart from 13 distance)
    PR[7,2]=PR[7,2]+130

    END FOR


    where to put

    R[Counter] = (R[Counter]+1)
    If R[Counter]<11, JMP LBL [1]

    Call second positioning

    Continue the pick and place

    Edited once, last by NathanJo (August 2, 2024 at 3:24 PM).

    Instead of using a counter, I would use one register for the X axis and another one for the Y axis. Let's say R[1] and R[2].

    Then, I would put an IF statement at the end, checking if I'm at the problematic position.

    If you have few specific positions you could do something like this:

    IF (R[1]=3 AND R[2]=3), JMP LBL[1]

    IF (R[1]=3 AND R[2]=5), JMP LBL[1]

    IF (R[1]=4 AND R[2]=1), JMP LBL[1]

    If it's a continuous range of positions you could do this:

    IF (R[1]<=X AND R[2]<=Y), JMP LBL[1]


    Hope it helps

    1. I sincerely appreciate your assistance. I am encountering limit errors with the second and third pick-ups in the last row, while the others are functioning correctly. Despite employing a different arm configuration for the last row, the limit error persists. Unfortunately, we are unable to modify the physical design. We must devise a solution utilizing an arm configuration. I welcome any suggestions you may have.

    Quote from HawkME

    Right, your for loop registers already are counters. Just use them.

    I sincerely appreciate your assistance. I am encountering limit errors with the second and third pick-ups in the last row, while the others are functioning correctly. Despite employing a different arm configuration for the last row, the limit error persists. Unfortunately, we are unable to modify the physical design. We must devise a solution utilizing an arm configuration. I welcome any suggestions you may have.

    My project involves 20 rings that need to be "picked and placed." The first 11 picks go smoothly, but when I try to pick the 11th, 17th, and 18th rings, the arms stop moving because of a limitation error. I've explored several solutions, including using a counter to track the picks. I set it up to count to 11, and when it reaches 12, I adjusted the arm's position in hopes that it would bend more easily to pick the 11th ring.

    However, when the program runs, the arm moves into position but still follows the same tricky picking routine. The new arm configuration hasn’t helped. I need assistance in finding a solution for this issue. I attempted the same approach for picking the 17th and 18th rings, but something seems off, and I can't pinpoint the problem.

    Please post the code for your entire program. It appears that you are winding up the wrist.


    You need to to have a joint move to a fixed position, no offsets, that you move to everytime you approach and exit from your fixture. Make that position as neutral as possible (J4 and J6 as close to 0 degrees as possible).


    Also you are putting the robot near a singularity. You could fix that by changing the relationship of height or angle between the robot and fixture.

    Quote from HawkME

    Please post the code for your entire program. It appears that you are winding up the wrist.


    You need to to have a joint move to a fixed position, no offsets, that you move to everytime you approach and exit from your fixture. Make that position as neutral as possible (J4 and J6 as close to 0 degrees as possible).


    Also you are putting the robot near a singularity. You could fix that by changing the relationship of height or angle between the robot and fixture.

    I'm sorry, but the code has been modified. Thank you for your understanding and support.

    I have a few questions since I'm just getting started with FANUC robots. Can a program begin with a specific User Frame and User Tool, and then switch to another User Frame and User Tool at some point during execution? For example:

    UF = 1

    Utool = 1

    ......

    ......

    UF = 2

    UTool = 2

    Is this the correct approach?

    2. If this isn't possible, what is the proper term for it?

    3. If we can indeed change the User Frame and User Tool mid-program, how would I revert back to the original User Frame and User Tool?

    Could you provide a simple example to help clarify? Thank you!

  • NathanJo August 27, 2024 at 8:36 PM

    Selected a post as the best answer.

    Also keep in mind that if you are using P[...]-positions in your motion instructions, then the currently active UF and UT must be the same as they were when the position was taught.

    If you use PR[...], then the robot will try to move to the specified coordinates with the currently active UF and UT. Hopefully you've programmed it correct, but it opens up for collisions or worse if not handled properly.

    Quote from gpunkt

    Also keep in mind that if you are using P[...]-positions in your motion instructions, then the currently active UF and UT must be the same as they were when the position was taught.

    If you use PR[...], then the robot will try to move to the specified coordinates with the currently active UF and UT. Hopefully you've programmed it correct, but it opens up for collisions or worse if not handled properly.

    A good practice for points that will be common betwheen tasks if saved on PR registers, like the first point before entering one machine, is to change the way it's stored from cartesian to joints through the data screen.

    This will make sure that when executed, no matter the frame or tool that is selected, it will move to the correct location.

    It's very usseful if you do it in conjunction to a refposition with that same axis values, as it allows you to check where the robot is if you want to to an auto-homing routine or safe-travel to another machine.

    Then you can use this points on that program to move the robot betwheen machines without the need to ensure the correct frame or tool is selected (sometimes you use more than one tool on the paths, so saving that points on joints it wouldn't matter the tool as the robot will just move to that position no matter what you have selected)

    Quote from HawkME

    I usually like to break it up into multiple programs when I change frames, so each program uses only 1 frame. Not a necessity but helps with trouble shooting.

    That's wonderful! I'm actually using that right now too. Thank you for bringing this up and sharing your knowledge.

Advertising from our partners