1  [[cha:important-user-concepts]]
  2  
  3  = Important User Concepts
  4  
  5  This chapter covers important user concepts that should be understood
  6  before attempting to run a CNC machine with g code.
  7  
  8  [[sec:trajectory-control]](((Trajectory Control)))
  9  
 10  == Trajectory Control
 11  
 12  === Trajectory Planning
 13  
 14  Trajectory planning, in general, is the means by which LinuxCNC follows the
 15  path specified by your G Code program, while still operating within the
 16  limits of your machinery.
 17  
 18  A G Code program can never be fully obeyed. For example, imagine you
 19  specify as a single-line program the following move:
 20  
 21  ----
 22  G1 X1 F10 (G1 is linear move, X1 is the destination, F10 is the speed)
 23  ----
 24  
 25  In reality, the whole move can't be made at F10, since the machine
 26  must accelerate from a stop, move toward X=1, and then decelerate to
 27  stop again. Sometimes part of the move is done at F10, but for many
 28  moves, especially short ones, the specified feed rate is never reached
 29  at all. Having short moves in your G Code can cause your machine to
 30  slow down and speed up for the longer moves if the 'naive cam detector'
 31  is not employed with G64 Pn.
 32  
 33  The basic acceleration and deceleration described above is not complex
 34  and there is no compromise to be made. In the INI file the specified
 35  machine constraints such as maximum axis velocity and axis acceleration
 36  must be obeyed by the trajectory planner.
 37  
 38  For more information on the Trajectory Panner ini options see the
 39  <<sec:traj-section, Trajectory Section>> in the INI chapter.
 40  
 41  === Path Following
 42  
 43  A less straightforward problem is that of path following. When you
 44  program a corner in G Code, the trajectory planner can do several
 45  things, all of which are right in some cases: it can decelerate to a
 46  stop exactly at the coordinates of the corner, and then accelerate in
 47  the new direction. It can also do what is called blending, which is to
 48  keep the feed rate up while going through the corner, making it
 49  necessary to round the corner off in order to obey machine constraints.
 50  You can see that there is a trade off here: you can slow down to get
 51  better path following, or keep the speed up and have worse path
 52  following. Depending on the particular cut, the material, the tooling,
 53  etc., the programmer may want to compromise differently.
 54  
 55  Rapid moves also obey the current trajectory control. With moves long
 56  enough to reach maximum velocity on a machine with low acceleration and
 57  no path tolerance specified, you can get a fairly round corner.
 58  
 59  === Programming the Planner(((Programming the Planner)))
 60  
 61  The trajectory control commands are as follows:
 62  
 63  * 'G61' - (Exact Path Mode) visits the programmed point exactly, even though
 64      that means it might temporarily come to a complete stop in order to
 65      change direction to the next programmed point. 
 66  
 67  * 'G61.1' - (Exact Stop Mode) tells the planner to come to an exact stop at every
 68      segment's end. 
 69  
 70  * 'G64' - (Blend Without Tolerance Mode) G64 is the default setting when you
 71      start LinuxCNC. G64 is just blending and the naive cam detector is not
 72      enabled. G64 and G64 P0 tell the planner to sacrifice path following
 73      accuracy in order to keep the feed rate up. This is necessary for some
 74      types of material or tooling where exact stops are harmful, and can
 75      work great as long as the programmer is careful to keep in mind that
 76      the tool's path will be somewhat more curvy than the program specifies.
 77      When using G0 (rapid) moves with G64 use caution on clearance moves and
 78      allow enough distance to clear obstacles based on the acceleration
 79      capabilities of your machine.
 80  
 81  * 'G64 P- Q-' - (Blend With Tolerance Mode) This enables the 'naive cam detector' and
 82      enables blending with a tolerance. If you program G64 P0.05, you tell
 83      the planner that you want continuous feed, but at programmed corners
 84      you want it to slow down enough so that the tool path can stay within
 85      0.05 user units of the programmed path. The exact amount of slowdown
 86      depends on the geometry of the programmed corner and the machine
 87      constraints, but the only thing the programmer needs to worry about is
 88      the tolerance. This gives the programmer complete control over the path
 89      following compromise. The blend tolerance can be changed throughout the
 90      program as necessary. Beware that a specification of G64 P0 has the
 91      same effect as G64 alone (above), which is necessary for backward
 92      compatibility for old G Code programs. See the <<gcode:g64,G64 section>>
 93      of the G code chapter.
 94  
 95  * 'Blending without tolerance' - The controlled point will touch each specified
 96      movement at at least one point. The machine will never move at such a speed
 97      that it cannot come to an exact stop at the end of the current movement (or
 98      next movement, if you pause when blending has already started). The
 99      distance from the end point of the move is as large as it needs to be to
100      keep up the best contouring feed.
101  
102  * 'Naive Cam Detector' - Successive G1 moves that involve only the XYZ axes
103      that deviate less than Q- from a straight line are merged into a single
104      straight line. This merged movement replaces the individual G1 movements
105      for the purposes of blending with tolerance. Between successive movements,
106      the controlled point will pass no more than P- from the actual endpoints of
107      the movements. The controlled point will touch at least one point on
108      each movement. The machine will never move at such a speed that it
109      cannot come to an exact stop at the end of the current movement (or
110      next movement, if you pause when blending has already started) On G2/3
111      moves in the G17 (XY) plane when the maximum deviation of an arc from a
112      straight line is less than the G64 Q- tolerance the arc is broken into
113      two lines (from start of arc to midpoint, and from midpoint to end).
114      those lines are then subject to the naive cam algorithm for lines.
115      Thus, line-arc, arc-arc, and arc-line cases as well as line-line
116      benefit from the 'naive cam detector'. This improves contouring
117      performance by simplifying the path. 
118  
119  In the following figure the blue line represents the actual machine
120  velocity. The red lines are the acceleration capability of the machine.
121  The horizontal lines below each plot is the planned move. The upper
122  plot shows how the trajectory planner will slow the machine down when
123  short moves are encountered to stay within the limits of the machines
124  acceleration setting to be able to come to an exact stop at the end of
125  the next move. The bottom plot shows the effect of the Naive Cam
126  Detector to combine the moves and do a better job of keeping the
127  velocity as planned.
128  
129  .Naive Cam Detector
130  
131  image::images/naive-cam.png[align="center", alt="Naive Cam Detector"]
132  
133  === Planning Moves
134  
135  Make sure moves are 'long enough' to suit your machine/material.
136  Principally because of the rule that the machine will never move at
137  such a speed that it cannot come to a complete stop at the end of the
138  current movement, there is a minimum movement length that will allow
139  the machine to keep up a requested feed rate with a given acceleration
140  setting.
141  
142  The acceleration and deceleration phase each use half the ini file
143  MAX_ACCELERATION. In a blend that is an exact reversal, this causes the
144  total axis acceleration to equal the ini file MAX_ACCELERATION. In
145  other cases, the actual machine acceleration is somewhat less than the
146  ini file acceleration
147  
148  //// This is a duplicate paragraph to the one below without latexmath.////
149  
150  To keep up the feed rate, the move must be longer than the distance it
151  takes to accelerate from 0 to the desired feed rate and then stop
152  again. Using A as *1/2* the ini file MAX_ACCELERATION 
153  and F as the feed rate *in units per second*, the acceleration time is 
154  *t~a~ = F/A* and the acceleration distance is 
155  *d~a~ = F*t~a~/2*. The deceleration time 
156  and distance are the same, making the critical distance 
157  *d = d~a~ + d~d~ = 2 * d~a~ = F^2^/A*. 
158  
159  For example, for a feed rate of 1 inch per second and an acceleration of
160  *10 inches/sec^2^*, the critical distance is 
161  *1^2^/10 = 1/10 = 0.1 inches*.
162  
163  For a feed rate of 0.5 inch per second, the critical distance is 
164  *5^2^/100 = 25/100 = 0.025* inches.
165  
166  ////
167  This section has been commented out until latexmath is working again.
168  
169  To keep up the feed rate, the move must be longer than the distance it
170  takes to accelerate from 0 to the desired feed rate and then stop
171  again. Using A as latexmath:[$\frac{1}{2}$] the ini file MAX_ACCELERATION 
172  and F as the feed rate *in units per second*, the acceleration time is 
173  latexmath:[$ ta = \frac{F}{A} $] and the acceleration distance is 
174  latexmath:[$ da = \frac{1}{2} \times F \times ta $]. The deceleration time 
175  and distance are the same, making the critical distance 
176  latexmath:[$ d = da + dd = 2 \times da = \frac{F^{2}}{A} $]. 
177  
178  For example, for a feed rate of 1 inch per second and an acceleration of 
179  latexmath:[$ 10 \frac{inch}{sec^{2}} $], the critical distance is 
180  latexmath:[$\frac{1^{2}}{10} = \frac{1}{10} = 0.1$] inch. 
181  For a feed rate of 0.5 inch per second, the critical distance is 
182  latexmath:[$ \frac{0.5^{2}}{10} = \frac{0.25}{10} = 0.025$] inch.
183  ////
184  
185  == G Code
186  
187  === Defaults
188  
189  When LinuxCNC first starts up many G and M codes are loaded by default. The
190  current active G and M codes can be viewed on the MDI tab in the
191  'Active G-Codes:' window in the AXIS interface. These G and M codes
192  define the behavior of LinuxCNC and it is important that you understand what
193  each one does before running LinuxCNC. The defaults can be changed when
194  running a G-Code file and left in a different state than when you
195  started your LinuxCNC session. The best practice is to set the defaults
196  needed for the job in the preamble of your G-Code file and not assume
197  that the defaults have not changed. Printing out the G-Code
198  <<gcode:quick-reference-table,Quick Reference>> page can help you remember
199  what each one is.
200  
201  === Feed Rate
202  
203  How the feed rate is applied depends on if an axis involved with the
204  move is a rotary axis. Read and understand the <<sub:feed-rate,Feed Rate>>
205  section if you have a rotary axis or a lathe.
206  
207  === Tool Radius Offset
208  
209  Tool Radius Offset (G41/42) requires that the tool be able to touch
210  somewhere along each programmed move without gouging the two adjacent
211  moves. If that is not possible with the current tool diameter you will
212  get an error. A smaller diameter tool may run without an error on the
213  same path. This means you can program a cutter to pass down a path that
214  is narrower than the cutter without any errors. See the 
215  <<sec:cutter-compensation,Cutter Compensation>> Section
216  for more information.
217  
218  == Homing
219  
220  After starting LinuxCNC each axis must be homed prior to running a program
221  or running a MDI command. 
222  
223  If your machine does not have home switches a match mark on each axis
224  can aid in homing the machine coordinates to the same place each time.
225  
226  Once homed your soft limits that are set in the ini file will be used.
227  
228  If you want to deviate from the default behavior, or want to use the
229  Mini interface you will need to set the option NO_FORCE_HOMING = 1 in
230  the [TRAJ] section of your ini file. More information on homing can be
231  found in the Integrator Manual.
232  
233  == Tool Changes
234  
235  There are several options when doing manual tool changes. See the
236  <<sec:emcio-section,[EMCIO] section>> for information on configuration
237  of these options. Also see the <<gcode:g28-g28.1,G28>> and <<gcode:g30-g30.1,G30>>
238  section of the G code chapter.
239  
240  == Coordinate Systems
241  
242  The Coordinate Systems can be confusing at first. Before running a CNC
243  machine you must understand the basics of the coordinate systems used
244  by LinuxCNC. In depth information on the LinuxCNC Coordinate Systems
245  is in the <<cha:coordinate-system,Coordinate System>> Section of this
246  manual.
247  
248  === G53 Machine Coordinate
249  
250  When you home LinuxCNC you set the G53 Machine Coordinate System to 0 for
251  each axis homed.
252  
253   - No other coordinate systems or tool offsets are changed by homing. 
254  
255  The only time you move in the G53 machine coordinate system is when
256  you program a G53 on the same line as a move. Normally you are in the
257  G54 coordinate system.
258  
259  === G54-59.3 User Coordinates
260  
261  Normally you use the G54 Coordinate System. When an offset is applied to a
262  current user coordinate system a small blue ball with lines will be at the
263  <<sec.machine-corrdinate-system, machine origin>> when your DRO is displaying
264  'Position: Relative Actual' in Axis. If your offsets are temporary use the Zero
265  Coordinate System from the Machine menu or program 'G10 L2 P1 X0 Y0 Z0'
266  at the end of your G Code file. Change the 'P' number to suit the
267  coordinate system you wish to clear the offset in.
268  
269   -  Offsets stored in a user coordinate system are retained when LinuxCNC is
270     shut down.
271   -  Using the 'Touch Off' button in Axis sets an offset for the chosen
272     User Coordinate System.
273  
274  === When You Are Lost
275  
276  If you're having trouble getting 0,0,0 on the DRO when you think you
277  should, you may have some offsets programmed in and need to remove
278  them.
279  
280   - Move to the Machine origin with G53 G0 X0 Y0 Z0
281   - Clear any G92 offset with G92.1
282   - Use the G54 coordinate system with G54
283   - Set the G54 coordinate system to be the same as the 
284     machine coordinate system with G10 L2 P1 X0 Y0 Z0 R0
285   - Turn off tool offsets with G49
286   - Turn on the Relative Coordinate Display from the menu
287  
288  Now you should be at the machine origin X0 Y0 Z0 and the relative
289  coordinate system should be the same as the machine coordinate system.
290  
291  == Machine Configurations
292  
293  The following diagram shows a typical mill showing direction of travel
294  of the tool and the mill table and limit switches. Notice how the mill table
295  moves in the opposite direction of the Cartesian coordinate system arrows
296  shown by the 'Tool Direction' image. This makes the 'tool' move in the
297  correct direction in relation to the material.
298  
299  .Mill Configuration
300  image::images/mill-diagram_en.svg[align="center", alt="Mill Configuration"]
301  
302  The following diagram shows a typical lathe showing direction of travel
303  of the tool and limit switches.
304  
305  .Lathe Configuration
306  image::images/lathe-diagram_en.svg[align="center", alt="Lathe Configuration"]
307  
308  // vim: set syntax=asciidoc: