See if this has any deleterious effect on motion planning by slicers that inser their own jerk and acceleration controls. The problem I see is that these settings can take effect on blocks already in the planner, and the only way around this would be to shadow these settings in planner blocks and use the shadowed settings in the planner.
* Clean up Temperature PID
* Improve EEPROM read/write/validate
* Group `SINGLENOZZLE` saved settings
* Group planner saved settings
* Group filament change saved settings
* Group skew saved settings
* Group `FWRETRACT` saved settings
- Move FWRETRACT to the planner
- Combine leveling, skew, etc. in a single modifier method
- Have kinematic and non-kinematic moves call one planner method
- Drop `max_jerk` with `JUNCTION_DEVIATION`
- Add `max_e_jerk_factor` for use by `LIN_ADVANCE`
- Recalculate `max_e_jerk_factor` when `junction_deviation_mm` changes
- Fix LCD editing of `junction_deviation_mm`
* Automatically reset stepper timeout in manage_inactivity
Any code that adds moves to the planner can skip resetting the stepper timeout. We can let `idle` / `manage_inactivity` reset the timer whenever it detects any moves in the planner.
* blocks_queued => has_blocks_queued
`M204` is often used by slicers to set acceleration depending on perimeter, infill, etc., so Marlin's answers are flooding the serial windows. Silence `M204` according to the philosophy that setter commands should only send a reply if no parameter is given.
* Merging early because of build failures. See #8105
* Make LPC1768 pinmapping not specific to Re-ARM
* Add HAL_PIN_TYPE and LPC1768 pin features
* M43 Updates
* Move pin map into pinsDebug_LPC1768.h
* Incorporate comments and M226
* Fix persistent store compilation issues
* Update pin features
* Update MKS SBASE pins
* Use native LPC1768 pin numbers in M42, M43, and M226
Scott Lahteine
Scott Lahteine
InsanityAutomation
Thomas Moore
scott0122
Jan
etagle
Andy Shaw
GMagician
Sebastianv650
Bob-the-Kuhn
Thomas Moore