Posts by robotero

Hi

Always change the batteries with the controller ON

You replaced the batteries with the controller OFF, now calibration counts are lost.

You need to calibrate the robot

If you select update you can load the SMB data from the cabinet

But first you need to check if the data is valid when you check the status

open Calibration from the main menu, then check the status of the robot

and open it

Check the SMB status, you probably need to load rev data to the SMB

Yes, there are several utility plug-ins

I always install all of them

I suggest building a controller using simotion from siemens, they have libraries to make the path interpolation for articulated robots. I've been using simotion to control gantry robots.

You can create a Power On event routine and do what ever you need (in this case turning a signal ON)

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

Quote from enagy

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

Just chain-multiply Inverse of UF3 by UF2 and finally the vision PR Offset

The result is the a PR Offset in UF3 coordinates

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:
Worldtobase*basetotool0*TCP

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.

Quote from Snowblind

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