The following is a simplified explanation of kinematics, and how they work with LinuxCNC. This was originally written as a post to one of the mailing lists, but was placed here instead so that it could be referred to later.
When we use G-code to describe a part, we use coordinates X, Y, and Z. These three numbers describe a single point in three dimensional space. But a cutting tool isn't a single point in space, it also has an orientation. A tool at X0 Y0 Z0 pointing straight down is not the same as one at X0 Y0 Z0 pointing 45 degrees left and 5 degrees to the back of the machine. A complete description of the orientation of a tool (or any other object) in three-dimensional space consists of 6 numbers, not 3. First you have the three linear coordinates, X, Y, and Z. Then you have the angular coordinates, A, B, and C. I sometimes like to use the words "pitch", "yaw", and "roll", to make it very clear that we are talking about angles.
A set of 6 numbers like this describes the "Cartesian coordinates" of a particular tool position. It always takes all six numbers to completely define the position of a tool. A particular line of G-code may only specify three (or even one), but the others are still there, they just re-use their previous values. The Cartesian coordinates can also be thought of as "part coordinates". They tell you where the tool should be with respect to the part, in purely geometric terms.
Now lets look at "machine coordinates". Assume we have a hypothetical shop with four machines, a Sherline mill, a Bridgeport mill, a radial drill press, and a robot arm holding a Dremel tool. All of these machines are equipped with motors for CNC control.
The Sherline is simple - it has three motors. One controls the table, one controls the saddle, and one controls the head. We will use the terms "table", "saddle", and "head" to refer to these motors, not X, Y, and Z.
The Bridgeport is just a little bit more complicated. It has "table" and "saddle" motors like the Sherline, plus two more motors, one for the "quill", and one for the "knee". Now you can see why I don't want to call them X, Y, and Z. Which one is Z, the quill or the knee?
The radial drill is even worse. It has a large round vertical column that supports a horizontal arm. One motor slides the arm up and down the column, we'll call that one "lift". Another motor called "pivot" swings the arm around the column, to cover a wide working area. A third motor called "extend" slides the head in and out along the arm, and a fourth motor runs the quill. Now, we not only have two motors (lift and quill) that both move the tool parallel to the Z axis, we also have one motor that controls a pivoting joint instead of a linear slide.
Finally we have the robot arm. It also has four motors, but they control completely different things: "waist", "shoulder", "elbow", and "wrist". All these motors produce pivoting motions, not linear motions. The waist motor rotates the entire robot around in a circle. The shoulder motor tilts the entire arm up and down. The elbow bends and straightens a joint at the middle of the arm, and the wrist bends and straightens a joint at the end of the arm.
Things like "table", "saddle", "head", "quill", "knee", "lift", "pivot", "extend", "waist", "shoulder", "elbow", and "wrist", are known as "joints" and their positions are described with "machine coordinates". They are distinct from "part" or "Cartesian" coordinates. They describe the position of the parts of the machine. Machine coordinates are not limited to three linear and three angular. You can have any number, and any mix of linear and angular. The Sherline has three linear, the Bridgeport has four linear, the radial drill has three linear and one angular, and the robot has four angular.
Part or Cartesian coordinates describe the orientation of the tool in three dimensional space. They deal only with the mathematical concepts of 3-D space. There are always three linear and three angular coordinates, because that is how things in 3-D space are mathematically described. There are no limits to Cartesian coordinates - they can describe the position of a tool 0.01 inches above a part, or the position of a spaceship orbiting Alpha Centuari.
Machine coordinates on the other hand are solidly grounded in reality. They describe the state of the machine, and care nothing about mathematical concepts. If a machine only has three motors, then the machine coordinates only consist of three numbers. In addition, machine coordinates have upper and lower limits that cannot be exceeded. Cartesian coordinates may be able to describe a spaceship in orbit, but the machine can't reach it, and machine coordinates reflect that limitation.
For a machine like a Sherline, and even for the Bridgeport (if you ignore the "knee or quill" issue), the machine coordinates match up perfectly with the part coordinates. If you want a straight line in X, you can move the table. For a straight line in Y, you move the saddle, and so on.
Since the machine and part coordinates line up so nicely for conventional machines, most software treats them the same. Most people do too. Ignoring the distinction between the two kinds of coordinates makes things much simpler and easier to understand. You stop thinking about "table" and "saddle" amd just think "X" and "Y", since that is what the G-code uses.
Ignoring the difference between machine and part coordinates is nice when you have a simple machine. But when the machine is something like our radial drill or robot arm you can't ignore it. A simple move along "X" in part coordinates may require movement from two or more motors in machine coordinates. For example, on the radial drill, unless the arm happens to be aligned with the X axis, we need to move both the "pivot" and "radius" motors to move in a straight line along "X". When working with this kind of machine, you must understand the difference between "part" and "machine" coordinates.
So did I, and we're finally there. Once you understand the difference between part and machine coordinates, kinematics is easy. Kinematics is nothing more than the translation between part and machine coordinates, and back again.
Unlike programs that ignore the difference between part and machine coordinates, LinuxCNC always makes the distinction, even when it doesn't have to. LinuxCNC uses kinematics to translate from one to the other. For machines like Sherlines and Bridgeports, where the part and machine coordinates are the same, LinuxCNC uses a kinematics module called "trivkins", which stands for "trivial kinematics". It is definitely trivial - it simply copies the coordinates from one side to the other.
However, trivkins can be replaced with other kinematics modules, that do more complicated translations. For something like our radial drill, it is pretty easy to do the geometry to convert from "X" and "Y" to "pivot" and "radius". (The math is known as cylindrical coordinates.) For the robot arm it is more complicated, but still just a bunch of math.
Once you understand that kinematics is nothing more than translation from part to machine coordinates, it becomes clear that kinematics can be used to compensate for leadscrew error, non-square axes, and many other types of machine errors. If the table travel is 89.5 degrees to the saddle instead of 90, then for every inch the table moves, the saddle needs to move 0.00872 inches to compensate for the misalignment. The kinematics module is the ideal place to make such a correction.
Leadscrew correction could be done in the kinematics module as well, but LinuxCNC treats it as a special case. Since the error is parallel to the travel of the screw, the correction is applied directly to the motor in question, not to any other machine coordinate. That means it can be done downstream of the kinematics module, right before the commands go out to the motors. (On the "part coordinates" side of the kinematics, the coordinates are a single entity that consists of three linear and three angular values. But after the kinematics, each "machine coordinate" is an independent value and can be compensated individually.)
The NIST version of what is now LinuxCNC had leadscrew compensation downstream of the kinematics, so that even with trivkins you could still do screw compensation. LinuxCNC has hooks for the same thing, but the code is currently commented out. (The actual compensation code is simple, but the method used for getting the compensation data from a file on disk to the realtime code that does the work was rather messy. In the interest of getting things working, it was disabled. It needs to be fixed and enabled.)
The leadscrew compensation algorithm lets you specify two different compensation profiles, one for each direction of travel. The difference between the two represents the backlash. Using this approach you can compensate for a screw that has more backlash near the center where the wear is bad, and less near the ends where there is less wear. For users who don't want to provide customized screw error and/or backlash compensation profiles, conventional backlash compensation can be used instead. This replaces the position dependent forward and reverse compensation curves (from disk) with a fixed correction that is either plus or minus half the configured backlash value, based on the direction of travel.
![[Home]](/chips.gif)