Posts by I3ooI3oo

    I have recently talked with Fanuc about this in depth. The short answer to your question is yes. You can use joint position data and move to it in a linear move. The controller first calculations the XYZWPR data for the point with the given tool. Then it calculates the linear move from the location it is at before the move.

    It seems in your situation that the light curtains are a safety device for the table. Since you can not access the robots from the area of the light curtains they shouldn't be tied to the robots' fences. If the robot could hit the operator when someone breaks the light curtain then and only then should they need to be tied in.


    I would assume that the robots know when the table is going to rotate and can not be in a location that could hit them. I often use a reference position bit to help control the ability of the tables rotation. Both robot's reference position for the table would need to be not flagged for the table to rotate, thus making sure the table never hits robots.

    I recently had something like this. When running 2 robots with RIPE setup. When ever power flickered both teach pendents locked up, despite being powered from a UPS and the RIPE network being setup with a cross-over cable directly plugged between the two controllers. It was repeatable. I never did figure out what was causing it.

    Quote


    Refer to section 3.1 of the R-30iA handling tool documentation. That explain how to set up frames. Also, someone correct me if I'm wrong but, even if you go create a frame, the points that you've already created won't be updates, even if you switch to the created frame and touch them up. You'll have to create new points while the new frame is selected. However if you switch over to user/tool (whichever type you created) while jogging, the robot axis should move in reference to the conveyor, allowing you to create 'perfectly' aligned points. Don't forget to switch the user/tool frame number in the program before the news points, and switch it back to the other frame after. Another option would be to shift the point's using the Prog Adjust or Program Shift utilities. I would still create the frame for future use. PM me if you have any more questions.


    From my dealing with Fanuc robots that is absolutely incorrect. I recently setup a robot that picks parts off a pallet on a conveyor. When the conveyor is moved you have to reteach the user frame. We designed the pallet so you can install 3x 100mm pointers so you can do a 3 point setup. Once you re calibrate the userframe you can pick up all parts off the pallet without touching up the locations.


    Since your points are taught off a Userframe and a TCP if you change either, all points referencing them will be updated also.

    Programs on Fanuc robots can only do one operation at a time. So you would need a temp register unless R[10] can change.


    R[9]= R[10] - 1
    R[9]= R[9] * R[5]


    Now R[9] = ((R[10]-1)*R[5])

    The following is a quick little for loop that could create a number of stacks in a square pattern. It can be done more efficiently but this is easy to understand.



    P[1] = LOCATION OF THE FIRST PART.
    P[2] = LOCATION OF THE FIRST PART APPROACH HIGH ENOUGH TO CLEAR STACK
    R[1] = X COUNT MAX
    R[2] = Y COUNT MAX
    R[3] = Z COUNT MAX
    R[4] = CURRENT X COUNT
    R[5] = CURRENT Y COUNT
    R[6] = CURRENT Z COUNT
    R[7] = CURRENT X OFFSET
    R[8] = CURRENT Y OFFSET
    R[9] = CURRENT Z OFFSET
    R[10]= X OFFSET AMOUNT
    R[11]= Y OFFSET AMOUNT
    R[12]= Z OFFSET AMOUNT



    *edited to fix the copy and paste typos.

    I would see if you can register on Fanuc's https://crc.frc.com/login.aspx . Then see if you can signup for their online tool handling class. It will only take a few hours to get a understanding.


    With the CRC Online Site you can:

    Each robot will need it's own user frame. Since the user frame is an offset from the robot's world frame. If all the robots can reach a common area you can program each user frame to be the same common. It other words you can make a position have the same xyzwpr in each robot's user frame.

    When you do this test, if you watch the Joint data for all the other axis do they move?


    When moving joint 6 on a 6 axis robot in joint mode and watching world position status. You will see changing WPR depending on the angle of the faceplate in relation to the robot world 0,0,0,0,0,0. Only when the faceplate is parallel with the robots base and perpendicular to X and Y will the rotation only be seen in R . The WPR data is the relationship of the utool to the world frame. W being the rotation around X, P is the rotation arounf Y and R is the rotation around Z.

    Does your utool have any data in it?


    Create a new uTool with direct entry. Set XYZWPR all to 0. Init that new utool. Now move J6 while watching the POS displayed in world. You should see no movement in XYZWP.


    If your uTool has anything in W or P, when you rotate J6, your position of W and P will move. It is if you bent your finger and then rotated your wrist. The angle of your finger relative to your body would change.

    I have a new R30ib Compact plus controller with a SCARA. We don't use any special spark killing diodes. We always wire the outputs to optically isolated Opto modules instead of relays. Which would prevent any arcs and or sparks. We also use 2 different 24v sources for the different banks as they connect to different devices.

    On my last system running 2x LR Mate 200iD, I setup one of my more complicated homing/ park routines. Since we were using 2 robot to pick from 1 pallet and present to 1 laser and then place on a tester that is operated by a 3rd robot (Scara). Since I was using both a I/O bit for intent to go to a location along with position reference I/O for each of the location.


    So each homing program checked the I/O of itself and the Jpos value of J1 to see what it was needing to check. If it was over the pallet it would need to take it's current location and set Z = 0 to raise it above any parts on the pallet then retract to pallet perch. Before moving it had to check if the other robot was at the pallet or going to the pallet if it was then robot 1 couldn't move, and would require manual jogging as one couldn't tell if the robots were intertwined.


    The program did this for 4 different zones. It would handle parking from about 90% of possible locations the robots could get into while running correctly and being just down abruptly. They would park themselves at the end of each program. I could have gotten it to work with all possible positions but it would have taken another day or two to write out all the extra error checking and location calculations.


    That being said homing programs could be quite complicated depending on the complexity of the robot's work envelope.

Advertising from our partners