- Fix `prepare_move` function not calling `adjust_delta`
- Add more shorthand for plan_buffer_line.
- Fix wrong `federate` usage, assuming they are all mm/m
- Minor `stepper.cpp` cleanup

- Add some documentation to planner and stepper headers
- Patch up RAMBO pins with undefs
- Add `sync_plan_position` inline to set current XYZE
- Swap indices in `extruder_offset` to fix initialization values

- Patched up for most included configurations

- Fix a bug reading `code_value` for `M503 Sn`
- Hide and remove unused variables

Z_DUAL_ENDSTOPS is a feature to enable the use of 2 endstops for both Z
steppers - Let's call them Z stepper and Z2 stepper.
That way the machine is capable to align the bed during home, since both
Z steppers are homed.
There is also an implementation of M666 (software endstops adjustment)
to this feature.
After Z homing, this adjustment is applied to just one of the steppers
in order to align the bed.
One just need to home the Z axis and measure the distance difference
between both Z axis and apply the math: Z adjust = Z - Z2.
If the Z stepper axis is closer to the bed, the measure Z > Z2 (yes, it
is.. think about it) and the Z adjust would be positive.
Play a little bit with small adjustments (0.5mm) and check the
behaviour.
The M119 (endstops report) will start reporting the Z2 Endstop as well.

- Patch up macros in stepper.cpp

- Use named axis indexes, `X_AXIS` etc.
- Replace `block.steps_A` with block.steps[A]`
- Replace `A_segment_time` with `segment_time[A]`
- Add `A_AXIS`, `B_AXIS` for `COREXY` axes
- Conditional compile based on `EXTRUDERS`
- Add BLOCK_MOD macro for planner block indexes
- Apply coding standards to `planner.h` and `planner.cpp`
- Small optimizations of planner code
- Update `stepper.cpp` for new `block` struct
- Replace `memcpy` with loops, let the compiler unroll them
- Make `movesplanned` into an inline function

- Addressing #1625

- Add `Conditionals.h` with calculated configuration values
- Add `SanityCheck.h` with checks for configuration errors
- Remove equivalent code from all configurations
- Move error checks from some sources to `SanityCheck.h` also
- Fix initialization of count_direction in stepper.cpp

When one hit "Stop Print" option in LCD menu, the command buffer was not
cleared. The printer keep moving until the buffer has been emptied.
Actually I could not clear the command buffer as well.. I don't know
why, it doesnt work as expected.
I need to implement a routine inside Stepper ISR to handle such
situation.

The Check Endstop logic must be:

if (current_block->steps_x != current_block->steps_y || (TEST(out_bits,
X_AXIS) == TEST(out_bits, Y_AXIS)))
if (TEST(out_bits, X_HEAD))

not

if (TEST(out_bits, X_HEAD) && (current_block->steps_x !=
current_block->steps_y || (TEST(out_bits, X_AXIS) == TEST(out_bits,
Y_AXIS))))

Same applies for Y axis.

- Add BIT and TEST macros
- Add _APPLY_ macros to stepper.cpp to help with consolidation
- Consolidate code in stepper.cpp using macros
- Apply standards in stepper.cpp
- Use >= 0 instead of > -1 as a better semantic
- Replace DUAL_Y_CARRIAGE with Y_DUAL_STEPPER_DRIVERS

- Moved sanity-checks to Marlin_main.cpp
- Applied to other configuration files
- Fixed formatting of ABL output
- Passing verbose level to probe_pt
- Miscellaneous cleanup
- Put CONFIG_STEPPERS_TOSHIBA into Configuration.h

The X_Axis could not home to min while Y_Max endstop was trigged.

- Both TMC, L6470 and pin-driven drivers work.
- All can be mixed and matched as needed.

Fixed how stepper ISR figure it out when the head (extruder) is going to
Min or Max direction.
Added Homing to Max Endstops.

removed function step_wait() from stepper.cpp because its used nowhere.

Issue #1385 describes a delay that the compiler is optimizing out and
this solution.

Tosh stepper drivers need to be driven slower, so the stepper code
was interleaved to separate the pin HIGH from the pin LOW. This adds
enough instructions to make it work, without needing nops.

This reverts commit eea3ba5588.

This reverts commit 2715f6ddbf.

also, removed some trouble for compilation with corexy.
I think that babystepping is only possible in z for a delta tower.
not sure if it would be usefull to step individual motors on a delta, i don't own one

It is a realtime control over the head position via the LCD menu system that works _while_ printing.
Using it, one can e.g. tune the z-position in realtime, while printing the first layer.
Also, lost steps can be manually added/removed, but thats not the prime feature.
Stuff is placed into the Tune->Babystep *

It is not possible to have realtime control via gcode sending due to the buffering, so I did not include a gcode yet. However, it could be added, but it movements will not be realtime then.

Historically, a very similar thing was implemented for the "Kaamermaker" project, while Joris was babysitting his offspring, hence the name.

say goodby to fuddling around with the z-axis.

Check the Readme for instruction how to enable and configure the feature

Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped in either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)

This reverts commit 7ee275b620.

Enables two stepper drivers to be used for the Y axis (useful for
Shapeoko style machines)
Each Y driver can be stepped either the same way or in opposite
directions, accounting for different hardware setups (leadscrew vs. belt
driven)