Strange issue

    Hi all,

    I am programming a second hand M3ia 6A delta robot with a R30iA mate controller.

    There are 2 vacuum cups that are used to pick parts, one TCP for each one utool1 and utool2.

    There is one frame for the plate I pick the parts from.

    Parts are placed perfectly aligned parallel to the frame axes and there are +/- 20 rows and 17 columns.

    And now the catch:

    When I manually put a vacuum cup 1 centered on top of the first part, I select the utool 1 and the uframe 1, and I move manually (jog) the robot in X and Y axes selecting the UFRAME movement type, robot moves perfectly aligned across the parts.

    When I manually put a vacuum cup 2 centered on top of the first part, I select the utool 2 and the uframe 1, and I move manually (jog) the robot in X and Y axes selecting the UFRAME movement type, robot has a big deviation of +/- 8 degrees.

    This looks not normal at all to me.

    Even the tool would be wrong (bad coords received from the technical office), the coords I am moving the robot across the UFRAME...

    I can think about:

    1. The robot is not well calibrated, that is possible because customer had it mounted in a very small area, it had been powered up without having the robot connected to the cabinet and it had to be mastered by me using "manual" methods (no quick cal was possible because the robot can't be placed in the required position and I had to master axis by axis.

    2. The robot has a mechanical problem and there are some deviations when the clamp is inclined.

    3. Maybe the software in the robot is not the right one (who knows what could have happened there before).

    4. ?

    To put some extra fun, I have made the movments with tool 2 dependant on UFRAME 3 (another one), changing that UFRAME orientation solved the issue, and guess what? I ended up putting exactly the same values that I had at the beginning for UFRAME 1.

    Any idea of what could be going on here?

    Thank you all in advance.

    How did you define the tools 1 and 2 ? Did you teach them or just punch number from a drawing ?

    Are the tools equidistant from the 0,0,0 or one tool is "centered" and the other one offset ?.


    I'm just looking at your issue from the tool point of view and not from the user

    Assuming that your tools are not perfect, maybe this is why your user aren't working the way they supposed to

    Retired but still helping

    HawkME the tools and frames I have defined:

    Tool Frame

    -165.9 51.9 -27.9 -160.0 30.0 -180.0 t1

    -165.9 -51.9 -27.9 160.0 30.0 -180.0 t2

    User Frame

    419.3 -317.6 -118.1 0.0 0.0 150.5 UFrame1

    -363.1 -194.6 -115.7 0.0 0.0 59.4 UFrame2

    419.3 -317.6 -118.1 0.0 0.0 150.5 uFrame3

    Fabian Munoz tool data comes from a 3D design and I entered the numbers directly, one tcp is at the right side of the robot and the other one is at the left side.

    But, if Fanuc works like the other robots out there, even the TCP is not perfect, the robot should move in a straight line when you move it using the frame system...

    Thank you all.

    Can you post a picture of the tool.

    1st thing I noticed is a negative number in the Z of both tools? And the W, P, and R values, they look wonky? I would like to see the tool.

    If you put the tool on a pointer and rotate (in user or world) in W, P, or R does it stay on the pointer?

    I see it is a 6 axis, teaching the tool frame will give you a better XYZ, then manually put in the angles (that's if the rotation around pointer showed them to be correct).

    That's where I would start.

    Doctor_C I've attached the tool picture with the values.

    You'll notice the values have changed.

    I've used roboguide to find the "normal" orientation, Z was looking upwards before.

    The old values gave the same TCP position with the Z axis looking in the opposite direction (at least in roboguide).

    As those are vacuum cups, it's complicated to get a "perfect" zero teaching it manually, that's why we wanted to go the manual introduction method.

    There is some mechanical play in the 4, 5 and 6 axes. But even with that the behavior seems strange to me.

    With any of those numbers in tools the virtual robot moves normally / as one would expect.

    Thanks for posting!

    I always use to release the handbroken when changing uframe/utool numbers on the tp, because sometimes (not on every robot) if not done, the robot moves incorrectly on an axis even moving in uframe.

    Not sure the reason this happens, but it happened me various times.

    One thing to note is that fanuc axis 6 interface has 2 holes to fix the tool, have you checked if tool reorients correctly?

    Maybe you have the suction cup interface incorrectly mounted (inverted), also some mechanical units have that 2 holes rotated around 20 degrees (I think the M10iA with the 4th axis painted in black).


    To do this type of TCP measures I usually use a pointer fixed on the machine I work and then I measure the TCP as accurate I can putting another pointer but screwing it on the pneumatic racor hole. Then I only update the XYZ coordinates, original orientations from the offline TCP program are maintained.


    Make sure the robot is well calibrated before trying to make a TCP... if robot is not calibrated correctly is next to impossible to reorient correctly and robot may behave incorrectly on all linear movements.

    A correctly mastered and mechanically sound robot should always jog in a straight line in world or user mode. And it should follow the frame axis. Could be an exception on certain robots if you are near a singularity.

    Based on all the info provided, I think your initial guess is correct, there is something wrong with this robot.

    If you have the original mastercount values I would try to restore them, if robot has not lost power to the encoders and motors or encoders have not been replaced its better to use the factory original mastering data than to master each axis manually again. This data is always provided with the robot and its usually stored on paper inside the controller cabinet.

    Being a secondhand robot it will likelly not be the case but its easy to check if it works or not.

    I work a lot with vision equipment and it makes a big diference when a robot is well calibrated, I needed to restore calibration on various controllers and is night and day difference when you need to pick parts with different rotations.

    HawkME, Doctor_C, Fabian Munoz and Shellmer thank for your messages.

    Shellmer I don't have the original mastercount values, and I am sure the robot has lost power to the encoders, in fact my customer decided to power on the electrical cabinet without plugging the robot to the cabinet before.

    I will have to specialize the points a lot more than I would like... Patience.

Advertising from our partners