Follow-up the PR #3643(Temperature singleton)
・Change from fanSpeedSoftPwm[0] to thermalManager.fanSpeedSoftPwm[0] in planner.cpp
It fix compilation error when FAN_SOFT_PWM is enabled.
・Remove declaration of setExtruderAutoFanState() in temperature.h
Because that function was abolished.
・Change from babystepsTodo to thermalManager.babystepsTodo in ultralcd.cpp
It fix compilation errors when BABYSTEPPING is enabled.
As noted by @darkjavi et.al. in #103, the E1 motor was not being enabled in planner.cpp when using DUAL_X_CARRIAGE. This patch enables and disables E1 as it should.
Elsewhere DRYRUN turns off the heating elements
and ignores constraints on them.
Here, whenever motion is entered into the planner,
if DRY RUN is set, we instantly act as if the E_AXIS
is in the desired final position.
@CONSULitAS
planner.cpp: Add FAN_MIN_PWM for slow fan stopping issue (V2.1 with
macro and linear scaling)
@thinkyhead thanks for idea on linear scaling
With these changes the output of `M503 S0` is all you need to restore
the EEPROM. Building on this it is straightforward to save and restore
the EEPROM state using the SD card or external GCode file.
- Added `M145` to set “heatup states” for the LCD menu
- Added `M420` to toggle Mesh Bed Leveling
- Added `M421` to set a single Mesh coordinate
- Extended `Config_PrintSettings` with added M codes
- Cleaned up some comments here and there
- 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
- 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
- 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
Added option to set Travel Acceleration (non printing moves).
The M204 options was a non sense (S for printing moves and T for retract
moves).
It has been changed to:
P = Printing moves
R = Retract only (no X, Y, Z) moves
T = Travel (non
printing) moves
I will add this info o G-Code wiki in reprap.org. I also advise to put
this info in Marlin next version changelog.
- Nonlinear auto bed leveling code (includes G29, G30, Z_RAISE_AFTER_PROBING). Cleaned it up to be a delta-specific AUTO_BED_LEVELING_GRID code path.
- Allen key z-probe deployment and retraction code. Cleaned it up and added safety checks.
For cartesian bots, the X_AXIS is the real X movement and same for
Y_AXIS.
But for corexy bots, that is not true. The "X_AXIS" and "Y_AXIS" motors
(that should be named to A_AXIS
and B_AXIS) cannot be used for X and Y length, because A=X+Y and B=X-Y.
So we need to create other 2 "AXIS", named X_HEAD and Y_HEAD, meaning
the real displacement of the Head.
Having the real displacement of the head, we can calculate the total
movement length and apply the desired speed.
Improvement to avoid reinitializing delay buffer with every print. Fixed
issues in buffer indexing and memory out of bounds due to floating point
imprecision. Simplified the code by avoiding conversion to standard
diameter and 1cu mm extrusion, which caused complications in determining
mm extruded.
This feature allows the printer to read the filament diameter
automatically and adjust the printer in real time. Added code to read
an analog voltage that represents a filament diameter measurement. This
measurement is delayed in a ring buffer to compensate for sensors that
are a distance away from the extruder. The measurement is used to
adjust the volumetric_multiplier for the extruder. Some additional g
codes (M404, M405, M406, M407) are used to set parameters and turn
on/off the control. g code M221 is updated. Pins for RAMPS1.4, RAMBO,
and Printrboard are identified for analog input. The configuration file
is updated with relevant user parameters.
Having the non-active feeder motors powered on all the time is not
necessary. A feature to deactivate the unused feeder motors has been
implemented. The feature is enabled on default but can be switched off
in the configuration.
Removed the calculation of the inverse matrix since the rotation matrix is orthogonal, therefore inverted == transposed.
Much simpler and mathematically robust.
Reviert previous change of #if BLAH_PIN > 0 to #if defined(BLAH_PIN) &&
BLAH_PIN > -1. Unfortunately some times pin 0 is used. For my sins I've
gone through and replaced all unsafe checks of #if BLAH_PIN > -1 with
the safe version.
Add new 'callback' edit-menu types that call a function after the edit is done. Use this to display and edit Ki and Kd correctly (removing the scaling first and reapplying it after). Also use it to reset maximum stepwise acceleration rates, after updating mm/s^2 rates via menus. (Previously, changes did nothing to affect planner unless saved back to EEPROM, and the machine reset).
Add calls to updatePID() so that PID loop uses updated values whether set by gcode (it already did this), or by restoring defaults, or loading from EEPROM (it didn't do those last two). Similarly, update the maximum step/s^2 accel rates when the mm/s^2 values are changed - whether by menu edits, restore defaults, or EEPROM read.
Refactor the acceleration rate update logic, and the PID scaling logic, into new functions that can be called from wherever, including the callbacks.
Add menu items to allow the z jerk and e jerk to be viewed/edited in the Control->Motion menu, as per xy jerk.
Conflicts:
Marlin/language.h
Add a feature to run the cooling fan at full speed for a small period
(default 100ms) when first starting the fan. Some fans wont reliably
start spinning at low power, and many fans have issue with the PWM at
low power. However, once the fan starts spinning it can reliably be
set to a wide range of PWM values.
Scott Lahteine