Revamped homing cycle. Axis limits and max travel bug fixes. Build info. Refactored config.h.
- Revamped and improved homing cycle. Now tied directly into the main planner and stepper code, which enables much faster homing seek rates. Also dropped the compiled flash size by almost 1KB, meaning 1KB more for other features. - Refactored config.h. Removed obsolete defines and configuration options. Moved lots of “advanced” options into the advanced area of the file. - Updated defaults.h with the new homing cycle. Also updated the Sherline 5400 defaults and added the ShapeOko2 defaults per user submissions. - Fixed a bug where the individual axes limits on velocity and acceleration were not working correctly. Caused by abs() returning a int, rather than a float. Corrected with fabs(). Duh. - Added build version/date to the Grbl welcome message to help indicate which version a user is operating on. - Max travel settings were not being defaulted into the settings EEPROM correctly. Fixed. - To stop a single axis during a multi-axes homing move, the stepper algorithm now has a simple axis lock mask which inhibits the desired axes from moving. Meaning, if one of the limit switches engages before the other, we stop that one axes and keep moving the other.
This commit is contained in:
117
config.h
117
config.h
@ -29,7 +29,7 @@
|
||||
#define config_h
|
||||
|
||||
// Default settings. Used when resetting EEPROM. Change to desired name in defaults.h
|
||||
#define DEFAULTS_ZEN_TOOLWORKS_7x7
|
||||
#define DEFAULTS_SHERLINE_5400
|
||||
|
||||
// Serial baud rate
|
||||
#define BAUD_RATE 115200
|
||||
@ -49,76 +49,17 @@
|
||||
#define CMD_CYCLE_START '~'
|
||||
#define CMD_RESET 0x18 // ctrl-x
|
||||
|
||||
// The "Stepper Driver Interrupt" employs an inverse time algorithm to manage the Bresenham line
|
||||
// stepping algorithm. The value ISR_TICKS_PER_SECOND is the frequency(Hz) at which the inverse time
|
||||
// algorithm ticks at. Recommended step frequencies are limited by the inverse time frequency by
|
||||
// approximately 0.75-0.9 * ISR_TICK_PER_SECOND. Meaning for 30kHz, the max step frequency is roughly
|
||||
// 22.5-27kHz, but 30kHz is still possible, just not optimal. An Arduino can safely complete a single
|
||||
// interrupt of the current stepper driver algorithm theoretically up to a frequency of 35-40kHz, but
|
||||
// CPU overhead increases exponentially as this frequency goes up. So there will be little left for
|
||||
// other processes like arcs.
|
||||
#define ISR_TICKS_PER_SECOND 30000L // Integer (Hz)
|
||||
|
||||
// The temporal resolution of the acceleration management subsystem. Higher number give smoother
|
||||
// acceleration but may impact performance. If you run at very high feedrates (>15kHz or so) and
|
||||
// very high accelerations, this will reduce the error between how the planner plans the velocity
|
||||
// profiles and how the stepper program actually performs them. The correct value for this parameter
|
||||
// is machine dependent, so it's advised to set this only as high as needed. Approximate successful
|
||||
// values can widely range from 50 to 200 or more. Cannot be greater than ISR_TICKS_PER_SECOND/2.
|
||||
// NOTE: Ramp count variable type in stepper module may need to be updated if changed.
|
||||
#define ACCELERATION_TICKS_PER_SECOND 120L
|
||||
|
||||
// NOTE: Make sure this value is less than 256, when adjusting both dependent parameters.
|
||||
#define ISR_TICKS_PER_ACCELERATION_TICK (ISR_TICKS_PER_SECOND/ACCELERATION_TICKS_PER_SECOND)
|
||||
|
||||
// The inverse time algorithm can use either floating point or long integers for its counters (usually
|
||||
// very small values ~10^-6), but with integers, the counter values must be scaled to be greater than
|
||||
// one. This multiplier value scales the floating point counter values for use in a long integer, which
|
||||
// are significantly faster to compute with a slightly higher precision ceiling than floats. Long
|
||||
// integers are finite so select the multiplier value high enough to avoid any numerical round-off
|
||||
// issues and still have enough range to account for all motion types. However, in most all imaginable
|
||||
// CNC applications, the following multiplier value will work more than well enough. If you do have
|
||||
// happened to weird stepper motion issues, try modifying this value by adding or subtracting a
|
||||
// zero and report it to the Grbl administrators.
|
||||
#define INV_TIME_MULTIPLIER 100000
|
||||
|
||||
// Minimum stepper rate for the "Stepper Driver Interrupt". Sets the absolute minimum stepper rate
|
||||
// in the stepper program and never runs slower than this value. If the INVE_TIME_MULTIPLIER value
|
||||
// changes, it will affect how this value works. So, if a zero is add/subtracted from the
|
||||
// INV_TIME_MULTIPLIER value, do the same to this value if you want to same response.
|
||||
// NOTE: Compute by (desired_step_rate/60) * INV_TIME_MULTIPLIER/ISR_TICKS_PER_SECOND. (mm/min)
|
||||
// #define MINIMUM_STEP_RATE 1000L // Integer (mult*mm/isr_tic)
|
||||
|
||||
// Minimum stepper rate. Only used by homing at this point. May be removed in later releases.
|
||||
#define MINIMUM_STEPS_PER_MINUTE 800 // (steps/min) - Integer value only
|
||||
|
||||
// Minimum planner junction speed. Sets the default minimum junction speed the planner plans to at
|
||||
// every buffer block junction, except for starting from rest and end of the buffer, which are always
|
||||
// zero. This value controls how fast the machine moves through junctions with no regard for acceleration
|
||||
// limits or angle between neighboring block line move directions. This is useful for machines that can't
|
||||
// tolerate the tool dwelling for a split second, i.e. 3d printers or laser cutters. If used, this value
|
||||
// should not be much greater than zero or to the minimum value necessary for the machine to work.
|
||||
#define MINIMUM_JUNCTION_SPEED 0.0 // (mm/min)
|
||||
|
||||
// Time delay increments performed during a dwell. The default value is set at 50ms, which provides
|
||||
// a maximum time delay of roughly 55 minutes, more than enough for most any application. Increasing
|
||||
// this delay will increase the maximum dwell time linearly, but also reduces the responsiveness of
|
||||
// run-time command executions, like status reports, since these are performed between each dwell
|
||||
// time step. Also, keep in mind that the Arduino delay timer is not very accurate for long delays.
|
||||
#define DWELL_TIME_STEP 50 // Integer (1-255) (milliseconds)
|
||||
// Uncomment the following define if you are using hardware that drives high when your limits
|
||||
// are reached. You will need to ensure that you have appropriate pull-down resistors on the
|
||||
// limit switch input pins, or that your hardware drives the pins low when they are open (non-
|
||||
// triggered).
|
||||
// #define LIMIT_SWITCHES_ACTIVE_HIGH
|
||||
|
||||
// If homing is enabled, homing init lock sets Grbl into an alarm state upon power up. This forces
|
||||
// the user to perform the homing cycle (or override the locks) before doing anything else. This is
|
||||
// mainly a safety feature to remind the user to home, since position is unknown to Grbl.
|
||||
#define HOMING_INIT_LOCK // Comment to disable
|
||||
|
||||
// The homing cycle seek and feed rates will adjust so all axes independently move at the homing
|
||||
// seek and feed rates regardless of how many axes are in motion simultaneously. If disabled, rates
|
||||
// are point-to-point rates, as done in normal operation. For example in an XY diagonal motion, the
|
||||
// diagonal motion moves at the intended rate, but the individual axes move at 70% speed. This option
|
||||
// just moves them all at 100% speed.
|
||||
#define HOMING_RATE_ADJUST // Comment to disable
|
||||
|
||||
// Define the homing cycle search patterns with bitmasks. The homing cycle first performs a search
|
||||
// to engage the limit switches. HOMING_SEARCH_CYCLE_x are executed in order starting with suffix 0
|
||||
// and searches the enabled axes in the bitmask. This allows for users with non-standard cartesian
|
||||
@ -144,6 +85,39 @@
|
||||
// parser state depending on user preferences.
|
||||
#define N_STARTUP_LINE 2 // Integer (1-5)
|
||||
|
||||
// ---------------------------------------------------------------------------------------
|
||||
// ADVANCED CONFIGURATION OPTIONS:
|
||||
|
||||
// The "Stepper Driver Interrupt" employs an inverse time algorithm to manage the Bresenham line
|
||||
// stepping algorithm. The value ISR_TICKS_PER_SECOND is the frequency(Hz) at which the inverse time
|
||||
// algorithm ticks at. Recommended step frequencies are limited by the inverse time frequency by
|
||||
// approximately 0.75-0.9 * ISR_TICK_PER_SECOND. Meaning for 30kHz, the max step frequency is roughly
|
||||
// 22.5-27kHz, but 30kHz is still possible, just not optimal. An Arduino can safely complete a single
|
||||
// interrupt of the current stepper driver algorithm theoretically up to a frequency of 35-40kHz, but
|
||||
// CPU overhead increases exponentially as this frequency goes up. So there will be little left for
|
||||
// other processes like arcs.
|
||||
#define ISR_TICKS_PER_SECOND 30000L // Integer (Hz)
|
||||
|
||||
// The temporal resolution of the acceleration management subsystem. Higher number give smoother
|
||||
// acceleration but may impact performance. If you run at very high feedrates (>15kHz or so) and
|
||||
// very high accelerations, this will reduce the error between how the planner plans the velocity
|
||||
// profiles and how the stepper program actually performs them. The correct value for this parameter
|
||||
// is machine dependent, so it's advised to set this only as high as needed. Approximate successful
|
||||
// values can widely range from 50 to 200 or more. Cannot be greater than ISR_TICKS_PER_SECOND/2.
|
||||
// NOTE: Ramp count variable type in stepper module may need to be updated if changed.
|
||||
#define ACCELERATION_TICKS_PER_SECOND 120L
|
||||
|
||||
// NOTE: Make sure this value is less than 256, when adjusting both dependent parameters.
|
||||
#define ISR_TICKS_PER_ACCELERATION_TICK (ISR_TICKS_PER_SECOND/ACCELERATION_TICKS_PER_SECOND)
|
||||
|
||||
// Minimum planner junction speed. Sets the default minimum junction speed the planner plans to at
|
||||
// every buffer block junction, except for starting from rest and end of the buffer, which are always
|
||||
// zero. This value controls how fast the machine moves through junctions with no regard for acceleration
|
||||
// limits or angle between neighboring block line move directions. This is useful for machines that can't
|
||||
// tolerate the tool dwelling for a split second, i.e. 3d printers or laser cutters. If used, this value
|
||||
// should not be much greater than zero or to the minimum value necessary for the machine to work.
|
||||
#define MINIMUM_JUNCTION_SPEED 0.0 // (mm/min)
|
||||
|
||||
// Number of arc generation iterations by small angle approximation before exact arc trajectory
|
||||
// correction. This parameter maybe decreased if there are issues with the accuracy of the arc
|
||||
// generations. In general, the default value is more than enough for the intended CNC applications
|
||||
@ -151,8 +125,12 @@
|
||||
// computational efficiency of generating arcs.
|
||||
#define N_ARC_CORRECTION 20 // Integer (1-255)
|
||||
|
||||
// ---------------------------------------------------------------------------------------
|
||||
// FOR ADVANCED USERS ONLY:
|
||||
// Time delay increments performed during a dwell. The default value is set at 50ms, which provides
|
||||
// a maximum time delay of roughly 55 minutes, more than enough for most any application. Increasing
|
||||
// this delay will increase the maximum dwell time linearly, but also reduces the responsiveness of
|
||||
// run-time command executions, like status reports, since these are performed between each dwell
|
||||
// time step. Also, keep in mind that the Arduino delay timer is not very accurate for long delays.
|
||||
#define DWELL_TIME_STEP 50 // Integer (1-255) (milliseconds)
|
||||
|
||||
// The number of linear motions in the planner buffer to be planned at any give time. The vast
|
||||
// majority of RAM that Grbl uses is based on this buffer size. Only increase if there is extra
|
||||
@ -198,11 +176,6 @@
|
||||
// case, please report any successes to grbl administrators!
|
||||
// #define ENABLE_XONXOFF // Default disabled. Uncomment to enable.
|
||||
|
||||
// Uncomment the following define if you are using hardware that drives high when your limits
|
||||
// are reached. You will need to ensure that you have appropriate pull-down resistors on the
|
||||
// limit switch input pins, or that your hardware drives the pins low when they are open (non-
|
||||
// triggered).
|
||||
// #define LIMIT_SWITCHES_ACTIVE_HIGH
|
||||
|
||||
// ---------------------------------------------------------------------------------------
|
||||
|
||||
|
Reference in New Issue
Block a user