Tool Setup Screen - Trajectory Planner
(Click on Image to Jump to related help)
The Tool Setup Screen allows KMotionCNC to be configured for a particular machine tool. Each machine tool is likely to have different motion resolution, speeds, and acceleration limits. It is also likely to different I/O requirements with regard to Spindle control and such. Additionally a machine may have different initialization and homing requirements. KMotionCNC has a flexible mechanism for defining what type of action is to be performed for various M Codes and Custom Buttons.
KMotionCNC contains a powerful Trajectory Planner. The Trajectory Planner utilizes a "break angle" concept to decide when a stop must be made. Vectors that are in the same direction within the "break angle" are traversed without stopping. When a "sharp" angle is detected a complete stop will be made before beginning on the next vector. The Break Angle Parameter allows the user to specify the angle in degrees that will be considered a "sharp" angle. KMotionCNC considers the change in direction in 3 dimensions (x,y,z ignoring a). The Trajectory Planner is capable of optimizing the acceleration and deceleration through many short (or long) vectors all of which may have different acceleration and velocity limitations.
The Trajectory Planner also has a "lookahead" parameter. With KMotionCNC the G Code Program itself, the G Code Interpreter, and the Trajectory Planner all reside within the PC running Microsoft Windows™. Since the Microsoft Windows™ is not a real-time OS, a certain amount of motion must be buffered in the motion controller to handle the cases where the PC program doesn't have a chance to execute for a while. These time periods are typically very short (a few milliseconds), but in some extreme cases may occasionally be as long as one or several seconds. The worst case is often a factor of the hardware (disk network adapters, etc) and associated drivers that are loaded into the system. The lookahead parameter is used to determine how much motion, in terms of time, should be downloaded to the motion controller before actual motion is initiated. Furthermore, after motion has begun, the lookahead parameter is used to pause the trajectory planner to avoid having the Trajectory Planner get too far ahead of the actual motion. The disadvantage of having the Trajectory Planner get too far ahead is that if the User decides to override the feed rate, since the motion has already been planned and downloaded, the rate will not be changed quickly. A value of 3 seconds is very conservative on most systems. If more responsive feed rate override is desirable, an experiment with a smaller value might be made.
"Collinear Tolerance" allows GCode blocks that are nearly linear, to be combined into a single linear segment to allow faster and smoother motion. Often GCode programs generated by 3D CAD systems contain very small vectors that appear jagged or noisy due to numerical round off errors . See below for an example of a small GCode fragment from an intended circle. The 0.3 inch diameter circle was divided into 10,000 sides each only 0.0001 inches in length. Intuitively one would think this would result in an extremely smooth contour. Ironically, rounding off to 4 decimal digits introduces "noise" that results in sharp angles and each axis being required to repeatedly stop and start. Even with quite high acceleration, stopping and starting over short distances results in extremely low average speed and most likely a rough surface. A combined segment shown below in blue will result in a faster and smoother motion.
Segments are combined as long as all intermediate waypoints do not deviate from the combined segment by more than the allowed collinear tolerance. Setting the collinear tolerance to zero will disallow any segments from being combined.
N70 G90 G54 G0 X6.315 Y4.7132 Z1.
N100 G1 X6.3151 F60.
N110 Y4.7133
N120 X6.3152 Y4.7134
N130 Y4.7135
N140 X6.3153 Y4.7136
N150 Y4.7137
N160 X6.3154 Y4.7138
N170 X6.3155 Y4.7139
N180 Y4.714
N190 X6.3156 Y4.7141
N200 Y4.7142
N210 X6.3157 Y4.7143
N220 Y4.7144
N230 X6.3158
The "Arcs To Segments" option allows circular arcs that were specified in the original GCode to be replaced by a number of linear segments. Each arc will be recursively subdivided until any cord error deviation from the original path is less than the Collinear Tolerance parameter. Sub dividing the arc (actually a helix) into line segments allows the path motion to be more fully optimized by the Trajectory Planner. This is because as the motion progresses through the arc the direction changes. As the direction changes the different axes become involved and also work together in different ways (diagonal directions make use of more than one axis). This means constraints (max velocity and acceleration) vary throughout the arc. With individual line segments the Trajectory planner is able to use optimal acceleration and velocity throughout the arc. When Arcs To Segments is not selected the entire arc may be treated as a single entity and will use the most limited velocity and acceleration constraints throughout the arc for the entire arc. If the feed rate is slow and curvature based accelerations are small relative to the axis limits then there will be little performance increase in using segments.
When the "Arcs To Segments" Option is selected the Collinear Tolerance must be larger than zero. Care should be used in selecting a Collinear Tolerance so that an excessive number of segments is not generated. The number of segments increases as the square root of the inverse of the Collinear Tolerance (cutting the tolerance in half increase the number of segments by 40%).
For a description of the Corner Rounding feature and Corner Tolerance and Facet Angle see here.
Defines the Jog Speeds for both the Jog Buttons and any attached Gamepad controller. These speed are the maximum Jog speed which is the double arrow jog button or the GamePad joystick fully depressed. See Also Jog Buttons. The Reverse R/Z may be selected if the GamePad Z motion is reversed on a particular GamePad device.
Defines the step size distances for the Step Buttons that are displayed on the main KMotionCNC Screen. Setting a step size to zero will hide the size selection. See Also Jog Buttons.
Defines options relating to Lathe systems.
Selecting the Lathe option orients the Jog Buttons and default GViewer orientations to have +Z horizontal to the right and with X vertical as most Lathe systems are configured. The "X Positive Front" rotates the axes system (and X Jog Keys) so that the tool moves toward the front of the system as X increases. This is more suitable for cutting tools mounted on the front side of the spindle. Otherwise the tool moves toward the back as X increases. This is more suitable for read mounted tools.
X Positive Rear
X Positive Front
When Diameter Mode is selected the Gcode X Units, X Offset Units, and X DRO Units are all in terms of diameter. In this mode actual tool cutter motion is 1/2 the specified value so the the total diameter of the cut part is the specified value. When Diameter Mode is not selected, Radius mode will be used, the tool cutter motion will be the specified value, and the cut part will have a radius of the specified value in the GCode.
The Hardware Range value allows control over what part of the Feed Rate Override (FRO) Range is handled by Hardware, and what part is handled by Software (Trajectory Planner).
Hardware FRO has the advantage of having instant response, however it has a disadvantage of having accelerations distorted by time warping. Accelerations will be distorted by the square of the FRO setting. For example a FRO of 2.0 will result in accelerations 4X higher than planned. Hardware FRO can be thought of like playing a movie back in fast or slow motion. Another analogy might be a car that plans a trajectory accelerating from 0 to 60MPH in 10 seconds. Played at double time (FRO=2.0) would result in acceleration from 0 to 120MPH in 5 seconds! Similarly feed rates through tight curves will be proportionally increased by the FRO possibly resulting in excessive acceleration. Velocities are also increased proportionally by the Hardware FRO. This is obviously the normal intention, however speeds at or near the maximum possible for the system may now exceed the capabilities of the system. This also applies for Rapid (G0) motions. Any Hardware FRO value higher than 1.0 must have maximum system settings set in a manner that accelerations and velocities have sufficient margins to allow this increased acceleration and velocity.
Hardware FRO values less than 1.0 will be distorted in the opposite manner. Accelerations will be unnecessarily slow. In the previous car analogy played at slow motion (FRO=0.5) the car would accelerate from 0 to 30MPH in 20 seconds. Motions through tight curves will be proportionally slowed down regardless if a higher speed might be possible and closer to the desired feed rate. Hardware FRO values less than 1.0 will never cause a maximum acceleration or velocity limit to be exceeded.
Software FRO always provides the optimal motion without ever exceeding any system constraint. Maximum Accelerations and Velocities on all axes will always be honored. Accelerations to feed rate will always be optimized. Speeds through curves will always be optimal. However such optimized Trajectory Planning is complex and requires look ahead and results in some delayed response to changes. Reducing lookahead can minimize this delay.
The FRO Hardware Range Parameter sets the boundary FRO value where values below the setting will be handled by Hardware, and values above the setting will be handled by Software. Here are some examples:
Hardware Range = 0.0 will cause all FRO values to be handled by Software.
Hardware Range = 100.0 (a huge value) will result in all FRO values being handled by Hardware.
Hardware Range = 1.0 will cause all values less than 1.0 to be handled by Hardware and values greater than 1.0 to be handled in Software. This is the largest value that will never cause the set values of Max Acceleration or Max Velocity set in the Trajectory Planner to be exceeded.
Hardware range = 1.2 will cause all values less than 1.2 to be handled by Hardware and values greater than 1.2 to be handled in Software. This setting is useful if it is required to have minor increases (+20%) and all decreases have an instant effect. However this requires that the set values of Max Acceleration or Max Velocity set in the Trajectory Planner be set by a factor of 1/1.22 = 0.69 of the system capabilities in order to provide margin to allow for the Hardware FRO.
Hardware Range = 0.5 will cause all values less than 0.5 to be handled by Hardware, and values greater than 0.5 to be handled in Software. In most cases this will result in a similar result as Hardware Range = 0.0 (with all changes handled by Software). However in cases for example where the FRO is suddenly reduced from 1.0 to 0.25 the system will first reduce the FRO to 0.5 in Software, and then the remainder, another factor of 0.5 in Hardware. The Software effect will be delayed but the hardware effect will be instant. This provides most all of the benefits of Software FRO in the normal ranges of (ie 0.9 - 1.1) while also allowing a means of instantly slowing down.
Limits the Rapid FRO to the specified value. Rapid FRO is always performed in hardware so values Rapid FRO values greater than 1.0 will exceed the specified Velocity, Acceleration, and Jerk specified in KFLOP. Use this limit to avoid FRO values that would cause Velocities, Accelerations, or Jerks that the system would be incapable of performing. This value is commonly set to 1.0 if the parameters specified in KFLOP are set at the maximum possible. To allow FRO values greater than 1.0 the system must have sufficient margin to be able to exceed the specified parameters. Values less than 1.0 are not commonly specified.
Selects whether Rapids are performed as 3rd-order (Jerk limited) motions or 2nd order Feed Motions. Most systems will not select this option so that Rapids are performed as faster/smoother 3rd-order Jerk-Limited motions. However KFLOP performs 3rd order Rapids as a single linear interpolated multi-axis motion at the actuator level. This is fine for normal Cartesian xyz linear systems however may cause problems for highly non-linear kinematic systems as a straight line in actuator space is not likely to be a straight line in real CAD space. For example a Delta Platform is an example of a non-linear system. This may result in a rapid motion path from one point to another to be along a somewhat unpredictable curved path. In some cases this may result in an undesirable crash. Geometric Correction is also a form of nonlinearity. However Geometric correction is usually not sufficiently non-linear to cause problems unless long rapids are performed passing very close to part surfaces or features. If nonlinearity is an issue for your system, select this option and Rapids will always be performed along a straight line as they will be subdivided into small segments where proper actuator positions are calculated to keep the motion along a straight line. Regardless of whether this option is selected or not the Velocity and Acceleration will be set by the KFLOP Axis Parameters not by the current GCode Feed Rate or Trajectory Planner Settings.
Displays in the DROs the Measured Encoder Position for axes that are configured with an Input Mode other than None. When Un-checked all DROs display the commanded position.
Zero/Set Buttons near DROs allow the User to Set the DRO to Zero or a Specified Value. This is accomplished by adjusting GCode Offsets. When this option is selected then the currently selected Fixture Offset will be adjusted. When unchecked the Global G92/G52 Offset will be adjusted.
Tool Length/Offset Immediately
This option causes the KMotionCNC Drop Down Tool Selector to immediately select and apply the Tool Length (and offsets) Compensation without having to select and turn on the compensation in GCode with "HxxxxG43".
This option causes the automatic execution of an TxxxM6 operation after the Tool Table has been edited to re-select the specified Tool so the selected Tool ID, slot, offsets, image all reflect the current state of the Tool Table.
The Axis Motion Parameters define the scale, maximum feed velocities, and maximum feed accelerations for each of the six axis.
The first parameter is the axis's scale in counts/inch. For the example value of 100 shown, KMotionCNC will command the motion controller to move 100 counts for each inch of motion in the G Code Program. This value is always in counts/inch regardless of the units used in the interpreter. KMotionCNC will automatically perform any conversions.
The second parameter is the maximum allowed feed rate for the axis in inches/sec. Note that the G Code Interpreter Feed Rate is defined in inches per minute or (mm per minute) so be aware of the different time units. These are maximum feed rates for each axis. If a vector tool motion at a particular feed rate has any component velocity that exceeds the corresponding axis's maximum velocity, the feed rate for the vector will be reduced so that all axes remain at or below their maximum allowed velocity.
The third parameter is the maximum allowed acceleration for the axis in inches/sec2. The G Code Language has no provisions for specifying acceleration rates. Therefore the acceleration (and deceleration) along a vector used will always be the largest acceleration such that each axis's acceleration is at or below the specified limit.
The velocity and acceleration limits apply only to linear and circular feed motions (G1, G2, G3). Rapid motions (G0) use the settings in the motion controller (velocity, acceleration, and Jerk) to move each axis independently from one point to another (which is likely not to be a straight line). To change the speed of Rapid motions change the configuration settings in the motion controller.
Axes A,B,C sometimes are angular axes and are programmed to move angles of degrees rather than linear distances. If so select "Degrees" so that the axis moves in degrees regardless of the Inch or mm modes in GCode.
The best method for performing coordinated linear and angular combined motion is to use G93 Inverse Time Mode. This mode allows the CAD system to generate GCode that will cause the feed rate at the tool to always be at the desired feed rate based on the geometry of the system. However this requires a time (specified by its inverse) for each GCode block to be computed and included in the data stream. If Inverse TIme GCode data is not available a Radius for each Angular Axis can be specified. This allows the Trajectory planner to convert angular motion rates to linear motion rates. This assumes that the tool will remain at a relatively constant radius from the rotation axis (ie. engraving on a cylinder). Whenever Degrees is specified with a non-zero radius then the Trajectory Planner will consider the motion for that axis to be at the equivalent radius and orthogonal to all other combined motions.
As an example for the settings shown above for Axis A the maximum linear Velocity and Acceleration rates are the same as X, Y, and Z assuming a 10 inch radius about the A Axis of rotation.
57.295 deg/sec x π/180deg x 10in = 10in/sec
229.183 deg/sec2 x π/180deg x 10in = 40in/sec2
The GCode sequence shown below will perform a G1 Feed a linear distance of 10 inches in both X and A. Because the X and A axis are assumed to be orthogonal the combined distance will be assumed to be 14.1 inches total. At a feed rate of 60 ipm = 1 ips, the total Feed Time will be 14.1 sec (plus a small acceleration time).
G20
G0 X0 Y0 Z0 A0
G1 X10 A57.295 F60
M2
Spindle Speed measurement is also supported (Single Point Threading is under development). A quadrature encoder is required on the spindle. Specify the Sensor Type as 1 to enable the Spindle measurement. Configure the Axis Channel that is configured to read the encoder (Note this is not the encoder channel, rather it is the axis that has the encoder channel configured as its input). Specify the Update time, Tau, and counts/rev. See here for more information.