chamnit/grbl — pull request #4 by jgeisler0303 (2011-11-18 14:42:57+00:00)
Title: Improved Planner

Hi, here is an attempt to merge my planner with your latest edge branch.
The new planner will only loop in reverse direction until the buffer tail or one of the following conditions are met:

* A block is an all acceleration block, this is flagged the by 'calculate_trapezoid_for_block'. Since the planner will always attempt to raise the entry and exit speed of a block, there is nothing it can do to an all acceleration block: the exit speed is already at its max given the entry speed and the entry speed can be assumed to be at its max too because it must have been maximized previously in order for the current block to become an all acceleration block.
* The exit speed of a block is already at its max.
* A block has reached its nominal speed. This implies that all previous block must have been maximized prior to this block.

My simulations show that this scheme often leads to only three or four blocks (depending on acceleration, nominal speed and line length) being re-planned.

Once the reverse loop is finished, the forward loop will start. The forward loop now integrates the calculation of 'max_allowable_speed' and 'calculate_trapezoid_for_block'.

To be able to touch the buffer tail (block currently being executed) a new flag is introduced: 'st_accelerating'. It indicates if the stepper is still in the acceleration phase or not. Since the planner will always try to prolong the acceleration phase a block can be touched if its acceleration phase is still in progress. To make the test and changes atomic, they are wrapped in cli()...sei(). This is done inside 'calculate_trapezoid_for_block' because it is only here that stepper relevant data (integer types) are changed. All the 'double' data that have been calculated up until this point are temporary and only max values from a deceleration point of view. So, if 'calculate_trapezoid_for_block' detects that, in the last microsecond, the stepper has reached the end of the acceleration phase, everything can still be unrolled and the planner tries to prolong acceleration (or nominal speed) with the next block.

Of course, if the acceleration phase of the tail block has already ended, one could still try to postpone the deceleration phase in case the block has a plateau phase. But think that would be overkill.

Other small things have changed in the hope make an improvement:

* Disabling the acceleration manager is no longer needed
* The unit vector is calculated based on the floating point positions to smooth things even more (remember our discussion about constant small speed changed in an arc?).
* A 'rate_factor' was added to the block data to eliminate the two divisions 'current->entry_speed/current->nominal_speed,' and 'next->entry_speed/current->nominal_speed' in the planner loop.
* Moved the disabling of the stepper interrupt ahead of 'STEPPER_IDLE_LOCK_TIME' to make sure the stepping stops immediately.

Unfortunately I have only tested successful compilation of the code but not its correct functioning. I hope to do that this WE.