* K8200: new folder in example_configurations for Vellemann K8200 (3Drag
clone - should work with 3Drag too, please report)
* K8200/language.h: updated machine name and URL for K8200
* K8200/Configuration.h/Configuration_adv.h: updated manually with
parameters
form genuine Vellemann Firmware "firmware_k8200_marlinv2" based on the
recent development branch
* K8200/files by Vellemann: added folder with original files from
Vellemann homepage, since there is no GitHub fork you could link to by
them
I tested the changes on my K8200 with 20x4-LCD and Arduino 1.0.5 for
Windows - everything works well
* 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.
