* Adds config parameter `PID_PARAMS_PER_EXTRUDER` - allows single PID
parameters to be used where this would be preferable (e.g. dual
identical extruders)
* When disabled, will use `float Kp, Ki, Kd, Kc;` as before.
Preprocessor macros used to switch between.
* ultralcd.cpp defines extra menus for extra parameters only where
required
* M301 reports `e:xx` only if independent pid parameters enabled
* EEPROM structure still leaves space for 3 extruders worth, when undef
will save single parameter to all extruder positions, but only read the
first
* Switching off saves approx 330 B with no LCD enabled, 2634B with LCD
(RRD) enabled: this is significant.
* LCD modifications should be tested.
This change introduces an improvement to G29 command on Marlin.
Auto bed leveling operation's reliability is based on the repeatability of the Z-probe switch and the servo. This change introduces an option to G29 command. When the G29 command is sent with an "e" option, during auto bed levelling the servo is not retracted between probes which decreases the bias on auto bed levelling resulting from servo.
G29 command does the auto bed probing as it is.
G29 E command engages the servo on first probing point, probes all points and retracts the servo after probing the last point.
Please comment your opinions, test on your printer and check the code on a programmer's perspective. (I am not a good programmer.)
* Depending on extruder count, will add menu items for ultralcd to edit
individual PID parameters for each extruder
* Added menu items to each language_xx.h
* Builds OK, but recommend testing with typical LCD
* Variables Kp, Ki, Kd, Kc now arrays of size EXTRUDERS
* M301 gains (optional, default=0) E parameter to define which
extruder's settings to modify. Tested, works with Repetier Host's EEPROM
config window, albeit only reads/updates settings for E0.
* All Kp, Ki, Kd, Kc parameters saved in EEPROM (version now v14), up to
3 extruders supported (same as Marlin in general)
Small changes (and formatting to confuse the diff’er) which first
allows DOGLCD and LCD_PROGRESS_BAR to be enabled in tandem, then a
#warning (rather than error) that the extra progress bar / message
options don’t apply to graphical displays at this time. This leaves
open perhaps combining the progress bar and message area in some future
(or forked custom) graphical LCD display arrangement (at which time the
relevant variables may be moved into ultralcd.cpp with externs in
ultralcd.h). I also added a conditional error that the progress bar and
the filament display may not work well together.
logo is now 110 pixels wide and starts 9 pixels in from top left corner and also 9 pixels down from same corner... this will give a 9 pixel border all way round
ver info is placed centered and there is a 9 pixel from bottom of display to ver info
The previous calc was wrong. Between N points there are only N-1 gaps,
not N.
So changing AUTO_BED_LEVELING_GRID_POINTS to
(AUTO_BED_LEVELING_GRID_POINTS-1)
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.
try, try again.
If 'OK' is garbled on sending PC won't receive it. Both machines will
wait on each other forever. This resends OK if nothing is heard from PC
for a while to avoid this bad case.
The compiler does not support comparing float values: "error: floating constant in preprocessor expression"
The loss in X/Y precision shouldn't matter for Z probes, as most microswitches or inductive sensors are larger than 1mm square anyway.
The compiler does not support comparing float values: "error: floating constant in preprocessor expression"
The loss in X/Y precision shouldn't matter for Z probes, as most microswitches or inductive sensors are larger than 1mm square anyway.
Somehow the pin definitions for the MAX6675 Slave Select/Chip Select got changed back to the hardware SPI SS/CS.
Pin 49 cannot be used as that is used by the SD card socket to detect if an SD card is present.
Pin 53 is the Hardware SPI SS, which is dedicated, nicely, to the SD card SS and therefore cannot be used as the MAX6675 SS
Pin 66 is in Aux2 port adjacent to the Hardware SPI interface port on RAMPS 1.4, and is currently not used for anything.
This is the optimal code for a self-contained formatter, although the
original code is crafty in being smaller and simpler, and can be
evaluated as using the original output as a scratch pad for state,
making the final formatter more straightforward. While this code is
longer, all code-paths are minimal.
This is the optimal code for a self-contained formatter, although the
original code is crafty in being smaller and simpler, and can be
evaluated as using the original output as a scratch pad for state,
making the final formatter more straightforward. While this code is
longer, all code-paths are minimal.
Bo Herrmannsen