grbl-LPC-CoreXY/config.h

249 lines
14 KiB
C
Raw Normal View History

/*
config.h - compile time configuration
Part of Grbl
Copyright (c) 2009-2011 Simen Svale Skogsrud
Copyright (c) 2011-2013 Sungeun K. Jeon
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/>.
*/
#ifndef config_h
#define config_h
// IMPORTANT: Any changes here requires a full re-compiling of the source code to propagate them.
// Default settings. Used when resetting EEPROM. Change to desired name in defaults.h
#define DEFAULTS_GENERIC
// Serial baud rate
#define BAUD_RATE 9600
// Define pin-assignments
// NOTE: All step bit and direction pins must be on the same port.
#define STEPPING_DDR DDRD
#define STEPPING_PORT PORTD
#define X_STEP_BIT 2 // Uno Digital Pin 2
#define Y_STEP_BIT 3 // Uno Digital Pin 3
#define Z_STEP_BIT 4 // Uno Digital Pin 4
#define X_DIRECTION_BIT 5 // Uno Digital Pin 5
#define Y_DIRECTION_BIT 6 // Uno Digital Pin 6
#define Z_DIRECTION_BIT 7 // Uno Digital Pin 7
#define STEP_MASK ((1<<X_STEP_BIT)|(1<<Y_STEP_BIT)|(1<<Z_STEP_BIT)) // All step bits
#define DIRECTION_MASK ((1<<X_DIRECTION_BIT)|(1<<Y_DIRECTION_BIT)|(1<<Z_DIRECTION_BIT)) // All direction bits
#define STEPPING_MASK (STEP_MASK | DIRECTION_MASK) // All stepping-related bits (step/direction)
#define STEPPERS_DISABLE_DDR DDRB
#define STEPPERS_DISABLE_PORT PORTB
#define STEPPERS_DISABLE_BIT 0 // Uno Digital Pin 8
#define STEPPERS_DISABLE_MASK (1<<STEPPERS_DISABLE_BIT)
// NOTE: All limit bit pins must be on the same port
#define LIMIT_DDR DDRB
#define LIMIT_PIN PINB
#define LIMIT_PORT PORTB
#define X_LIMIT_BIT 1 // Uno Digital Pin 9
#define Y_LIMIT_BIT 2 // Uno Digital Pin 10
#define Z_LIMIT_BIT 3 // Uno Digital Pin 11
#define LIMIT_INT PCIE0 // Pin change interrupt enable pin
#define LIMIT_INT_vect PCINT0_vect
#define LIMIT_PCMSK PCMSK0 // Pin change interrupt register
#define LIMIT_MASK ((1<<X_LIMIT_BIT)|(1<<Y_LIMIT_BIT)|(1<<Z_LIMIT_BIT)) // All limit bits
#define SPINDLE_ENABLE_DDR DDRB
#define SPINDLE_ENABLE_PORT PORTB
#define SPINDLE_ENABLE_BIT 4 // Uno Digital Pin 12
#define SPINDLE_DIRECTION_DDR DDRB
#define SPINDLE_DIRECTION_PORT PORTB
#define SPINDLE_DIRECTION_BIT 5 // Uno Digital Pin 13 (NOTE: D13 can't be pulled-high input due to LED.)
#define COOLANT_FLOOD_DDR DDRC
#define COOLANT_FLOOD_PORT PORTC
#define COOLANT_FLOOD_BIT 3 // Uno Analog Pin 3
// NOTE: Uno analog pins 4 and 5 are reserved for an i2c interface, and may be installed at
// a later date if flash and memory space allows.
Re-factored system states and alarm management. Serial baud support greater than 57600. - Refactored system states to be more clear and concise. Alarm locks processes when position is unknown to indicate to user something has gone wrong. - Changed mc_alarm to mc_reset, which now manages the system reset function. Centralizes it. - Renamed '$X' kill homing lock to kill alarm lock. - Created an alarm error reporting method to clear up what is an alarm: message vs a status error: message. For GUIs mainly. Alarm codes are negative. Status codes are positive. - Serial baud support upto 115200. Previous baudrate calc was unstable for 57600 and above. - Alarm state locks out all g-code blocks, including startup scripts, but allows user to access settings and internal commands. For example, to disable hard limits, if they are problematic. - Hard limits do not respond in an alarm state. - Fixed a problem with the hard limit interrupt during the homing cycle. The interrupt register is still active during the homing cycle and still signal the interrupt to trigger when re-enabled. Instead, just disabled the register. - Homing rate adjusted. All axes move at homing seek rate, regardless of how many axes move at the same time. This is unlike how the stepper module does it as a point to point rate. - New config.h settings to disable the homing rate adjustment and the force homing upon powerup. - Reduced the number of startup lines back down to 2 from 3. This discourages users from placing motion block in there, which can be very dangerous. - Startup blocks now run only after an alarm-free reset or after a homing cycle. Does not run when $X kill is called. For satefy reasons
2012-11-15 01:36:29 +01:00
// #define ENABLE_M7 // Mist coolant disabled by default. Uncomment to enable.
#ifdef ENABLE_M7
#define COOLANT_MIST_DDR DDRC
#define COOLANT_MIST_PORT PORTC
#define COOLANT_MIST_BIT 4 // Uno Analog Pin 4
#endif
// NOTE: All pinouts pins must be on the same port
#define PINOUT_DDR DDRC
#define PINOUT_PIN PINC
#define PINOUT_PORT PORTC
#define PIN_RESET 0 // Uno Analog Pin 0
#define PIN_FEED_HOLD 1 // Uno Analog Pin 1
#define PIN_CYCLE_START 2 // Uno Analog Pin 2
#define PINOUT_INT PCIE1 // Pin change interrupt enable pin
#define PINOUT_INT_vect PCINT1_vect
#define PINOUT_PCMSK PCMSK1 // Pin change interrupt register
#define PINOUT_MASK ((1<<PIN_RESET)|(1<<PIN_FEED_HOLD)|(1<<PIN_CYCLE_START))
// 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
// 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.
// NOTE: If changed, manually update help message in report.c.
#define CMD_STATUS_REPORT '?'
#define CMD_FEED_HOLD '!'
#define CMD_CYCLE_START '~'
#define CMD_RESET 0x18 // ctrl-x
// The "Stepper Driver Interrupt" employs the Pramod Ranade inverse time algorithm to manage the
// Bresenham line stepping algorithm. The value ISR_TICKS_PER_SECOND is the frequency(Hz) at which
// the Ranade algorithm ticks at. Recommended step frequencies are limited by the Ranade 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.
#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 Ranade algorithm can use either floating point or long integers for its counters, but for
// integers the counter values must be scaled since these values can be very small (10^-6). This
// multiplier value scales the floating point counter values for use in a long integer. 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 RANADE_MULTIPLIER 100000000.0
// 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)
// 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 RANADE_MULTIPLIER value
// changes, it will affect how this value works. So, if a zero is add/subtracted from the
// RANADE_MULTIPLIER value, do the same to this value if you want to same response.
// NOTE: Compute by (desired_step_rate/60) * RANADE_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
// 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)
Re-factored system states and alarm management. Serial baud support greater than 57600. - Refactored system states to be more clear and concise. Alarm locks processes when position is unknown to indicate to user something has gone wrong. - Changed mc_alarm to mc_reset, which now manages the system reset function. Centralizes it. - Renamed '$X' kill homing lock to kill alarm lock. - Created an alarm error reporting method to clear up what is an alarm: message vs a status error: message. For GUIs mainly. Alarm codes are negative. Status codes are positive. - Serial baud support upto 115200. Previous baudrate calc was unstable for 57600 and above. - Alarm state locks out all g-code blocks, including startup scripts, but allows user to access settings and internal commands. For example, to disable hard limits, if they are problematic. - Hard limits do not respond in an alarm state. - Fixed a problem with the hard limit interrupt during the homing cycle. The interrupt register is still active during the homing cycle and still signal the interrupt to trigger when re-enabled. Instead, just disabled the register. - Homing rate adjusted. All axes move at homing seek rate, regardless of how many axes move at the same time. This is unlike how the stepper module does it as a point to point rate. - New config.h settings to disable the homing rate adjustment and the force homing upon powerup. - Reduced the number of startup lines back down to 2 from 3. This discourages users from placing motion block in there, which can be very dangerous. - Startup blocks now run only after an alarm-free reset or after a homing cycle. Does not run when $X kill is called. For satefy reasons
2012-11-15 01:36:29 +01: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
// 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
// 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.
#define N_HOMING_LOCATE_CYCLE 2 // Integer (1-128)
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 18:32:23 +01: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.
Re-factored system states and alarm management. Serial baud support greater than 57600. - Refactored system states to be more clear and concise. Alarm locks processes when position is unknown to indicate to user something has gone wrong. - Changed mc_alarm to mc_reset, which now manages the system reset function. Centralizes it. - Renamed '$X' kill homing lock to kill alarm lock. - Created an alarm error reporting method to clear up what is an alarm: message vs a status error: message. For GUIs mainly. Alarm codes are negative. Status codes are positive. - Serial baud support upto 115200. Previous baudrate calc was unstable for 57600 and above. - Alarm state locks out all g-code blocks, including startup scripts, but allows user to access settings and internal commands. For example, to disable hard limits, if they are problematic. - Hard limits do not respond in an alarm state. - Fixed a problem with the hard limit interrupt during the homing cycle. The interrupt register is still active during the homing cycle and still signal the interrupt to trigger when re-enabled. Instead, just disabled the register. - Homing rate adjusted. All axes move at homing seek rate, regardless of how many axes move at the same time. This is unlike how the stepper module does it as a point to point rate. - New config.h settings to disable the homing rate adjustment and the force homing upon powerup. - Reduced the number of startup lines back down to 2 from 3. This discourages users from placing motion block in there, which can be very dangerous. - Startup blocks now run only after an alarm-free reset or after a homing cycle. Does not run when $X kill is called. For satefy reasons
2012-11-15 01:36:29 +01: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 18:32:23 +01:00
// 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
// of grbl, and should be on the order or greater than the size of the buffer to help with the
// computational efficiency of generating arcs.
#define N_ARC_CORRECTION 20 // Integer (1-255)
// ---------------------------------------------------------------------------------------
// FOR ADVANCED USERS ONLY:
// 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 Mega 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 17 // 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.
// NOTE: 50 characters is not a problem except for extreme cases, but the line buffer size
// 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.
// #define LINE_BUFFER_SIZE 70 // Uncomment to override default in protocol.h
// 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
// 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!
// #define ENABLE_XONXOFF // Default disabled. Uncomment to enable.
// ---------------------------------------------------------------------------------------
// TODO: Install compile-time option to send numeric status codes rather than strings.
#endif