2011-02-04 23:55:37 +00:00
|
|
|
/*
|
|
|
|
config.h - compile time configuration
|
|
|
|
Part of Grbl
|
|
|
|
|
2013-08-19 21:07:47 +00:00
|
|
|
Copyright (c) 2011-2013 Sungeun K. Jeon
|
2011-02-04 23:55:37 +00:00
|
|
|
Copyright (c) 2009-2011 Simen Svale Skogsrud
|
|
|
|
|
|
|
|
Grbl is free software: you can redistribute it and/or modify
|
|
|
|
it under the terms of the GNU General Public License as published by
|
|
|
|
the Free Software Foundation, either version 3 of the License, or
|
|
|
|
(at your option) any later version.
|
|
|
|
|
|
|
|
Grbl is distributed in the hope that it will be useful,
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
GNU General Public License for more details.
|
|
|
|
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
|
|
along with Grbl. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2013-08-19 21:07:47 +00:00
|
|
|
// This file contains compile-time configurations for Grbl's internal system. For the most part,
|
|
|
|
// users will not need to directly modify these, but they are here for specific needs, i.e.
|
|
|
|
// performance tuning or adjusting to non-typical machines.
|
2011-02-04 23:55:37 +00:00
|
|
|
|
2011-09-24 13:46:41 +00:00
|
|
|
// IMPORTANT: Any changes here requires a full re-compiling of the source code to propagate them.
|
|
|
|
|
2013-08-19 21:07:47 +00:00
|
|
|
#ifndef config_h
|
|
|
|
#define config_h
|
|
|
|
|
2012-11-19 02:52:16 +00:00
|
|
|
// Default settings. Used when resetting EEPROM. Change to desired name in defaults.h
|
|
|
|
#define DEFAULTS_GENERIC
|
|
|
|
|
|
|
|
// Serial baud rate
|
2011-02-04 23:55:37 +00:00
|
|
|
#define BAUD_RATE 9600
|
|
|
|
|
2013-08-19 21:07:47 +00:00
|
|
|
// Default pin mappings. Grbl officially supports the Arduino Uno only. Other processor types
|
|
|
|
// may exist from user-supplied templates or directly user-defined in pin_map.h
|
2013-08-21 02:05:16 +00:00
|
|
|
#define PIN_MAP_ARDUINO_UNO
|
2012-11-04 17:48:57 +00:00
|
|
|
|
2011-12-09 01:47:48 +00:00
|
|
|
// Define runtime command special characters. These characters are 'picked-off' directly from the
|
|
|
|
// serial read data stream and are not passed to the grbl line execution parser. Select characters
|
|
|
|
// that do not and must not exist in the streamed g-code program. ASCII control characters may be
|
2012-01-06 17:10:41 +00:00
|
|
|
// used, if they are available per user setup. Also, extended ASCII codes (>127), which are never in
|
|
|
|
// g-code programs, maybe selected for interface programs.
|
2012-11-16 04:53:11 +00:00
|
|
|
// NOTE: If changed, manually update help message in report.c.
|
2011-12-09 01:47:48 +00:00
|
|
|
#define CMD_STATUS_REPORT '?'
|
|
|
|
#define CMD_FEED_HOLD '!'
|
|
|
|
#define CMD_CYCLE_START '~'
|
|
|
|
#define CMD_RESET 0x18 // ctrl-x
|
|
|
|
|
2011-09-29 22:25:48 +00:00
|
|
|
// The temporal resolution of the acceleration management subsystem. Higher number give smoother
|
|
|
|
// acceleration but may impact performance.
|
2011-09-24 13:46:41 +00:00
|
|
|
// NOTE: Increasing this parameter will help any resolution related issues, especially with machines
|
|
|
|
// requiring very high accelerations and/or very fast feedrates. In general, this will reduce the
|
|
|
|
// error between how the planner plans the motions and how the stepper program actually performs them.
|
|
|
|
// However, at some point, the resolution can be high enough, where the errors related to numerical
|
|
|
|
// round-off can be great enough to cause problems and/or it's too fast for the Arduino. 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 range from 30L to 100L or more.
|
2012-11-09 02:23:47 +00:00
|
|
|
#define ACCELERATION_TICKS_PER_SECOND 50L
|
2011-09-24 13:46:41 +00:00
|
|
|
|
|
|
|
// Minimum planner junction speed. Sets the default minimum speed the planner plans for at the end
|
|
|
|
// of the buffer and all stops. This should not be much greater than zero and should only be changed
|
|
|
|
// if unwanted behavior is observed on a user's machine when running at very slow speeds.
|
|
|
|
#define MINIMUM_PLANNER_SPEED 0.0 // (mm/min)
|
|
|
|
|
2011-10-07 05:14:21 +00:00
|
|
|
// Minimum stepper rate. Sets the absolute minimum stepper rate in the stepper program and never runs
|
2011-09-24 13:46:41 +00:00
|
|
|
// slower than this value, except when sleeping. This parameter overrides the minimum planner speed.
|
|
|
|
// This is primarily used to guarantee that the end of a movement is always reached and not stop to
|
|
|
|
// never reach its target. This parameter should always be greater than zero.
|
|
|
|
#define MINIMUM_STEPS_PER_MINUTE 800 // (steps/min) - Integer value only
|
|
|
|
|
2011-12-09 01:47:48 +00:00
|
|
|
// 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.
|
2012-01-16 01:25:12 +00:00
|
|
|
#define DWELL_TIME_STEP 50 // Integer (1-255) (milliseconds)
|
2011-02-04 23:55:37 +00:00
|
|
|
|
2012-11-15 00:36:29 +00:00
|
|
|
// 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
|
|
|
|
|
2012-11-19 02:52:16 +00:00
|
|
|
// 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
|
|
|
|
// machines, such as a lathe (x then z), to configure the homing cycle behavior to their needs.
|
|
|
|
// Search cycle 0 is required, but cycles 1 and 2 are both optional and may be commented to disable.
|
|
|
|
// After the search cycle, homing then performs a series of locating about the limit switches to hone
|
|
|
|
// in on machine zero, followed by a pull-off maneuver. HOMING_LOCATE_CYCLE governs these final moves,
|
|
|
|
// and this mask must contain all axes in the search.
|
|
|
|
// NOTE: Later versions may have this installed in settings.
|
|
|
|
#define HOMING_SEARCH_CYCLE_0 (1<<Z_AXIS) // First move Z to clear workspace.
|
|
|
|
#define HOMING_SEARCH_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // Then move X,Y at the same time.
|
|
|
|
// #define HOMING_SEARCH_CYCLE_2 // Uncomment and add axes mask to enable
|
|
|
|
#define HOMING_LOCATE_CYCLE ((1<<X_AXIS)|(1<<Y_AXIS)|(1<<Z_AXIS)) // Must contain ALL search axes
|
|
|
|
|
2012-10-10 04:01:10 +00:00
|
|
|
// Number of homing cycles performed after when the machine initially jogs to limit switches.
|
|
|
|
// This help in preventing overshoot and should improve repeatability. This value should be one or
|
|
|
|
// greater.
|
2012-11-19 02:52:16 +00:00
|
|
|
#define N_HOMING_LOCATE_CYCLE 2 // Integer (1-128)
|
2012-10-10 04:01:10 +00:00
|
|
|
|
New startup script setting. New dry run, check gcode switches. New system state variable. Lots of reorganizing.
(All v0.8 features installed. Still likely buggy, but now thourough
testing will need to start to squash them all. As soon as we're done,
this will be pushed to master and v0.9 development will be started.
Please report ANY issues to us so we can get this rolled out ASAP.)
- User startup script! A user can now save one (up to 5 as compile-time
option) block of g-code in EEPROM memory. This will be run everytime
Grbl resets. Mainly to be used as a way to set your preferences, like
G21, G54, etc.
- New dry run and check g-code switches. Dry run moves ALL motions at
rapids rate ignoring spindle, coolant, and dwell commands. For rapid
physical proofing of your code. The check g-code switch ignores all
motion and provides the user a way to check if there are any errors in
their program that Grbl may not like.
- Program restart! (sort of). Program restart is typically an advanced
feature that allows users to restart a program mid-stream. The check
g-code switch can perform this feature by enabling the switch at the
start of the program, and disabling it at the desired point with some
minimal changes.
- New system state variable. This state variable tracks all of the
different state processes that Grbl performs, i.e. cycle start, feed
hold, homing, etc. This is mainly for making managing of these task
easier and more clear.
- Position lost state variable. Only when homing is enabled, Grbl will
refuse to move until homing is completed and position is known. This is
mainly for safety. Otherwise, it will let users fend for themselves.
- Moved the default settings defines into config.h. The plan is to
eventually create a set of config.h's for particular as-built machines
to help users from doing it themselves.
- Moved around misc defines into .h files. And lots of other little
things.
2012-11-03 17:32:23 +00:00
|
|
|
// Number of blocks Grbl executes upon startup. These blocks are stored in EEPROM, where the size
|
|
|
|
// and addresses are defined in settings.h. With the current settings, up to 5 startup blocks may
|
|
|
|
// be stored and executed in order. These startup blocks would typically be used to set the g-code
|
|
|
|
// parser state depending on user preferences.
|
2012-11-15 00:36:29 +00:00
|
|
|
#define N_STARTUP_LINE 2 // Integer (1-5)
|
New startup script setting. New dry run, check gcode switches. New system state variable. Lots of reorganizing.
(All v0.8 features installed. Still likely buggy, but now thourough
testing will need to start to squash them all. As soon as we're done,
this will be pushed to master and v0.9 development will be started.
Please report ANY issues to us so we can get this rolled out ASAP.)
- User startup script! A user can now save one (up to 5 as compile-time
option) block of g-code in EEPROM memory. This will be run everytime
Grbl resets. Mainly to be used as a way to set your preferences, like
G21, G54, etc.
- New dry run and check g-code switches. Dry run moves ALL motions at
rapids rate ignoring spindle, coolant, and dwell commands. For rapid
physical proofing of your code. The check g-code switch ignores all
motion and provides the user a way to check if there are any errors in
their program that Grbl may not like.
- Program restart! (sort of). Program restart is typically an advanced
feature that allows users to restart a program mid-stream. The check
g-code switch can perform this feature by enabling the switch at the
start of the program, and disabling it at the desired point with some
minimal changes.
- New system state variable. This state variable tracks all of the
different state processes that Grbl performs, i.e. cycle start, feed
hold, homing, etc. This is mainly for making managing of these task
easier and more clear.
- Position lost state variable. Only when homing is enabled, Grbl will
refuse to move until homing is completed and position is known. This is
mainly for safety. Otherwise, it will let users fend for themselves.
- Moved the default settings defines into config.h. The plan is to
eventually create a set of config.h's for particular as-built machines
to help users from doing it themselves.
- Moved around misc defines into .h files. And lots of other little
things.
2012-11-03 17:32:23 +00:00
|
|
|
|
2012-06-27 03:48:42 +00:00
|
|
|
// ---------------------------------------------------------------------------------------
|
|
|
|
// FOR ADVANCED USERS ONLY:
|
|
|
|
|
2012-11-09 02:23:47 +00:00
|
|
|
// 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
|
|
|
|
// available RAM, like when re-compiling for a Teensy or Sanguino. Or decrease if the Arduino
|
|
|
|
// begins to crash due to the lack of available RAM or if the CPU is having trouble keeping
|
|
|
|
// up with planning new incoming motions as they are executed.
|
|
|
|
// #define BLOCK_BUFFER_SIZE 18 // Uncomment to override default in planner.h.
|
|
|
|
|
|
|
|
// Line buffer size from the serial input stream to be executed. Also, governs the size of
|
|
|
|
// each of the startup blocks, as they are each stored as a string of this size. Make sure
|
|
|
|
// to account for the available EEPROM at the defined memory address in settings.h and for
|
|
|
|
// the number of desired startup blocks.
|
2013-04-05 15:29:07 +00:00
|
|
|
// NOTE: 70 characters is not a problem except for extreme cases, but the line buffer size
|
2012-11-09 02:23:47 +00:00
|
|
|
// can be too small and g-code blocks can get truncated. Officially, the g-code standards
|
|
|
|
// support up to 256 characters. In future versions, this default will be increased, when
|
|
|
|
// we know how much extra memory space we can re-invest into this.
|
2013-04-05 15:29:07 +00:00
|
|
|
// #define LINE_BUFFER_SIZE 70 // Uncomment to override default in protocol.h
|
2012-11-09 02:23:47 +00:00
|
|
|
|
|
|
|
// Serial send and receive buffer size. The receive buffer is often used as another streaming
|
|
|
|
// buffer to store incoming blocks to be processed by Grbl when its ready. Most streaming
|
|
|
|
// interfaces will character count and track each block send to each block response. So,
|
|
|
|
// increase the receive buffer if a deeper receive buffer is needed for streaming and avaiable
|
|
|
|
// memory allows. The send buffer primarily handles messages in Grbl. Only increase if large
|
|
|
|
// messages are sent and Grbl begins to stall, waiting to send the rest of the message.
|
|
|
|
// #define RX_BUFFER_SIZE 128 // Uncomment to override defaults in serial.h
|
|
|
|
// #define TX_BUFFER_SIZE 64
|
|
|
|
|
2012-06-27 03:48:42 +00:00
|
|
|
// Toggles XON/XOFF software flow control for serial communications. Not officially supported
|
|
|
|
// due to problems involving the Atmega8U2 USB-to-serial chips on current Arduinos. The firmware
|
|
|
|
// on these chips do not support XON/XOFF flow control characters and the intermediate buffer
|
|
|
|
// in the chips cause latency and overflow problems with standard terminal programs. However,
|
|
|
|
// using specifically-programmed UI's to manage this latency problem has been confirmed to work.
|
|
|
|
// As well as, older FTDI FT232RL-based Arduinos(Duemilanove) are known to work with standard
|
|
|
|
// terminal programs since their firmware correctly manage these XON/XOFF characters. In any
|
|
|
|
// case, please report any successes to grbl administrators!
|
2012-09-21 23:55:02 +00:00
|
|
|
// #define ENABLE_XONXOFF // Default disabled. Uncomment to enable.
|
2012-01-06 17:10:41 +00:00
|
|
|
|
2012-06-27 03:48:42 +00:00
|
|
|
// Creates a delay between the direction pin setting and corresponding step pulse by creating
|
|
|
|
// another interrupt (Timer2 compare) to manage it. The main Grbl interrupt (Timer1 compare)
|
|
|
|
// sets the direction pins, and does not immediately set the stepper pins, as it would in
|
|
|
|
// normal operation. The Timer2 compare fires next to set the stepper pins after the step
|
|
|
|
// pulse delay time, and Timer2 overflow will complete the step pulse, except now delayed
|
|
|
|
// by the step pulse time plus the step pulse delay. (Thanks langwadt for the idea!)
|
|
|
|
// This is an experimental feature that should only be used if your setup requires a longer
|
|
|
|
// delay between direction and step pin settings (some opto coupler based drivers), as it may
|
|
|
|
// adversely effect Grbl's high-end performance (>10kHz). Please notify Grbl administrators
|
|
|
|
// of your successes or difficulties, as we will monitor this and possibly integrate this as a
|
|
|
|
// standard feature for future releases. However, we suggest to first try our direction delay
|
|
|
|
// hack/solution posted in the Wiki involving inverting the stepper pin mask.
|
2012-10-21 22:55:59 +00:00
|
|
|
// NOTE: Uncomment to enable. The recommended delay must be > 3us and the total step pulse
|
|
|
|
// time, which includes the Grbl settings pulse microseconds, must not exceed 127us. Reported
|
|
|
|
// successful values for certain setups have ranged from 10 to 20us.
|
|
|
|
// #define STEP_PULSE_DELAY 10 // Step pulse delay in microseconds. Default disabled.
|
2012-06-27 03:48:42 +00:00
|
|
|
|
2013-11-23 02:12:29 +00:00
|
|
|
// 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
|
|
|
|
|
2012-06-27 03:48:42 +00:00
|
|
|
// ---------------------------------------------------------------------------------------
|
2012-01-06 17:10:41 +00:00
|
|
|
|
2012-11-01 15:37:27 +00:00
|
|
|
// TODO: Install compile-time option to send numeric status codes rather than strings.
|
2012-03-10 19:34:09 +00:00
|
|
|
|
2011-12-09 01:47:48 +00:00
|
|
|
#endif
|