2009-01-28 23:48:21 +01:00
|
|
|
/*
|
2011-01-14 16:45:18 +01:00
|
|
|
stepper.c - stepper motor driver: executes motion plans using stepper motors
|
2009-01-28 23:48:21 +01:00
|
|
|
Part of Grbl
|
|
|
|
|
2013-12-31 06:02:05 +01:00
|
|
|
Copyright (c) 2011-2014 Sungeun K. Jeon
|
2012-12-08 23:00:58 +01:00
|
|
|
Copyright (c) 2009-2011 Simen Svale Skogsrud
|
2011-09-24 15:46:41 +02:00
|
|
|
|
2009-01-28 23:48:21 +01:00
|
|
|
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/>.
|
|
|
|
*/
|
|
|
|
|
2014-01-11 04:22:10 +01:00
|
|
|
#include "system.h"
|
|
|
|
#include "nuts_bolts.h"
|
2009-01-28 23:48:21 +01:00
|
|
|
#include "stepper.h"
|
2011-02-05 00:45:41 +01:00
|
|
|
#include "settings.h"
|
2011-02-11 00:34:53 +01:00
|
|
|
#include "planner.h"
|
2011-01-31 23:04:39 +01:00
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
|
2013-12-11 06:33:06 +01:00
|
|
|
// Some useful constants.
|
2014-02-09 18:46:34 +01:00
|
|
|
#define DT_SEGMENT (1.0/(ACCELERATION_TICKS_PER_SECOND*60.0)) // min/segment
|
|
|
|
#define REQ_MM_INCREMENT_SCALAR 1.25
|
2013-11-23 01:35:58 +01:00
|
|
|
#define RAMP_ACCEL 0
|
|
|
|
#define RAMP_CRUISE 1
|
2013-10-30 02:10:39 +01:00
|
|
|
#define RAMP_DECEL 2
|
|
|
|
|
2014-02-09 18:46:34 +01:00
|
|
|
// Define Adaptive Multi-Axis Step-Smoothing(AMASS) levels and cutoff frequencies. The highest level
|
|
|
|
// frequency bin starts at 0Hz and ends at its cutoff frequency. The next lower level frequency bin
|
|
|
|
// starts at the next higher cutoff frequency, and so on. The cutoff frequencies for each level must
|
|
|
|
// be considered carefully against how much it over-drives the stepper ISR, the accuracy of the 16-bit
|
|
|
|
// timer, and the CPU overhead. Level 0 (no AMASS, normal operation) frequency bin starts at the
|
|
|
|
// Level 1 cutoff frequency and up to as fast as the CPU allows (over 30kHz in limited testing).
|
|
|
|
// NOTE: AMASS cutoff frequency multiplied by ISR overdrive factor must not exceed maximum step frequency.
|
2014-01-05 19:54:59 +01:00
|
|
|
// NOTE: Current settings are set to overdrive the ISR to no more than 16kHz, balancing CPU overhead
|
|
|
|
// and timer accuracy. Do not alter these settings unless you know what you are doing.
|
2013-12-31 02:44:46 +01:00
|
|
|
#define MAX_AMASS_LEVEL 3
|
2014-01-11 04:22:10 +01:00
|
|
|
// AMASS_LEVEL0: Normal operation. No AMASS. No upper cutoff frequency. Starts at LEVEL1 cutoff frequency.
|
2014-01-05 19:54:59 +01:00
|
|
|
#define AMASS_LEVEL1 (F_CPU/8000) // Over-drives ISR (x2). Defined as F_CPU/(Cutoff frequency in Hz)
|
|
|
|
#define AMASS_LEVEL2 (F_CPU/4000) // Over-drives ISR (x4)
|
|
|
|
#define AMASS_LEVEL3 (F_CPU/2000) // Over-drives ISR (x8)
|
2013-12-31 02:44:46 +01:00
|
|
|
|
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Stores the planner block Bresenham algorithm execution data for the segments in the segment
|
|
|
|
// buffer. Normally, this buffer is partially in-use, but, for the worst case scenario, it will
|
|
|
|
// never exceed the number of accessible stepper buffer segments (SEGMENT_BUFFER_SIZE-1).
|
|
|
|
// NOTE: This data is copied from the prepped planner blocks so that the planner blocks may be
|
2014-01-05 19:54:59 +01:00
|
|
|
// discarded when entirely consumed and completed by the segment buffer. Also, AMASS alters this
|
|
|
|
// data for its own use.
|
2013-11-23 01:35:58 +01:00
|
|
|
typedef struct {
|
|
|
|
uint8_t direction_bits;
|
2013-12-30 04:34:51 +01:00
|
|
|
uint32_t steps[N_AXIS];
|
|
|
|
uint32_t step_event_count;
|
2013-11-23 01:35:58 +01:00
|
|
|
} st_block_t;
|
|
|
|
static st_block_t st_block_buffer[SEGMENT_BUFFER_SIZE-1];
|
|
|
|
|
|
|
|
// Primary stepper segment ring buffer. Contains small, short line segments for the stepper
|
|
|
|
// algorithm to execute, which are "checked-out" incrementally from the first block in the
|
|
|
|
// planner buffer. Once "checked-out", the steps in the segments buffer cannot be modified by
|
|
|
|
// the planner, where the remaining planner block steps still can.
|
|
|
|
typedef struct {
|
2014-01-05 19:54:59 +01:00
|
|
|
uint16_t n_step; // Number of step events to be executed for this segment
|
|
|
|
uint8_t st_block_index; // Stepper block data index. Uses this information to execute this segment.
|
|
|
|
uint16_t cycles_per_tick; // Step distance traveled per ISR tick, aka step rate.
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
2014-01-05 19:54:59 +01:00
|
|
|
uint8_t amass_level; // Indicates AMASS level for the ISR to execute this segment
|
2013-12-31 06:02:05 +01:00
|
|
|
#else
|
2014-01-05 19:54:59 +01:00
|
|
|
uint8_t prescaler; // Without AMASS, a prescaler is required to adjust for slow timing.
|
2013-12-31 06:02:05 +01:00
|
|
|
#endif
|
2013-11-23 01:35:58 +01:00
|
|
|
} segment_t;
|
|
|
|
static segment_t segment_buffer[SEGMENT_BUFFER_SIZE];
|
2011-02-04 22:09:09 +01:00
|
|
|
|
2014-01-05 19:54:59 +01:00
|
|
|
// Stepper ISR data struct. Contains the running data for the main stepper ISR.
|
2011-12-09 02:47:48 +01:00
|
|
|
typedef struct {
|
|
|
|
// Used by the bresenham line algorithm
|
2013-12-30 04:34:51 +01:00
|
|
|
uint32_t counter_x, // Counter variables for the bresenham line tracer
|
2013-12-31 02:44:46 +01:00
|
|
|
counter_y,
|
|
|
|
counter_z;
|
|
|
|
#ifdef STEP_PULSE_DELAY
|
2013-12-30 04:34:51 +01:00
|
|
|
uint8_t step_bits; // Stores out_bits output to complete the step pulse delay
|
|
|
|
#endif
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
uint8_t execute_step; // Flags step execution for each interrupt.
|
|
|
|
uint8_t step_pulse_time; // Step pulse reset time after step rise
|
2013-12-31 02:44:46 +01:00
|
|
|
uint8_t step_outbits; // The next stepping-bits to be output
|
|
|
|
uint8_t dir_outbits;
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
|
|
|
uint32_t steps[N_AXIS];
|
|
|
|
#endif
|
2013-11-23 01:35:58 +01:00
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
uint16_t step_count; // Steps remaining in line segment motion
|
2013-11-23 01:35:58 +01:00
|
|
|
uint8_t exec_block_index; // Tracks the current st_block index. Change indicates new block.
|
|
|
|
st_block_t *exec_block; // Pointer to the block data for the segment being executed
|
|
|
|
segment_t *exec_segment; // Pointer to the segment being executed
|
2012-01-06 18:10:41 +01:00
|
|
|
} stepper_t;
|
|
|
|
static stepper_t st;
|
2013-10-30 02:10:39 +01:00
|
|
|
|
|
|
|
// Step segment ring buffer indices
|
|
|
|
static volatile uint8_t segment_buffer_tail;
|
2013-11-23 01:35:58 +01:00
|
|
|
static uint8_t segment_buffer_head;
|
2013-10-30 02:10:39 +01:00
|
|
|
static uint8_t segment_next_head;
|
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Used to avoid ISR nesting of the "Stepper Driver Interrupt". Should never occur though.
|
|
|
|
static volatile uint8_t busy;
|
2013-10-30 02:10:39 +01:00
|
|
|
|
|
|
|
// Pointers for the step segment being prepped from the planner buffer. Accessed only by the
|
|
|
|
// main program. Pointers may be planning segments or planner blocks ahead of what being executed.
|
2013-11-23 01:35:58 +01:00
|
|
|
static plan_block_t *pl_block; // Pointer to the planner block being prepped
|
|
|
|
static st_block_t *st_prep_block; // Pointer to the stepper block data being prepped
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Segment preparation data struct. Contains all the necessary information to compute new segments
|
|
|
|
// based on the current executing planner block.
|
|
|
|
typedef struct {
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
uint8_t st_block_index; // Index of stepper common data block being prepped
|
|
|
|
uint8_t flag_partial_block; // Flag indicating the last block completed. Time to load a new one.
|
2013-10-30 02:10:39 +01:00
|
|
|
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
float steps_remaining;
|
2014-02-09 18:46:34 +01:00
|
|
|
float step_per_mm; // Current planner block step/millimeter conversion scalar
|
|
|
|
float req_mm_increment;
|
|
|
|
float dt_remainder;
|
2013-11-23 01:35:58 +01:00
|
|
|
|
|
|
|
uint8_t ramp_type; // Current segment ramp state
|
2013-12-11 06:33:06 +01:00
|
|
|
float mm_complete; // End of velocity profile from end of current planner block in (mm).
|
2014-02-09 18:46:34 +01:00
|
|
|
// NOTE: This value must coincide with a step(no mantissa) when converted.
|
2013-11-23 01:35:58 +01:00
|
|
|
float current_speed; // Current speed at the end of the segment buffer (mm/min)
|
|
|
|
float maximum_speed; // Maximum speed of executing block. Not always nominal speed. (mm/min)
|
|
|
|
float exit_speed; // Exit speed of executing block (mm/min)
|
|
|
|
float accelerate_until; // Acceleration ramp end measured from end of block (mm)
|
|
|
|
float decelerate_after; // Deceleration ramp start measured from end of block (mm)
|
|
|
|
} st_prep_t;
|
|
|
|
static st_prep_t prep;
|
|
|
|
|
|
|
|
|
|
|
|
/* BLOCK VELOCITY PROFILE DEFINITION
|
|
|
|
__________________________
|
2013-10-30 02:10:39 +01:00
|
|
|
/| |\ _________________ ^
|
|
|
|
/ | | \ /| |\ |
|
|
|
|
/ | | \ / | | \ s
|
|
|
|
/ | | | | | \ p
|
|
|
|
/ | | | | | \ e
|
|
|
|
+-----+------------------------+---+--+---------------+----+ e
|
2013-11-23 01:35:58 +01:00
|
|
|
| BLOCK 1 ^ BLOCK 2 | d
|
|
|
|
|
|
|
|
|
time -----> EXAMPLE: Block 2 entry speed is at max junction velocity
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
The planner block buffer is planned assuming constant acceleration velocity profiles and are
|
|
|
|
continuously joined at block junctions as shown above. However, the planner only actively computes
|
|
|
|
the block entry speeds for an optimal velocity plan, but does not compute the block internal
|
|
|
|
velocity profiles. These velocity profiles are computed ad-hoc as they are executed by the
|
|
|
|
stepper algorithm and consists of only 7 possible types of profiles: cruise-only, cruise-
|
|
|
|
deceleration, acceleration-cruise, acceleration-only, deceleration-only, full-trapezoid, and
|
|
|
|
triangle(no cruise).
|
|
|
|
|
|
|
|
maximum_speed (< nominal_speed) -> +
|
|
|
|
+--------+ <- maximum_speed (= nominal_speed) /|\
|
|
|
|
/ \ / | \
|
|
|
|
current_speed -> + \ / | + <- exit_speed
|
|
|
|
| + <- exit_speed / | |
|
|
|
|
+-------------+ current_speed -> +----+--+
|
|
|
|
time --> ^ ^ ^ ^
|
|
|
|
| | | |
|
|
|
|
decelerate_after(in mm) decelerate_after(in mm)
|
|
|
|
^ ^ ^ ^
|
|
|
|
| | | |
|
|
|
|
accelerate_until(in mm) accelerate_until(in mm)
|
|
|
|
|
|
|
|
The step segment buffer computes the executing block velocity profile and tracks the critical
|
|
|
|
parameters for the stepper algorithm to accurately trace the profile. These critical parameters
|
|
|
|
are shown and defined in the above illustration.
|
2013-10-30 02:10:39 +01:00
|
|
|
*/
|
2011-01-31 23:04:39 +01:00
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
|
2012-11-01 16:37:27 +01:00
|
|
|
// Stepper state initialization. Cycle should only start if the st.cycle_start flag is
|
|
|
|
// enabled. Startup init and limits call this function but shouldn't start the cycle.
|
|
|
|
void st_wake_up()
|
2011-12-09 02:47:48 +01:00
|
|
|
{
|
2014-01-11 04:22:10 +01:00
|
|
|
// Enable stepper drivers.
|
|
|
|
if (bit_istrue(settings.flags,BITFLAG_INVERT_ST_ENABLE)) { STEPPERS_DISABLE_PORT |= (1<<STEPPERS_DISABLE_BIT); }
|
|
|
|
else { STEPPERS_DISABLE_PORT &= ~(1<<STEPPERS_DISABLE_BIT); }
|
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
if (sys.state & (STATE_CYCLE | STATE_HOMING)){
|
2012-11-01 16:37:27 +01:00
|
|
|
// Initialize stepper output bits
|
2013-12-31 02:44:46 +01:00
|
|
|
st.dir_outbits = settings.dir_invert_mask;
|
|
|
|
st.step_outbits = settings.step_invert_mask;
|
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
// Initialize step pulse timing from settings. Here to ensure updating after re-writing.
|
|
|
|
#ifdef STEP_PULSE_DELAY
|
|
|
|
// Set total step pulse time after direction pin set. Ad hoc computation from oscilloscope.
|
|
|
|
st.step_pulse_time = -(((settings.pulse_microseconds+STEP_PULSE_DELAY-2)*TICKS_PER_MICROSECOND) >> 3);
|
|
|
|
// Set delay between direction pin write and step command.
|
2013-12-31 02:44:46 +01:00
|
|
|
OCR0A = -(((settings.pulse_microseconds)*TICKS_PER_MICROSECOND) >> 3);
|
2013-12-30 04:34:51 +01:00
|
|
|
#else // Normal operation
|
|
|
|
// Set step pulse time. Ad hoc computation from oscilloscope. Uses two's complement.
|
|
|
|
st.step_pulse_time = -(((settings.pulse_microseconds-2)*TICKS_PER_MICROSECOND) >> 3);
|
|
|
|
#endif
|
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
// Enable Stepper Driver Interrupt
|
2013-12-30 04:34:51 +01:00
|
|
|
TIMSK1 |= (1<<OCIE1A);
|
2012-11-01 16:37:27 +01:00
|
|
|
}
|
2011-05-31 13:08:42 +02:00
|
|
|
}
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2011-10-12 04:51:04 +02:00
|
|
|
// Stepper shutdown
|
2011-12-09 02:47:48 +01:00
|
|
|
void st_go_idle()
|
|
|
|
{
|
2014-02-09 18:46:34 +01:00
|
|
|
// Disable Stepper Driver Interrupt. Allow Stepper Port Reset Interrupt to finish, if active.
|
|
|
|
TIMSK1 &= ~(1<<OCIE1A); // Disable Timer1 interrupt
|
|
|
|
TCCR1B = (TCCR1B & ~((1<<CS12) | (1<<CS11))) | (1<<CS10); // Reset clock to no prescaling.
|
2013-10-30 02:10:39 +01:00
|
|
|
busy = false;
|
2014-01-11 04:22:10 +01:00
|
|
|
|
|
|
|
// Set stepper driver idle state, disabled or enabled, depending on settings and circumstances.
|
2014-02-09 18:46:34 +01:00
|
|
|
bool pin_state = false; // Keep enabled.
|
2013-12-30 04:34:51 +01:00
|
|
|
if (((settings.stepper_idle_lock_time != 0xff) || bit_istrue(sys.execute,EXEC_ALARM)) && sys.state != STATE_HOMING) {
|
2012-11-01 16:37:27 +01:00
|
|
|
// Force stepper dwell to lock axes for a defined amount of time to ensure the axes come to a complete
|
|
|
|
// stop and not drift from residual inertial forces at the end of the last movement.
|
|
|
|
delay_ms(settings.stepper_idle_lock_time);
|
2014-02-09 18:46:34 +01:00
|
|
|
pin_state = true; // Override. Disable steppers.
|
2012-10-13 21:11:43 +02:00
|
|
|
}
|
2014-02-09 18:46:34 +01:00
|
|
|
if (bit_istrue(settings.flags,BITFLAG_INVERT_ST_ENABLE)) { pin_state = !pin_state; } // Apply pin invert.
|
2014-01-11 04:22:10 +01:00
|
|
|
if (pin_state) { STEPPERS_DISABLE_PORT |= (1<<STEPPERS_DISABLE_BIT); }
|
|
|
|
else { STEPPERS_DISABLE_PORT &= ~(1<<STEPPERS_DISABLE_BIT); }
|
2011-02-11 00:34:53 +01:00
|
|
|
}
|
|
|
|
|
2010-12-20 14:01:38 +01:00
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
/* "The Stepper Driver Interrupt" - This timer interrupt is the workhorse of Grbl. Grbl employs
|
|
|
|
the venerable Bresenham line algorithm to manage and exactly synchronize multi-axis moves.
|
|
|
|
Unlike the popular DDA algorithm, the Bresenham algorithm is not susceptible to numerical
|
|
|
|
round-off errors and only requires fast integer counters, meaning low computational overhead
|
|
|
|
and maximizing the Arduino's capabilities. However, the downside of the Bresenham algorithm
|
|
|
|
is, for certain multi-axis motions, the non-dominant axes may suffer from un-smooth step
|
2014-01-05 19:54:59 +01:00
|
|
|
pulse trains, or aliasing, which can lead to strange audible noises or shaking. This is
|
|
|
|
particularly noticeable or may cause motion issues at low step frequencies (0-5kHz), but
|
|
|
|
is usually not a physical problem at higher frequencies, although audible.
|
|
|
|
To improve Bresenham multi-axis performance, Grbl uses what we call an Adaptive Multi-Axis
|
|
|
|
Step Smoothing (AMASS) algorithm, which does what the name implies. At lower step frequencies,
|
|
|
|
AMASS artificially increases the Bresenham resolution without effecting the algorithm's
|
|
|
|
innate exactness. AMASS adapts its resolution levels automatically depending on the step
|
|
|
|
frequency to be executed, meaning that for even lower step frequencies the step smoothing
|
|
|
|
level increases. Algorithmically, AMASS is acheived by a simple bit-shifting of the Bresenham
|
|
|
|
step count for each AMASS level. For example, for a Level 1 step smoothing, we bit shift
|
|
|
|
the Bresenham step event count, effectively multiplying it by 2, while the axis step counts
|
|
|
|
remain the same, and then double the stepper ISR frequency. In effect, we are allowing the
|
|
|
|
non-dominant Bresenham axes step in the intermediate ISR tick, while the dominant axis is
|
|
|
|
stepping every two ISR ticks, rather than every ISR tick in the traditional sense. At AMASS
|
|
|
|
Level 2, we simply bit-shift again, so the non-dominant Bresenham axes can step within any
|
2014-02-09 18:46:34 +01:00
|
|
|
of the four ISR ticks, the dominant axis steps every four ISR ticks, and quadruple the
|
|
|
|
stepper ISR frequency. And so on. This, in effect, virtually eliminates multi-axis aliasing
|
|
|
|
issues with the Bresenham algorithm and does not significantly alter Grbl's performance, but
|
|
|
|
in fact, more efficiently utilizes unused CPU cycles overall throughout all configurations.
|
|
|
|
AMASS retains the Bresenham algorithm exactness by requiring that it always executes a full
|
|
|
|
Bresenham step, regardless of AMASS Level. Meaning that for an AMASS Level 2, all four
|
|
|
|
intermediate steps must be completed such that baseline Bresenham (Level 0) count is always
|
|
|
|
retained. Similarly, AMASS Level 3 means all eight intermediate steps must be executed.
|
|
|
|
Although the AMASS Levels are in reality arbitrary, where the baseline Bresenham counts can
|
|
|
|
be multiplied by any integer value, multiplication by powers of two are simply used to ease
|
|
|
|
CPU overhead with bitshift integer operations.
|
2013-12-30 04:34:51 +01:00
|
|
|
This interrupt is simple and dumb by design. All the computational heavy-lifting, as in
|
|
|
|
determining accelerations, is performed elsewhere. This interrupt pops pre-computed segments,
|
|
|
|
defined as constant velocity over n number of steps, from the step segment buffer and then
|
|
|
|
executes them by pulsing the stepper pins appropriately via the Bresenham algorithm. This
|
|
|
|
ISR is supported by The Stepper Port Reset Interrupt which it uses to reset the stepper port
|
|
|
|
after each pulse. The bresenham line tracer algorithm controls all stepper outputs
|
|
|
|
simultaneously with these two interrupts.
|
2013-12-07 16:40:25 +01:00
|
|
|
|
|
|
|
NOTE: This interrupt must be as efficient as possible and complete before the next ISR tick,
|
2013-12-30 04:34:51 +01:00
|
|
|
which for Grbl must be less than 33.3usec (@30kHz ISR rate). Oscilloscope measured time in
|
|
|
|
ISR is 5usec typical and 25usec maximum, well below requirement.
|
2014-02-09 18:46:34 +01:00
|
|
|
NOTE: This ISR expects at least one step to be executed per segment.
|
2013-10-30 02:10:39 +01:00
|
|
|
*/
|
2013-12-07 16:40:25 +01:00
|
|
|
// TODO: Replace direct updating of the int32 position counters in the ISR somehow. Perhaps use smaller
|
|
|
|
// int8 variables and update position counters only when a segment completes. This can get complicated
|
|
|
|
// with probing and homing cycles that require true real-time positions.
|
2013-12-30 04:34:51 +01:00
|
|
|
ISR(TIMER1_COMPA_vect)
|
|
|
|
{
|
2012-12-08 23:00:58 +01:00
|
|
|
// SPINDLE_ENABLE_PORT ^= 1<<SPINDLE_ENABLE_BIT; // Debug: Used to time ISR
|
2011-12-09 02:47:48 +01:00
|
|
|
if (busy) { return; } // The busy-flag is used to avoid reentering this interrupt
|
2011-01-24 20:55:25 +01:00
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
// Set the direction pins a couple of nanoseconds before we step the steppers
|
2013-12-31 02:44:46 +01:00
|
|
|
DIRECTION_PORT = (DIRECTION_PORT & ~DIRECTION_MASK) | (st.dir_outbits & DIRECTION_MASK);
|
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
// Then pulse the stepping pins
|
|
|
|
#ifdef STEP_PULSE_DELAY
|
2014-02-09 18:46:34 +01:00
|
|
|
st.step_bits = (STEP_PORT & ~STEP_MASK) | st.step_outbits; // Store out_bits to prevent overwriting.
|
2013-12-30 04:34:51 +01:00
|
|
|
#else // Normal operation
|
2014-02-09 18:46:34 +01:00
|
|
|
STEP_PORT = (STEP_PORT & ~STEP_MASK) | st.step_outbits;
|
2013-12-30 04:34:51 +01:00
|
|
|
#endif
|
|
|
|
|
|
|
|
// Enable step pulse reset timer so that The Stepper Port Reset Interrupt can reset the signal after
|
|
|
|
// exactly settings.pulse_microseconds microseconds, independent of the main Timer1 prescaler.
|
2013-12-31 02:44:46 +01:00
|
|
|
TCNT0 = st.step_pulse_time; // Reload Timer0 counter
|
2014-02-09 18:46:34 +01:00
|
|
|
TCCR0B = (1<<CS01); // Begin Timer0. Full speed, 1/8 prescaler
|
2013-12-31 02:44:46 +01:00
|
|
|
|
2012-01-16 02:25:12 +01:00
|
|
|
busy = true;
|
2013-10-30 02:10:39 +01:00
|
|
|
sei(); // Re-enable interrupts to allow Stepper Port Reset Interrupt to fire on-time.
|
|
|
|
// NOTE: The remaining code in this ISR will finish before returning to main program.
|
|
|
|
|
|
|
|
// If there is no step segment, attempt to pop one from the stepper buffer
|
2013-11-23 01:35:58 +01:00
|
|
|
if (st.exec_segment == NULL) {
|
2013-10-30 02:10:39 +01:00
|
|
|
// Anything in the buffer? If so, load and initialize next step segment.
|
|
|
|
if (segment_buffer_head != segment_buffer_tail) {
|
|
|
|
// Initialize new step segment and load number of steps to execute
|
2013-11-23 01:35:58 +01:00
|
|
|
st.exec_segment = &segment_buffer[segment_buffer_tail];
|
2014-02-09 18:46:34 +01:00
|
|
|
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifndef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
2014-02-09 18:46:34 +01:00
|
|
|
// With AMASS is disabled, set timer prescaler for segments with slow step frequencies (< 250Hz).
|
2013-12-31 06:02:05 +01:00
|
|
|
TCCR1B = (TCCR1B & ~(0x07<<CS10)) | (st.exec_segment->prescaler<<CS10);
|
|
|
|
#endif
|
2014-02-09 18:46:34 +01:00
|
|
|
|
|
|
|
// Initialize step segment timing per step and load number of steps to execute.
|
2013-12-30 04:34:51 +01:00
|
|
|
OCR1A = st.exec_segment->cycles_per_tick;
|
|
|
|
st.step_count = st.exec_segment->n_step; // NOTE: Can sometimes be zero when moving slow.
|
2013-10-30 02:10:39 +01:00
|
|
|
// If the new segment starts a new planner block, initialize stepper variables and counters.
|
2013-11-23 01:35:58 +01:00
|
|
|
// NOTE: When the segment data index changes, this indicates a new planner block.
|
|
|
|
if ( st.exec_block_index != st.exec_segment->st_block_index ) {
|
|
|
|
st.exec_block_index = st.exec_segment->st_block_index;
|
|
|
|
st.exec_block = &st_block_buffer[st.exec_block_index];
|
2014-02-09 18:46:34 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Initialize Bresenham line and distance counters
|
|
|
|
st.counter_x = (st.exec_block->step_event_count >> 1);
|
2013-10-30 02:10:39 +01:00
|
|
|
st.counter_y = st.counter_x;
|
2013-12-31 02:44:46 +01:00
|
|
|
st.counter_z = st.counter_x;
|
2012-12-08 23:00:58 +01:00
|
|
|
}
|
2014-02-09 18:46:34 +01:00
|
|
|
|
|
|
|
st.dir_outbits = st.exec_block->direction_bits ^ settings.dir_invert_mask;
|
|
|
|
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
2014-02-09 18:46:34 +01:00
|
|
|
// With AMASS enabled, adjust Bresenham axis increment counters according to AMASS level.
|
2013-12-31 06:02:05 +01:00
|
|
|
st.steps[X_AXIS] = st.exec_block->steps[X_AXIS] >> st.exec_segment->amass_level;
|
|
|
|
st.steps[Y_AXIS] = st.exec_block->steps[Y_AXIS] >> st.exec_segment->amass_level;
|
|
|
|
st.steps[Z_AXIS] = st.exec_block->steps[Z_AXIS] >> st.exec_segment->amass_level;
|
|
|
|
#endif
|
2014-02-09 18:46:34 +01:00
|
|
|
|
2010-03-03 00:26:48 +01:00
|
|
|
} else {
|
2013-11-23 01:35:58 +01:00
|
|
|
// Segment buffer empty. Shutdown.
|
2011-05-31 13:08:42 +02:00
|
|
|
st_go_idle();
|
2012-01-06 18:10:41 +01:00
|
|
|
bit_true(sys.execute,EXEC_CYCLE_STOP); // Flag main program for cycle end
|
2012-12-08 23:00:58 +01:00
|
|
|
return; // Nothing to do but exit.
|
|
|
|
}
|
|
|
|
}
|
2013-12-30 04:34:51 +01:00
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
// Reset step out bits.
|
|
|
|
st.step_outbits = 0;
|
2013-12-30 04:34:51 +01:00
|
|
|
|
|
|
|
// Execute step displacement profile by Bresenham line algorithm
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
|
|
|
st.counter_x += st.steps[X_AXIS];
|
|
|
|
#else
|
|
|
|
st.counter_x += st.exec_block->steps[X_AXIS];
|
|
|
|
#endif
|
2013-12-31 02:44:46 +01:00
|
|
|
if (st.counter_x > st.exec_block->step_event_count) {
|
|
|
|
st.step_outbits |= (1<<X_STEP_BIT);
|
|
|
|
st.counter_x -= st.exec_block->step_event_count;
|
|
|
|
if (st.exec_block->direction_bits & (1<<X_DIRECTION_BIT)) { sys.position[X_AXIS]--; }
|
|
|
|
else { sys.position[X_AXIS]++; }
|
|
|
|
}
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
|
|
|
st.counter_y += st.steps[Y_AXIS];
|
|
|
|
#else
|
|
|
|
st.counter_y += st.exec_block->steps[Y_AXIS];
|
|
|
|
#endif
|
2013-12-31 02:44:46 +01:00
|
|
|
if (st.counter_y > st.exec_block->step_event_count) {
|
|
|
|
st.step_outbits |= (1<<Y_STEP_BIT);
|
|
|
|
st.counter_y -= st.exec_block->step_event_count;
|
|
|
|
if (st.exec_block->direction_bits & (1<<Y_DIRECTION_BIT)) { sys.position[Y_AXIS]--; }
|
|
|
|
else { sys.position[Y_AXIS]++; }
|
|
|
|
}
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
|
|
|
st.counter_z += st.steps[Z_AXIS];
|
|
|
|
#else
|
|
|
|
st.counter_z += st.exec_block->steps[Z_AXIS];
|
|
|
|
#endif
|
2013-12-31 02:44:46 +01:00
|
|
|
if (st.counter_z > st.exec_block->step_event_count) {
|
|
|
|
st.step_outbits |= (1<<Z_STEP_BIT);
|
|
|
|
st.counter_z -= st.exec_block->step_event_count;
|
|
|
|
if (st.exec_block->direction_bits & (1<<Z_DIRECTION_BIT)) { sys.position[Z_AXIS]--; }
|
|
|
|
else { sys.position[Z_AXIS]++; }
|
|
|
|
}
|
|
|
|
|
|
|
|
// During a homing cycle, lock out and prevent desired axes from moving.
|
|
|
|
if (sys.state == STATE_HOMING) { st.step_outbits &= sys.homing_axis_lock; }
|
|
|
|
|
|
|
|
st.step_count--; // Decrement step events count
|
2013-12-30 04:34:51 +01:00
|
|
|
if (st.step_count == 0) {
|
|
|
|
// Segment is complete. Discard current segment and advance segment indexing.
|
|
|
|
st.exec_segment = NULL;
|
|
|
|
if ( ++segment_buffer_tail == SEGMENT_BUFFER_SIZE) { segment_buffer_tail = 0; }
|
2011-10-12 04:51:04 +02:00
|
|
|
}
|
2013-12-30 04:34:51 +01:00
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
st.step_outbits ^= settings.step_invert_mask; // Apply step port invert mask
|
2011-12-09 02:47:48 +01:00
|
|
|
busy = false;
|
2014-02-09 18:46:34 +01:00
|
|
|
// SPINDLE_ENABLE_PORT ^= 1<<SPINDLE_ENABLE_BIT; // Debug: Used to time ISR
|
2009-01-28 23:48:21 +01:00
|
|
|
}
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
/* The Stepper Port Reset Interrupt: Timer0 OVF interrupt handles the falling edge of the step
|
2014-02-09 18:46:34 +01:00
|
|
|
pulse. This should always trigger before the next Timer1 COMPA interrupt and independently
|
|
|
|
finish, if Timer1 is disabled after completing a move.
|
|
|
|
NOTE: Interrupt collisions between the serial and stepper interrupts can cause delays by
|
|
|
|
a few microseconds, if they execute right before one another. Not a big deal, but can
|
|
|
|
cause issues at high step rates if another high frequency asynchronous interrupt is
|
|
|
|
added to Grbl.
|
|
|
|
*/
|
|
|
|
// This interrupt is enabled by ISR_TIMER1_COMPAREA when it sets the motor port bits to execute
|
|
|
|
// a step. This ISR resets the motor port after a short period (settings.pulse_microseconds)
|
|
|
|
// completing one step cycle.
|
2013-12-31 02:44:46 +01:00
|
|
|
ISR(TIMER0_OVF_vect)
|
2009-01-28 23:48:21 +01:00
|
|
|
{
|
2013-12-30 04:34:51 +01:00
|
|
|
// Reset stepping pins (leave the direction pins)
|
2014-02-09 18:46:34 +01:00
|
|
|
STEP_PORT = (STEP_PORT & ~STEP_MASK) | (settings.step_invert_mask & STEP_MASK);
|
2013-12-31 02:44:46 +01:00
|
|
|
TCCR0B = 0; // Disable Timer0 to prevent re-entering this interrupt when it's not needed.
|
2009-01-28 23:48:21 +01:00
|
|
|
}
|
2013-12-30 04:34:51 +01:00
|
|
|
#ifdef STEP_PULSE_DELAY
|
|
|
|
// This interrupt is used only when STEP_PULSE_DELAY is enabled. Here, the step pulse is
|
|
|
|
// initiated after the STEP_PULSE_DELAY time period has elapsed. The ISR TIMER2_OVF interrupt
|
|
|
|
// will then trigger after the appropriate settings.pulse_microseconds, as in normal operation.
|
|
|
|
// The new timing between direction, step pulse, and step complete events are setup in the
|
|
|
|
// st_wake_up() routine.
|
2013-12-31 02:44:46 +01:00
|
|
|
ISR(TIMER0_COMPA_vect)
|
2013-12-30 04:34:51 +01:00
|
|
|
{
|
2014-02-09 18:46:34 +01:00
|
|
|
STEP_PORT = st.step_bits; // Begin step pulse.
|
2013-12-30 04:34:51 +01:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
2011-12-09 02:47:48 +01:00
|
|
|
// Reset and clear stepper subsystem variables
|
|
|
|
void st_reset()
|
|
|
|
{
|
2014-02-09 18:46:34 +01:00
|
|
|
// Initialize stepper driver idle state.
|
|
|
|
st_go_idle();
|
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
memset(&prep, 0, sizeof(prep));
|
2011-12-09 02:47:48 +01:00
|
|
|
memset(&st, 0, sizeof(st));
|
2013-11-23 01:35:58 +01:00
|
|
|
st.exec_segment = NULL;
|
|
|
|
pl_block = NULL; // Planner block pointer used by segment buffer
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
segment_buffer_tail = 0;
|
|
|
|
segment_buffer_head = 0; // empty = tail
|
|
|
|
segment_next_head = 1;
|
2013-11-23 01:35:58 +01:00
|
|
|
busy = false;
|
2011-12-09 02:47:48 +01:00
|
|
|
}
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
|
2009-01-28 23:48:21 +01:00
|
|
|
// Initialize and start the stepper motor subsystem
|
2014-01-11 04:22:10 +01:00
|
|
|
void stepper_init()
|
2009-01-28 23:48:21 +01:00
|
|
|
{
|
2013-12-31 02:44:46 +01:00
|
|
|
// Configure step and direction interface pins
|
2014-02-09 18:46:34 +01:00
|
|
|
STEP_DDR |= STEP_MASK;
|
|
|
|
STEP_PORT = (STEP_PORT & ~STEP_MASK) | settings.step_invert_mask;
|
2011-05-31 13:08:42 +02:00
|
|
|
STEPPERS_DISABLE_DDR |= 1<<STEPPERS_DISABLE_BIT;
|
2013-12-31 02:44:46 +01:00
|
|
|
DIRECTION_DDR |= DIRECTION_MASK;
|
|
|
|
DIRECTION_PORT = (DIRECTION_PORT & ~DIRECTION_MASK) | settings.dir_invert_mask;
|
2013-12-30 04:34:51 +01:00
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
// Configure Timer 1: Stepper Driver Interrupt
|
2013-12-30 04:34:51 +01:00
|
|
|
TCCR1B &= ~(1<<WGM13); // waveform generation = 0100 = CTC
|
|
|
|
TCCR1B |= (1<<WGM12);
|
2014-02-09 18:46:34 +01:00
|
|
|
TCCR1A &= ~((1<<WGM11) | (1<<WGM10));
|
|
|
|
TCCR1A &= ~((1<<COM1A1) | (1<<COM1A0) | (1<<COM1B1) | (1<<COM1B0)); // Disconnect OC1 output
|
|
|
|
// TCCR1B = (TCCR1B & ~((1<<CS12) | (1<<CS11))) | (1<<CS10); // Set in st_go_idle().
|
|
|
|
// TIMSK1 &= ~(1<<OCIE1A); // Set in st_go_idle().
|
2014-01-11 04:22:10 +01:00
|
|
|
|
2013-12-31 02:44:46 +01:00
|
|
|
// Configure Timer 0: Stepper Port Reset Interrupt
|
2014-02-09 18:46:34 +01:00
|
|
|
TIMSK0 &= ~((1<<OCIE0B) | (1<<OCIE0A) | (1<<TOIE0)); // Disconnect OC0 outputs and OVF interrupt.
|
2013-12-31 02:44:46 +01:00
|
|
|
TCCR0A = 0; // Normal operation
|
|
|
|
TCCR0B = 0; // Disable Timer0 until needed
|
|
|
|
TIMSK0 |= (1<<TOIE0); // Enable Timer0 overflow interrupt
|
2013-12-30 04:34:51 +01:00
|
|
|
#ifdef STEP_PULSE_DELAY
|
2013-12-31 02:44:46 +01:00
|
|
|
TIMSK0 |= (1<<OCIE0A); // Enable Timer0 Compare Match A interrupt
|
2013-12-30 04:34:51 +01:00
|
|
|
#endif
|
2009-01-28 23:48:21 +01:00
|
|
|
}
|
2014-01-11 04:22:10 +01:00
|
|
|
|
2010-06-28 23:29:58 +02:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Called by planner_recalculate() when the executing block is updated by the new plan.
|
|
|
|
void st_update_plan_block_parameters()
|
|
|
|
{
|
|
|
|
if (pl_block != NULL) { // Ignore if at start of a new block.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.flag_partial_block = true;
|
2013-11-23 01:35:58 +01:00
|
|
|
pl_block->entry_speed_sqr = prep.current_speed*prep.current_speed; // Update entry speed.
|
|
|
|
pl_block = NULL; // Flag st_prep_segment() to load new velocity profile.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
/* Prepares step segment buffer. Continuously called from main program.
|
|
|
|
|
|
|
|
The segment buffer is an intermediary buffer interface between the execution of steps
|
|
|
|
by the stepper algorithm and the velocity profiles generated by the planner. The stepper
|
|
|
|
algorithm only executes steps within the segment buffer and is filled by the main program
|
|
|
|
when steps are "checked-out" from the first block in the planner buffer. This keeps the
|
|
|
|
step execution and planning optimization processes atomic and protected from each other.
|
|
|
|
The number of steps "checked-out" from the planner buffer and the number of segments in
|
|
|
|
the segment buffer is sized and computed such that no operation in the main program takes
|
|
|
|
longer than the time it takes the stepper algorithm to empty it before refilling it.
|
2014-02-09 18:46:34 +01:00
|
|
|
Currently, the segment buffer conservatively holds roughly up to 40-50 msec of steps.
|
|
|
|
NOTE: Computation units are in steps, millimeters, and minutes.
|
2013-10-30 02:10:39 +01:00
|
|
|
*/
|
|
|
|
void st_prep_buffer()
|
|
|
|
{
|
|
|
|
while (segment_buffer_tail != segment_next_head) { // Check if we need to fill the buffer.
|
2013-12-31 06:02:05 +01:00
|
|
|
|
2014-02-09 18:46:34 +01:00
|
|
|
// Determine if we need to load a new planner block or if the block has been replanned.
|
2013-11-23 01:35:58 +01:00
|
|
|
if (pl_block == NULL) {
|
|
|
|
pl_block = plan_get_current_block(); // Query planner for a queued block
|
|
|
|
if (pl_block == NULL) { return; } // No planner blocks. Exit.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
|
|
|
// Check if the segment buffer completed the last planner block. If so, load the Bresenham
|
2014-02-09 18:46:34 +01:00
|
|
|
// data for the block. If not, we are still mid-block and the velocity profile was updated.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
if (prep.flag_partial_block) {
|
|
|
|
prep.flag_partial_block = false; // Reset flag
|
2013-11-23 01:35:58 +01:00
|
|
|
} else {
|
2014-02-09 18:46:34 +01:00
|
|
|
// Increment stepper common data index to store new planner block data.
|
2013-11-23 01:35:58 +01:00
|
|
|
if ( ++prep.st_block_index == (SEGMENT_BUFFER_SIZE-1) ) { prep.st_block_index = 0; }
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Prepare and copy Bresenham algorithm segment data from the new planner block, so that
|
2014-02-09 18:46:34 +01:00
|
|
|
// when the segment buffer completes the planner block, it may be discarded when the
|
|
|
|
// segment buffer finishes the prepped block, but the stepper ISR is still executing it.
|
2013-11-23 01:35:58 +01:00
|
|
|
st_prep_block = &st_block_buffer[prep.st_block_index];
|
2013-12-30 04:34:51 +01:00
|
|
|
st_prep_block->direction_bits = pl_block->direction_bits;
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifndef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
2013-12-31 02:44:46 +01:00
|
|
|
st_prep_block->steps[X_AXIS] = pl_block->steps[X_AXIS];
|
|
|
|
st_prep_block->steps[Y_AXIS] = pl_block->steps[Y_AXIS];
|
|
|
|
st_prep_block->steps[Z_AXIS] = pl_block->steps[Z_AXIS];
|
|
|
|
st_prep_block->step_event_count = pl_block->step_event_count;
|
2013-12-31 06:02:05 +01:00
|
|
|
#else
|
2014-02-09 18:46:34 +01:00
|
|
|
// With AMASS enabled, simply bit-shift multiply all Bresenham data by the max AMASS
|
|
|
|
// level, such that we never divide beyond the original data anywhere in the algorithm.
|
|
|
|
// If the original data is divided, we can lose a step from integer roundoff.
|
2013-12-31 06:02:05 +01:00
|
|
|
st_prep_block->steps[X_AXIS] = pl_block->steps[X_AXIS] << MAX_AMASS_LEVEL;
|
|
|
|
st_prep_block->steps[Y_AXIS] = pl_block->steps[Y_AXIS] << MAX_AMASS_LEVEL;
|
|
|
|
st_prep_block->steps[Z_AXIS] = pl_block->steps[Z_AXIS] << MAX_AMASS_LEVEL;
|
|
|
|
st_prep_block->step_event_count = pl_block->step_event_count << MAX_AMASS_LEVEL;
|
2013-12-31 02:44:46 +01:00
|
|
|
#endif
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
|
|
|
// Initialize segment buffer data for generating the segments.
|
2013-12-30 04:34:51 +01:00
|
|
|
prep.steps_remaining = pl_block->step_event_count;
|
2013-12-07 16:40:25 +01:00
|
|
|
prep.step_per_mm = prep.steps_remaining/pl_block->millimeters;
|
2014-02-09 18:46:34 +01:00
|
|
|
prep.req_mm_increment = REQ_MM_INCREMENT_SCALAR*pl_block->millimeters/prep.steps_remaining;
|
|
|
|
|
|
|
|
prep.dt_remainder = 0.0; // Reset for new planner block
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
2013-12-11 06:33:06 +01:00
|
|
|
if (sys.state == STATE_HOLD) {
|
|
|
|
// Override planner block entry speed and enforce deceleration during feed hold.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.current_speed = prep.exit_speed;
|
|
|
|
pl_block->entry_speed_sqr = prep.exit_speed*prep.exit_speed;
|
|
|
|
}
|
|
|
|
else { prep.current_speed = sqrt(pl_block->entry_speed_sqr); }
|
2013-10-30 02:10:39 +01:00
|
|
|
}
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
|
2013-12-08 04:08:24 +01:00
|
|
|
/* ---------------------------------------------------------------------------------
|
|
|
|
Compute the velocity profile of a new planner block based on its entry and exit
|
|
|
|
speeds, or recompute the profile of a partially-completed planner block if the
|
|
|
|
planner has updated it. For a commanded forced-deceleration, such as from a feed
|
|
|
|
hold, override the planner velocities and decelerate to the target exit speed.
|
|
|
|
*/
|
2013-12-11 06:33:06 +01:00
|
|
|
prep.mm_complete = 0.0; // Default velocity profile complete at 0.0mm from end of block.
|
2013-11-23 01:35:58 +01:00
|
|
|
float inv_2_accel = 0.5/pl_block->acceleration;
|
2014-02-09 18:46:34 +01:00
|
|
|
if (sys.state == STATE_HOLD) { // [Forced Deceleration to Zero Velocity]
|
2013-12-07 16:40:25 +01:00
|
|
|
// Compute velocity profile parameters for a feed hold in-progress. This profile overrides
|
|
|
|
// the planner block profile, enforcing a deceleration to zero speed.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.ramp_type = RAMP_DECEL;
|
2014-02-09 18:46:34 +01:00
|
|
|
// Compute decelerate distance relative to end of block.
|
|
|
|
float decel_dist = pl_block->millimeters - inv_2_accel*pl_block->entry_speed_sqr;
|
|
|
|
if (decel_dist < 0.0) {
|
|
|
|
// Deceleration through entire planner block. End of feed hold is not in this block.
|
2013-12-07 16:40:25 +01:00
|
|
|
prep.exit_speed = sqrt(pl_block->entry_speed_sqr-2*pl_block->acceleration*pl_block->millimeters);
|
2014-02-09 18:46:34 +01:00
|
|
|
} else {
|
|
|
|
prep.mm_complete = decel_dist; // End of feed hold.
|
|
|
|
prep.exit_speed = 0.0;
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
}
|
2014-02-09 18:46:34 +01:00
|
|
|
} else { // [Normal Operation]
|
2013-12-08 04:08:24 +01:00
|
|
|
// Compute or recompute velocity profile parameters of the prepped planner block.
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.ramp_type = RAMP_ACCEL; // Initialize as acceleration ramp.
|
2013-12-07 16:40:25 +01:00
|
|
|
prep.accelerate_until = pl_block->millimeters;
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.exit_speed = plan_get_exec_block_exit_speed();
|
|
|
|
float exit_speed_sqr = prep.exit_speed*prep.exit_speed;
|
|
|
|
float intersect_distance =
|
2013-12-07 16:40:25 +01:00
|
|
|
0.5*(pl_block->millimeters+inv_2_accel*(pl_block->entry_speed_sqr-exit_speed_sqr));
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
if (intersect_distance > 0.0) {
|
2013-12-07 16:40:25 +01:00
|
|
|
if (intersect_distance < pl_block->millimeters) { // Either trapezoid or triangle types
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
// NOTE: For acceleration-cruise and cruise-only types, following calculation will be 0.0.
|
|
|
|
prep.decelerate_after = inv_2_accel*(pl_block->nominal_speed_sqr-exit_speed_sqr);
|
|
|
|
if (prep.decelerate_after < intersect_distance) { // Trapezoid type
|
|
|
|
prep.maximum_speed = sqrt(pl_block->nominal_speed_sqr);
|
|
|
|
if (pl_block->entry_speed_sqr == pl_block->nominal_speed_sqr) {
|
|
|
|
// Cruise-deceleration or cruise-only type.
|
|
|
|
prep.ramp_type = RAMP_CRUISE;
|
|
|
|
} else {
|
|
|
|
// Full-trapezoid or acceleration-cruise types
|
|
|
|
prep.accelerate_until -= inv_2_accel*(pl_block->nominal_speed_sqr-pl_block->entry_speed_sqr);
|
|
|
|
}
|
|
|
|
} else { // Triangle type
|
|
|
|
prep.accelerate_until = intersect_distance;
|
|
|
|
prep.decelerate_after = intersect_distance;
|
|
|
|
prep.maximum_speed = sqrt(2.0*pl_block->acceleration*intersect_distance+exit_speed_sqr);
|
|
|
|
}
|
|
|
|
} else { // Deceleration-only type
|
|
|
|
prep.ramp_type = RAMP_DECEL;
|
2013-12-07 16:40:25 +01:00
|
|
|
// prep.decelerate_after = pl_block->millimeters;
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.maximum_speed = prep.current_speed;
|
|
|
|
}
|
|
|
|
} else { // Acceleration-only type
|
|
|
|
prep.accelerate_until = 0.0;
|
2013-12-07 16:40:25 +01:00
|
|
|
// prep.decelerate_after = 0.0;
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
prep.maximum_speed = prep.exit_speed;
|
2013-11-23 01:35:58 +01:00
|
|
|
}
|
2014-02-09 18:46:34 +01:00
|
|
|
}
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
}
|
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// Initialize new segment
|
|
|
|
segment_t *prep_segment = &segment_buffer[segment_buffer_head];
|
|
|
|
|
2013-10-30 02:10:39 +01:00
|
|
|
// Set new segment to point to the current segment data block.
|
2013-11-23 01:35:58 +01:00
|
|
|
prep_segment->st_block_index = prep.st_block_index;
|
|
|
|
|
2014-02-09 18:46:34 +01:00
|
|
|
|
|
|
|
float mm_remaining = pl_block->millimeters;
|
|
|
|
float minimum_mm = pl_block->millimeters-prep.req_mm_increment;
|
|
|
|
if (minimum_mm < 0.0) { minimum_mm = 0.0; }
|
|
|
|
if (sys.state == STATE_HOLD) {
|
|
|
|
if (minimum_mm < prep.mm_complete) { // NOTE: Exit condition
|
|
|
|
// Less than one step to decelerate to zero speed, but already very close. AMASS
|
|
|
|
// requires full steps to execute. So, just bail.
|
|
|
|
prep.current_speed = 0.0;
|
|
|
|
prep.dt_remainder = 0.0;
|
|
|
|
prep.steps_remaining = ceil(pl_block->millimeters * prep.step_per_mm);
|
|
|
|
pl_block->millimeters = prep.steps_remaining/prep.step_per_mm; // Update with full steps.
|
|
|
|
plan_cycle_reinitialize();
|
|
|
|
sys.state = STATE_QUEUED;
|
|
|
|
return; // Segment not generated, but current step data still retained.
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-08 04:08:24 +01:00
|
|
|
/*------------------------------------------------------------------------------------
|
|
|
|
Compute the average velocity of this new segment by determining the total distance
|
|
|
|
traveled over the segment time DT_SEGMENT. The following code first attempts to create
|
|
|
|
a full segment based on the current ramp conditions. If the segment time is incomplete
|
|
|
|
when terminating at a ramp state change, the code will continue to loop through the
|
|
|
|
progressing ramp states to fill the remaining segment execution time. However, if
|
|
|
|
an incomplete segment terminates at the end of the velocity profile, the segment is
|
|
|
|
considered completed despite having a truncated execution time less than DT_SEGMENT.
|
|
|
|
The velocity profile is always assumed to progress through the ramp sequence:
|
|
|
|
acceleration ramp, cruising state, and deceleration ramp. Each ramp's travel distance
|
|
|
|
may range from zero to the length of the block. Velocity profiles can end either at
|
|
|
|
the end of planner block (typical) or mid-block at the end of a forced deceleration,
|
|
|
|
such as from a feed hold.
|
2013-12-30 04:34:51 +01:00
|
|
|
*/
|
2014-02-09 18:46:34 +01:00
|
|
|
float dt_max = DT_SEGMENT; // Maximum segment time
|
2014-01-11 04:22:10 +01:00
|
|
|
float dt = 0.0; // Initialize segment time
|
2013-12-30 04:34:51 +01:00
|
|
|
float time_var = dt_max; // Time worker variable
|
2013-12-08 04:08:24 +01:00
|
|
|
float mm_var; // mm-Distance worker variable
|
2014-02-09 18:46:34 +01:00
|
|
|
float speed_var; // Speed worker variable
|
2013-11-23 01:35:58 +01:00
|
|
|
do {
|
|
|
|
switch (prep.ramp_type) {
|
|
|
|
case RAMP_ACCEL:
|
2013-12-07 16:40:25 +01:00
|
|
|
// NOTE: Acceleration ramp only computes during first do-while loop.
|
2014-01-11 04:22:10 +01:00
|
|
|
speed_var = pl_block->acceleration*time_var;
|
|
|
|
mm_remaining -= time_var*(prep.current_speed + 0.5*speed_var);
|
2013-11-23 01:35:58 +01:00
|
|
|
if (mm_remaining < prep.accelerate_until) { // End of acceleration ramp.
|
|
|
|
// Acceleration-cruise, acceleration-deceleration ramp junction, or end of block.
|
|
|
|
mm_remaining = prep.accelerate_until; // NOTE: 0.0 at EOB
|
2013-12-07 16:40:25 +01:00
|
|
|
time_var = 2.0*(pl_block->millimeters-mm_remaining)/(prep.current_speed+prep.maximum_speed);
|
2013-11-23 01:35:58 +01:00
|
|
|
if (mm_remaining == prep.decelerate_after) { prep.ramp_type = RAMP_DECEL; }
|
|
|
|
else { prep.ramp_type = RAMP_CRUISE; }
|
|
|
|
prep.current_speed = prep.maximum_speed;
|
|
|
|
} else { // Acceleration only.
|
2013-12-08 04:08:24 +01:00
|
|
|
prep.current_speed += speed_var;
|
2013-11-23 01:35:58 +01:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case RAMP_CRUISE:
|
|
|
|
// NOTE: mm_var used to retain the last mm_remaining for incomplete segment time_var calculations.
|
|
|
|
mm_var = mm_remaining - prep.maximum_speed*time_var;
|
|
|
|
if (mm_var < prep.decelerate_after) { // End of cruise.
|
|
|
|
// Cruise-deceleration junction or end of block.
|
|
|
|
time_var = (mm_remaining - prep.decelerate_after)/prep.maximum_speed;
|
|
|
|
mm_remaining = prep.decelerate_after; // NOTE: 0.0 at EOB
|
|
|
|
prep.ramp_type = RAMP_DECEL;
|
|
|
|
} else { // Cruising only.
|
|
|
|
mm_remaining = mm_var;
|
|
|
|
}
|
|
|
|
break;
|
|
|
|
default: // case RAMP_DECEL:
|
2013-12-08 04:08:24 +01:00
|
|
|
// NOTE: mm_var used as a misc worker variable to prevent errors when near zero speed.
|
|
|
|
speed_var = pl_block->acceleration*time_var; // Used as delta speed (mm/min)
|
|
|
|
if (prep.current_speed > speed_var) { // Check if at or below zero speed.
|
|
|
|
// Compute distance from end of segment to end of block.
|
|
|
|
mm_var = mm_remaining - time_var*(prep.current_speed - 0.5*speed_var); // (mm)
|
|
|
|
if (mm_var > prep.mm_complete) { // Deceleration only.
|
|
|
|
mm_remaining = mm_var;
|
|
|
|
prep.current_speed -= speed_var;
|
2013-12-30 04:34:51 +01:00
|
|
|
break; // Segment complete. Exit switch-case statement. Continue do-while loop.
|
2013-12-08 04:08:24 +01:00
|
|
|
}
|
|
|
|
} // End of block or end of forced-deceleration.
|
|
|
|
time_var = 2.0*(mm_remaining-prep.mm_complete)/(prep.current_speed+prep.exit_speed);
|
|
|
|
mm_remaining = prep.mm_complete;
|
2013-10-30 02:10:39 +01:00
|
|
|
}
|
2013-11-23 01:35:58 +01:00
|
|
|
dt += time_var; // Add computed ramp time to total segment time.
|
2013-12-30 04:34:51 +01:00
|
|
|
if (dt < dt_max) { time_var = dt_max - dt; } // **Incomplete** At ramp junction.
|
2014-01-11 04:22:10 +01:00
|
|
|
else {
|
2014-02-09 18:46:34 +01:00
|
|
|
if (mm_remaining > minimum_mm) { // Check for very slow segments with zero steps.
|
2014-01-11 04:22:10 +01:00
|
|
|
dt_max += DT_SEGMENT; // Increase segment time to ensure at least one step in segment.
|
|
|
|
time_var = dt_max - dt;
|
|
|
|
} else {
|
|
|
|
break; // **Complete** Exit loop. Segment execution time maxed.
|
|
|
|
}
|
|
|
|
}
|
2013-12-08 04:08:24 +01:00
|
|
|
} while (mm_remaining > prep.mm_complete); // **Complete** Exit loop. Profile complete.
|
2014-02-09 18:46:34 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
|
|
|
|
/* -----------------------------------------------------------------------------------
|
2014-02-09 18:46:34 +01:00
|
|
|
Compute segment step rate, steps to execute, and apply necessary rate corrections.
|
2013-11-23 01:35:58 +01:00
|
|
|
NOTE: Steps are computed by direct scalar conversion of the millimeter distance
|
|
|
|
remaining in the block, rather than incrementally tallying the steps executed per
|
|
|
|
segment. This helps in removing floating point round-off issues of several additions.
|
|
|
|
However, since floats have only 7.2 significant digits, long moves with extremely
|
|
|
|
high step counts can exceed the precision of floats, which can lead to lost steps.
|
|
|
|
Fortunately, this scenario is highly unlikely and unrealistic in CNC machines
|
|
|
|
supported by Grbl (i.e. exceeding 10 meters axis travel at 200 step/mm).
|
|
|
|
*/
|
2014-02-09 18:46:34 +01:00
|
|
|
float steps_remaining = prep.step_per_mm*mm_remaining; // Convert mm_remaining to steps
|
|
|
|
float n_steps_remaining = ceil(steps_remaining); // Round-up current steps remaining
|
|
|
|
float last_n_steps_remaining = ceil(prep.steps_remaining); // Round-up last steps remaining
|
|
|
|
prep_segment->n_step = last_n_steps_remaining-n_steps_remaining; // Compute number of steps to execute.
|
|
|
|
|
|
|
|
// Compute segment step rate. Since steps are integers and mm distances traveled are not,
|
|
|
|
// the end of every segment can have a partial step of varying magnitudes that are not
|
|
|
|
// executed, because the stepper ISR requires whole steps due to the AMASS algorithm. To
|
|
|
|
// compensate, we track the time to execute the previous segment's partial step and simply
|
|
|
|
// apply it with the partial step distance to the current segment, so that it minutely
|
|
|
|
// adjusts the whole segment rate to keep step output exact. These rate adjustments are
|
|
|
|
// typically very small and do not adversely effect performance, but ensures that Grbl
|
|
|
|
// outputs the exact acceleration and velocity profiles as computed by the planner.
|
|
|
|
dt += prep.dt_remainder; // Apply previous segment partial step execute time
|
|
|
|
float inv_rate = dt/(last_n_steps_remaining - steps_remaining); // Compute adjusted step rate inverse
|
|
|
|
prep.dt_remainder = (n_steps_remaining - steps_remaining)*inv_rate; // Update segment partial step time
|
|
|
|
|
|
|
|
// Compute CPU cycles per step for the prepped segment.
|
|
|
|
uint32_t cycles = ceil( (TICKS_PER_MICROSECOND*1000000*60)*inv_rate ); // (cycles/step)
|
2013-12-31 02:44:46 +01:00
|
|
|
|
2013-12-31 06:02:05 +01:00
|
|
|
#ifdef ADAPTIVE_MULTI_AXIS_STEP_SMOOTHING
|
|
|
|
// Compute step timing and multi-axis smoothing level.
|
2014-01-11 04:22:10 +01:00
|
|
|
// NOTE: AMASS overdrives the timer with each level, so only one prescalar is required.
|
2014-01-02 20:12:35 +01:00
|
|
|
if (cycles < AMASS_LEVEL1) { prep_segment->amass_level = 0; }
|
|
|
|
else {
|
|
|
|
if (cycles < AMASS_LEVEL2) { prep_segment->amass_level = 1; }
|
|
|
|
else if (cycles < AMASS_LEVEL3) { prep_segment->amass_level = 2; }
|
|
|
|
else { prep_segment->amass_level = 3; }
|
2013-12-31 02:44:46 +01:00
|
|
|
cycles >>= prep_segment->amass_level;
|
|
|
|
prep_segment->n_step <<= prep_segment->amass_level;
|
2014-01-02 20:12:35 +01:00
|
|
|
}
|
2013-12-31 06:02:05 +01:00
|
|
|
if (cycles < (1UL << 16)) { prep_segment->cycles_per_tick = cycles; } // < 65536 (4.1ms @ 16MHz)
|
|
|
|
else { prep_segment->cycles_per_tick = 0xffff; } // Just set the slowest speed possible.
|
|
|
|
#else
|
|
|
|
// Compute step timing and timer prescalar for normal step generation.
|
|
|
|
if (cycles < (1UL << 16)) { // < 65536 (4.1ms @ 16MHz)
|
|
|
|
prep_segment->prescaler = 1; // prescaler: 0
|
|
|
|
prep_segment->cycles_per_tick = cycles;
|
|
|
|
} else if (cycles < (1UL << 19)) { // < 524288 (32.8ms@16MHz)
|
|
|
|
prep_segment->prescaler = 2; // prescaler: 8
|
|
|
|
prep_segment->cycles_per_tick = cycles >> 3;
|
|
|
|
} else {
|
|
|
|
prep_segment->prescaler = 3; // prescaler: 64
|
|
|
|
if (cycles < (1UL << 22)) { // < 4194304 (262ms@16MHz)
|
|
|
|
prep_segment->cycles_per_tick = cycles >> 6;
|
2014-01-02 20:12:35 +01:00
|
|
|
} else { // Just set the slowest speed possible. (Around 4 step/sec.)
|
2013-12-31 06:02:05 +01:00
|
|
|
prep_segment->cycles_per_tick = 0xffff;
|
|
|
|
}
|
|
|
|
}
|
2013-12-31 02:44:46 +01:00
|
|
|
#endif
|
2013-12-30 04:34:51 +01:00
|
|
|
|
|
|
|
// Determine end of segment conditions. Setup initial conditions for next segment.
|
|
|
|
if (mm_remaining > prep.mm_complete) {
|
2014-02-09 18:46:34 +01:00
|
|
|
// Normal operation. Block incomplete. Distance remaining in block to be executed.
|
2013-12-30 04:34:51 +01:00
|
|
|
pl_block->millimeters = mm_remaining;
|
|
|
|
prep.steps_remaining = steps_remaining;
|
|
|
|
} else {
|
|
|
|
// End of planner block or forced-termination. No more distance to be executed.
|
|
|
|
if (mm_remaining > 0.0) { // At end of forced-termination.
|
2014-02-09 18:46:34 +01:00
|
|
|
// Reset prep parameters for resuming and then bail.
|
|
|
|
// NOTE: Currently only feed holds qualify for this scenario. May change with overrides.
|
2013-12-07 16:40:25 +01:00
|
|
|
prep.current_speed = 0.0;
|
2014-02-09 18:46:34 +01:00
|
|
|
prep.dt_remainder = 0.0;
|
2013-12-07 16:40:25 +01:00
|
|
|
prep.steps_remaining = ceil(steps_remaining);
|
2014-02-09 18:46:34 +01:00
|
|
|
pl_block->millimeters = prep.steps_remaining/prep.step_per_mm; // Update with full steps.
|
|
|
|
plan_cycle_reinitialize();
|
|
|
|
sys.state = STATE_QUEUED; // End cycle.
|
|
|
|
|
|
|
|
// TODO: Try to move QUEUED setting into cycle re-initialize.
|
|
|
|
|
2013-12-30 04:34:51 +01:00
|
|
|
} else { // End of planner block
|
|
|
|
// The planner block is complete. All steps are set to be executed in the segment buffer.
|
|
|
|
pl_block = NULL;
|
|
|
|
plan_discard_current_block();
|
Reinstated feed holds into new stepper algorithm and planner. Rough draft, but working.
- Reinstated the feed hold feature with the new stepper algorithm and
new optimized planner. It works, but will be re-factored a bit soon to
clean up the code.
- At this point, feedrate overrides may need to be installed in the
v1.0 version of grbl, while this version will likely be pushed to the
edge branch soon and pushed to master after the bugs have been squashed.
- Measured the overall performance of the new planner and stepper
algorithm on an oscilloscope. The new planner is about 4x faster than
before, where it is completing a plan in around 1ms. The stepper
algorithm itself is minutely faster, as it is a little lighter. The
trade-off in the increased planner performance comes from the new step
segment buffer. However, even in the worse case scenario, the step
segment buffer generates a new segment with a typical 0.2 ms, and the
worse case is 1ms upon a new block or replanning the active block.
Added altogether, it’s argubly still twice as efficient as the old one.
2013-12-05 05:49:24 +01:00
|
|
|
}
|
2013-10-30 02:10:39 +01:00
|
|
|
}
|
2013-12-30 04:34:51 +01:00
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// New step segment initialization completed. Increment segment buffer indices.
|
2013-10-30 02:10:39 +01:00
|
|
|
segment_buffer_head = segment_next_head;
|
|
|
|
if ( ++segment_next_head == SEGMENT_BUFFER_SIZE ) { segment_next_head = 0; }
|
|
|
|
|
2014-02-09 18:46:34 +01:00
|
|
|
if (sys.state == STATE_QUEUED) { return; } // Bail if hold completes
|
|
|
|
|
2013-11-23 01:35:58 +01:00
|
|
|
// int32_t blength = segment_buffer_head - segment_buffer_tail;
|
|
|
|
// if (blength < 0) { blength += SEGMENT_BUFFER_SIZE; }
|
|
|
|
// printInteger(blength);
|
2013-10-30 02:10:39 +01:00
|
|
|
}
|
|
|
|
}
|
2013-12-07 16:40:25 +01:00
|
|
|
|
|
|
|
/*
|
|
|
|
TODO: With feedrate overrides, increases to the override value will not significantly
|
2013-12-11 06:33:06 +01:00
|
|
|
change the current planner and stepper operation. When the value increases, we simply
|
2013-12-07 16:40:25 +01:00
|
|
|
need to recompute the block plan with new nominal speeds and maximum junction velocities.
|
|
|
|
However with a decreasing feedrate override, this gets a little tricky. The current block
|
|
|
|
plan is optimal, so if we try to reduce the feed rates, it may be impossible to create
|
|
|
|
a feasible plan at its current operating speed and decelerate down to zero at the end of
|
|
|
|
the buffer. We first have to enforce a deceleration to meet and intersect with the reduced
|
|
|
|
feedrate override plan. For example, if the current block is cruising at a nominal rate
|
|
|
|
and the feedrate override is reduced, the new nominal rate will now be lower. The velocity
|
|
|
|
profile must first decelerate to the new nominal rate and then follow on the new plan.
|
|
|
|
Another issue is whether or not a feedrate override reduction causes a deceleration
|
|
|
|
that acts over several planner blocks. For example, say that the plan is already heavily
|
|
|
|
decelerating throughout it, reducing the feedrate override will not do much to it. So,
|
|
|
|
how do we determine when to resume the new plan? One solution is to tie into the feed hold
|
|
|
|
handling code to enforce a deceleration, but check when the current speed is less than or
|
|
|
|
equal to the block maximum speed and is in an acceleration or cruising ramp. At this
|
|
|
|
point, we know that we can recompute the block velocity profile to meet and continue onto
|
|
|
|
the new block plan.
|
2013-12-11 06:33:06 +01:00
|
|
|
One "easy" way to do this is to have the step segment buffer enforce a deceleration and
|
|
|
|
continually re-plan the planner buffer until the plan becomes feasible. This can work
|
|
|
|
and may be easy to implement, but it expends a lot of CPU cycles and may block out the
|
|
|
|
rest of the functions from operating at peak efficiency. Still the question is how do
|
|
|
|
we know when the plan is feasible in the context of what's already in the code and not
|
|
|
|
require too much more code?
|
2013-12-07 16:40:25 +01:00
|
|
|
*/
|