Important User Concepts

Trajectory planning, in general, is the means by which LinuxCNC follows the path specified by your G-code program, while still operating within the limits of your machinery.

A G-code program can never be fully obeyed. For example, imagine you specify as a single-line program the following move:

In reality, the whole move can’t be made at F10, since the machine must accelerate from a stop, move toward X=1, and then decelerate to stop again. Sometimes part of the move is done at F10, but for many moves, especially short ones, the specified feed rate is never reached at all. Having short moves in your G-code can cause your machine to slow down and speed up for the longer moves if the naive cam detector is not employed with G64 Pn.

The basic acceleration and deceleration described above is not complex and there is no compromise to be made. In the INI file the specified machine constraints, such as maximum axis velocity and axis acceleration, must be obeyed by the trajectory planner.

For more information on the Trajectory Planner INI options see the Trajectory Section in the INI chapter.

A less straightforward problem is that of path following. When you program a corner in G-code, the trajectory planner can do several things, all of which are right in some cases:

You can see that there is a trade off here: you can slow down to get better path following, or keep the speed up and have worse path following. Depending on the particular cut, the material, the tooling, etc., the programmer may want to compromise differently.

Rapid moves also obey the current trajectory control. With moves long enough to reach maximum velocity on a machine with low acceleration and no path tolerance specified, you can get a fairly round corner.

The trajectory control commands are as follows:

In the following figure the blue line represents the actual machine velocity. The red lines are the acceleration capability of the machine. The horizontal lines below each plot is the planned move. The upper plot shows how the trajectory planner will slow the machine down when short moves are encountered, to stay within the limits of the machines acceleration setting to be able to come to an exact stop at the end of the next move. The bottom plot shows the effect of the Naive Cam Detector to combine the moves and do a better job of keeping the velocity as planned.

Make sure moves are long enough to suit your machine/material. Principally because of the rule that the machine will never move at such a speed that it cannot come to a complete stop at the end of the current movement, there is a minimum movement length that will allow the machine to keep up a requested feed rate with a given acceleration setting.

The acceleration and deceleration phase each use half the INI file MAX_ACCELERATION. In a blend that is an exact reversal, this causes the total axis acceleration to equal the INI file MAX_ACCELERATION. In other cases, the actual machine acceleration is somewhat less than the INI file acceleration.

To keep up the feed rate, the move must be longer than the distance it takes to accelerate from 0 to the desired feed rate and then stop again. Using A as 1/2 the INI file MAX_ACCELERATION and F as the feed rate in units per second, the acceleration time is t_a = F/A and the acceleration distance is d_a = F*t_a/2. The deceleration time and distance are the same, making the critical distance d = d_a + d_d = 2 * d_a = F²/A.

For example, for a feed rate of 1 inch per second and an acceleration of 10 inches/sec², the critical distance is 1²/10 = 1/10 = 0.1 inches.

For a feed rate of 0.5 inch per second, the critical distance is 5²/100 = 25/100 = 0.025 inches.

When LinuxCNC first starts up many G- and M-codes are loaded by default. The current active G- and M-codes can be viewed on the MDI tab in the Active G-codes: window in the AXIS interface. These G- and M-codes define the behavior of LinuxCNC and it is important that you understand what each one does before running LinuxCNC. The defaults can be changed when running a G-code file and left in a different state than when you started your LinuxCNC session. The best practice is to set the defaults needed for the job in the preamble of your G-code file and not assume that the defaults have not changed. Printing out the G-code Quick Reference page can help you remember what each one is.

How the feed rate is applied depends on if an axis involved with the move is a rotary axis. Read and understand the Feed Rate section if you have a rotary axis or a lathe.

Tool Radius Offset (G41/42) requires that the tool be able to touch somewhere along each programmed move without gouging the two adjacent moves. If that is not possible with the current tool diameter you will get an error. A smaller diameter tool may run without an error on the same path. This means you can program a cutter to pass down a path that is narrower than the cutter without any errors. See the Cutter Compensation section for more information.

When you home LinuxCNC you set the G53 Machine Coordinate System to 0 for each axis homed.

No other coordinate systems or tool offsets are changed by homing.

The only time you move in the G53 machine coordinate system is when you program a G53 on the same line as a move. Normally you are in the G54 coordinate system.

Normally you use the G54 Coordinate System. When an offset is applied to a current user coordinate system, a small blue ball with lines will be at the machine origin when your DRO is displaying Position: Relative Actual in AXIS. If your offsets are temporary use the Zero Coordinate System from the Machine menu or program G10 L2 P1 X0 Y0 Z0 at the end of your G-code file. Change the P number to suit the coordinate system you wish to clear the offset in.

If you’re having trouble getting 0,0,0 on the DRO when you think you should, you may have some offsets programmed in and need to remove them.

Now you should be at the machine origin X0 Y0 Z0 and the relative coordinate system should be the same as the machine coordinate system.