Posts by robotero

    Check the attached kinematic analysis for a Fanuc LR mate arm

    Axes Z2, Z3 are normal to the arm plane ( the plane formed by axes Z0, and Z3) that is why a3 is 90

    There is an offset: a3, because z3 and Z4 do not intersect

    But in you robot they intersect

    Z0 of world frame in Fanuc's points upwards off course, Y0 points left and normal to the arm plane, X0 is along the arm plane

    After all transformations the tool 0 frame has Z6 normal to the face plate.

    You can define several sets of Dh parameters for a given robotic arm, but the best one would make the robot easier to jog.

    Please notice that fanuc measure the angle with respect to the vertical and the horizontal for axes 2 and 3

    check also this video

    theta d alpha a

    1 theta1 150.95 90 missing (you can also use alpha -90, so when you jog in +J2, the arm moves forward)

    2 theta2 0 0 250

    3 theta3 0 90 0 (here is zero, but usually there is an offset distance, choosing alpha +90 makes J3+ to move the forearm upwards)

    4a theta4 104.97 0 0

    4b 0 150 -90 0 (alpha is -90 here but usually +90 makes +J5 to point the tool downwards)

    5 theta5 0 90 0

    6 theta6 64.99 0 0

    You choices for alpha values have an effect in how intuitive would be your jog buttons.

    Again, the normal convention is to ended up with the tool face plate coordinate frame such as

    +X is pointing upwards (world +Z)

    +Y pointing to the left (world -Y)

    +Z pointing outwards, normal to the faceplate

    this might look awkward, but 90% of the time the last link is moved downwards 90 degrees

    So the tool X+ points in the direction of the application (welding, dispensing, etc)

    Y+ tool point rights to the application direction

    Z+ tool point towards the material

    If robot was at home position and you made scribes

    You need to jog all axis to find the encoders zero marks then return the robot manually to the scribed home position.

    master in that position using the joint values from the taught home position

    just open a program an get the joint position values from the home position

    Or open the home position signal configuration.

    The other way is also valid, just master to zero marks, and then zero master axis 1 latter

    My application has a robot rotated -45 degrees in relation to the cell. In order to get the WorldZones to line up, I changed the base frame Q1 to 0.92388 and Q4 to -0.38268.

    My understanding is that this will change the world co-ordinate system by 45 degrees so I can make the WorldZones line up with the cell.

    Is this the correct way to do this?

    Yes, is correct. Just update the orientation of the wobj0

    Touching up PR43 would not do, because it is re-defined at (program) execution time.

    I think registers R193, R194, R195, R199,R200 are meant to adjust your position PR43
    Just move the robot in USER Frame check the difference between the PR43 and the desired position

    Modify the registers as required

    PR41 and PR42 are just way points

    The base position is PR44, I wouldn't modify this one.
    If you modify PR44 , then you MUST zero all registers R193,R194,R195,R199,R200, because no adjustment is needed.

    Just make a backup of your program before any changes suggested here

    Do not blame the robot, check your process

    Since the first time I read your post I couldn't stopped thinking how can you be so sure the robot "moved"?
    The only way to be positive is to program a verification posture and check robot's repeatability.

    In arc welding for example we verify the torch regularly by replacing the conic torch nozzle with a straight nozzle
    the robot moves to a verification station that has a sliding tube. If torch is perfectly aligned the tube slides over the nozzle as a sleeve, otherwise any deviation would prevent it.

    If the robot does not repeat after opening the gate, I think is just a mere coincidence and I bet the variation is in other elements of the cell.

    If the robot is not properly anchored, it would start shifting.

    When you create a station with robot from backup it uses the latest robotware version by default
    You need to download the robotware version that is installed in your system
    When you are creating the cell, robotstudio tells you want version the robotware version of the backup
    Then go to addins and seach for the robotware, downloaded and install it

    You DON'T need to explicitly specify the arm model, it is loaded automatically when the cell is created

    I assume you attempted a S/W install under controlled start
    Check what other options are installed in your system

    The system will only allowed you to install the libraries according to your installed options
    For example you can add basic positioner if you have that option

    The basic positioner will be added as group 2
    Then you configured the axis as a basic positioner

    I think this is the path to reconfigured the 7th axis as a separate group

    Could you please post what option you have

    The position of the tool relative to world object is known
    And is the product of three transformations:

    You want to know the position tool0 relative to base

    You then need to premultiply by the inverse of Worldtobase and post multiply by the inverse of TCP

    I am sure there are commands inside RAPID to do the math

    What robot were version is installed in your robot?

    IN version 6.5 new useful mathematical functions were added

    PR are representations of transformations, transformations are multiplied NOT ADDED

    Just in a particular case you can add them: by keeping the USER & TOOL frames aligned

    To make your code work, in the second method you need to multiply PR[2] by PR[1] and store the result in say PR[3]
    then move to PR[3] with USER frame 0 active. But Fanuc does not provide such operator (at least not without Karel)

    1 and 3 should be the same, but sometimes the shifted position is wrong and requires to change the PR representation to force the correct one.

    W, P, R are Euler angels. In PR register on FANUC they are intrinsic angles, which means each next rotation is made with respect to frame already modified by previous rotation.

    Exactly WPR stand for yaW, Pitch, and Roll angles
    The product of the three transformations can be seen as both as intrinsic or extrinsic

    The gimbal lock ONLY happens when you rotate around Y +90 or -90 degrees, making X,Z rotations redundant
    a unique solution cannot be computed because there are infinite possible combinations

    Although the system uses the USER/TOOL frames as references during teaching, the PR is stored as raw positional/orientation data
    not associated to any USET/TOOL frame

    So you must take into account which USER\TOOL frame are active when you use the PR in a movement instruction

    If you have a USER/TOOL frame defined, and teach a PR with these frames as reference, then (in general) you SHOULD be able to manipulate the values of the PR to get a new position/orientation

    Just to test record again your PR, then rotate in tool (or user) around Y and record a new PR
    compare both to see the representation

    One way to do it is by defining a pivot TCP, at the radius distance from the laser torch TCP

    The idea is to move the robot so as the pivoting TCP is at the center of the circle
    and at the same time the laser is at the start cutting point

    Then just move the robot with a Linear interpolation, keeping the same position but changing the orientation
    This will make the laser to move along a circular path.

    Unfortunately, this will rotate the tool and probably your cables will become a limitation.
    Off course this will also have the limitation that only circles and the defined distance can be made
    unless you dynamically change the pivot TCP

    Another way is to compute the entire circular path with linear segments.
    I've done that before. I was asked for a full parametric routine. Only centers were taught, the routine compute all movements needed using the center position and some parameter values.
    The robot then made the approach movement at the defined clear distance,
    move down to cutting depth, then move along a circle; compensating the cutter radius to get the design circle dimension

    Sorry, I cannot disclose the code, but I can give you a hint in case you attempt to code it yourself
    The position of the laser is compute inside a loop that rotates the offset around the center
    In that way successive points are computed
    then a linear move command inside the loop cuts each segment as they arecomputed

    Guau! Your robot is loaded with many cool options You have multitasking and multi motion groups, but the 7 axis was configured as an extended axis
    So basically it belongs to group 1
    If I remember correctly you need to configure it as an auxiliary axis instead
    to create it’s own group

    Sent from my iPhone using Tapatalk