# Tool Cartesian

• Okay forgive the new guy asking probably a simple question. I'm having trouble wrapping my head around Tool cordinates. I thought I had it understood with EOAT being riveter, forward +X reverse -X Left +Y Right -Y down -Z up +Z this is a Fanu hanging upside down. When I got to a flow drill it all went different for me. i understand the TCP distinguises the line of travel. Is there a simple formula similar to world cordinate where thumb is =Z index finger =X and middle finger at 90degrees =Y not alot of experince under my belt and trying to improve skills any help appreciated.

• Hi graf
Welcome to the robot-forum

" forward +X reverse -X Left +Y Right -Y down -Z up +Z"
This is the "world" as we know it. Right hand rule, which is what you described " forward +X reverse -X Left +Y Right -Y down -Z up +Z".

So, I don't understand what your problem is.
I think you have to understand between jogging in USER, TOOL or WORLD with recording the point with a particular TOOL frame and/or USER frame

DO you know how to teach a USERFRAME ?

somar

• Thanks for the reply, tool (1) user frame (0) would it be safe to say that due to the different TCP location of the EOAT that that is where the tool cartesian cordinates varies, for instance the riverter the anvil is the TCP where as on the flow screw gun the nose is TCP both haning upside down. Is the a set rule of thumb that distinguses X Y Z like in World cordinates,. Such as given a specific TCP right might be Y+ Left might be Y- etc etc

• I am not a Fanuc expert, so... But the tool coordinate system will always be "right-hand rule" because that is the industry default math definition. An end effector tool transform definition is usually taught by some method or the transform components {x, y, z, rx, ry, rz} are explicitly entered to the controller from CAD or other data. So the actual implementation of the tool definition may not behave as you expect because of how the definition was created. The orientation of the tool coordinate system may have accurate, but unexpected values. You may expect the tool to move in Tool Motion Mode in a certain direction, but because of a minor component data entry mistake, it moves in an unexpected direction. Easily changed, and knowledge/understanding of this comes with experience.

TygerDawg

Blue Technik

• Graf

I think TygerDawg answer is better than mine, I thought your problem was the userframe (having the robot hanging gave me that idea)

Play with the values of the tool,
How did you enter this values ? did you teach them or you entered them from CAD values ?See if they match, even if X,Y and Z are correct, your problem could be on rx, ry, rz

somar

• Appreciate the replays I'll check when I go back to work

• The thing to remember is, a frame transform (World, Tool, userframe, whatever) is always relative to some starting point. For most robots, the World frame is fixed to the baseplate of the robot, directly below the axis of Joint 1, and with an orientation fixed to some physical feature of the baseplate. Usually, these days, it's right-hand rule, with X+ being in the direction the robot "faces" when Axis 1 is at 0deg, and Z+ being straight "up" away from the floor.
Of course, there are variants -- some robot brands (20 years ago) used to use left-hand rule, and even today you have robots that have a linear rail for Axis 1 rather than a rotary axis, so the rules can vary a bit. But in general, the rules TD outlined are adhered to.

Now, a Tool transform is always relative to the "zero tool." Usually, this a a point defined at the center of the tool mounting flange (usually the center of the Axis 6 faceplate). Because the "zero tool" is defined as part of the robot's kinematic model, and cannot be changed, the robot always knows where the Zero Tool is at any moment, from the positions of the various axes. Then, in order to determine the position of the tool mounted to the robot, the processor takes the position of the Zero Tool, and adds the XYZ and Yaw-Pitch-Roll values of the mounted tool, to determine the actual position of the active tool.
Now, the thing is, the definition of the Tool axes relative to the physical build of the tool is up to the end user. Some companies define their welding tools with Z+ pointing straight out from the tip of the welder, but some other companies (using the same hardware) define the Tool X+ axis that way. A few use Z- instead. The key point here is that the TCP can be defined any way you like, relative to the hardware. But, if you are using a path program generated from a Simulation program (RobCAD, ProcessSimulate, Delmia/Catia, etc), you have to ensure that the tool transform in the robot matches the tool transform used in the Simulation software. The TCP transform can be anything you like, but they have to match. Of course, sometimes this isn't easy, because some simulation software defines a TCP differently from the way the robot does, so the Sim and the robot have to use different XYZ-YPR numbers to define the same physical transform. This is because most Sim packages can do simulations for many different root brands, but each robot brand uses a different mathematical formula to define a TCP transform.
For example, KUKA robots use XYZ, ABC (A=Rz, B=Ry, C=Rx), but Delmia/Catia uses XYZ,Rx,Ry,Rz. Older Kawasakis used XYZ, Rz,Ry,Rz. ABBs use XYZ,Q1,Q2,Q3,Q4 (quaternions). If you know how to convert from one to the other, you could move a tool from any brand robot to any other, and still get a perfectly good TCP. But the numbers each robot used would be different.

• The free version of RoboDK allows you to import/export rotation angles in different formats according to different euler rotation order. You can then quickly visualize and modify a TCP, a reference frame or a target. It also includes Quaterion data for ABB robots. See the image file attached or the link attached. You can set your default rotation preference in "Tools->Options->General tab->Default Euler angles mode". The simulator also changes this preference depending on the robot brand that is being used.

https://www.robodk.com/help.php#frames

I hope this helps.