docs: Update release notes for v0.8.0 release

Signed-off-by: Kevin O'Connor <kevin@koconnor.net>

.gitignore

@@ -3,3 +3,4 @@ out
 *.pyc
 .config
 .config.old
+klippy/.version

.travis.yml

@@ -4,9 +4,22 @@ language: c
 addons:
   apt:
     packages:
+      # AVR GCC packages
       - gcc-avr
       - avr-libc
-            - wget
+      # PRU GCC build packages
+      - pv
+      - libmpfr-dev
+      - libgmp-dev
+      - libmpc-dev
+      - texinfo
+      - libncurses5-dev
+      - bison
+      - flex
+
+cache:
+  directories:
+  - travis_cache
 
 install: ./scripts/travis-install.sh
 

Makefile

@@ -1,6 +1,6 @@
 # Klipper build system
 #
-# Copyright (C) 2016,2017  Kevin O'Connor <kevin@koconnor.net>
+# Copyright (C) 2016-2019  Kevin O'Connor <kevin@koconnor.net>
 #
 # This file may be distributed under the terms of the GNU GPLv3 license.
 
@@ -32,11 +32,13 @@ dirs-y = src
 cc-option=$(shell if test -z "`$(1) $(2) -S -o /dev/null -xc /dev/null 2>&1`" \
     ; then echo "$(2)"; else echo "$(3)"; fi ;)
 
-CFLAGS := -I$(OUT) -Isrc -I$(OUT)board-generic/ -O2 -MD -g \
+CFLAGS := -I$(OUT) -Isrc -I$(OUT)board-generic/ -std=gnu11 -O2 -MD -g \
     -Wall -Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \
     -ffunction-sections -fdata-sections
 CFLAGS += -flto -fwhole-program -fno-use-linker-plugin
 
+OBJS_klipper.elf = $(patsubst %.c, $(OUT)src/%.o,$(src-y))
+OBJS_klipper.elf += $(OUT)compile_time_request.o
 CFLAGS_klipper.elf = $(CFLAGS) -Wl,--gc-sections
 
 CPPFLAGS = -I$(OUT) -P -MD -MT $@
@@ -64,28 +66,35 @@ $(OUT)%.o: %.c $(OUT)autoconf.h $(OUT)board-link
 	@echo "  Compiling $@"
 	$(Q)$(CC) $(CFLAGS) -c $< -o $@
 
+$(OUT)%.ld: %.lds.S $(OUT)board-link
+	@echo "  Preprocessing $@"
+	$(Q)$(CPP) -I$(OUT) -P -MD -MT $@ $< -o $@
+
 ################ Main build rules
 
 $(OUT)board-link: $(KCONFIG_CONFIG)
 	@echo "  Creating symbolic link $(OUT)board"
 	$(Q)mkdir -p $(addprefix $(OUT), $(dirs-y))
 	$(Q)touch $@
-	$(Q)ln -Tsf $(PWD)/src/$(CONFIG_BOARD_DIRECTORY) $(OUT)board
+	$(Q)rm -f $(OUT)board
+	$(Q)ln -sf $(PWD)/src/$(CONFIG_BOARD_DIRECTORY) $(OUT)board
 	$(Q)mkdir -p $(OUT)board-generic
-	$(Q)ln -Tsf $(PWD)/src/generic $(OUT)board-generic/board
+	$(Q)rm -f $(OUT)board-generic/board
+	$(Q)ln -sf $(PWD)/src/generic $(OUT)board-generic/board
 
 $(OUT)%.o.ctr: $(OUT)%.o
 	$(Q)$(OBJCOPY) -j '.compile_time_request' -O binary $^ $@
 
 $(OUT)compile_time_request.o: $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) ./scripts/buildcommands.py
 	@echo "  Building $@"
-	$(Q)cat $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) > $(OUT)klipper.compile_time_request
+	$(Q)cat $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) | tr -s '\0' '\n' > $(OUT)compile_time_request.txt
-	$(Q)$(PYTHON) ./scripts/buildcommands.py -d $(OUT)klipper.dict -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(OBJDUMP);$(STRIP)" $(OUT)klipper.compile_time_request $(OUT)compile_time_request.c
+	$(Q)$(PYTHON) ./scripts/buildcommands.py -d $(OUT)klipper.dict -t "$(CC);$(AS);$(LD);$(OBJCOPY);$(OBJDUMP);$(STRIP)" $(OUT)compile_time_request.txt $(OUT)compile_time_request.c
 	$(Q)$(CC) $(CFLAGS) -c $(OUT)compile_time_request.c -o $@
 
-$(OUT)klipper.elf: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)compile_time_request.o
+$(OUT)klipper.elf: $(OBJS_klipper.elf)
 	@echo "  Linking $@"
-	$(Q)$(CC) $^ $(CFLAGS_klipper.elf) -o $@
+	$(Q)$(CC) $(OBJS_klipper.elf) $(CFLAGS_klipper.elf) -o $@
+	$(Q)scripts/check-gcc.sh $@ $(OUT)compile_time_request.o
 
 ################ Kconfig rules
 

README.md

@@ -1,29 +1,16 @@
 Welcome to the Klipper project!
 
-This project implements a 3d-printer firmware. There are two parts to
+[![Klipper](docs/img/klipper-logo-small.png)](https://www.klipper3d.org/)
-this firmware - code that runs on a micro-controller and code that
-runs on a host machine. The host software does the work to build a
-schedule of events, while the micro-controller software does the work
-to execute the provided schedule at the specified times.
 
-See the [features](docs/Features.md) document to find out why you
+https://www.klipper3d.org/
-should use Klipper. To begin using Klipper start by
-[installing](docs/Installation.md) it.
 
-There is also [developer documentation](docs/Overview.md) available.
+Klipper is a 3d-Printer firmware. It combines the power of a general
+purpose computer with one or more micro-controllers. See the
+[features document](https://www.klipper3d.org/Features.html) for more
+information on why you should use Klipper.
 
-License
+To begin using Klipper start by
-=======
+[installing](https://www.klipper3d.org/Installation.html) it.
 
-Klipper is free software: you can redistribute it and/or modify
+Klipper is Free Software. See the [license](COPYING) or read the
-it under the terms of the GNU General Public License as published by
+[documentation](https://www.klipper3d.org/Overview.html).
-the Free Software Foundation, either version 3 of the License, or
-(at your option) any later version.
-
-Klipper is distributed in the hope that it will be useful,
-but WITHOUT ANY WARRANTY; without even the implied warranty of
-MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License
-along with Klipper.  If not, see <http://www.gnu.org/licenses/>.

config/example-delta.cfg

@@ -113,19 +113,13 @@ delta_radius: 174.75
 # angles.
 [delta_calibrate]
 radius: 50
-#   Radius (in mm) of the area that may be probed. This is typically
+#   Radius (in mm) of the area that may be probed. This is the radius
-#   the size of the printer bed. This parameter must be provided.
+#   of nozzle coordinates to be probed; if using an automatic probe
+#   with an XY offset then choose a radius small enough so that the
+#   probe always fits over the bed. This parameter must be provided.
 #speed: 50
-#   The speed (in mm/s) of non-probing moves during the
+#   The speed (in mm/s) of non-probing moves during the calibration.
-#   calibration. The default is 50.
+#   The default is 50.
 #horizontal_move_z: 5
 #   The height (in mm) that the head should be commanded to move to
 #   just prior to starting a probe operation. The default is 5.
-#manual_probe:
-#   If true, then DELTA_CALIBRATE will perform manual probing. If
-#   false, then a PROBE command will be run at each probe
-#   point. Manual probing is accomplished by manually jogging the Z
-#   position of the print head at each probe point and then issuing a
-#   NEXT extended g-code command to record the position at that
-#   point. The default is false if a [probe] config section is present
-#   and true otherwise.

config/example-menu.cfg

@@ -0,0 +1,205 @@
+# This file serves as documentation for config parameters. One may
+# copy and edit this file to configure a new menu layout.
+# The snippets in this file may be copied into the main printer.cfg file.
+# See the "example.cfg" file for description of common config parameters.
+
+# Available menu elements:
+#   item - purely visual element
+#   command - same like 'item' but with gcode trigger
+#   input - same like 'command' but has value changing capabilities
+#   list - menu element container, with entry and exit gcode triggers
+#   vsdcard - same as 'list' but will append files from virtual sdcard
+#   deck - special container for custom screens (cards) has entry and exit gcode triggers.
+#   card - special content card for custom screens. Can only be used in 'deck'!
+
+#[menu item1]
+#type: item
+#   Type will determine menu item properties and behaviours:
+#name:
+#   This is mandatory attribute for every menu element.
+#   You can use Python output formatting for parameter and transform values.
+#   Quotes can be used in the beginning and end of name.
+#cursor:
+#   It allows to change cursor character for selected menu element.
+#   The default is >
+#   This parameter is optional.
+#width:
+#   This attribute accepts integer value. Element name is cut to this width.
+#   This parameter is optional.
+#scroll:
+#   This attribute accepts static boolean value. You can use it together with 'width'.
+#   When this is enabled then names longer than width are scrolled back and forth.
+#   The default is disabled. This parameter is optional.
+#enable:
+#   This attribute accepts static boolean values and parameters (converted to boolean).
+#   It accepts multiple logical expressions. Values separated by comma will return True if all elements are true.
+#   Values on different lines will return True if any element is true.
+#   You can use logical negation by using character ! as parameter prefix.
+#parameter:
+#   This attribute accepts float values or special variables. Multiple values are delimited by comma.
+#   All available parameter variables can be listed by 'MENU DO=dump' gcode, menu itself must be running.
+#   This value is available for output formatting as {0}..{n} Where n is count of parameters.
+#transform:
+#   This attribute allows to transform parameters value to something else.
+#   More than one transformation can be added. Each transformation must be on separate line.
+#   These transformed values are available for output formatting as {n+1}..{x}
+#   Where n is count of parameters and x is count of transformations.
+#   In order to transform the value of a particular parameter, you must add
+#   an parameter index as prefix. Like this "transform: 1.choose('OFF','ON')"
+#   If the index is not set then the default index 0 is used.
+#
+#   map(fromLow,fromHigh,toLow,toHigh) - interpolate re-maps a parameter value from one range to another.
+#   Output value type is taken from toHigh. It can be int or float.
+#
+#   choose(e1,e2) - boolean chooser, converts the value of the parameter to the boolean type (0 and 1),
+#   and selects the corresponding value by the index from the list.
+#
+#   choose(e1,e2,...) - int chooser, converts the value of the parameter to the int type
+#   and selects the corresponding value by the index from the list.
+#
+#   choose({key:value,..}) - special dictionary chooser, parameter value cast type by first key type.
+#   Selects the corresponding value by the key from the dictionary.
+#
+#   int(), float(), bool(), str(), abs(), bin(), hex(), oct(), days(), hours(), minutes(), seconds()
+#   These will convert parameter value to the special form.
+#   int,float,bool,str,abs,bin,hex and oct are python functions.
+#   days,hours,minutes,seconds will convert parameter value (it's taken as seconds) to time specific value
+#
+#   scale(xx) - Multiplies parameter value by this xx. Pure interger or float value is excpected.
+
+
+#[menu command1]
+#type:command
+#name:
+#cursor:
+#width:
+#scroll:
+#enable:
+#parameter:
+#transform:
+#gcode:
+#   When menu element is clicked then gcodes on this attribute will be executed.
+#   Can have multiline gcode script and supports output formatting for parameter and transform values.
+#action:
+#   Special action can be executed. Supports [back, exit] menu commands
+#   and [respond response_info] command. Respond command will send '// response_info' to host.
+
+#[menu input1]
+#type: input
+#name:
+#cursor:
+#width:
+#enable:
+#transform:
+#parameter:
+#   Value from parameter (always index 0) is taken as input value when in edit mode.
+#gcode:
+#   This will be triggered in realtime mode, on exit from edit mode
+#   or in edit mode this will be triggered after click button long press (>0.8sec).
+#longpress_gcode:
+#   In edit mode this will be triggered after click button long press (>0.8sec).
+#   The default is empty. This parameter is optional.
+#reverse:
+#   This attribute accepts static boolean value.
+#   When enabled it will reverse increment and decrement directions for input.
+#   The default is False. This parameter is optional.
+#readonly:
+#   This attribute accepts same logical expression as 'enable'.
+#   When true then input element is readonly like 'item' and cannot enter to edit mode.
+#   The default is False. This parameter is optional.
+#realtime:
+#   This attribute accepts static boolean value.
+#   When enabled it will execute gcode after each value change.
+#   The default is False. This parameter is optional.
+#input_min:
+#   It accepts integer or float value. Will set minimal bound for edit value.
+#   The default is 2.2250738585072014e-308. This parameter is optional.
+#input_max:
+#   It accepts integer or float value. Will set maximal bound for edit value.
+#   The default is 1.7976931348623157e+308. This parameter is optional.
+#input_step:
+#   This is mandatory attribute for input.
+#   It accepts positive integer or float value. Will determine increment
+#   and decrement steps for edit value.
+#input_step2:
+#   This is optional attribute for input.
+#   It accepts positive integer or float value. Will determine fast rate
+#   increment and decrement steps for edit value.
+#   The default is 0 (input_step will be used instead)
+
+#[menu list1]
+#type:list or vsdcard
+#name:
+#cursor:
+#width:
+#scroll:
+#enable:
+#enter_gcode:
+#   Will trigger gcode script when entering to this menu container.
+#   This parameter is optional.
+#leave_gcode:
+#   Will trigger gcode script when leaving from this menu container.
+#   This parameter is optional.
+#show_back:
+#   This attribute accepts static boolean value.
+#   Show back [..] as first element.
+#   The default is True. This parameter is optional.
+#show_title:
+#   This attribute accepts static boolean value.
+#   Show container name next to back [..] element.
+#   The default is True. This parameter is optional.
+#items:
+#   Menu elements listed in this container.
+#   Each element must be on separate line.
+#   Elements can be grouped on same line by separating them with comma
+#
+#   When element name stars with . then menu system will add parent
+#   container config name as prefix to element name (delimited by space)
+
+#[menu infodeck]
+#type: deck
+#name:
+#cursor:
+#width:
+#scroll:
+#enable:
+#enter_gcode
+#leave_gcode
+#longpress_menu:
+#   Entry point to menu container. When this attribute is set then
+#   long press > 0.8s will initiate this menu container if not in edit mode.
+#   The default is disabled. This parameter is optional.
+#items:
+#   It accepts only 'card' elements. You are able to switch between different card screens
+#   by using encoder or up/down buttons.
+#content:
+#   It allows quickly define single card decks by adding content directly to deck.
+#   You have to remove deck item attribute and use named items in content.
+#   The menu functionality will then internally create one card item for this deck.
+#   This is optional.
+
+#[menu card1]
+#type: card
+#name:
+#content:
+#   Card screen content. Each line represents display line.
+#   Quotes can be used in the beginning and end of line.
+#   Rendered elements are available for output formatting as {0}..{x}. It's always string type.
+#   It's possible directly use menu item names in content by leaving items attribute out or empty
+#   and use menu items names directly in content as {msg,xpos|ypos}. The menu functionality will then
+#   internally build a item list and replace names with indexes in content.
+#   This is optional.
+#items:
+#   List of elements in card. Each line represents a single index for content formatting.
+#   It's possible to show multiple elements in one place by separating them with comma on single line.
+#   If first element is integer then timed cycle is used (integer value is cycle time in seconds)
+#   If no integer element then first enabled element is shown.
+#   In cycler multiple elements can be grouped into one postition by separating them with |
+#   This way only simple menu items can be grouped.
+#   Example: 5,prt_time, prt_progress - elements prt_time and prt_progress are switched after 5s
+#   Example: msg,xpos|ypos - elements xpos and ypos are grouped and showed together when msg is disabled.
+#use_cursor:
+#   This attribute accepts static boolean value.
+#   When enabled the menu system uses a cursor instead of blinking to visualize item selection
+#   and edit mode for this card. Cursor and placeholder is always added as item name prefix.
+#   The default is False. This parameter is optional.

config/example-multi-mcu.cfg

@@ -9,17 +9,17 @@
 # micro-controllers on the printer. Typically, both the X and Y axes
 # are connected to the main micro-controller.
 [mcu]
-serial: /dev/ttyACM0
+serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0
 pin_map: arduino
 
 # The "zboard" micro-controller will be used to control the Z axis.
 [mcu zboard]
-serial: /dev/ttyACM1
+serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
 pin_map: arduino
 
 # The "auxboard" micro-controller will be used to control the heaters.
 [mcu auxboard]
-serial: /dev/ttyACM2
+serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0
 pin_map: arduino
 
 [stepper_x]

config/example-polar.cfg

@@ -0,0 +1,84 @@
+# This file serves as documentation for config parameters of "polar"
+# style printers. One may copy and edit this file to configure a new
+# polar printer.
+
+# POLAR KINEMATICS ARE A WORK IN PROGRESS. Moves around the 0,0
+# position are known to not work properly.
+
+# Only parameters unique to polar printers are described here - see
+# the "example.cfg" file for description of common config parameters.
+
+# The stepper_bed section is used to describe the stepper controlling
+# the bed.
+[stepper_bed]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: 0.001963495
+#   On a polar printer the step_distance is the amount each step pulse
+#   moves the bed in radians (for example, a 1.8 degree stepper with
+#   16 micro-steps would be 2 * pi * (1.8 / 360) / 16 == 0.001963495).
+#   This parameter must be provided.
+
+# The stepper_arm section is used to describe the stepper controlling
+# the carriage on the arm.
+[stepper_arm]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .01
+endstop_pin: ^ar14
+position_endstop: 300
+position_max: 300
+homing_speed: 50
+
+# The stepper_z section is used to describe the stepper controlling
+# the Z axis.
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^ar18
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .0022
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: polar
+#   This option must be "polar" for polar printers.
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30

config/example-winch.cfg

@@ -0,0 +1,96 @@
+# This file serves as documentation for config parameters of cable
+# winch style printers. One may copy and edit this file to configure a
+# new cable winch printer.
+
+# CABLE WINCH SUPPORT IS EXPERIMENTAL - PROCEED WITH CAUTION!
+
+# Homing is not implemented on cable winch kinematics. In order to
+# home the printer, manually send movement commands until the toolhead
+# is at 0,0,0 and then issue a G28 command.
+
+# Only parameters unique to cable winch printers are described here -
+# see the "example.cfg" file for description of common config
+# parameters.
+
+# The stepper_a section describes the stepper connected to the first
+# cable winch. A minimum of 3 and a maximum of 26 cable winches may be
+# defined (stepper_a to stepper_z) though it is common to define 4.
+[stepper_a]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: .01
+#   The step_distance is the nominal distance (in mm) the toolhead
+#   moves towards the cable winch on each step pulse. This parameter
+#   must be provided.
+anchor_x: 0
+anchor_y: -2000
+anchor_z: -100
+#   The x, y, and z position of the cable winch in cartesian space.
+#   These parameters must be provided.
+
+[stepper_b]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .01
+anchor_x: 2000
+anchor_y: 1000
+anchor_z: -100
+
+[stepper_c]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .01
+anchor_x: -2000
+anchor_y: 1000
+anchor_z: -100
+
+[stepper_d]
+step_pin: ar36
+dir_pin: ar34
+enable_pin: !ar30
+step_distance: .01
+anchor_x: 0
+anchor_y: 0
+anchor_z: 3000
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .0022
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: watermark
+min_temp: 0
+max_temp: 130
+
+# Print cooling fan (omit section if fan not present).
+#[fan]
+#pin: ar9
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: winch
+#   This option must be "winch" for cable winch printers.
+max_velocity: 300
+max_accel: 3000

config/example.cfg

@@ -11,11 +11,13 @@
 # A note on pin names: pins may be configured with a hardware name
 # (such as "PA4") or with an Arduino alias name (such as "ar29" or
 # "analog3"). In order to use Arduino names, the pin_map variable in
-# the mcu section must be present and have a value of "arduino".
+# the mcu section must be present and have a value of "arduino". Pin
-# Pin names may be preceded by an '!' to indicate that a reverse
+# names may be preceded by an '!' to indicate that a reverse polarity
-# polarity should be used (eg, trigger on low instead of high). Input
+# should be used (eg, trigger on low instead of high). Input pins may
-# pins may be preceded by a '^' to indicate that a hardware pull-up
+# be preceded by a '^' to indicate that a hardware pull-up resistor
-# resistor should be enabled for the pin.
+# should be enabled for the pin. If the micro-controller supports
+# pull-down resistors then an input pin may alternatively be preceded
+# by a '~'.
 
 
 # The stepper_x section is used to describe the stepper controlling
@@ -28,7 +30,8 @@ dir_pin: ar55
 #   parameter must be provided.
 enable_pin: !ar38
 #   Enable pin (default is enable high; use ! to indicate enable
-#   low). If this parameter is not provided then the stepper motor
+#   low). Alternatively, this may be a comma separated list of pins to
+#   enable. If this parameter is not provided then the stepper motor
 #   driver must always be enabled.
 step_distance: .0225
 #   Distance in mm that each step causes the axis to travel. This
@@ -51,7 +54,11 @@ position_max: 200
 #   is 5mm/s.
 #homing_retract_dist: 5.0
 #   Distance to backoff (in mm) before homing a second time during
-#   homing. The default is 5mm.
+#   homing. Set this to zero to disable the second home. The default
+#   is 5mm.
+#second_homing_speed:
+#   Velocity (in mm/s) of the stepper when performing the second home.
+#   The default is homing_speed/2.
 #homing_positive_dir:
 #   If true, homing will cause the stepper to move in a positive
 #   direction (away from zero); if false, home towards zero. The
@@ -96,29 +103,28 @@ nozzle_diameter: 0.500
 #   Diameter of the nozzle orifice (in mm). This parameter must be
 #   provided.
 filament_diameter: 3.500
-#   Diameter of the raw filament (in mm) as it enters the
+#   The nominal diameter of the raw filament (in mm) as it enters the
 #   extruder. This parameter must be provided.
 #max_extrude_cross_section:
-#   Maximum area of the cross section of an extrusion line (in
+#   Maximum area (in mm^2) of an extrusion cross section (eg,
-#   mm^2). This setting prevents excessive amounts of extrusion during
+#   extrusion width multiplied by layer height). This setting prevents
-#   relatively small XY moves. If a move requests an extrusion rate
+#   excessive amounts of extrusion during relatively small XY moves.
-#   that would exceed this value it will cause an error to be
+#   If a move requests an extrusion rate that would exceed this value
-#   returned. The default is: 4.0 * nozzle_diameter^2
+#   it will cause an error to be returned. The default is: 4.0 *
+#   nozzle_diameter^2
 #max_extrude_only_distance: 50.0
-#   Maximum length (in mm of raw filament) that an extrude only move
+#   Maximum length (in mm of raw filament) that a retraction or
-#   may be. If an extrude only move requests a distance greater than
+#   extrude-only move may have. If a retraction or extrude-only move
-#   this value it will cause an error to be returned. The default is
+#   requests a distance greater than this value it will cause an error
-#   50mm.
+#   to be returned. The default is 50mm.
 #max_extrude_only_velocity:
-#   Maximum velocity (in mm/s) of the extruder motor for extrude only
-#   moves. If this is not specified then it is calculated to match the
-#   limit an XY printing move with a max_extrude_cross_section
-#   extrusion would have.
 #max_extrude_only_accel:
-#   Maximum acceleration (in mm/s^2) of the extruder motor for extrude
+#   Maximum velocity (in mm/s) and acceleration (in mm/s^2) of the
-#   only moves. If this is not specified then it is calculated to
+#   extruder motor for retractions and extrude-only moves. These
-#   match the limit an XY printing move with a
+#   settings do not place any limit on normal printing moves. If not
-#   max_extrude_cross_section extrusion would have.
+#   specified then they are calculated to match the limit an XY
+#   printing move with a cross section of 4.0*nozzle_diameter^2 would
+#   have.
 #pressure_advance: 0.0
 #   The amount of raw filament to push into the extruder during
 #   extruder acceleration. An equal amount of filament is retracted
@@ -146,8 +152,12 @@ heater_pin: ar10
 #   periods) to the heater. The default is 1.0.
 sensor_type: EPCOS 100K B57560G104F
 #   Type of sensor - this may be "EPCOS 100K B57560G104F", "ATC
-#   Semitec 104GT-2", "NTC 100K beta 3950", or "AD595". This parameter
+#   Semitec 104GT-2", "NTC 100K beta 3950", "Honeywell 100K
-#   must be provided.
+#   135-104LAG-J01", "NTC 100K MGB18-104F39050L32", "AD595", "PT100
+#   INA826", "MAX6675", "MAX31855", "MAX31856", or "MAX31865".
+#   Additional sensor types may be available - see the
+#   example-extras.cfg file for details. This parameter must be
+#   provided.
 sensor_pin: analog13
 #   Analog input pin connected to the sensor. This parameter must be
 #   provided.
@@ -155,9 +165,18 @@ sensor_pin: analog13
 #   The resistance (in ohms) of the pullup attached to the
 #   thermistor. This parameter is only valid when the sensor is a
 #   thermistor. The default is 4700 ohms.
+#inline_resistor: 0
+#   The resistance (in ohms) of an extra (not heat varying) resistor
+#   that is placed inline with the thermistor. It is rare to set this.
+#   This parameter is only valid when the sensor is a thermistor. The
+#   default is 0 ohms.
 #adc_voltage: 5.0
 #   The ADC comparison voltage. This parameter is only valid when the
-#   sensor is an AD595. The default is 5 volts.
+#   sensor is an AD595 or "PT100 INA826". The default is 5 volts.
+#smooth_time: 2.0
+#   A time value (in seconds) over which temperature measurements will
+#   be smoothed to reduce the impact of measurement noise. The default
+#   is 2 seconds.
 control: pid
 #   Control algorithm (either pid or watermark). This parameter must
 #   be provided.
@@ -170,10 +189,6 @@ pid_Ki: 1.08
 pid_Kd: 114
 #   Kd is the "derivative" constant for the pid. This parameter must
 #   be provided for PID heaters.
-#pid_deriv_time: 2.0
-#   A time value (in seconds) over which the derivative in the pid
-#   will be smoothed to reduce the impact of measurement noise. The
-#   default is 2 seconds.
 #pid_integral_max:
 #   The maximum "windup" the integral term may accumulate. The default
 #   is to use the same value as max_power.
@@ -222,22 +237,48 @@ pin: ar9
 #   enabled for extended periods, while a value of 0.5 would allow the
 #   pin to be enabled for no more than half the time. This setting may
 #   be used to limit the total power output (over extended periods) to
-#   the fan. The default is 1.0.
+#   the fan. If this value is less than 1.0 then fan speed requests
+#   will be scaled between zero and max_power (for example, if
+#   max_power is .9 and a fan speed of 80% is requested then the fan
+#   power will be set to 72%). The default is 1.0.
+#shutdown_speed: 0
+#   The desired fan speed (expressed as a value from 0.0 to 1.0) if
+#   the micro-controller software enters an error state. The default
+#   is 0.
 #cycle_time: 0.010
 #   The amount of time (in seconds) for each PWM power cycle to the
 #   fan. It is recommended this be 10 milliseconds or greater when
 #   using software based PWM. The default is 0.010 seconds.
 #hardware_pwm: False
-#   Enable this to use hardware PWM instead of software PWM. The
+#   Enable this to use hardware PWM instead of software PWM. Most fans
-#   default is False.
+#   do not work well with hardware PWM, so it is not recommended to
+#   enable this unless there is an electrical requirement to switch at
+#   very high speeds. When using hardware PWM the actual cycle time is
+#   constrained by the implementation and may be significantly
+#   different than the requested cycle_time. The default is False.
 #kick_start_time: 0.100
 #   Time (in seconds) to run the fan at full speed when first enabling
 #   it (helps get the fan spinning). The default is 0.100 seconds.
+#off_below: 0.0
+#   The minimum input speed which will power the fan (expressed as a
+#   value from 0.0 to 1.0). When a speed lower than off_below is
+#   requested the fan will instead be turned off. This setting may be
+#   used to prevent fan stalls and to ensure kick starts are
+#   effective. The default is 0.0.
+#
+#   This setting should be recalibrated whenever max_power is adjusted.
+#   To calibrate this setting, start with off_below set to 0.0 and the
+#   fan spinning. Gradually lower the fan speed to determine the lowest
+#   input speed which reliably drives the fan without stalls. Set
+#   off_below to the duty cycle corresponding to this value (for
+#   example, 12% -> 0.12) or slightly higher.
 
 # Micro-controller information.
 [mcu]
 serial: /dev/ttyACM0
-#   The serial port to connect to the MCU. The default is /dev/ttyS0
+#   The serial port to connect to the MCU. If unsure (or if it
+#   changes) see the "Where's my serial port?" section of the FAQ. The
+#   default is /dev/ttyS0
 #baud: 250000
 #   The baud rate to use. The default is 250000.
 pin_map: arduino
@@ -281,14 +322,16 @@ max_z_accel: 30
 #   mm/s^2) of movement along the z axis. It limits the acceleration
 #   of the z stepper motor on cartesian printers. The default is to
 #   use max_accel for max_z_accel.
-#motor_off_time: 600
+#square_corner_velocity: 5.0
-#   Time (in seconds) of idle time before the printer will try to
+#   The maximum velocity (in mm/s) that the toolhead may travel a 90
-#   disable active motors. The default is 600 seconds.
+#   degree corner at. A non-zero value can reduce changes in extruder
-#junction_deviation: 0.02
+#   flow rates by enabling instantaneous velocity changes of the
-#   Distance (in mm) used to control the internal approximated
+#   toolhead during cornering. This value configures the internal
-#   centripetal velocity cornering algorithm. A larger number will
+#   centripetal velocity cornering algorithm; corners with angles
-#   permit higher "cornering speeds" at the junction of two moves. The
+#   larger than 90 degrees will have a higher cornering velocity while
-#   default is 0.02mm.
+#   corners with angles less than 90 degrees will have a lower
+#   cornering velocity. If this is set to zero then the toolhead will
+#   decelerate to zero at each corner. The default is 5mm/s.
 
 
 # Looking for more options? Check the example-extras.cfg file.

config/generic-azteeg-x5-mini-v3.cfg

@@ -0,0 +1,90 @@
+# This file contains common pin mappings for the Azteeg X5 Mini v3. To use
+# this config, the firmware should be compiled for the LPC1769.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P2.1
+dir_pin: P0.11
+enable_pin: !P0.10
+step_distance: .0125
+endstop_pin: ^P1.24
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P2.2
+dir_pin: P0.20
+enable_pin: !P0.19
+step_distance: .0125
+endstop_pin: ^P1.26
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P2.3
+dir_pin: P0.22
+enable_pin: !P0.21
+step_distance: .0125
+endstop_pin: ^P1.28
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[extruder]
+step_pin: P2.0
+dir_pin: P0.5
+enable_pin: !P0.4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.24
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P0.26
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[mcp4451 stepper_digipot1]
+i2c_address: 44
+# Scale the config so that wiper values can be specified in amps.
+scale: 2
+# wiper 0 is X (aka alpha), 1 is Y, 2 is Z, 3 is E0
+wiper_0: 1.0
+wiper_1: 1.0
+wiper_2: 1.0
+wiper_3: 1.0
+
+# Mini Viki2 LCD - this board does not work with Reprap LCDs
+#[display]
+#lcd_type: uc1701
+#cs_pin: P0.16
+#a0_pin: P2.6
+#encoder_pins: ^!P3.25, ^P3.26
+#click_pin: ^!P2.11

config/generic-bigtreetech-skr-mini-e3.cfg

@@ -0,0 +1,129 @@
+# This file contains common pin mappings for the BIGTREETECH SKR mini
+# E3. To use this config, the firmware should be compiled for the
+# STM32F103 with a "28KiB bootloader". Also, select "Enable extra
+# low-level configuration options" and configure "GPIO pins to set at
+# micro-controller startup" to "!PC13".
+
+# The "make flash" command does not work on the SKR mini E3. Instead,
+# after running "make", copy the generated "out/klipper.bin" file to a
+# file named "firmware.bin" on an SD card and then restart the SKR
+# mini E3 with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB13
+dir_pin: !PB12
+enable_pin: !PB14
+step_distance: .0125
+endstop_pin: ^PC0
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[tmc2209 stepper_x]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 0
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB10
+dir_pin: !PB2
+enable_pin: !PB11
+step_distance: .0125
+endstop_pin: ^PC1
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[tmc2209 stepper_y]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 1
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PB0
+dir_pin: PC5
+enable_pin: !PB1
+step_distance: .0025
+endstop_pin: ^PC2
+position_endstop: 0.0
+position_max: 250
+
+[tmc2209 stepper_z]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 2
+microsteps: 16
+run_current: 0.580
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PB3
+dir_pin: !PB4
+enable_pin: !PD2
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA0
+control: pid
+pid_Kp: 21.527
+pid_Ki: 1.063
+pid_Kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2209 extruder]
+uart_pin: PC11
+tx_pin: PC10
+uart_address: 3
+microsteps: 16
+run_current: 0.650
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC9
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PC3
+control: pid
+pid_Kp: 54.027
+pid_Ki: 0.770
+pid_Kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PA8
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output usb_pullup_enable]
+pins: !PC13
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PB5, EXP1_3=PA9,   EXP1_5=PA10, EXP1_7=PB8, EXP1_9=<GND>,
+    EXP1_2=PB6, EXP1_4=<RST>, EXP1_6=PB9,  EXP1_8=PB7, EXP1_10=<5V>
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-mini.cfg

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for the BIGTREETECH SKR
+# MINI. To use this config, the firmware should be compiled for the
+# STM32F103 with a "28KiB bootloader".
+
+# The "make flash" command does not work on the SKR mini. Instead,
+# after running "make", copy the generated "out/klipper.bin" file to a
+# file named "firmware.bin" on an SD card and then restart the SKR
+# mini with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PB15
+step_distance: .0025
+endstop_pin: PC2 # X+ is PA2
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PB13
+dir_pin: PB14
+enable_pin: !PB12
+step_distance: .0025
+endstop_pin: PC1 # Y+ is PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB10
+dir_pin: PB11
+enable_pin: !PB2
+step_distance: .0125
+endstop_pin: PC0 # Z+ is PC3
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PC5
+dir_pin: PB0
+enable_pin: !PC4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PA8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[heater_bed]
+#heater_pin: PC9
+#sensor_type: ATC Semitec 104GT-2
+#sensor_pin: PB1
+#control: watermark
+#min_temp: 0
+#max_temp: 130
+
+[fan]
+pin: PC8
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC10, EXP1_3=PB6,  EXP1_5=PC13, EXP1_7=PC15, EXP1_9=<GND>,
+    EXP1_2=PC11, EXP1_4=PC12, EXP1_6=PB7,  EXP1_8=PC14, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PB4, EXP2_3=PD2,  EXP2_5=PB8, EXP2_7=PB9,   EXP2_9=<GND>,
+    EXP2_2=PB3, EXP2_4=PA15, EXP2_6=PB5, EXP2_8=<RST>, EXP2_10=<NC>
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-pro.cfg

@@ -0,0 +1,222 @@
+# This file contains common pin mappings for the BigTreeTech SKR PRO.
+# To use this config, the firmware should be compiled for the
+# STM32F407 with a "32KiB bootloader".
+
+# The "make flash" command does not work on the SKR PRO. Instead,
+# after running "make", copy the generated "out/klipper.bin" file to a
+# file named "firmware.bin" on an SD card and then restart the SKR PRO
+# with that SD card.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PE9
+dir_pin: PF1
+enable_pin: !PF2
+step_distance: .0025
+endstop_pin: PB10
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PE11
+dir_pin: PE8
+enable_pin: !PD7
+step_distance: .0025
+endstop_pin: PE12
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PE13
+dir_pin: PC2
+enable_pin: !PC0
+step_distance: .0125
+endstop_pin: PG8
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PE14
+dir_pin: PA0
+enable_pin: !PC3
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB1 # Heat0
+sensor_pin: PF3 # T0 Header
+sensor_type: EPCOS 100K B57560G104F
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin: PD15
+#dir_pin: PE7
+#enable_pin: !PA3
+#heater_pin: PD14 # Heat1
+#sensor_pin: PF4 # T1
+#...
+
+#[extruder2]
+#step_pin: PD13
+#dir_pin: PG9
+#enable_pin: !PF0
+#heater_pin: PB0 # Heat2
+#sensor_pin: PF5 # T2
+#...
+
+[heater_bed]
+heater_pin: PD12
+sensor_pin: PF6 # T3
+sensor_type: ATC Semitec 104GT-2
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[heater_fan fan1]
+pin: PE5
+
+#[heater_fan fan2]
+#pin: PE6
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+
+########################################
+# TMC2208 configuration
+########################################
+
+#[tmc2208 stepper_x]
+#uart_pin: PC13
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: PE3
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: PE1
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2208 extruder]
+#uart_pin: PD4
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder1]
+#uart_pin: PD1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder2]
+#uart_pin: PD6
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# TMC2130 configuration
+########################################
+
+#[tmc2130 stepper_x]
+#cs_pin: PA15
+#spi_bus: spi3a
+##diag1_pin: PB10
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: PB8
+#spi_bus: spi3a
+##diag1_pin: PE12
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: PB9
+#spi_bus: spi3a
+##diag1_pin: PG8
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2130 extruder]
+#cs_pin: PB3
+#spi_bus: spi3a
+##diag1_pin: PE15
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder1]
+#cs_pin: PG15
+#spi_bus: spi3a
+##diag1_pin: PE10
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder2]
+#cs_pin: PG12
+#spi_bus: spi3a
+##diag1_pin: PG5
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PG4, EXP1_3=PD11, EXP1_5=PG2, EXP1_7=PG6, EXP1_9=<GND>,
+    EXP1_2=PA8, EXP1_4=PD10, EXP1_6=PG3, EXP1_8=PG7, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PB14, EXP2_3=PG10, EXP2_5=PF11, EXP2_7=PF12,  EXP2_9=<GND>,
+    EXP2_2=PB13, EXP2_4=PB12, EXP2_6=PB15, EXP2_8=<RST>, EXP2_10=PF13
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-v1.1.cfg

@@ -0,0 +1,91 @@
+# This file contains common pin mappings for the BIGTREETECH SKR V1.1
+# board. To use this config, the firmware should be compiled for the
+# LPC1768.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P0.4
+dir_pin: !P0.5
+enable_pin: !P4.28
+step_distance: .0025
+endstop_pin: P1.29
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P2.1
+dir_pin: P2.2
+enable_pin: !P2.0
+step_distance: .0025
+endstop_pin: P1.27
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P0.20
+dir_pin: P0.21
+enable_pin: !P0.19
+step_distance: .0125
+endstop_pin: !P1.25
+position_endstop: 0.5
+position_max: 200
+
+#[stepper_z1]
+#step_pin: P0.1
+#dir_pin: P0.0
+#enable_pin: !P0.10
+#position_endstop: 0.5
+#position_max: 200
+
+[extruder]
+step_pin: P0.11
+dir_pin: P2.13
+enable_pin: !P2.12
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.24
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: P2.5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.3
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=P1.30, EXP1_3=P0.18, EXP1_5=P0.15, EXP1_7=<NC>, EXP1_9=<GND>,
+    EXP1_2=P2.11, EXP1_4=P0.16, EXP1_6=<NC>,  EXP1_8=<NC>, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
+    EXP2_2=P0.15, EXP2_4=P1.23, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "ssp0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-bigtreetech-skr-v1.3.cfg

@@ -0,0 +1,205 @@
+# This file contains common pin mappings for the BIGTREETECH SKR V1.3
+# board. To use this config, the firmware should be compiled for the
+# LPC1768.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P2.2
+dir_pin: !P2.6
+enable_pin: !P2.1
+step_distance: .0125
+endstop_pin: P1.29  # P1.28 for X-max
+position_endstop: 0
+position_max: 320
+homing_speed: 50
+
+[stepper_y]
+step_pin: P0.19
+dir_pin: !P0.20
+enable_pin: !P2.8
+step_distance: .0125
+endstop_pin: P1.27  # P1.26 for Y-max
+position_endstop: 0
+position_max: 300
+homing_speed: 50
+
+[stepper_z]
+step_pin: P0.22
+dir_pin: P2.11
+enable_pin: !P0.21
+step_distance: .0025
+endstop_pin: P1.25  # P1.24 for Z-max
+position_endstop: 0.5
+position_max: 400
+
+[extruder]
+step_pin: P2.13
+dir_pin: !P0.11
+enable_pin: !P2.12
+step_distance: .010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.24
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 260
+
+#[extruder1]
+#step_pin: P0.1
+#dir_pin: P0.0
+#enable_pin: !P0.10
+#heater_pin: P2.4
+#sensor_pin: P0.25
+#...
+
+[heater_bed]
+heater_pin: P2.5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.3
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 2000
+max_z_velocity: 25
+max_z_accel: 100
+
+
+########################################
+# TMC2208 configuration
+########################################
+
+# For TMC2208 UART
+#   1) Remove all of the jumpers below the stepper drivers
+#   2) Place jumpers on the red pin headers labeled XUART (XUART, YUART etc.)
+
+#[tmc2208 stepper_x]
+#uart_pin: P1.17
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: P1.15
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: P1.10
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2208 extruder]
+#uart_pin: P1.8
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2208 extruder1]
+#uart_pin: P1.1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# TMC2130 configuration
+########################################
+
+# For TMC SPI
+#   1) Place jumpers on all the red pin headers under the stepper drivers
+#   2) Remove jumpers from the red pin headers labeled XUART (XUART, YUART etc.)
+
+#[tmc2130 stepper_x]
+#cs_pin: P1.17
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.29
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: P1.15
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.27
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: P1.10
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.25
+#microsteps: 16
+#run_current: 0.650
+#hold_current: 0.450
+#stealthchop_threshold: 30
+
+#[tmc2130 extruder]
+#cs_pin: P1.8
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.28
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+#[tmc2130 extruder1]
+#cs_pin: P1.1
+#spi_software_miso_pin: P0.5
+#spi_software_mosi_pin: P4.28
+#spi_software_sclk_pin: P0.4
+##diag1_pin: P1.26
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 5
+
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=P1.30, EXP1_3=P1.18, EXP1_5=P1.20, EXP1_7=P1.22, EXP1_9=<GND>,
+    EXP1_2=P0.28, EXP1_4=P1.19, EXP1_6=P1.21, EXP1_8=P1.23, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=P0.17, EXP2_3=P3.26, EXP2_5=P3.25, EXP2_7=P1.31, EXP2_9=<GND>,
+    EXP2_2=P0.15, EXP2_4=P0.16, EXP2_6=P0.18, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "ssp0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-cramps.cfg

@@ -49,7 +49,7 @@ filament_diameter: 1.750
 heater_pin: P9_15
 sensor_type: EPCOS 100K B57560G104F
 pullup_resistor: 2000
-sensor_pin: P9_36
+sensor_pin: host:analog5
 control: pid
 pid_Kp: 22.2
 pid_Ki: 1.08
@@ -61,7 +61,7 @@ max_temp: 250
 heater_pin: P8_11
 sensor_type: EPCOS 100K B57560G104F
 pullup_resistor: 2000
-sensor_pin: P9_33
+sensor_pin: host:analog4
 control: watermark
 min_temp: 0
 max_temp: 130
@@ -73,6 +73,9 @@ pin: P9_41
 serial: /dev/rpmsg_pru30
 pin_map: beaglebone
 
+[mcu host]
+serial: /tmp/klipper_host_mcu
+
 [printer]
 kinematics: cartesian
 max_velocity: 300

config/generic-duet2-duex.cfg

@@ -0,0 +1,371 @@
+# This file contains common pin mappings for Duet2 Eth/Wifi boards
+# that have the Duex expansion board. To use this config, the firmware
+# should be compiled for the SAM4E8E.
+
+# See the example.cfg file for a description of available parameters.
+
+## Drivers
+# Here are the pins for the 10 stepper drivers supported by a Duet2 board
+# | Drive |  DIR pin |  STEP pin |  ENDSTOP pin |  SPI EN pin |
+# |-------|----------|-----------|--------------|-------------|
+# | X     |  PD11    |  PD6      |  PC14        |  PD14       |
+# | Y     |  PD12    |  PD7      |  PA2         |  PC9        |
+# | Z     |  PD13    |  PD8      |  PD29        |  PC10       |
+# | E0    |  PA1     |  PD5      |  PD10        |  PC17       |
+# | E1    |  PD9     |  PD4      |  PC16        |  PC25       |
+# | E2    |  PD28    |  PD2      |  PE0*        |  PD23       |
+# | E3    |  PD22    |  PD1      |  PE1*        |  PD24       |
+# | E4    |  PD16    |  PD0      |  PE2*        |  PD25       |
+# | E5    |  PD17    |  PD3      |  PE3*        |  PD26       |
+# | E6    |  PC0     |  PD27     |  PA17*       |  PB14       |
+# Pins marked with asterisks (*) are only assigned to these functions
+# if no duex is connected. If a duex is connected, these endstops are
+# remapped to the SX1509 on the Duex (unfortunately they can't be used
+# as endstops in klipper, however one may use them as digital outs or
+# PWM outs). The SPI EN pins are required for the TMC2660 drivers (use
+# the SPI EN pin as 'cs_pin' in the respective config block). The
+# **enable pin for all steppers** is TMC_EN = !PC6.
+#
+## Fans
+# | FAN  |          PIN          |
+# |------|-----------------------|
+# | FAN0 |  PC23                 |
+# | FAN1 |  PC26                 |
+# | FAN2 |  PA0                  |
+# | FAN3 |  sx1509_duex:PIN_12*  |
+# | FAN4 |  sx1509_duex:PIN_7*   |
+# | FAN5 |  sx1509_duex:PIN_6*   |
+# | FAN6 |  sx1509_duex:PIN_5*   |
+# | FAN7 |  sx1509_duex:PIN_4*   |
+# | FAN8 |  sx1509_duex:PIN_15*  |
+# Pins marked with (*) assume the following sx1509 config section:
+#[sx1509 duex]
+#i2c_address: 62
+#
+## Heaters and Thermistors
+# | Extruder Drive |  HEAT pin |  TEMP pin |
+# |----------------|-----------|-----------|
+# | BED            |  PA19     |  PC13     |
+# | E0             |  PA20     |  PC15     |
+# | E1             |  PA16     |  PC12     |
+# | E2             |  PC3      |  PC29     |
+# | E3             |  PC5      |  PC30     |
+# | E4             |  PC8      |  PC31     |
+# | E5             |  PC11     |  PC27     |
+# | E6             |  PA15     |  PA18     |
+#
+## Misc pins
+# |    Name     |   Pin   |
+# |-------------|---------|
+# | ZProbe_IN   |  PC1    |
+# | PS_ON       |  PD15   |
+# | LED_ONBOARD |  PC2    |
+# | SPI0_CS0    |  PC24   |
+# | SPI0_CS1    |  PB2    |
+# | SPI0_CS2    |  PC18   |
+# | SPI0_CS3    |  PC19   |
+# | SPI0_CS4    |  PC20   |
+# | SPI0_CS5    |  PA24   |
+# | SPI0_CS6    |  PE1*   |
+# | SPI0_CS7    |  PE2*   |
+# | SPI0_CS8    |  PE3*   |
+# | SX1509_IRQ  |  PA17*  |
+# | SG_TST      |  PE0*   |
+# | ENC_SW      |  PA7    |
+# | ENC_A       |  PA8    |
+# | ENC_B       |  PC7    |
+# | LCD_DB7     |  PD18   |
+# | LCD_DB6     |  PD19   |
+# | LCD_DB5     |  PD20   |
+# | LCD_DB4     |  PD21   |
+# | LCD_RS      |  PC28   |
+# | LCD_E       |  PA25   |
+# Pins marked with one asterisk (*) replace E2_STOP-E6_STOP if a duex is present
+# For the remaining pins check the schematics provided here: https://github.com/T3P3/Duet
+
+[stepper_x]
+step_pin: PD6
+dir_pin: PD11
+enable_pin: !PC6, tmc2660_stepper_x:virtual_enable
+step_distance: .0125
+endstop_pin: ^PC14
+position_endstop: 0
+position_max: 250
+
+[tmc2660 stepper_x]
+cs_pin: PD14 # X_SPI_EN Required for communication
+spi_bus: usart1 # All TMC2660 drivers are connected to USART1
+microsteps: 16
+interpolate: True # 1/16 micro-steps interpolated to 1/256
+run_current: 1.000
+sense_resistor: 0.051
+idle_current_percent: 20
+
+[stepper_y]
+step_pin: PD7
+dir_pin: !PD12
+enable_pin: !PC6, tmc2660_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[tmc2660 stepper_y]
+cs_pin: PC9
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+idle_current_percent: 20
+
+[stepper_z]
+step_pin: PD8
+dir_pin: PD13
+enable_pin: !PC6, tmc2660_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PD29
+position_endstop: 0.5
+position_max: 200
+
+[tmc2660 stepper_z]
+cs_pin: PC10
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E4
+[stepper_z1]
+step_pin: PD0
+dir_pin: PD16
+enable_pin: !PC6, tmc2660_stepper_z1:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z1]
+cs_pin: PD25
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E5
+[stepper_z2]
+step_pin: PD3
+dir_pin: !PD17
+enable_pin: !PC6, tmc2660_stepper_z2:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z2]
+cs_pin: PD26
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E6
+[stepper_z3]
+step_pin: PD27
+dir_pin: !PC0
+enable_pin: !PC6, tmc2660_stepper_z3:virtual_enable
+step_distance: .0025
+
+[tmc2660 stepper_z3]
+cs_pin: PB14
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E0
+[extruder0]
+step_pin: PD5
+dir_pin: PA1
+enable_pin: !PC6, tmc2660_extruder0:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PA20
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC15
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2660 extruder0]
+cs_pin: PC17
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+#On drive E1
+[extruder1]
+step_pin: PD4
+dir_pin: PD9
+enable_pin: !PC6, tmc2660_extruder1:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PA16
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC12
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2660 extruder1]
+cs_pin: PC25
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+# On drive E2
+[extruder2]
+step_pin: PD2
+dir_pin: !PD28
+enable_pin: !PC6, tmc2660_extruder2:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PC3
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC29
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2660 extruder2]
+cs_pin: PD23
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+# On drive E3
+[extruder3]
+step_pin: PD1
+dir_pin: !PD22
+enable_pin: !PC6, tmc2660_extruder3:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PC5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC30
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2660 extruder3]
+cs_pin: PD24
+spi_bus: usart1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+sense_resistor: 0.051
+
+[heater_bed]
+heater_pin: !PA19
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC13
+control: watermark
+min_temp: 0
+max_temp: 130
+
+# Fan0
+[fan]
+pin: PC23
+
+# Fan1 controlled by extruder0
+[heater_fan nozzle_cooling_fan]
+pin: PC26
+heater: extruder0
+heater_temp: 45
+fan_speed: 1.0
+
+# Fan2, controlled by E5_TEMP
+[temperature_fan chamber_fan]
+pin: PA0
+max_power: 1
+shutdown_speed: 1
+cycle_time: 0.01
+min_temp: 40
+max_temp: 120
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC27
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[sx1509 duex]
+i2c_address: 62 # Address is fixed on duex boards
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output onboard_led]
+pins: !PC2
+
+[output_pin FAN3]
+pin: sx1509_duex:PIN_12
+pwm: True
+hardware_pwm: True # Only hardware PWM fans are supported
+
+[output_pin FAN4]
+pin: sx1509_duex:PIN_7
+pwm: True
+hardware_pwm: True
+
+[output_pin FAN5]
+pin: sx1509_duex:PIN_6
+pwm: True
+hardware_pwm: True
+
+[output_pin FAN6]
+pin: sx1509_duex:PIN_5
+pwm: True
+hardware_pwm: True
+
+[output_pin FAN7]
+pin: sx1509_duex:PIN_4
+pwm: True
+hardware_pwm: True
+
+[output_pin FAN8]
+pin: sx1509_duex:PIN_15
+pwm: True
+hardware_pwm: True
+
+[output_pin GPIO1] # General purpose pin broken out on the duex
+pin: sx1509_duex:PIN_11
+pwm: False
+value: 1

config/generic-duet2-maestro.cfg

@@ -0,0 +1,148 @@
+# This file contains common pin mappings for the Duet2 Maestro. To use
+# this config, the firmware should be compiled for the sam4s8c.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PC20
+dir_pin: PC18
+enable_pin: !PA1, tmc2208_stepper_x:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA24
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_x]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: !PC14, !PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PC2
+dir_pin: PA8
+enable_pin: !PA1, tmc2208_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PB6
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_y]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: PC14, !PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC28
+dir_pin: PB4
+enable_pin: !PA1, tmc2208_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PC10
+position_endstop: 0.5
+position_max: 200
+
+[tmc2208 stepper_z]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: !PC14, PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 30
+
+[extruder]
+step_pin: PC4
+dir_pin: PB7
+enable_pin: !PA1, tmc2208_extruder:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PC1
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PB0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2208 extruder]
+uart_pin: PA9
+tx_pin: PA10
+select_pins: PC14, PC16, !PC17
+sense_resistor: 0.075
+microsteps: 16
+run_current: 0.800
+stealthchop_threshold: 5
+
+#[extruder1]
+#step_pin: PC5
+#dir_pin: PC6
+#enable_pin: !PA1
+#heater_pin: !PA16
+#sensor_pin: PC30
+#...
+#[tmc2208 extruder1]
+#select_pins: !PC14, !PC16, PC17
+#sense_resistor: 0.075
+#...
+
+# External steppers
+# e2: step_pin=PC31 dir_pin=PA18 enable_pin=PC27 select_pins=PC14,!PC16,PC17
+# e3: step_pin=PC21 dir_pin=PC24 enable_pin=PC25 select_pins=!PC14,PC16,PC17
+# e0_stop: endstop_pin=PA25
+# e1_stop: endstop_pin=PC7
+# c_temp: sensor_pin=PB1
+
+[heater_bed]
+heater_pin: !PC0
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA20
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC23  # FAN0
+
+#[heater_fan nozzle_cooling_fan]
+#pin: PC22  # FAN1
+
+#[heater_fan board_cooling_fan]
+#pin: PC29  # FAN2
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output led]
+pins: !PC26
+
+# EXP1 / EXP2 (display) pins
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PA15, EXP1_3=PA6, EXP1_5=PA2,  EXP1_7=<NC>, EXP1_9=<GND>,
+    EXP1_2=PA7,  EXP1_4=PC9, EXP1_6=<NC>, EXP1_8=<NC>, EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PA5, EXP2_3=PC3,  EXP2_5=PB5, EXP2_7=<NC>,  EXP2_9=<GND>,
+    EXP2_2=PA2, EXP2_4=PB13, EXP2_6=PA6, EXP2_8=<RST>, EXP2_10=<NC>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "usart0"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-duet2.cfg

@@ -0,0 +1,118 @@
+# This file contains common pin mappings for Duet2 Eth/Wifi boards. To
+# use this config, the firmware should be compiled for the SAM4E8E.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD6
+dir_pin: PD11
+enable_pin: !PC6, tmc2660_stepper_x:virtual_enable
+step_distance: .0125
+endstop_pin: ^PC14
+position_endstop: 0
+position_max: 250
+
+[tmc2660 stepper_x]
+cs_pin: PD14
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[stepper_y]
+step_pin: PD7
+dir_pin: !PD12
+enable_pin: !PC6, tmc2660_stepper_y:virtual_enable
+step_distance: .0125
+endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[tmc2660 stepper_y]
+cs_pin: PC9
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[stepper_z]
+step_pin: PD8
+dir_pin: PD13
+enable_pin: !PC6, tmc2660_stepper_z:virtual_enable
+step_distance: .0025
+endstop_pin: ^PD29
+#endstop_pin: PD10  # E0 endstop
+#endstop_pin: PC16  # E1 endstop
+position_endstop: 0.5
+position_max: 200
+
+[tmc2660 stepper_z]
+cs_pin: PC10
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+[extruder]
+step_pin: PD5
+dir_pin: PA1
+enable_pin: !PC6, tmc2660_extruder:virtual_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: !PA20
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC15
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2660 extruder]
+cs_pin: PC17
+spi_bus: usart1
+microsteps: 16
+run_current: 1.000
+sense_resistor: 0.051
+
+#[extruder1]
+#step_pin: PD4
+#dir_pin: PD9
+#enable_pin: !PC6, tmc2660_extruder1:virtual_enable
+#heater_pin: !PA16
+#sensor_pin: PC12
+#...
+#[tmc2660 extruder1]
+#cs_pin: PC25
+#spi_bus: usart1
+#sense_resistor: 0.051
+#...
+
+[heater_bed]
+heater_pin: !PA19
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC13
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC23  # FAN0
+
+#[heater_fan nozzle_cooling_fan]
+#pin: PC26  # FAN1
+
+#[heater_fan board_cooling_fan]
+#pin: PA0  # FAN2
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100

config/generic-einsy-rambo.cfg

@@ -0,0 +1,106 @@
+# This file contains common pin mappings for Einsy Rambo boards. To use
+# this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PC0
+dir_pin: PL0
+enable_pin: !PA7
+step_distance: .005
+endstop_pin: ^PB6
+#endstop_pin: tmc2130_stepper_x:virtual_endstop
+position_endstop: 0
+position_max: 250
+
+[tmc2130 stepper_x]
+cs_pin: PG0
+microsteps: 16
+run_current: .5
+sense_resistor: 0.220
+diag1_pin: !PK2
+
+[stepper_y]
+step_pin: PC1
+dir_pin: !PL1
+enable_pin: !PA6
+step_distance: .005
+endstop_pin: ^PB5
+#endstop_pin: tmc2130_stepper_y:virtual_endstop
+position_endstop: 0
+position_max: 210
+
+[tmc2130 stepper_y]
+cs_pin: PG2
+microsteps: 16
+run_current: .5
+sense_resistor: 0.220
+diag1_pin: !PK7
+
+[stepper_z]
+step_pin: PC2
+dir_pin: PL2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PB4
+#endstop_pin: tmc2130_stepper_z:virtual_endstop
+position_endstop: 0.5
+position_max: 200
+
+[tmc2130 stepper_z]
+cs_pin: PK5
+microsteps: 16
+run_current: .5
+sense_resistor: 0.220
+diag1_pin: !PK6
+
+[extruder]
+step_pin: PC3
+dir_pin: PL6
+enable_pin: !PA4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[tmc2130 extruder]
+cs_pin: PK4
+microsteps: 16
+run_current: .5
+sense_resistor: 0.220
+diag1_pin: !PK3
+
+[heater_bed]
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF2
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PH5
+
+#[heater_fan nozzle_cooling_fan]
+#pin: PH3
+
+[mcu]
+serial: /dev/ttyACM0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output yellow_led]
+pins: !PB7

config/generic-fysetc-cheetah-v1.1.cfg

@@ -0,0 +1,125 @@
+# This file contains common pin mappings for the Fysetc Cheetah v1.1
+# board. To use this config, the firmware should be compiled for the
+# STM32F103 with "No bootloader" and with "Use USB for communication"
+# disabled.
+
+# The "make flash" command does not work on the Cheetah. Instead,
+# after running "make", run the following command to flash the board:
+#  stm32flash -w out/klipper.bin -v -i rts,-dtr,dtr /dev/ttyUSB0
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB8
+dir_pin: !PB9
+enable_pin: !PA8
+step_distance: .0125
+endstop_pin: ^PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2209 stepper_x]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 0
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB2
+dir_pin: !PB3
+enable_pin: !PB1
+step_distance: .0125
+endstop_pin: ^PB4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2209 stepper_y]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 1
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC0
+dir_pin: PC1
+enable_pin: !PC2
+step_distance: .0025
+endstop_pin: ^PA15
+position_endstop: 0
+position_max: 200
+
+[tmc2209 stepper_z]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 2
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PC15
+dir_pin: !PC14
+enable_pin: !PC13
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC6
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid
+pid_kp: 21.527
+pid_ki: 1.063
+pid_kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2209 extruder]
+uart_pin: PA3
+tx_pin: PA2
+uart_address: 3
+microsteps: 16
+run_current: 1.0
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid
+pid_kp: 54.027
+pid_ki: 0.770
+pid_kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC9,  EXP1_3=PC11, EXP1_5=PC10, EXP1_7=PB12, EXP1_9=<GND>,
+    EXP1_2=PC12, EXP1_4=PB14, EXP1_6=PB13, EXP1_8=PB15, EXP1_10=<5V>
+    # Pins EXP1_4, EXP1_8, EXP1_6 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-fysetc-cheetah-v1.2.cfg

@@ -0,0 +1,121 @@
+# This file contains common pin mappings for the Fysetc Cheetah v1.2b
+# board. To use this config, the firmware should be compiled for the
+# STM32F103 with "No bootloader" and with "Use USB for communication"
+# disabled.
+
+# The "make flash" command does not work on the Cheetah. Instead,
+# after running "make", run the following command to flash the board:
+#  stm32flash -w out/klipper.bin -v -i rts,-dtr,dtr /dev/ttyUSB0
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB8
+dir_pin: !PB9
+enable_pin: !PA8
+step_distance: .0125
+endstop_pin: ^PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_x]
+uart_pin: PA12
+tx_pin: PA11
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_y]
+step_pin: PB2
+dir_pin: !PB3
+enable_pin: !PB1
+step_distance: .0125
+endstop_pin: ^PB4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc2208 stepper_y]
+uart_pin: PB7
+tx_pin: PB6
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 250
+
+[stepper_z]
+step_pin: PC0
+dir_pin: PC1
+enable_pin: !PC2
+step_distance: .0025
+endstop_pin: ^PA15
+position_endstop: 0
+position_max: 200
+
+[tmc2208 stepper_z]
+uart_pin: PB11
+tx_pin: PB10
+microsteps: 16
+run_current: 0.800
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[extruder]
+step_pin: PC15
+dir_pin: !PC14
+enable_pin: !PC13
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC6
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid
+pid_kp: 21.527
+pid_ki: 1.063
+pid_kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[tmc2208 extruder]
+uart_pin: PA3
+tx_pin: PA2
+microsteps: 16
+run_current: 1.0
+hold_current: 0.500
+stealthchop_threshold: 5
+
+[heater_bed]
+heater_pin: PC7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid
+pid_kp: 54.027
+pid_ki: 0.770
+pid_kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC8
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC9,  EXP1_3=PC11, EXP1_5=PC10, EXP1_7=PB12, EXP1_9=<GND>,
+    EXP1_2=PC12, EXP1_4=PB14, EXP1_6=PB13, EXP1_8=PB15, EXP1_10=<5V>
+    # Pins EXP1_4, EXP1_8, EXP1_6 are also MISO, MOSI, SCK of bus "spi2"
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.

config/generic-fysetc-f6.cfg

@@ -0,0 +1,306 @@
+# This file contains common pin mappings for a Fysetc F6 board.
+# To use this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PF0
+dir_pin: PF1
+enable_pin: !PD7
+step_distance: .0125
+endstop_pin: PK1  # PK2 for X-max
+position_endstop: 0
+position_max: 200
+
+[stepper_y]
+step_pin: PF6
+dir_pin: PF7
+enable_pin: !PF2
+step_distance: .0125
+endstop_pin: PJ1  # PJ0 for Y-max
+position_endstop: 0
+position_max: 200
+
+[stepper_z]
+step_pin: PL6
+dir_pin: PL1
+enable_pin: !PF4
+step_distance: .0025
+endstop_pin: PB6  # PE4 for Z-max
+position_endstop: 0
+position_max: 400
+
+[extruder]
+step_pin: PA4
+dir_pin: !PA6
+enable_pin: !PA2
+step_distance: .01
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PE3
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK4
+control: pid
+pid_Kp: 22
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 260
+
+#[extruder1]
+#step_pin: PC1
+#dir_pin: !PC3
+#enable_pin: !PC7
+#heater_pin: PH3
+#sensor_pin: PK5
+
+#[extruder2]
+#step_pin: PF5
+#dir_pin: !PF3
+#enable_pin: !PG1
+#heater_pin: PH4
+#sensor_pin: PK6
+
+[heater_bed]
+heater_pin: PH5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK7
+control: watermark
+min_temp: 0
+max_temp: 130
+
+#fan for printed model FAN0
+[fan]
+pin: PL5
+
+#fan for hotend FAN1
+#[heater_fan my_nozzle_fan]
+#pin: PL4
+#shutdown_speed: 1
+
+#fan for control board FAN2
+#[heater_fan my_control_fan]
+#pin: PL3
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+#Prevents communication issues with SPI drivers
+[static_digital_output disable_sdcard]
+pins: PB0
+
+########################################
+# TMC UART configuration
+########################################
+
+# For TMC UART
+#   1) Remove all jumpers below the stepper drivers.
+#   2) Place jumper on the left and middle pin of the three pin header.
+
+#[tmc2208 stepper_x]
+#uart_pin: PG3
+#tx_pin: PJ2
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_y]
+#uart_pin: PJ3
+#tx_pin: PJ4
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 stepper_z]
+#uart_pin: PE2
+#tx_pin: PE6
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 100
+
+#[tmc2208 extruder]
+#uart_pin: PJ5
+#tx_pin: PJ6
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 extruder1]
+#uart_pin: PE7
+#tx_pin: PD4
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+#[tmc2208 extruder2]
+#uart_pin: PA1
+#tx_pin: PD5
+#microsteps: 16
+#run_current: 0.8
+#hold_current: 0.5
+#stealthchop_threshold: 250
+
+########################################
+# TMC SPI configuration
+########################################
+
+# For TMC SPI
+#   1) Remove all jumpers below the stepper drivers.
+#   2) Place jumper on the middle and right pin of the small three pin header.
+#   3) Place jumpers on the four small two pin headers.
+
+# For TMC Sensorless homing / DIAG1
+#   1) Place jumper on the small two pin header near the endstop.
+
+#[tmc2130 stepper_x]
+#cs_pin: PG4
+#diag1_pin: PK1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_y]
+#cs_pin: PG2
+#diag1_pin: PJ1
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 stepper_z]
+#cs_pin: PJ6
+#diag1_pin: PB6
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder]
+#cs_pin: PL2
+#diag1_pin: PE4
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder1]
+#cs_pin: PC5
+#diag1_pin: PJ0
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+#[tmc2130 extruder2]
+#cs_pin: PL7
+#diag1_pin: PK2
+#microsteps: 16
+#run_current: 0.800
+#hold_current: 0.500
+#stealthchop_threshold: 250
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+
+# These must be turned 180° when compared to the default RAMPS layout.
+# The aliases below are 180° turned from what Fysetc considers pin 1,
+# but visually correspond to the plugs on the board.
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PC0, EXP1_2=PC2,
+    EXP1_3=PH0, EXP1_4=PH1,
+    EXP1_5=PA1, EXP1_6=PA3,    # Slot in the socket on this side
+    EXP1_7=PA5, EXP1_8=PA7,
+    EXP1_9=<GND>, EXP1_10=<5V>,
+
+    # EXP2 header
+    EXP2_1=PB3, EXP2_2=PB1,
+    EXP2_3=PC6, EXP2_4=PB0,
+    EXP2_5=PC4, EXP2_6=PB2,    # Slot in the socket on this side
+    EXP2_7=PL0, EXP2_8=<RST>,
+    EXP2_9=<GND>, EXP2_10=<5V> # or PG0 via jumper
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.
+
+########################################
+# Servos
+########################################
+
+# See the example-extras.cfg file for more information.
+# All Servo pins support hardware PWM.
+
+#[servo my_servo1]
+#pin: PB7
+
+#[servo my_servo2]
+#pin: PB5
+
+#[servo my_servo3]
+#pin: PB4
+
+#[servo my_servo4]
+#pin: PG5
+
+########################################
+# RGB header
+########################################
+
+# See the example-extras.cfg file for more information.
+# All RGB pins support hardware PWM.
+
+#[output_pin blue]
+#pin: PH6
+
+#[output_pin red]
+#pin: PE5
+
+#[output_pin green]
+#pin: PG5
+
+########################################
+# AUX-1 header
+########################################
+
+# Various analog and digital pins
+# PK0 (analog), PK3 (analog), <GND>, <5V>
+# PE0 (RXD0)  , PE1 (TXD0)  , <GND>, <5V>
+
+########################################
+# SD header
+########################################
+
+# Various digital / SPI pins
+# PL0 , PB2, PB0, RST
+# <5V>, PB3, PB1, <GND>
+
+########################################
+# UART header
+########################################
+
+# Various digital / UART pins
+# <5V>
+# <GND>
+# PD2
+# PD3
+
+########################################
+# I2C header
+########################################
+
+# SCL, SDA, <5V>, <GND>

config/generic-gt2560.cfg

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for the Geeetech GT2560
+# board. GT2560 board uses a firmware compiled for the AVR
+# atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar25
+dir_pin: ar23
+enable_pin: !ar27
+step_distance: .0125
+endstop_pin: ^ar22
+position_endstop: 0
+position_max: 200
+homing_speed: 30
+
+[stepper_y]
+step_pin: ar31
+dir_pin: ar33
+enable_pin: !ar29
+step_distance: .0125
+endstop_pin: ^ar26
+position_endstop: 0
+position_max: 200
+homing_speed: 30
+
+[stepper_z]
+step_pin: ar37
+dir_pin: !ar39
+enable_pin: !ar35
+step_distance: .0025
+endstop_pin: ^ar30
+position_endstop: 0
+position_max: 200
+position_min: 0.0
+
+[extruder]
+step_pin: ar43
+dir_pin: ar45
+enable_pin: !ar41
+step_distance: .0104789
+nozzle_diameter: 0.4
+filament_diameter: 1.750
+heater_pin: ar2
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog8
+min_temp: 0
+max_temp: 250
+control: pid
+pid_kp: 29.800
+pid_ki: 1.774
+pid_kd: 125.159
+
+[heater_bed]
+heater_pin: ar4
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog10
+min_temp: 0
+max_temp: 120
+control: pid
+pid_kp: 63.041
+pid_ki: 2.898
+pid_kd: 342.787
+
+[fan]
+pin: ar7
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 1500
+max_z_velocity: 20
+max_z_accel: 500
+
+[display]
+lcd_type: hd44780
+rs_pin: ar20
+e_pin: ar17
+d4_pin: ar16
+d5_pin: ar21
+d6_pin: ar5
+d7_pin: ar6
+encoder_pins: ^ar42, ^ar40
+click_pin: ^!ar19

config/generic-melzi.cfg

@@ -2,12 +2,12 @@
 # this config, the firmware should be compiled for the AVR
 # atmega1284p.
 
-# Note, a number of Melzi boards are shipped without a bootloader. In
+# Note, a number of Melzi boards are shipped with a bootloader that
-# that case, an external programmer will be needed to flash a
+# requires the following command to flash the board:
-# bootloader to the board (for example, see
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
-# http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/
+# If the above command does not work and "make flash" does not work
-# ). Once that is done, one should be able to use the standard "make
+# then one may need to flash a bootloader to the board - see the
-# flash" command to flash Klipper.
+# Klipper docs/Bootloaders.md file for more information.
 
 # See the example.cfg file for a description of available parameters.
 

config/generic-mini-rambo.cfg

@@ -78,7 +78,7 @@ max_z_accel: 100
 pin: PL3
 pwm: True
 scale: 2.0
-cycle_time: .002
+cycle_time: .000030
 hardware_pwm: True
 static_value: 1.3
 
@@ -86,7 +86,7 @@ static_value: 1.3
 pin: PL4
 pwm: True
 scale: 2.0
-cycle_time: .002
+cycle_time: .000030
 hardware_pwm: True
 static_value: 1.3
 
@@ -94,7 +94,7 @@ static_value: 1.3
 pin: PL5
 pwm: True
 scale: 2.0
-cycle_time: .002
+cycle_time: .000030
 hardware_pwm: True
 static_value: 1.25
 

config/generic-minitronics1.cfg

@@ -0,0 +1,80 @@
+# This file contains common pin mappings for Minitronics v1.0
+# boards. To use this config, the firmware should be compiled for the
+# AVR atmega1280.
+
+# The "make flash" command does not work on the Minitronics v1.0
+# because the board actually has an atmega1281 chip. Use the following
+# command to flash the board:
+#  avrdude -carduino -patmega1281 -P/dev/ttyUSB0 -b57600 -D -Uout/klipper.elf.hex
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PF2
+dir_pin: PF1
+enable_pin: !PF3
+step_distance: .0125
+endstop_pin: ^!PE3
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PA1
+dir_pin: PA2
+enable_pin: !PA0
+step_distance: .0125
+endstop_pin: ^!PE4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PA4
+dir_pin: !PA5
+enable_pin: !PA3
+step_distance: .0025
+endstop_pin: ^!PB4
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PA7
+dir_pin: PA6
+enable_pin: !PG2
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF7
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF6
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB7
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output yellow_led]
+pins: PF0

config/generic-printrboard-g2.cfg

@@ -0,0 +1,117 @@
+# This file contains common pin mappings for Printrboard G2 boards.
+# To use this config, the firmware should be compiled for the SAM3x8c.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PB15
+dir_pin: !PA16
+enable_pin: !PB16
+step_distance: .0125
+endstop_pin: ^PA11
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PA29
+dir_pin: !PB1
+enable_pin: !PB0
+step_distance: .0125
+endstop_pin: ^PB26
+position_endstop: 150
+position_max: 150
+homing_speed: 50
+
+[stepper_z]
+step_pin: PA21
+dir_pin: PA26
+enable_pin: !PA25
+step_distance: .0025
+endstop_pin: ^!PA10
+position_endstop: 0
+position_min: -2
+position_max: 200
+
+[output_pin motor_x_pwm]
+pin: PB17
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_y_pwm]
+pin: PB19
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_z_pwm]
+pin: PB18
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.8
+
+[output_pin motor_e_pwm]
+pin: PA2
+pwm: True
+hardware_pwm: True
+scale: 2.25
+cycle_time: .000004
+value: 0.5
+
+[output_pin heater_enable]
+pin: PA7
+pwm: True
+cycle_time: 0.050
+value: 0.1
+
+[thermistor G2]
+temperature1: 20
+resistance1: 140000
+temperature2: 195
+resistance2: 593
+temperature3: 255
+resistance3: 189
+
+[extruder]
+step_pin: PB14
+dir_pin: PB23
+enable_pin: !PB22
+step_distance: .008
+nozzle_diameter: 0.300
+filament_diameter: 1.750
+heater_pin: PA5
+sensor_pin: PA23
+sensor_type: G2
+inline_resistor: 4700
+control: pid
+pid_kp: 29.852
+pid_ki: 2.843
+pid_kd: 78
+min_temp: 0
+max_temp: 290
+
+[fan]
+pin: PB27
+
+[heater_fan nozzle_cooling_fan]
+pin: PA6
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 400
+max_accel: 2500
+max_z_velocity: 15
+max_z_accel: 300
+
+[static_digital_output step_config]
+pins: PA19, PB20, PA27, PB10

config/generic-printrboard.cfg

@@ -66,7 +66,7 @@ max_temp: 130
 pin: PC6
 
 [mcu]
-serial: /dev/ttyACM0
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
 
 [printer]
 kinematics: cartesian
@@ -74,3 +74,11 @@ max_velocity: 300
 max_accel: 3000
 max_z_velocity: 5
 max_z_accel: 100
+
+# Use the following on a Printrboard RevF to control stepper current.
+#[mcp4728 stepper_current_dac]
+#scale: 2.327
+#channel_a: 1.2 # Extruder
+#channel_b: 1.2 # stepper_z
+#channel_c: 1.0 # stepper_y
+#channel_d: 1.0 # stepper_x

config/generic-radds.cfg

@@ -0,0 +1,111 @@
+# This file contains common pin mappings for RADDS (v1.5) boards.  To
+# use this config, the firmware should be compiled for the Arduino
+# Due.
+
+# See the example.cfg file for a description of available parameters.
+
+# Temp sensor pins: analog0..analog4
+# Mosfet Pins: ar7 (Heatbed), ar8, ar9, ar11, ar12, ar13
+
+[stepper_x]
+step_pin: ar24
+dir_pin: ar23
+enable_pin: ar26
+step_distance: .0125
+endstop_pin: ^ar28
+#endstop_pin: ^ar34
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar17
+dir_pin: !ar16
+enable_pin: ar22
+step_distance: .0125
+endstop_pin: ^ar30
+#endstop_pin: ^ar36
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar2
+dir_pin: ar3
+enable_pin: ar15
+step_distance: .0025
+endstop_pin: ^ar32
+#endstop_pin: ^ar38
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: analog7
+dir_pin: analog6
+enable_pin: analog8
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar13
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog0
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin:           analog10
+#dir_pin:            analog9
+#enable_pin:         analog11
+
+#[extruder2]
+#step_pin:           ar51
+#dir_pin:            ar53
+#enable_pin:         ar49
+
+[heater_bed]
+heater_pin: ar7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog1
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: ar9
+
+#[heater_fan nozzle_cooling_fan]
+#pin: ar8
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+# "RepRapDiscount 2004 Smart Controller" type displays
+#[display]
+#lcd_type: hd44780
+#rs_pin: ar42
+#e_pin: ar43
+#d4_pin: ar44
+#d5_pin: ar45
+#d6_pin: ar46
+#d7_pin: ar47
+#encoder_pins: ^ar52, ^ar50
+#click_pin: ^!ar48
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: ar42
+#sclk_pin: ar44
+#sid_pin: ar43

config/generic-rambo.cfg

@@ -108,19 +108,15 @@ pins:
 [static_digital_output yellow_led]
 pins: !PB7
 
-# "RepRapDiscount 2004 Smart Controller" type displays
+# Common EXP1 / EXP2 (display) pins
-#[display]
+[board_pins]
-#lcd_type: hd44780
+aliases:
-#rs_pin: PG4
+    # Common EXP1/EXP2 headers found on RAMBo v1.4
-#e_pin: PG3
+    EXP1_1=PE6, EXP1_3=PG3, EXP1_5=PJ2, EXP1_7=PJ7, EXP1_9=<GND>,
-#d4_pin: PJ2
+    EXP1_2=PE2, EXP1_4=PG4, EXP1_6=PJ3, EXP1_8=PJ4, EXP1_10=<5V>,
-#d5_pin: PJ3
+    # EXP2 header
-#d6_pin: PJ7
+    EXP2_1=PB3, EXP2_3=PJ5, EXP2_5=PJ6, EXP2_7=PD4, EXP2_9=<GND>,
-#d7_pin: PJ4
+    EXP2_2=PB1, EXP2_4=PB0, EXP2_6=PB2, EXP2_8=PE7, EXP2_10=PH2
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi"
 
-# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+# See the sample-lcd.cfg file for definitions of common LCD displays.
-#[display]
-#lcd_type: st7920
-#cs_pin: PG4
-#sclk_pin: PJ2
-#sid_pin: PG3

config/generic-ramps.cfg

@@ -83,19 +83,16 @@ max_accel: 3000
 max_z_velocity: 5
 max_z_accel: 100
 
-# "RepRapDiscount 2004 Smart Controller" type displays
+# Common EXP1 / EXP2 (display) pins
-#[display]
+[board_pins]
-#lcd_type: hd44780
+aliases:
-#rs_pin: ar16
+    # Common EXP1 header found on many "all-in-one" ramps clones
-#e_pin: ar17
+    EXP1_1=ar37, EXP1_3=ar17, EXP1_5=ar23, EXP1_7=ar27, EXP1_9=<GND>,
-#d4_pin: ar23
+    EXP1_2=ar35, EXP1_4=ar16, EXP1_6=ar25, EXP1_8=ar29, EXP1_10=<5V>,
-#d5_pin: ar25
+    # EXP2 header
-#d6_pin: ar27
+    EXP2_1=ar50, EXP2_3=ar31, EXP2_5=ar33, EXP2_7=ar49, EXP2_9=<GND>,
-#d7_pin: ar29
+    EXP2_2=ar52, EXP2_4=ar53, EXP2_6=ar51, EXP2_8=ar41, EXP2_10=<RST>
+    # Pins EXP2_1, EXP2_6, EXP2_2 are also MISO, MOSI, SCK of bus "spi"
+    # Note, some boards wire: EXP2_8=<RST>, EXP2_10=ar41
 
-# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+# See the sample-lcd.cfg file for definitions of common LCD displays.
-#[display]
-#lcd_type: st7920
-#cs_pin: ar16
-#sclk_pin: ar23
-#sid_pin: ar17

config/generic-re-arm.cfg

@@ -0,0 +1,101 @@
+# This file contains common pin mappings for Re-Arm. To use this
+# config, the firmware should be compiled for the LPC1768.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P2.1
+dir_pin: P0.11
+enable_pin: !P0.10
+step_distance: .0125
+endstop_pin: ^P1.24
+#endstop_pin: ^P1.25
+position_endstop: 0.5
+position_min: 0
+position_max: 200
+homing_speed: 50
+
+# The stepper_y section is used to describe the Y axis as well as the
+# stepper controlling the X-Y movement.
+[stepper_y]
+step_pin: P2.2
+dir_pin: P0.20
+enable_pin: !P0.19
+step_distance: .0125
+endstop_pin: ^P1.26
+#endstop_pin: ^P1.27
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P2.3
+dir_pin: P0.22
+enable_pin: !P0.21
+step_distance: .0025
+endstop_pin: ^P1.29
+#endstop_pin: ^P1.28
+position_endstop: 0.5
+position_min: 0
+position_max: 200
+
+[extruder]
+step_pin: P2.0
+dir_pin: P0.5
+enable_pin: !P0.4
+step_distance: .0011365
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.23
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin: P2.8
+#dir_pin: P2.13
+#enable_pin: !P4.29
+#heater_pin: P2.4
+#sensor_pin: P0.25
+#...
+
+[heater_bed]
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.24
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.4
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+# Re-Arm will only work with this type of display
+#[display]
+#lcd_type: st7920
+#cs_pin: P0.16
+#sclk_pin: P0.15
+#sid_pin: P0.18
+#encoder_pins: ^P3.25, ^P3.26
+#click_pin: ^!P2.11
+#kill_pin: ^!P1.22
+# Ground the buzzer pin to prevent stray voltages causing an audible "whine"
+#[static_digital_output buzzer]
+#pins: !P1.30

config/generic-replicape.cfg

@@ -38,12 +38,6 @@ host_mcu: host
 #   This parameter controls the CFG6_ENN line on all stepper
 #   motors. True sets the enable lines to "open". The default is
 #   False.
-#servo0_enable: False
-#   This parameter controls whether end_stop_X_2 is used for endstops
-#   (via P9_11) or for servo_0 (via P9_14). The default is False.
-#servo1_enable: False
-#   This parameter controls whether end_stop_Y_2 is used for endstops
-#   (via P9_28) or for servo_1 (via P9_16). The default is False.
 stepper_x_microstep_mode: spread16
 #   This parameter controls the CFG1 and CFG2 pins of the given
 #   stepper motor driver. Available options are: disable, 1, 2,
@@ -132,3 +126,11 @@ max_temp: 130
 
 [fan]
 pin: replicape:power_fan0
+
+# The alternative servo pins channels on the endstops x2 and y2 can be used
+# via the special relicape pins servo0 (P9_14) and servo1 (P9_16).
+#[servo servo_x2]
+#pin: replicape:servo0
+#   PWM output pin controlling the servo. This parameter must be
+#   provided.
+#...

config/generic-rumba.cfg

@@ -0,0 +1,115 @@
+# This file contains common pin mappings for RUMBA boards.  To use
+# this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar17
+dir_pin: ar16
+enable_pin: !ar48
+step_distance: .0125
+endstop_pin: ^ar37
+#endstop_pin: ^ar36
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar54
+dir_pin: !ar47
+enable_pin: !ar55
+step_distance: .0125
+endstop_pin: ^ar35
+#endstop_pin: ^ar34
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar57
+dir_pin: ar56
+enable_pin: !ar62
+step_distance: .0125
+endstop_pin: ^ar33
+#endstop_pin: ^ar32
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: ar23
+dir_pin: ar22
+enable_pin: !ar24
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar2
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog15
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin: ar26
+#dir_pin: ar25
+#enable_pin: !ar27
+#heater_pin: ar3
+#sensor_pin: analog14
+#...
+
+#[extruder2]
+#step_pin: ar29
+#dir_pin: ar28
+#enable_pin: !ar39
+#heater_pin: ar6
+#sensor_pin: analog13
+#...
+
+[heater_bed]
+heater_pin: ar9
+sensor_type: NTC 100K beta 3950
+sensor_pin: analog11
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: ar7
+
+#[heater_fan fan1]
+#pin: ar8
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+# "RepRapDiscount 2004 Smart Controller" type displays
+#[display]
+#lcd_type: hd44780
+#rs_pin: ar19
+#e_pin: ar42
+#d4_pin: ar18
+#d5_pin: ar38
+#d6_pin: ar41
+#d7_pin: ar40
+#encoder_pins: ^ar11, ^ar12
+#click_pin: ^!ar43
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: ar19
+#sclk_pin: ar18
+#sid_pin: ar42
+#encoder_pins: ^ar11, ^ar12
+#click_pin: ^!ar43

config/generic-smoothieboard.cfg

@@ -0,0 +1,110 @@
+# This file contains common pin mappings for Smoothieboard. To use
+# this config, the firmware should be compiled for the LPC176x.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P2.0
+dir_pin: P0.5
+enable_pin: !P0.4
+step_distance: .0125
+endstop_pin: ^P1.24
+#endstop_pin: ^P1.25
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P2.1
+dir_pin: !P0.11
+enable_pin: !P0.10
+step_distance: .0125
+endstop_pin: ^P1.26
+#endstop_pin: ^P1.27
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P2.2
+dir_pin: P0.20
+enable_pin: !P0.19
+step_distance: .0025
+endstop_pin: ^P1.28
+#endstop_pin: ^P1.29
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: P2.3
+dir_pin: P0.22
+enable_pin: !P0.21
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P2.7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.24
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+#[extruder1]
+#step_pin: P2.8
+#dir_pin: P2.13
+#enable_pin: !P4.29
+#heater_pin: P2.6
+#sensor_pin: P0.25
+#...
+
+[heater_bed]
+heater_pin: P2.5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: P0.23
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P2.4
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[static_digital_output leds]
+pins: P1.18, P1.19, P1.20, P1.21, P4.28
+
+[mcp4451 stepper_digipot1]
+i2c_address: 44
+# Scale the config so that wiper values can be specified in amps.
+scale: 2.25
+# wiper 0 is X (aka alpha), 1 is Y, 2 is Z, 3 is E0
+wiper_0: 1.0
+wiper_1: 1.0
+wiper_2: 1.0
+wiper_3: 1.0
+
+[mcp4451 stepper_digipot2]
+i2c_address: 45
+scale: 2.25
+# wiper 0 is E1
+wiper_0: 1.0
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: P0.16
+#sclk_pin: P0.15
+#sid_pin: P0.18
+#encoder_pins: ^P3.25, ^P3.26
+#click_pin: ^!P1.30

config/kit-voron2-250mm.cfg

@@ -0,0 +1,299 @@
+# VORON2 250mm config
+
+# This is a base printer.cfg file for the VORON2 printer and matches the manual/build guide exactly
+# for controllers used (dual RAMPS) and pin layout for all connected components.
+# Created by "Boff" with help from the VORON community.
+
+# For other build sizes, controllers, or non-standard pin connections, please see
+# https://github.com/mzbotreprap/VORON/tree/master/Firmware/Klipper/Voron_2.1/Klipper/Configurations
+# for other example Klipper configs created by the VORON community.
+
+# This file is only an example - be sure to review and update it
+# according to the specifics of your printer. See the example.cfg and
+# example-extras.cfg files for a description of available Klipper parameters.
+
+# AND PLEASE READ THROUGH THE KLIPPER DOCUMENTATION FIRST!
+# https://github.com/KevinOConnor/klipper/tree/master/docs
+
+# *** THINGS TO CHANGE/CHECK: ***
+# Arduino paths                         [mcu] section
+# Thermistor types                      [extruder] and [heater_bed] sections - See 'sensor types' list at end of file
+# FSR switch (z endstop) location       [homing_override] section
+# FSR switch (z endstop) offset for Z0  [stepper_z] section
+# Probe points                          [quad_gantry_level] section
+# Min & Max gantry corner postions      [quad_gantry_level] section
+# PID tune                              [extruder] and [heater_bed] sections
+# Fine tune E steps                     [extruder] section
+
+[mcu]
+# Mcu for X/Y/E steppers
+serial: /dev/serial/by-id/**INSERT_YOUR_ARDUINO_DEFINITION_HERE**
+#   Obtain definition by "ls -l /dev/serial/by-id/"
+pin_map: arduino
+restart_method: arduino
+
+[mcu z]
+# Mcu for Z steppers
+serial: /dev/serial/by-id/**INSERT_YOUR_ARDUINO_DEFINITION_HERE**
+#   Obtain definition by "ls -l /dev/serial/by-id/"
+pin_map: arduino
+restart_method: arduino
+
+[printer]
+kinematics: corexy
+max_velocity: 350
+max_accel: 3000
+max_z_velocity: 50
+max_z_accel: 350
+
+[stepper_x]
+# B Stepper
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+#   X on mcu_xye
+step_distance: 0.0125
+#   80 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^ar2
+#   X_MAX on mcu_xye
+position_min: 0
+position_endstop: 250
+position_max: 250
+homing_speed: 100
+homing_retract_dist: 5
+
+[stepper_y]
+# A Stepper
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+#   Y on mcu_xye
+step_distance: 0.0125
+#   80 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^ar15
+#   Y_MAX on mcu_xye
+position_min: 0
+position_endstop: 250
+position_max: 250
+homing_speed: 100
+homing_retract_dist: 5
+
+[stepper_z]
+# Z0 Stepper - Front Left
+step_pin: z:ar54
+dir_pin: !z:ar55
+enable_pin: !z:ar38
+#   X on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+endstop_pin: ^!z:ar18
+#   Z_MIN on mcu_z
+position_endstop: -0.2
+#   Offset (in mm) for nozzle to bed off z switch
+position_max: 250
+position_min: -2
+#   Set to -2 to allow room for squaring gantry with quad_gantry_level
+homing_speed: 15.0
+second_homing_speed: 3.0
+homing_retract_dist: 3.0
+
+[stepper_z1]
+# Z1 Stepper - Rear Left
+step_pin: z:ar60
+dir_pin: z:ar61
+enable_pin: !z:ar56
+#   Y on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[stepper_z2]
+# Z2 Stepper - Rear Right
+step_pin: z:ar46
+dir_pin: !z:ar48
+enable_pin: !z:ar62
+#   Z on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[stepper_z3]
+# Z3 Stepper - Front Right
+step_pin: z:ar26
+dir_pin: z:ar28
+enable_pin: !z:ar24
+#   E0 on mcu_z
+step_distance: 0.00250
+#   400 steps per mm - 1.8 deg - 1/16 microstepping
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+#   E0 on mcu_xye
+step_distance: 0.00180180
+#   555 steps per mm - 1.8 deg - 1/16 microstepping (Mobius2)
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 780.0
+#   This is set high to allow the load/unload filament macros to run
+heater_pin: ar10
+#   D10 on mcu_xye
+max_power: 1.0
+sensor_type: NTC 100K beta 3950
+sensor_pin: analog13
+#   T0 on mcu_xye
+smooth_time: 3.0
+control: pid
+pid_Kp: 16.430
+pid_Ki: 0.755
+pid_Kd: 89.337
+min_extrude_temp: 170
+min_temp: 0
+max_temp: 270
+
+[probe]
+# Inductive Probe
+pin: ^z:ar19
+#   Z_MAX on mcu_z
+x_offset: 0.0
+y_offset: 25.0
+z_offset: 0.00
+speed: 2.0
+samples: 4
+#   Number of times to probe a point
+sample_retract_dist: 6.0
+#   How far to retract (in mm) from the probe point for multi-probe samples
+
+[fan]
+# Print cooling fan
+pin: ar9
+#   D9 on mcu_xye
+kick_start_time: 0.500
+
+[heater_fan hotend_fan]
+# Hotend fan
+pin: z:ar9
+#   D9 on mcu_z
+kick_start_time: 0.500
+heater: extruder
+heater_temp: 50.0
+
+[heater_fan controller_fan]
+# Controller fan
+pin: z:ar10
+#   D10 on mcu_z
+kick_start_time: 0.500
+heater: heater_bed
+heater_temp: 45.0
+
+[heater_fan exhaust_fan]
+# Exhaust fan
+pin: z:ar8
+#   D8 on mcu_z
+kick_start_time: 0.500
+heater: heater_bed
+heater_temp: 60.0
+
+[heater_bed]
+heater_pin: z:ar11
+#   D11 (servo) on mcu_z
+sensor_type: NTC 100K MGB18-104F39050L32
+sensor_pin: z:analog15
+#   T2 on mcu_z
+smooth_time: 3.0
+max_power: 0.75
+control: pid
+pid_Kp: 47.690
+pid_Ki: 1.556
+pid_Kd: 365.338
+min_temp: 0
+max_temp: 110
+
+[homing_override]
+axes: z
+set_position_z: 0
+gcode:
+   G90
+   G0 Z5 F600
+   G28 X Y
+   G0 X179 Y249.5 F3600
+#   XY Location of the FSR Switch
+   G28 Z
+   G0 Z10 F1800
+   G0 X125 Y125 Z20 F3600
+
+[quad_gantry_level]
+#   Use QUAD_GANTRY_LEVEL to level a gantry.
+gantry_corners:
+   -55,-7
+   305, 320
+#   Min & Max gantry corners - measure from nozzle at MIN (0,0) and MAX (250,250) to respective belt positions
+points:
+   25,0
+   25,200
+   225,200
+   225,0
+#   Probe points
+speed: 200
+horizontal_move_z: 6
+
+[display]
+# RepRapDiscount 128x64 Full Graphic Smart Controller
+lcd_type: st7920
+cs_pin: z:ar16
+sclk_pin: z:ar23
+sid_pin: z:ar17
+#   LCD connector on mcu_z
+menu_timeout: 40
+encoder_pins: ^z:ar33, ^z:ar31
+click_pin: ^!z:ar35
+kill_pin: ^!z:ar41
+
+
+###   Macros   ###
+
+[gcode_macro G32]
+gcode:
+    G28
+    QUAD_GANTRY_LEVEL
+    QUAD_GANTRY_LEVEL
+    G0 X125 Y125 Z20 F6000
+
+[gcode_macro PRINT_START]
+#   Use PRINT_START for the slicer starting script - PLEASE CUSTOMISE THE SCRIPT FOR YOUR SLICER OF CHOICE
+gcode:
+    M117 Homing...                 ; display message
+    G28                            ; home all axes
+    G1 Z20 F3000                   ; move nozzle away from bed
+    M117 Preheat (Print)           ; display message
+    M104 S0                        ; turn off hotend while waiting for bed to get to temp
+
+[gcode_macro PRINT_END]
+#   Use PRINT_END for the slicer ending script - PLEASE CUSTOMISE THE SCRIPT FOR YOUR SLICER OF CHOICE
+gcode:
+    M400                           ; wait for buffer to clear
+    G92 E0                         ; zero the extruder
+    G1 E-4.0 F3600                 ; retract
+    G91                            ; relative positioning
+    G0 Z1.00 X20.0 Y20.0 F20000    ; move nozzle to remove stringing
+    M104 S0                        ; turn off hotend
+    M140 S0                        ; turn off bed
+    M106 S0                        ; turn off fan
+    G1 Z20 F3000                   ; move nozzle up 20mm
+    G90                            ; absolute positioning
+    G0  X125 Y245 F3600            ; park nozzle at rear
+    M117 Finished!                 ; display message
+
+[gcode_macro UNLOAD_FILAMENT]
+gcode:
+    M83
+    G1 E10 F300
+    G1 E-780 F1800
+    M82
+
+[gcode_macro LOAD_FILAMENT]
+gcode:
+    M83
+    G1 E750 F1800
+    G1 E30 F300
+    G1 E15 F150
+    M82

config/kit-zav3d-2019.cfg

@@ -0,0 +1,151 @@
+# ZAV3D MAX config. To use this config, the firmware should be
+# compiled for the AVR atmega2560.
+
+# This is a base printer.cfg file for the ZAV3D Max printer and
+# matches the manual/build guide exactly for controllers used (MKS
+# MINI-B V1.0) and pin layout for all connected components.
+# Created by "Nurmukhamed Artykaly"
+
+# This file is only an example - be sure to review and update it
+# according to the specifics of your printer. See the example.cfg and
+# example-extras.cfg files for a description of available Klipper parameters.
+
+# AND PLEASE READ THROUGH THE KLIPPER DOCUMENTATION FIRST!
+# https://www.klipper3d.org/Overview.html
+
+# *** THINGS TO CHANGE/CHECK: ***
+# Arduino paths                         [mcu] section
+# Thermistor types                      [extruder] and [heater_bed] sections - See 'sensor types' list at end of file
+# FSR switch (z endstop) location       [homing_override] section
+# FSR switch (z endstop) offset for Z0  [stepper_z] section
+# Probe points                          [quad_gantry_level] section
+# Min & Max gantry corner postions      [quad_gantry_level] section
+# PID tune                              [extruder] and [heater_bed] sections
+# Fine tune E steps                     [extruder] section
+
+
+[stepper_x]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: .01
+endstop_pin: ^ar3
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+# The stepper_y section is used to describe the Y axis as well as the
+# stepper controlling the X-Y movement.
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .01
+endstop_pin: ^ar14
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+## Configuration with Z Endstop, without Probe tool like BLTOUCH or others.
+#[stepper_z]
+#step_pin: ar46
+#dir_pin: ar48
+#enable_pin: !ar62
+#step_distance: .0025
+## I used Z_MAX_ENDSTOP
+#endstop_pin: ^ar19
+## More about z-calibration is here https://vk.com/topic-107680682_34101598
+#position_endstop: 235
+#position_max: 235
+#homing_positive_dir: true
+
+## Configuration for Bltouch probe tool.
+## Read more about BLTOUCH here https://www.klipper3d.org/BLTouch.html
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+position_min: -3
+position_max: 230
+endstop_pin: probe:z_virtual_endstop
+
+## Configuration with PID Calibration.
+## Read more here https://www.klipper3d.org/Config_checks.html
+[extruder]
+step_pin: ar26
+dir_pin: !ar28
+enable_pin: !ar24
+step_distance: .004242
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+min_temp: 0
+max_temp: 250
+control: pid
+pid_kp: 26.596
+pid_ki: 1.166
+pid_kd: 151.598
+
+## Configuration with PID Calibration.
+## Read more here https://www.klipper3d.org/Config_checks.html
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+min_temp: 0
+max_temp: 130
+control: pid
+pid_kp: 73.517
+pid_ki: 1.822
+pid_kd: 741.600
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: corexy
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30
+
+[bltouch]
+sensor_pin: ^ar18
+control_pin: ar7
+x_offset: 39
+y_offset: 11
+z_offset: 0.9
+pin_up_touch_mode_reports_triggered: false
+samples: 2
+sample_retract_dist: 3.0
+
+[bed_mesh]
+speed: 100
+horizontal_move_z: 5
+min_point: 30,30
+max_point: 150,150
+probe_count: 3,3
+
+[homing_override]
+set_position_z: 6
+axes: z
+gcode:
+        G90
+        G1 Z10 F6000
+        G28 X Y
+        G1 X100 Y100 F6000
+        G28 Z0
+        G1 X100 Y100 Z10a
+
+[gcode_macro G29]
+gcode:
+        G28
+        G1 Z10 F600
+        BED_MESH_CALIBRATE

config/printer-adimlab-2018.cfg

@@ -0,0 +1,120 @@
+# This file contains pin mappings for the ADIMLab 3d printer 2018.
+# To use this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar25
+dir_pin: !ar23
+enable_pin: !ar27
+step_distance: .0125
+endstop_pin: ^!ar22
+position_min: -5
+position_endstop: -5
+position_max: 310
+homing_speed: 30.0
+
+[stepper_y]
+step_pin: ar32
+dir_pin: !ar33
+enable_pin: !ar31
+step_distance: .0125
+endstop_pin: ^!ar26
+position_endstop: 0
+position_max: 310
+homing_speed: 30.0
+
+[stepper_z]
+step_pin: ar35
+dir_pin: ar36
+enable_pin: !ar34
+step_distance: .0025
+endstop_pin: ^!ar29
+position_endstop: 0.0
+position_max: 400
+homing_speed: 5.0
+
+[extruder]
+step_pin: ar42
+dir_pin: ar43
+enable_pin: !ar37
+step_distance: .010799
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar2
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog8
+control: pid
+pid_Kp: 15.717
+pid_Ki: 0.569
+pid_Kd: 108.451
+min_temp: 0
+max_temp: 245
+
+[heater_bed]
+heater_pin: ar4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog10
+control: pid
+pid_Kp: 74.883
+pid_Ki: 1.809
+pid_Kd: 775.038
+min_temp: 0
+max_temp: 110
+
+[verify_heater heater_bed]
+# adjust for personal bed setup, this prevents stock heated bed from issuing
+# false positive heating errors due to slow temperature increase
+# 1 deg per 2 minutes.
+heating_gain: 1
+check_gain_time: 120
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 10
+max_z_accel: 60
+
+[output_pin stepper_xy_current]
+pin: ar44
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.3
+
+[output_pin stepper_z_current]
+pin: ar45
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.3
+
+[output_pin stepper_e_current]
+pin: ar46
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.25
+
+[display]
+lcd_type: st7920
+cs_pin: ar20
+sclk_pin: ar14
+sid_pin: ar15
+encoder_pins: ^ar41, ^ar40
+click_pin: ^!ar19
+
+# The filament runout sensor (on pin ar24) is not currently supported
+# in Klipper.
+
+[output_pin case_light]
+pin: ar7
+value: 1

config/printer-anet-a8-2017.cfg

@@ -77,3 +77,22 @@ max_velocity: 300
 max_accel: 1000
 max_z_velocity: 20
 max_z_accel: 100
+
+[display]
+lcd_type: hd44780
+rs_pin: PA3
+e_pin: PA2
+d4_pin: PD2
+d5_pin: PD3
+d6_pin: PC0
+d7_pin: PC1
+up_pin: PA1
+analog_range_up_pin: 9000, 13000
+down_pin: PA1
+analog_range_down_pin: 800, 1300
+click_pin: PA1
+analog_range_click_pin: 2000, 2500
+back_pin: PA1
+analog_range_back_pin: 4500, 5000
+#kill_pin: PA1
+#analog_range_kill_pin: 400, 600

config/printer-anet-e10-2018.cfg

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for Anet E10 printer from
+# 2018.  To use this config, the firmware should be compiled for the
+# AVR atmega1284p.
+
+# Note that the "make flash" command does not work with Anet boards -
+# the boards are typically flashed with this command:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD7
+dir_pin: PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^!PC2
+position_endstop: -3
+position_max: 220
+position_min: -3
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: !PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^!PC3
+position_endstop: -22
+position_min: -22
+position_max: 270
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: !PB2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^!PC4
+position_endstop: 0.5
+position_max: 300
+homing_speed: 20
+
+[extruder]
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: 0.01
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PA7
+control: pid
+pid_Kp: 27.0
+pid_Ki: 1.3
+pid_Kd: 136.09
+min_temp: 10
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PA6
+control: pid
+pid_Kp: 72.8
+pid_Ki: 1.2
+pid_Kd: 1100
+min_temp: 10
+max_temp: 130
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1000
+max_z_velocity: 20
+max_z_accel: 1000
+
+[display]
+lcd_type: st7920
+cs_pin: PA4
+sclk_pin: PA1
+sid_pin:PA3

config/printer-anycubic-4max-2018.cfg

@@ -0,0 +1,127 @@
+# Klipper firmware config file for Anycubic 4Max. To use this config,
+# the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: .0125
+endstop_pin: ^!ar3
+position_min: -2
+position_endstop: -2
+position_max: 205
+homing_speed: 60.0
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^!ar14
+position_endstop: 0
+position_max: 215
+homing_speed: 60.0
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^!ar18
+position_endstop: 0.5
+position_max: 305
+homing_speed: 8.0
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: 0.010354
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 2000
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_kp: 27.725
+pid_ki: 1.224
+pid_kd: 156.991
+min_temp: 0
+max_temp: 300
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_kp: 73.735
+pid_ki: 1.437
+pid_kd: 945.653
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: ar9
+kick_start_time: 1.0
+
+[mcu]
+serial: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 1200
+max_accel: 1500
+max_z_velocity: 40
+max_z_accel: 60
+
+[heater_fan extruder_fan]
+pin: ar44
+
+[heater_fan stepstick_fan]
+pin: ar7
+kick_start_time: 1.0
+
+[display]
+lcd_type: st7920
+cs_pin: ar16
+sclk_pin: ar23
+sid_pin: ar17
+encoder_pins: ^ar31, ^ar33
+click_pin: ^!ar35
+kill_pin: ^!ar41
+
+[filament_switch_sensor e0_sensor]
+switch_pin: ar19
+
+[gcode_macro START_PRINT]
+gcode:
+    M117 Starting...
+    G90 ; absolute positioning
+    M107 ; start with the fan off
+    G28 ; Home
+    G0 X5 Y5 F4500 ; Go to front
+    G0 Z0.3 ; Drop to bed
+    G92 E0 ; zero the extruded length
+    G1 Y40 E15 F500 ; Extrude 15mm of filament in a 4cm line
+    G92 E0 ; zero the extruded length
+    G1 Y80 F4000 ; Quickly wipe away from the filament line
+    G1 Z1 ; Raise and begin printing.
+    M117 Printing...
+
+[gcode_macro END_PRINT]
+gcode:
+    M117 End printing.
+    G91 ; relative positioning
+    G1 E-1 F300 ;retract the filament a bit before lifting the nozzle to release some of the pressure
+    G1 Z+5 E-2 F1000 ;move Z up a bit and extract a bit more
+    G90 ; absolute positioning
+    G1 X0 F2000 ; move X to min endstops so the head is out of the way
+    G1 Y200 F2000 ; Move Y to the back
+    m104 S0 ; turn hotend heating off
+    M140 S0 ; turn bed heating off
+    M107 ; turn fan off
+    M84 ; steppers off

config/printer-anycubic-kossel-2016.cfg

@@ -0,0 +1,109 @@
+# This file contains a configuration for the Anycubic Kossel delta
+# printer from 2016.
+
+# The Anycubic delta printers use the TriGorilla board which is an
+# AVR ATmega2560 Arduino + RAMPS compatible board.
+# To use this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_a]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .0125
+endstop_pin: ^ar2
+homing_speed: 60
+# The next parameter needs to be adjusted for
+# your printer. You may want to start with 280
+# and meassure the distance from nozzle to bed.
+# This value then needs to be added.
+position_endstop: 273.0
+arm_length: 229.4
+
+[stepper_b]
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^ar15
+
+[stepper_c]
+step_pin: ar46
+dir_pin: !ar48
+enable_pin: !ar62
+step_distance: .0125
+endstop_pin: ^ar19
+
+[extruder]
+step_pin: ar26
+dir_pin: !ar28
+enable_pin: !ar24
+step_distance: 0.010989
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+control: pid
+pid_Kp: 25.349
+pid_Ki: 1.216
+pid_Kd: 132.130
+min_extrude_temp: 150
+min_temp: 0
+max_temp: 275
+
+#[heater_bed]
+#heater_pin: ar8
+#sensor_type: EPCOS 100K B57560G104F
+#sensor_pin: analog14
+#control: watermark
+#min_temp: 0
+#max_temp: 130
+
+[fan]
+pin: ar9
+kick_start_time: 0.200
+
+[heater_fan extruder_cooler_fan]
+pin: ar44
+
+[mcu]
+serial: /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge_Controller_0001-if00-port0
+pin_map: arduino
+
+[printer]
+kinematics: delta
+max_velocity: 500
+max_accel: 3000
+max_z_velocity: 200
+delta_radius: 99.8
+# if you want to DELTA_CALIBRATE you may need that
+#minimum_z_position: -5
+
+[idle_timeout]
+timeout: 360
+
+#[delta_calibrate]
+#radius: 80
+#manual_probe:
+#   If true, then DELTA_CALIBRATE will perform manual probing. If
+#   false, then a PROBE command will be run at each probe
+#   point. Manual probing is accomplished by manually jogging the Z
+#   position of the print head at each probe point and then issuing a
+#   NEXT extended g-code command to record the position at that
+#   point. The default is false if a [probe] config section is present
+#   and true otherwise.
+
+# "RepRapDiscount 2004 Smart Controller" type displays
+[display]
+lcd_type: hd44780
+rs_pin: ar16
+e_pin: ar17
+d4_pin: ar23
+d5_pin: ar25
+d6_pin: ar27
+d7_pin: ar29
+encoder_pins: ^ar31, ^ar33
+click_pin: ^!ar35
+kill_pin: ^!ar41

config/printer-anycubic-kossel-plus-2017.cfg

@@ -0,0 +1,109 @@
+# This file contains a configuration for the "Anycubic Kossel Linear
+# Plus Large Printing Size", "Anycubic Kossel Pulley Plus Large
+# Printing Size" and similar delta printer from 2017.
+# The Anycubic delta printers use the TriGorilla board which is an
+# AVR ATmega2560 Arduino + RAMPS compatible board.
+# To use this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_a]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .0125
+endstop_pin: ^ar2
+homing_speed: 60
+# The next parameter needs to be adjusted for
+# your printer. You may want to start with 280
+# and meassure the distance from nozzle to bed.
+# This value then needs to be added.
+position_endstop: 295.6
+arm_length: 271.50
+
+[stepper_b]
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^ar15
+
+[stepper_c]
+step_pin: ar46
+dir_pin: !ar48
+enable_pin: !ar62
+step_distance: .0125
+endstop_pin: ^ar19
+
+[extruder]
+step_pin: ar26
+dir_pin: !ar28
+enable_pin: !ar24
+step_distance: 0.010989
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+control: pid
+pid_Kp: 25.349
+pid_Ki: 1.216
+pid_Kd: 132.130
+min_extrude_temp: 150
+min_temp: 0
+max_temp: 275
+
+#[heater_bed]
+#heater_pin: ar8
+#sensor_type: EPCOS 100K B57560G104F
+#sensor_pin: analog14
+#control: watermark
+#min_temp: 0
+#max_temp: 130
+
+[fan]
+pin: ar9
+kick_start_time: 0.200
+
+[heater_fan extruder_cooler_fan]
+pin: ar44
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: delta
+max_velocity: 500
+max_accel: 3000
+max_z_velocity: 200
+delta_radius: 115
+# if you want to DELTA_CALIBRATE you may need that
+#minimum_z_position: -5
+
+[idle_timeout]
+timeout: 360
+
+#[delta_calibrate]
+#radius: 115
+#manual_probe:
+#   If true, then DELTA_CALIBRATE will perform manual probing. If
+#   false, then a PROBE command will be run at each probe
+#   point. Manual probing is accomplished by manually jogging the Z
+#   position of the print head at each probe point and then issuing a
+#   NEXT extended g-code command to record the position at that
+#   point. The default is false if a [probe] config section is present
+#   and true otherwise.
+
+# "RepRapDiscount 2004 Smart Controller" type displays
+[display]
+lcd_type: hd44780
+rs_pin: ar16
+e_pin: ar17
+d4_pin: ar23
+d5_pin: ar25
+d6_pin: ar27
+d7_pin: ar29
+encoder_pins: ^ar31, ^ar33
+click_pin: ^!ar35
+kill_pin: ^!ar41

config/printer-creality-cr10-2017.cfg

@@ -2,12 +2,12 @@
 # CR-10. To use this config, the firmware should be compiled for the
 # AVR atmega1284p.
 
-# Note, a number of Melzi boards are shipped without a bootloader. In
+# Note, a number of Melzi boards are shipped with a bootloader that
-# that case, an external programmer will be needed to flash a
+# requires the following command to flash the board:
-# bootloader to the board (for example, see
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
-# http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/
+# If the above command does not work and "make flash" does not work
-# ). Once that is done, one should be able to use the standard "make
+# then one may need to flash a bootloader to the board - see the
-# flash" command to flash Klipper.
+# Klipper docs/Bootloaders.md file for more information.
 
 # See the example.cfg file for a description of available parameters.
 
@@ -59,7 +59,7 @@ max_temp: 250
 
 [heater_bed]
 heater_pin: PD4
-sensor_type: EPCOS 100K B57560G104F
+sensor_type: ATC Semitec 104GT-2
 sensor_pin: PA6
 control: pid
 pid_Kp: 426.68
@@ -86,3 +86,5 @@ lcd_type: st7920
 cs_pin: PA3
 sclk_pin: PA1
 sid_pin: PC1
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PC0

config/printer-creality-cr10mini-2017.cfg

@@ -0,0 +1,90 @@
+# This file contains common pin mappings for the 2017 Creality CR-10
+# mini. To use this config, the firmware should be compiled for the
+# AVR atmega1284p.
+
+# Note, a number of Melzi boards are shipped with a bootloader that
+# requires the following command to flash the board:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+# If the above command does not work and "make flash" does not work
+# then one may need to flash a bootloader to the board - see the
+# Klipper docs/Bootloaders.md file for more information.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD7
+dir_pin: !PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC2
+position_endstop: 0
+position_max: 300
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: !PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC3
+position_endstop: 0
+position_max: 220
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: PB2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PC4
+position_endstop: 0.0
+position_max: 300
+
+[extruder]
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA7
+control: pid
+pid_Kp: 22.57
+pid_Ki: 1.72
+pid_Kd: 73.96
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PA6
+control: pid
+pid_Kp: 426.68
+pid_Ki: 78.92
+pid_Kd: 576.71
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: PA3
+sclk_pin: PA1
+sid_pin: PC1
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PC0

config/printer-creality-cr10s-2017.cfg

@@ -29,8 +29,8 @@ dir_pin: !ar48
 enable_pin: !ar62
 step_distance: .0025
 endstop_pin: ^ar18
-position_endstop: 0.5
+position_endstop: 0
-position_max: 200
+position_max: 400
 
 [extruder]
 step_pin: ar26
@@ -51,7 +51,7 @@ max_temp: 250
 
 [heater_bed]
 heater_pin: ar8
-sensor_type: EPCOS 100K B57560G104F
+sensor_type: ATC Semitec 104GT-2
 sensor_pin: analog14
 control: pid
 pid_Kp: 690.34
@@ -73,3 +73,11 @@ max_velocity: 300
 max_accel: 3000
 max_z_velocity: 5
 max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: ar16
+sclk_pin: ar23
+sid_pin: ar17
+encoder_pins: ^ar33, ^ar31
+click_pin: ^!ar35

config/printer-creality-cr20-2018.cfg

@@ -0,0 +1,81 @@
+# This file contains pin mappings for the Creality CR-20. To use
+# this config, the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PF0
+dir_pin: PF1
+enable_pin: !PD7
+step_distance: .0125
+endstop_pin: ^PE5
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[stepper_y]
+step_pin: PF6
+dir_pin: PF7
+enable_pin: !PF2
+step_distance: .0125
+endstop_pin: ^PJ1
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[stepper_z]
+step_pin: PL3
+dir_pin: !PL1
+enable_pin: !PK0
+step_distance: .0025
+endstop_pin: ^PD3
+position_endstop: 0
+position_max: 250
+
+[extruder]
+step_pin: PA4
+dir_pin: PA6
+enable_pin: !PA2
+step_distance: .010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK5
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PH5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK6
+control: pid
+pid_Kp: 690.34
+pid_Ki: 111.47
+pid_Kd: 1068.83
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PH6
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: uc1701
+cs_pin: PA3
+a0_pin: PA5
+encoder_pins: ^PC4, ^PC6
+click_pin: ^!PC2

config/printer-creality-ender2-2017.cfg

@@ -0,0 +1,93 @@
+# This file contains common pin mappings for the 2017 Creality
+# Ender 2. To use this config, the firmware should be compiled for the
+# AVR atmega1284p.
+
+# Note, a number of Melzi boards are shipped with a bootloader that
+# requires the following command to flash the board:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+# If the above command does not work and "make flash" does not work
+# then one may need to flash a bootloader to the board - see the
+# Klipper docs/Bootloaders.md file for more information.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD7
+dir_pin: !PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC2
+position_endstop: 0
+position_max: 165
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: !PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC3
+position_endstop: 0
+position_max: 165
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: PB2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PC4
+position_endstop: 0.0
+position_max: 205
+
+[extruder]
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: 0.010753
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 500.0
+max_extrude_only_velocity: 200.0
+max_extrude_only_accel: 500.0
+heater_pin: PD5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA7
+control: pid
+pid_Kp: 21.73
+pid_Ki: 1.54
+pid_Kd: 76.55
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA6
+control: pid
+# PID Tuned for 60C
+pid_Kp: 72.487
+pid_Ki: 2.279
+pid_Kd: 576.275
+min_temp: 0
+max_temp: 100
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1500
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: uc1701
+cs_pin: PA3
+a0_pin: PA1
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PC0

config/printer-creality-ender3-2018.cfg

@@ -0,0 +1,93 @@
+# This file contains common pin mappings for the 2018 Creality
+# Ender 3. To use this config, the firmware should be compiled for the
+# AVR atmega1284p.
+
+# Note, a number of Melzi boards are shipped with a bootloader that
+# requires the following command to flash the board:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+# If the above command does not work and "make flash" does not work
+# then one may need to flash a bootloader to the board - see the
+# Klipper docs/Bootloaders.md file for more information.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD7
+dir_pin: !PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC2
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: !PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC3
+position_endstop: 0
+position_max: 235
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: PB2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PC4
+position_endstop: 0.0
+position_max: 250
+
+[extruder]
+max_extrude_only_distance: 100.0
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA7
+control: pid
+# tuned for stock hardware with 200 degree Celsius target
+pid_Kp: 21.527
+pid_Ki: 1.063
+pid_Kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA6
+control: pid
+# tuned for stock hardware with 50 degree Celsius target
+pid_Kp: 54.027
+pid_Ki: 0.770
+pid_Kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: PA3
+sclk_pin: PA1
+sid_pin: PC1
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PC0

config/printer-creality-ender5-2019.cfg

@@ -0,0 +1,93 @@
+# This file contains common pin mappings for the 2019 Creality
+# Ender 5. To use this config, the firmware should be compiled for the
+# AVR atmega1284p.
+
+# Note, a number of Melzi boards are shipped with a bootloader that
+# requires the following command to flash the board:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+# If the above command does not work and "make flash" does not work
+# then one may need to flash a bootloader to the board - see the
+# Klipper docs/Bootloaders.md file for more information.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PD7
+dir_pin: PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC2
+position_endstop: 0
+position_max: 235
+homing_speed: 30
+
+[stepper_y]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^PC3
+position_endstop: 0
+position_max: 235
+homing_speed: 30
+
+[stepper_z]
+step_pin: PB3
+dir_pin: !PB2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PC4
+position_endstop: 0.0
+position_max: 300
+
+[extruder]
+max_extrude_only_distance: 100.0
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: 0.010526
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA7
+control: pid
+# tuned for stock hardware with 200 degree Celsius target
+pid_Kp: 21.527
+pid_Ki: 1.063
+pid_Kd: 108.982
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA6
+control: pid
+# tuned for stock hardware with 50 degree Celsius target
+pid_Kp: 54.027
+pid_Ki: 0.770
+pid_Kd: 948.182
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: PA3
+sclk_pin: PA1
+sid_pin: PC1
+encoder_pins: ^PD2, ^PD3
+click_pin: ^!PC0

config/printer-makergear-m2-2012.cfg

@@ -12,8 +12,10 @@ endstop_pin: ^!PB6
 position_endstop: 0.0
 position_max: 200
 homing_speed: 50
-homing_stepper_phases: 32
+
-homing_endstop_accuracy: .200
+[endstop_phase stepper_x]
+phases: 32
+endstop_accuracy: .200
 
 [stepper_y]
 step_pin: PC1
@@ -24,8 +26,10 @@ endstop_pin: ^!PB5
 position_endstop: 0.0
 position_max: 250
 homing_speed: 50
-homing_stepper_phases: 32
+
-homing_endstop_accuracy: .200
+[endstop_phase stepper_y]
+phases: 32
+endstop_accuracy: .200
 
 [stepper_z]
 step_pin: PC2
@@ -37,8 +41,10 @@ position_min: 0.1
 position_endstop: 0.7
 position_max: 200
 homing_retract_dist: 2.0
-homing_stepper_phases: 32
+
-homing_endstop_accuracy: .070
+[endstop_phase stepper_z]
+phases: 32
+endstop_accuracy: .070
 
 [extruder]
 step_pin: PC3

config/printer-micromake-d1-2016.cfg

@@ -0,0 +1,79 @@
+# This file contains a configuration for the "Micromake D1" delta
+# printer (using the Makeboard 1.3 electronics). To use this config,
+# the firmware should be compiled for the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_a]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .01
+endstop_pin: ^ar2
+homing_speed: 100
+position_endstop: 319.5
+arm_length: 217.0
+
+[stepper_b]
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+step_distance: .01
+endstop_pin: ^ar15
+
+[stepper_c]
+step_pin: ar46
+dir_pin: !ar48
+enable_pin: !ar62
+step_distance: .01
+endstop_pin: ^ar19
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: 0.006271
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+max_extrude_only_distance: 100.0
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyACM0
+pin_map: arduino
+
+[printer]
+kinematics: delta
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 150
+delta_radius: 95
+
+[delta_calibrate]
+radius: 80
+
+#[probe]
+#pin: ^!ar18
+
+[display]
+lcd_type: hd44780
+rs_pin: ar16
+e_pin: ar17
+d4_pin: ar23
+d5_pin: ar25
+d6_pin: ar27
+d7_pin: ar29
+encoder_pins: ^ar31, ^ar33
+click_pin: ^!ar35
+kill_pin: ^!ar41

config/printer-tevo-flash-2018.cfg

@@ -0,0 +1,124 @@
+# Support for Tevo Flash. To use this config, the firmware should be
+# compiled for the AVR atmega2560.
+
+# Note, this config has only been tested on a modified Tevo Flash
+# (using a Bondtech BMG extruder). If using a stock printer it may be
+# necessary to update the extruder step_distance parameter.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .012491
+endstop_pin: !ar3
+position_endstop: -13
+position_min: -13
+position_max: 235
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .012441
+endstop_pin: !ar14
+position_endstop: -3
+position_min: -3
+position_max: 235
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .002520
+position_max: 250
+endstop_pin: probe:z_virtual_endstop
+position_min: -2
+
+[stepper_z1]
+step_pin: ar36
+dir_pin: ar34
+enable_pin: !ar30
+step_distance: .002520
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .002401
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog13
+control: pid
+pid_Kp: 18.547
+pid_Ki: 0.788
+pid_Kd: 109.193
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_Kp: 38.824
+pid_Ki: 0.539
+pid_Kd: 698.838
+min_temp: 0
+max_temp: 70
+
+[heater_fan my_nozzle_fan]
+pin: ar7
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1000
+max_z_velocity: 5
+max_z_accel: 100
+
+[display]
+lcd_type: uc1701
+cs_pin: ar25
+a0_pin: ar27
+encoder_pins: ^!ar31, ^!ar33
+click_pin: ^!ar35
+kill_pin: ar64
+
+[bltouch]
+sensor_pin: ar18
+control_pin: ar11
+x_offset: 0
+y_offset: 18
+z_offset: 1.64
+samples: 3
+sample_retract_dist: 5
+
+# The homing_override section modifies the default G28 behavior
+[homing_override]
+set_position_z: 0
+axes: z
+gcode:
+    G90
+    G1 Z5 F600
+    G28 X0 Y0
+    G1 X118 Y118 F3600
+    G28 Z0
+
+# Mesh Bed Leveling.
+[bed_mesh]
+min_point: 5,0
+max_point: 230,210
+probe_count: 9,9

config/printer-tronxy-x5s-2018.cfg

@@ -2,12 +2,12 @@
 # use this config, the firmware should be compiled for the AVR
 # atmega1284p.
 
-# Note, a number of Melzi boards are shipped without a bootloader. In
+# Note, a number of Melzi boards are shipped with a bootloader that
-# that case, an external programmer will be needed to flash a
+# requires the following command to flash the board:
-# bootloader to the board (for example, see
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
-# http://www.instructables.com/id/Flashing-a-Bootloader-to-the-CR-10/
+# If the above command does not work and "make flash" does not work
-# ). Once that is done, one should be able to use the standard "make
+# then one may need to flash a bootloader to the board - see the
-# flash" command to flash Klipper.
+# Klipper docs/Bootloaders.md file for more information.
 
 # See the example.cfg file for a description of available parameters.
 
@@ -65,6 +65,11 @@ control: watermark
 min_temp: 0
 max_temp: 150
 
+[verify_heater heater_bed]
+# adjust for personal bed setup, this prevents stock heated bed from issuing
+# false positive heating errors due to slow temperature increase
+check_gain_time: 600
+
 [fan]
 pin: PB4
 
@@ -83,7 +88,5 @@ lcd_type: st7920
 cs_pin: PA1
 sclk_pin: PC0
 sid_pin: PA3
-
+encoder_pins: ^PD2, ^PD3
-# buttons are:
+click_pin: ^!PA5
-# PD2, PD3: encoder
-# PA5: click

config/printer-tronxy-x8-2018.cfg

@@ -0,0 +1,91 @@
+# This file contains the configurations and pin mappings for the
+# Tronxy X8 using the CXY-V2-0508 board.  To use this config file, the
+# firmware should be compiled for the AVR ATmega1284p, 16MHz.
+
+# Some Tronxy printers come without a bootloader present on the
+# board. In that case, use MCUDude MightyCore ATmega1284p bootloader
+# with TQFP44 Sanguino pinout. The package can be found at
+# (https://github.com/MCUdude/MightyCore).  Follow Klipper install
+# instructions but instead of "make flash FLASH_DEVICE=/dev/ttyACM0",
+# use the following command:
+# avrdude -p atmega1284p -c arduino -b 115200 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+
+# See the example.cfg and example-extras.cfg files for a description
+# of available parameters.
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[stepper_x]
+step_pin: PD7
+dir_pin: PC5
+enable_pin: !PD6
+step_distance: 0.010
+endstop_pin: ^!PC2
+position_endstop: -47
+position_max: 220
+position_min: -47
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PD6
+step_distance: 0.010
+endstop_pin: ^!PC3
+position_endstop: 0
+position_max: 220
+position_min: 0
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: !PB2
+enable_pin: !PD6
+step_distance: 0.0025
+endstop_pin: ^!PC4
+position_endstop: 0
+position_max: 210
+homing_speed: 10
+
+[extruder]
+step_pin: PB1
+dir_pin: PB0
+enable_pin: !PD6
+step_distance: 0.009931
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA7
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 275
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA6
+control: watermark
+max_delta: 2.0
+min_temp: 0
+max_temp: 150
+
+[fan]
+pin: PB4
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1000
+max_z_velocity: 20
+max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: PA1
+sclk_pin: PC0
+sid_pin: PA3

config/printer-velleman-k8200-2013.cfg

@@ -0,0 +1,95 @@
+# This file contains common pin mappings for the Velleman K8200 and
+# 3Drag 3D printers (circa 2013). To use this config, the firmware
+# should be compiled for the AVR atmega2560.
+
+# Based on config from Martin Malmqvist and Per Hjort.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: ar54
+dir_pin: !ar55
+enable_pin: !ar38
+step_distance: .0125
+endstop_pin: ^ar3
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^ar14
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar46
+dir_pin: !ar48
+enable_pin: !ar63
+step_distance: .0025
+endstop_pin: ^ar18
+position_endstop: 0.5
+# Set position_max to 200 if you have the original Z-axis setup.
+position_max: 250
+
+[extruder]
+step_pin: ar26
+# Remove the "!" from dir_pin if you have an original extruder
+dir_pin: !ar28
+enable_pin: !ar24
+# You will have to calculate your own step_distance.
+# This is for the belted extruder https://www.thingiverse.com/thing:339928
+step_distance: .001333
+nozzle_diameter: 0.400
+filament_diameter: 2.85
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_Kp: 21.503
+pid_Ki: 1.103
+pid_Kd: 104.825
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: ar9
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog14
+control: pid
+pid_Kp: 75.283
+pid_Ki: 0.588
+pid_Kd: 2408.103
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: ar8
+kick_start_time: 0.500
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 1000
+max_z_velocity: 10
+max_z_accel: 100
+
+# The LCD is untested - "RepRapDiscount 2004 Smart Controller" displays
+#[display]
+#lcd_type: hd44780
+#rs_pin: ar27
+#e_pin: ar29
+#d4_pin: ar37
+#d5_pin: ar35
+#d6_pin: ar33
+#d7_pin: ar31
+#encoder_pins: ^ar16, ^ar17
+#click_pin: ^!ar23

config/printer-wanhao-duplicator-6-2016.cfg

@@ -0,0 +1,107 @@
+# Support for the Wanhao Duplicator 6 and its clones (eg, Monoprice
+# Ultimate). To use this config, the firmware should be compiled for
+# the AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PA3
+dir_pin: !PA1
+enable_pin: !PA5
+step_distance: 0.0125
+endstop_pin: ^!PA0
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC5
+dir_pin: PC4
+enable_pin: !PC6
+step_distance: 0.0125
+endstop_pin: ^!PA4
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PC2
+dir_pin: !PC1
+enable_pin: !PC3
+step_distance: 0.0025
+endstop_pin: ^!PA7
+position_endstop: 0.5
+position_max: 175
+homing_speed: 25
+
+[extruder]
+step_pin: PL7
+dir_pin: !PL6
+enable_pin: !PC0
+step_distance: 0.010091
+nozzle_diameter: 0.400
+filament_diameter: 1.7500
+heater_pin: PE4
+sensor_type: PT100 INA826
+sensor_pin: PK0
+control: pid
+pid_Kp: 26.571
+pid_Ki: 0.927
+pid_Kd: 190.318
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK2
+control: pid
+pid_Kp: 59.593
+pid_Ki: 3.01
+pid_Kd: 294.985
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: PH4
+
+[mcu]
+serial: /dev/ttyACM0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+# Software control for Stepper current
+[output_pin stepper_xy_current]
+pin: PL5
+pwm: True
+scale: 2.782
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.2
+
+[output_pin stepper_z_current]
+pin: PL4
+pwm: True
+scale: 2.782
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.2
+
+[output_pin stepper_e_current]
+pin: PL3
+pwm: True
+scale: 2.782
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.0
+
+[display]
+lcd_type: ssd1306
+reset_pin: PE3
+encoder_pins: ^PG1, ^PG0
+click_pin: ^!PD2

config/printer-wanhao-duplicator-i3-plus-mark2-2019.cfg

@@ -0,0 +1,81 @@
+# This file contains pin mappings for the Wanhao Duplicator i3 Plus
+# Mark II. To use this config, the firmware should be compiled for the
+# AVR atmega2560.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PF7
+dir_pin: !PK0
+enable_pin: !PF6
+step_distance: .0125
+endstop_pin: ^!PF0
+position_endstop: 0
+position_max: 200
+homing_speed: 30.0
+
+[stepper_y]
+step_pin: PK2
+dir_pin: !PK3
+enable_pin: !PE4
+step_distance: .0125
+endstop_pin: ^!PA2
+position_endstop: 0
+position_max: 200
+homing_speed: 30.0
+
+[stepper_z]
+step_pin: PK5
+dir_pin: PK7
+enable_pin: !PK4
+step_distance: .0025
+endstop_pin: probe:z_virtual_endstop
+position_max: 180
+position_min: -0.5
+
+[extruder]
+step_pin: PF4
+dir_pin: PF5
+enable_pin: !PF3
+step_distance: 0.010417
+nozzle_diameter: 0.300
+filament_diameter: 1.750
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF1
+control: pid
+pid_Kp: 20.982
+pid_Ki: 0.725
+pid_Kd: 151.861
+min_temp: 0
+max_temp: 260
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK6
+control: watermark
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: PE3
+
+[probe]
+pin: !PH3
+z_offset: 1.0
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 800
+max_z_velocity: 5
+max_z_accel: 100
+
+[bed_mesh]
+min_point: 20,20
+max_point: 190,130
+probe_count: 4,4

config/printer-wanhao-duplicator-i3-v2.1-2017.cfg

@@ -1,20 +1,22 @@
-# This file contains pin mappings and other appropriate default parameters
+# This file contains pin mappings and other appropriate default
-# for a Wanhao Duplicator i3 v2.1 and its clones
+# parameters for a Wanhao Duplicator i3 v2.1 and its clones (Monoprice
-# (Monoprice Maker Select, Cocoon Create, etc.)
+# Maker Select, Cocoon Create, etc.).
-# See the files example.cfg and example-extras.cfg for a description of available parameters.
 #
 # This will probably work on older revisions (v1.0, v2.0) of the printer
 # but is untested on those versions.
-#
+
+# Note, a number of Melzi boards are shipped with a bootloader that
+# requires the following command to flash the board:
+#  avrdude -p atmega1284p -c arduino -b 57600 -P /dev/ttyUSB0 -U out/klipper.elf.hex
+# If the above command does not work and "make flash" does not work
+# then one may need to flash a bootloader to the board - see the
+# Klipper docs/Bootloaders.md file for more information.
+
+# See the example.cfg file for a description of available parameters.
+
 # For best results with klipper and the Wanhao Duplicator i3, follow these
 # guidelines:
 #
-# - Flash a bootloader to the Melzi board in the printer
-#   See http://www.instructables.com/id/Using-an-Arduino-to-Flash-the-Melzi-Board-Wanhao-I/
-#
-# - Make sure the auto-reset jumper is *enabled* on the Melzi board
-#   (See step 1 in the bootloader tutorial above)
-#
 # - Locate the USB serial port for your printer in /dev/serial/by-id/ format.
 #   See https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#wheres-my-serial-port
 #   It will be something like:
@@ -65,6 +67,12 @@
 #     (like an upgraded hot end or a separate MOSFET for your heated bed), you may
 #     want to increase these values.
 #
+#     Note: Some Melzi boards were shipped with 10K pullup resistors
+#     instead of 4.7K. If the temperatures on your printer seem way
+#     off before running the PID tune, you may need to add
+#     "pullup_resistor: 10000" to both the extruder and the heater_bed
+#     config sections.
+#
 #   * [mcu] > serial
 #
 #     Enter the USB serial port of the printer in /dev/serial/by-id/ format
@@ -157,3 +165,5 @@ lcd_type: st7920
 cs_pin: PC1
 sclk_pin: PD3
 sid_pin: PC0
+encoder_pins: ^PA2, ^PA1
+click_pin: ^!PA3

config/sample-bltouch.cfg

@@ -1,56 +0,0 @@
-# This file provides example config file settings for the BLTouch
-# automatic bed leveling sensor. This file is just a "snippet" of
-# sections specific to the BLTouch - it must be added to a config file
-# containing the configuration of the rest of the printer.
-
-# Be sure to review and update this config with the appropriate pins
-# and coordinates for your printer.
-
-# See the "example.cfg" and "example-extras.cfg" files for a
-# description of config parameters.
-
-# Define the BLTouch servo
-[servo bltouch]
-pin: ar32
-maximum_servo_angle: 180
-minimum_pulse_width: 0.0006
-maximum_pulse_width: 0.0024
-
-# Define a probe using the BLTouch
-[probe]
-pin: ar30
-activate_gcode:
-    SET_SERVO SERVO=bltouch ANGLE=10
-    SET_SERVO SERVO=bltouch ANGLE=60
-    G4 P200
-deactivate_gcode:
-    SET_SERVO SERVO=bltouch ANGLE=90
-
-# Example bed_tilt config section
-[bed_tilt]
-#x_adjust:
-#y_adjust:
-points:
-    100,100
-    10,10
-    10,100
-    10,190
-    100,10
-    100,190
-    190,10
-    190,100
-    190,190
-probe_z_offset: 2.345
-
-# If the BLTouch is used to home the Z axis, then define a
-# homing_override section, use probe:z_virtual_endstop as the
-# endstop_pin in the stepper_z section, and set the endstop_position
-# in the stepper_z section to match the probe's probe_z_offset.
-#[homing_override]
-#set_position_z: 5
-#gcode:
-#    ; G90   ; Uncomment these 2 lines to blindly lift the Z 2mm at start
-#    ; G1 Z7 F600
-#    G28 X0 Y0
-#    G1 X100 Y100 F3600
-#    G28 Z0

config/sample-lcd.cfg

@@ -0,0 +1,143 @@
+# This file provides example configuration for common "RepRap" style
+# LCD displays that use EXP1/EXP2 plugs.
+
+# To configure a display from this file, make sure the main
+# printer.cfg file has a [board_pins] config section defining pin
+# aliases for the EXP1/EXP2 plugs, find the appropriate LCD type in
+# this file, and then copy-and-paste that section into printer.cfg.
+
+# See the "example-extras.cfg" file for description of config parameters.
+
+
+######################################################################
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+######################################################################
+
+[display]
+lcd_type: st7920
+cs_pin: EXP1_4
+sclk_pin: EXP1_5
+sid_pin: EXP1_3
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+#kill_pin: ^!EXP2_8
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# "RepRapDiscount 2004 Smart Controller" type displays
+######################################################################
+
+[display]
+lcd_type: hd44780
+rs_pin: EXP1_4
+e_pin: EXP1_3
+d4_pin: EXP1_5
+d5_pin: EXP1_6
+d6_pin: EXP1_7
+d7_pin: EXP1_8
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+#kill_pin: ^!EXP2_8
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# 128x64 Full Graphic Creality CR10 / ENDER 3 stockdisplay
+######################################################################
+
+[display]
+lcd_type: st7920
+cs_pin: EXP1_7
+sclk_pin: EXP1_6
+sid_pin: EXP1_8
+encoder_pins: ^EXP1_5, ^EXP1_3
+click_pin: ^!EXP1_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# MKS Mini 12864 LCD
+######################################################################
+
+# Make sure that the EXP1 and EXP2 are rotated correctly on the
+# display board. The cutouts on the connectors should be towards the
+# center of the PCB. See:
+#   https://reprap.org/wiki/MKS_MINI_12864#Physical_Interface
+# If they are wrong, the connector housing can be pried off carefully
+# with a small screwdriver and relocated the correct way.
+
+[display]
+lcd_type: uc1701
+cs_pin: EXP1_6
+a0_pin: EXP1_7
+contrast: 40
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+## Some micro-controller boards may require an spi bus to be specified:
+#spi_bus: spi
+## Alternatively, some micro-controller boards may work with software spi:
+#spi_software_miso_pin: EXP2_1
+#spi_software_mosi_pin: EXP2_6
+#spi_software_sclk_pin: EXP2_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+
+######################################################################
+# Fysetc Mini 12864Panel v2.1 (with neopixel backlight leds)
+######################################################################
+
+[display]
+lcd_type: st7567
+cs_pin: EXP1_3
+a0_pin: EXP1_4
+rs_pin: EXP1_5
+contrast: 63
+encoder_pins: ^EXP2_3, ^EXP2_5
+click_pin: ^!EXP1_2
+## Some micro-controller boards may require an spi bus to be specified:
+#spi_bus: spi
+## Alternatively, some micro-controller boards may work with software spi:
+#spi_software_miso_pin: EXP2_1
+#spi_software_mosi_pin: EXP2_6
+#spi_software_sclk_pin: EXP2_2
+
+[output_pin beeper]
+pin: EXP1_1
+
+[neopixel fysetc_mini12864]
+pin: EXP1_6
+chain_count: 3
+color_order_GRB: False
+initial_RED: 0.4
+initial_GREEN: 0.4
+initial_BLUE: 0.4
+
+
+######################################################################
+# Plug pin locations
+######################################################################
+
+# Some micro-controller boards and displays use inconsistent labeling
+# for the EXP1 and EXP2 headers. The following diagram shows the
+# correct location of pin 1 along with ground and power pins on the
+# EXP1 and EXP2 plugs:
+#
+#          EXP1:                        EXP2:
+#   +-----------------+          +-----------------+
+#   |  o  o  o  o  5V |          |  o  o  o  o  o  |
+#   |  1  o  o  o GND |          |  1  o  o  o GND |
+#   +------     ------+          +------     ------+
+#
+# Some boards may have the cutout in the wrong location. If so, it may
+# be possible to carefully pry the plastic header off of the pins with
+# a small screwdriver, then correct the orientation and reapply the
+# plastic header.

config/sample-macros.cfg

@@ -0,0 +1,117 @@
+# This file provides examples of Klipper G-Code macros.  The snippets
+# in this file may be copied into the main printer.cfg file and
+# customized.
+#
+# See the "example.cfg" file for description of common config parameters.
+
+
+######################################################################
+# Start Print and End Print
+######################################################################
+
+# Replace the slicer's custom start and end g-code scripts with
+# START_PRINT and END_PRINT.
+
+[gcode_macro START_PRINT]
+default_parameter_BED_TEMP: 60
+default_parameter_EXTRUDER_TEMP: 190
+gcode:
+    # Start bed heating
+    M140 S{BED_TEMP}
+    # Use absolute coordinates
+    G90
+    # Reset the G-Code Z offset (adjust Z offset if needed)
+    SET_GCODE_OFFSET Z=0.0
+    # Home the printer
+    G28
+    # Move the nozzle near the bed
+    G1 Z5 F3000
+    # Move the nozzle very close to the bed
+    G1 Z0.15 F300
+    # Wait for bed to reach temperature
+    M190 S{BED_TEMP}
+    # Set and wait for nozzle to reach temperature
+    M109 S{EXTRUDER_TEMP}
+
+[gcode_macro END_PRINT]
+gcode:
+    # Turn off bed, extruder, and fan
+    M140 S0
+    M104 S0
+    M106 S0
+    # Move nozzle away from print while retracting
+    G91
+    G1 X-2 Y-2 E-3 F300
+    # Raise nozzle by 10mm
+    G1 Z10 F3000
+    G90
+    # Disable steppers
+    M84
+
+
+######################################################################
+# Beeper
+######################################################################
+
+# M300 : Play tone. Beeper support, as commonly found on usual LCD
+# displays (i.e. RepRapDiscount 2004 Smart Controller, RepRapDiscount
+# 12864 Full Graphic). This defines a custom I/O pin and a custom
+# GCODE macro.  Usage:
+#   M300 [P<ms>] [S<Hz>]
+#   P is the tone duration, S the tone frequency.
+# The frequency won't be pitch perfect.
+
+[output_pin BEEPER_pin]
+pin: ar37
+#   Beeper pin. This parameter must be provided.
+#   ar37 is the default RAMPS/MKS pin.
+pwm: True
+#   A piezo beeper needs a PWM signal, a DC buzzer doesn't.
+value: 0
+#   Silent at power on, set to 1 if active low.
+shutdown_value: 0
+#   Disable at emergency shutdown (no PWM would be available anyway).
+cycle_time: 0.001
+#   PWM frequency : 0.001 = 1ms will give a base tone of 1kHz
+scale: 1000
+#   PWM parameter will be in the range of (0-1000 Hz).
+#   Although not pitch perfect.
+
+[gcode_macro M300]
+default_parameter_S: 1000
+#   Use a default 1kHz tone if S is omitted.
+default_parameter_P: 100
+#   Use a 10ms duration is P is omitted.
+gcode:
+    SET_PIN PIN=BEEPER_pin VALUE={S}
+    G4 P{P}
+    SET_PIN PIN=BEEPER_pin VALUE=0
+
+
+######################################################################
+# Filament Change
+######################################################################
+
+# M600: Filament Change. This macro will pause the printer, move the
+# tool to the change position, and retract the filament 50mm. Adjust
+# the retraction settings for your own extruder. After filament has
+# been changed, the print can be resumed from its previous position
+# with the "RESUME" gcode.
+
+[pause_resume]
+
+[gcode_macro M600]
+default_parameter_X: 50
+default_parameter_Y: 0
+default_parameter_Z: 10
+gcode:
+    SAVE_GCODE_STATE NAME=M600_state
+    PAUSE
+    G91
+    G1 E-.8 F2700
+    G1 Z{Z}
+    G90
+    G1 X{X} Y{Y} F3000
+    G91
+    G1 E-50 F1000
+    RESTORE_GCODE_STATE NAME=M600_state

config/sample-probe-as-z-endstop.cfg

@@ -0,0 +1,51 @@
+# This file provides example config file settings for use on a printer
+# that uses a Z probe instead of a traditional Z endstop switch. This
+# file is just a "snippet" of config sections - it must be added to a
+# config file containing the configuration of the rest of the printer.
+
+# Be sure to review and update this config with the appropriate pins
+# and coordinates for your printer.
+
+# See the "example.cfg" and "example-extras.cfg" files for a
+# description of config parameters.
+
+# Define a probe
+[probe]
+pin: ar30
+z_offset: 2.345
+
+# Example settings to add to stepper_z section
+[stepper_z]
+endstop_pin: probe:z_virtual_endstop
+position_min: -2 # The Z carriage may need to travel below the Z=0
+                 # homing point if the bed has a significant tilt.
+
+# The homing_override section modifies the default G28 behavior
+[homing_override]
+set_position_z: 0
+axes: z
+gcode:
+    G90
+    ; G1 Z2 F600 ; Uncomment to blindly lift the Z 2mm at start
+    G28 X0 Y0
+    G1 X100 Y100 F3600
+    G28 Z0
+
+# Example bed_tilt config section
+[bed_tilt]
+points:
+    100,100
+    10,10
+    10,100
+    10,190
+    100,10
+    100,190
+    190,10
+    190,100
+    190,190
+
+# Example bed_mesh config section
+[bed_mesh]
+min_point: 20,20
+max_point: 200,200
+probe_count: 4,4

docs/BLTouch.md

@@ -0,0 +1,134 @@
+Connecting BL-Touch
+===================
+
+A **warning** before you start: Avoid touching the BL-Touch pin with
+your bare fingers, since it is quite sensitive to finger grease. And
+if you do touch it, be very gentle, in order to not bend or push
+anything.
+
+Hook up the BL-Touch "servo" connector to a `control_pin` according to
+the BL-Touch documentation or your MCU documentation. Using the
+original wiring, the yellow wire from the triple is the `control_pin`
+and the white wire from the pair is the `sensor_pin`. You need to
+configure these pins according to your wiring. For example:
+
+```
+[bltouch]
+sensor_pin: P1.24
+control_pin: P1.26
+```
+
+If the BL-Touch will be used to home the Z axis then set `endstop_pin:
+probe:z_virtual_endstop` in the `[stepper_z]` config section and add a
+`[homing_override]` config section to raise the z-axis, home the
+x/y-axis, move to the center of the bed, and home the z-axis. For
+example:
+
+```
+[homing_override]
+gcode:
+    G90 ; Use absolute position mode
+    G1 Z10 ; Move up 10mm
+    G28 X Y
+    G1 X166 Y120 F6000 ; Change the X and Y coordinates to the center of your print bed
+    G28 Z
+set_position_z: 0.0
+```
+
+It's important that the initial Z upwards movement in the
+homing_override is high enough that the probe doesn't hit anything
+even if the probe pin happens to be in its lowest state.
+
+Initial tests
+=============
+
+Before moving on, verify that the BL-Touch is mounted at the correct
+height, the pin should be roughly 2 mm above the nozzle when retracted
+
+When you turn on the printer, the BL-Touch probe should perform a
+self-test and move the pin up and down a couple of times. Once the
+self-test is completed, the pin should be retracted and the red LED on
+the probe should be lit. If there are any errors, for example the
+probe is flashing red or the pin is down instead of up, please turn
+off the printer and check the wiring and configuration.
+
+If the above is looking good, it's time to test that the probe
+responds to commands from the firmware. First run `BLTOUCH_DEBUG
+COMMAND=pin_down` in your printer terminal. Verify that the pin moves
+down, and that the red LED on the probe turns off. If not, check your
+wiring and configuration again. Next issue a `BLTOUCH_DEBUG
+COMMAND=pin_up`, verify that the pin moves up, and that the red light
+turns on again. If it's flashing then there's some problem.
+
+Now, it's time to test homing with a twist. Instead of letting the
+probe pin touch the print bed, let it touch the nail on your
+finger. So issue a `G28`, wait until it starts to move down, and stop
+the movement by very gently touching the pin with your nail. You
+probably have to do it twice, since the default configuration makes it
+probe twice. But be prepared to turn off the printer, to avoid damage,
+if it doesn't stop when you touch the pin.
+
+If that was successful, do another `G28` but this time let it touch
+the bed as it should.
+
+Calibrating the BL-Touch offsets
+================================
+
+Follow the directions in the [Probe Calibrate](Probe_Calibrate.md)
+guide to set the x_offset, y_offset, and z_offset config parameters.
+
+It's a good idea to verify that the Z offset is close to 1mm. If not,
+then you probably want to move the probe up or down to fix this. You
+want it to trigger well before the nozzle hits the bed, so that
+possible stuck filament or a warped bed doesn't affect any probing
+action. But at the same time, you want the retracted position to be as
+far above the nozzle as possible to avoid it touching printed parts.
+If an adjustment is made to the probe position, then rerun the probe
+calibration steps.
+
+BL-Touch gone bad
+=================
+
+Once the BL-Touch is in inconsistent state, it starts blinking
+red. You can force it to leave that state by issuing:
+
+ BLTOUCH_DEBUG COMMAND=reset
+
+This may happen if its calibration is interrupted by the probe being
+blocked from being extracted.
+
+However, the BL-Touch may also not be able to calibrate itself
+anymore. This happens if the screw on its top is in the wrong position
+or the magnetic core inside the probe pin has moved. If it has moved
+up so that it sticks to the screw, it may not be able to lower its pin
+anymore. With this behavior you need to open the screw and use a
+ball-point pen to push it gently back into place. Re-Insert the pin
+into the BL-Touch so that it falls into the extracted
+position. Carefully readjust the headless screw into place. You need
+to find the right position so it is able to lower and raise the pin
+and the red light turns on and of. Use the `reset`, `pin_up` and
+`pin_down` commands to achieve this.
+
+Troubleshooting
+===============
+
+* If you are sure the wiring of the BL-Touch is correct and every
+  attempt to probe with the BL-Touch reports "BLTouch failed to verify
+  sensor state" then it may be necessary to add
+  `pin_up_touch_mode_reports_triggered: False` to the bltouch config
+  section. The BL-Touch v3 and many clones require this setting.
+
+* A BL-Touch v3 may not work correctly when its signal wire is
+  connected to the Z end-stop pin on some printer boards. The symptoms
+  of this problem are: the BL-Touch probe deploys, the printer
+  descends, the probe contacts a surface, the BL-Touch raises the
+  probe, the BL-Touch does not successfully notify the
+  micro-controller, and the printer continues to descend. The Z
+  end-stop pin on some printer boards have a capacitor to filter the
+  signal which the BL-Touch v3 may not support. The simplest solution
+  is to connect the BL-Touch v3 sensor wire to an available pin on the
+  printer board that is not associated with an end-stop (and thus is
+  unlikely to have a capacitor). An alternative solution is to
+  physically alter the printer board to disable the given end-stop
+  capacitor or to add a hardware "pull up resistor" to the BL-Touch v3
+  sensor wire.

docs/Bed_Level.md

@@ -0,0 +1,215 @@
+Bed leveling (sometimes also referred to as "bed tramming") is
+critical to getting high quality prints. If a bed is not properly
+"leveled" it can lead to poor bed adhesion, "warping", and subtle
+problems throughout the print. This document serves as a guide to
+performing bed leveling in Klipper.
+
+It's important to understand the goal of bed leveling. If the printer
+is commanded to a position `X0 Y0 Z10` during a print, then the goal
+is for the printer's nozzle to be exactly 10mm from the printer's
+bed. Further, should the printer then be commanded to a position of
+`X50 Z10` the goal is for the nozzle to maintain an exact distance of
+10mm from the bed during that entire horizontal move.
+
+In order to get good quality prints the printer should be calibrated
+so that Z distances are accurate to within about 25 microns (.025mm).
+This is a small distance - significantly smaller than the width of a
+typical human hair. This scale can not be measured "by eye". Subtle
+effects (such as heat expansion) impact measurements at this scale.
+The secret to getting high accuracy is to use a repeatable process and
+to use a leveling method that leverages the high accuracy of the
+printer's own motion system.
+
+# Choose the appropriate calibration mechanism
+
+Different types of printers use different methods for performing bed
+leveling. All of them ultimately depend on the "paper test" (described
+below). However, the actual process for a particular type of printer
+is described in other documents.
+
+Prior to running any of these calibration tools, be sure to run the
+checks described in the [config check document](Config_checks.md). It
+is necessary to verify basic printer motion before performing bed
+leveling.
+
+For printers with an "automatic Z probe" be sure to calibrate the
+probe following the directions in the
+[Probe Calibrate](Probe_Calibrate.md) document. For delta printers,
+see the [Delta Calibrate](Delta_Calibrate.md) document. For printers
+with bed screws and traditional Z endstops, see the
+[Manual Level](Manual_Level.md) document.
+
+During calibration it may be necessary to set the printer's Z
+`position_min` to a negative number (eg, `position_min = -2`). The
+printer enforces boundary checks even during calibration
+routines. Setting a negative number allows the printer to move below
+the nominal position of the bed, which may help when trying to
+determine the actual bed position.
+
+# The "paper test"
+
+The primary bed calibration mechanism is the "paper test". It involves
+placing a regular piece of "copy machine paper" between the printer's
+bed and nozzle, and then commanding the nozzle to different Z heights
+until one feels a small amount of friction when pushing the paper back
+and forth.
+
+It is important to understand the "paper test" even if one has an
+"automatic Z probe". The probe itself often needs to be calibrated to
+get good results. That probe calibration is done using this "paper
+test".
+
+In order to perform the paper test, cut a small rectangular piece of
+paper using a pair of scissors (eg, 5x3 cm). The paper generally has a
+width of around 100 microns (0.100mm). (The exact width of the paper
+isn't crucial.)
+
+The first step of the paper test is to inspect the printer's nozzle
+and bed. Make sure there is no plastic (or other debris) on the nozzle
+or bed.
+
+**Inspect the nozzle and bed to ensure no plastic is present!**
+
+If one always prints on a particular tape or printing surface then one
+may perform the paper test with that tape/surface in place. However,
+note that tape itself has a width and different tapes (or any other
+printing surface) will impact Z measurements. Be sure to rerun the
+paper test to measure each type of surface that is in use.
+
+If there is plastic on the nozzle then heat up the extruder and use a
+metal tweezers to remove that plastic. Wait for the extruder to fully
+cool to room temperature before continuing with the paper test. While
+the nozzle is cooling, use the metal tweezers to remove any plastic
+that may ooze out.
+
+**Always perform the paper test when both nozzle and bed are at room
+temperature!**
+
+When the nozzle is heated, its position (relative to the bed) changes
+due to thermal expansion. This thermal expansion is typically around a
+100 microns, which is about the same width as a typical piece of
+printer paper. The exact amount of thermal expansion isn't crucial,
+just as the exact width of the paper isn't crucial. Start with the
+assumption that the two are equal (see below for a method of
+determining the difference between the two widths).
+
+It may seem odd to calibrate the distance at room temperature when the
+goal is to have a consistent distance when heated. However, if one
+calibrates when the nozzle is heated, it tends to impart small amounts
+of molten plastic on to the paper, which changes the amount of
+friction felt. That makes it harder to get a good calibration.
+Calibrating while the bed/nozzle is hot also greatly increases the
+risk of burning oneself. The amount of thermal expansion is stable, so
+it is easily accounted for later in the calibration process.
+
+**Use an automated tool to determine precise Z heights!**
+
+Klipper has several helper scripts available (eg, MANUAL_PROBE,
+Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). See the
+documents
+[described above](#choose-the-appropriate-calibration-mechanism) to
+choose one of them.
+
+Run the appropriate command in the OctoPrint terminal window. The
+script will prompt for user interaction in the OctoPrint terminal
+output. It will look something like:
+```
+Recv: // Starting manual Z probe. Use TESTZ to adjust position.
+Recv: // Finish with ACCEPT or ABORT command.
+Recv: // Z position: ?????? --> 5.000 <-- ??????
+```
+
+The current height of the nozzle (as the printer currently understands
+it) is shown between the "--> <--". The number to the right is the
+height of the last probe attempt just greater than the current height,
+and to the left is the last probe attempt less than the current height
+(or ?????? if no attempt has been made).
+
+Place the paper between the nozzle and bed. It can be useful to fold a
+corner of the paper so that it is easier to grab. (Try not to push
+down on the bed when moving the paper back and forth.)
+
+![paper-test](img/paper-test.jpg)
+
+Use the TESTZ command to request the nozzle to move closer to the
+paper. For example:
+```
+TESTZ Z=-.1
+```
+
+The TESTZ command will move the nozzle a relative distance from the
+nozzle's current position. (So, `Z=-.1` requests the nozzle to move
+closer to the bed by .1mm.) After the nozzle stops moving, push the
+paper back and forth to check if the nozzle is in contact with the
+paper and to feel the amount of friction. Continue issuing TESTZ
+commands until one feels a small amount of friction when testing with
+the paper.
+
+If too much friction is found then one can use a positive Z value to
+move the nozzle up. It is also possible to use `TESTZ Z=+` or `TESTZ
+Z=-` to "bisect" the last position - that is to move to a position
+half way between two positions. For example, if one received the
+following prompt from a TESTZ command:
+```
+Recv: // Z position: 0.130 --> 0.230 <-- 0.280
+```
+Then a `TESTZ Z=-` would move the nozzle to a Z position of 0.180
+(half way between 0.130 and 0.230). One can use this feature to help
+rapidly narrow down to a consistent friction. It is also possible to
+use `Z=++` and `Z=--` to return directly to a past measurement - for
+example, after the above prompt a `TESTZ Z=--` command would move the
+nozzle to a Z position of 0.130.
+
+After finding a small amount of friction run the ACCEPT command:
+```
+ACCEPT
+```
+This will accept the given Z height and proceed with the given
+calibration tool.
+
+The exact amount of friction felt isn't crucial, just as the amount of
+thermal expansion and exact width of the paper isn't crucial. Just try
+to obtain the same amount of friction each time one runs the test.
+
+If something goes wrong during the test, one can use the `ABORT`
+command to exit the calibration tool.
+
+# Determining Thermal Expansion
+
+After successfully performing bed leveling, one may go on to calculate
+a more precise value for the combined impact of "thermal expansion",
+"width of the paper", and "amount of friction felt during the paper
+test".
+
+This type of calculation is generally not needed as most users find
+the simple "paper test" provides good results.
+
+The easiest way to make this calculation is to print a test object
+that has straight walls on all sides. The large hollow square found in
+[docs/prints/square.stl](prints/square.stl) can be used for this.
+When slicing the object, make sure the slicer uses the same layer
+height and extrusion widths for the first level that it does for all
+subsequent layers. Use a coarse layer height (the layer height should
+be around 75% of the nozzle diameter) and do not use a brim or raft.
+
+Print the test object, wait for it to cool, and remove it from the
+bed. Inspect the lowest layer of the object. (It may also be useful to
+run a finger or nail along the bottom edge.) If one finds the bottom
+layer bulges out slightly along all sides of the object then it
+indicates the nozzle was slightly closer to the bed then it should
+be. One can issue a `SET_GCODE_OFFSET Z=+.010` command to increase the
+height. In subsequent prints one can inspect for this behavior and
+make further adjustment as needed. Adjustments of this type are
+typically in 10s of microns (.010mm).
+
+If the bottom layer consistently appears narrower than subsequent
+layers then one can use the SET_GCODE_OFFSET command to make a
+negative Z adjustment. If one is unsure, then one can decrease the Z
+adjustment until the bottom layer of prints exhibit a small bulge, and
+then back-off until it disappears.
+
+The easiest way to apply the desired Z adjustment is to create a
+START_PRINT g-code macro, arrange for the slicer to call that macro
+during the start of each print, and add a SET_GCODE_OFFSET command to
+that macro. See the [slicers](Slicers.md) document for further
+details.

docs/Benchmarks.md

@@ -0,0 +1,404 @@
+This document describes Klipper benchmarks.
+
+Micro-controller Benchmarks
+===========================
+
+This section describes the mechanism used to generate the Klipper
+micro-controller step rate benchmarks.
+
+The primary goal of the benchmarks is to provide a consistent
+mechanism for measuring the impact of coding changes within the
+software. A secondary goal is to provide high-level metrics for
+comparing the performance between chips and between software
+platforms.
+
+The step rate benchmark is designed to find the maximum stepping rate
+that the hardware and software can reach. This benchmark stepping rate
+is not achievable in day-to-day use as Klipper needs to perform other
+tasks (eg, mcu/host communication, temperature reading, endstop
+checking) in any real-world usage.
+
+In general, the pins for the benchmark tests are chosen to flash LEDs
+or other innocuous pins. **Always verify that it is safe to drive the
+configured pins prior to running a benchmark.** It is not recommended
+to drive an actual stepper during a benchmark.
+
+## Step rate benchmark test ##
+
+The test is performed using the console.py tool (described in
+[Debugging.md](Debugging.md)). The micro-controller is configured for
+the particular hardware platform (see below) and then the following is
+cut-and-paste into the console.py terminal window:
+```
+SET start_clock {clock+freq}
+SET ticks 1000
+
+reset_step_clock oid=0 clock={start_clock}
+set_next_step_dir oid=0 dir=0
+queue_step oid=0 interval={ticks} count=60000 add=0
+set_next_step_dir oid=0 dir=1
+queue_step oid=0 interval=3000 count=1 add=0
+
+reset_step_clock oid=1 clock={start_clock}
+set_next_step_dir oid=1 dir=0
+queue_step oid=1 interval={ticks} count=60000 add=0
+set_next_step_dir oid=1 dir=1
+queue_step oid=1 interval=3000 count=1 add=0
+
+reset_step_clock oid=2 clock={start_clock}
+set_next_step_dir oid=2 dir=0
+queue_step oid=2 interval={ticks} count=60000 add=0
+set_next_step_dir oid=2 dir=1
+queue_step oid=2 interval=3000 count=1 add=0
+```
+
+The above tests three steppers simultaneously stepping. If running the
+above results in a "Rescheduled timer in the past" or "Stepper too far
+in past" error then it indicates the `ticks` parameter is too low (it
+results in a stepping rate that is too fast). The goal is to find the
+lowest setting of the ticks parameter that reliably results in a
+successful completion of the test. It should be possible to bisect the
+ticks parameter until a stable value is found.
+
+On a failure, one can copy-and-paste the following to clear the error
+in preparation for the next test:
+```
+clear_shutdown
+```
+
+To obtain the single stepper and dual stepper benchmarks, the same
+configuration sequence is used, but only the first block (for the
+single stepper case) or first two blocks (for the dual stepper case)
+of the above test is cut-and-paste into the console.py window.
+
+To produce the benchmarks found in the Features.md document, the total
+number of steps per second is calculated by multiplying the number of
+active steppers with the nominal mcu frequency and dividing by the
+final ticks parameter. The results are rounded to the nearest K. For
+example, with three active steppers:
+```
+ECHO Test result is: {"%.0fK" % (3. * freq / ticks / 1000.)}
+```
+
+Benchmarks may be run with the micro-controller code compiled using a
+"step pulse duration" of zero (the tables below report this as "no
+delay"). This configuration is believed to be valid in real-world
+usage when one is solely using Trinamic stepper drivers. The results
+of these benchmarks are not reported in the Features.md document.
+
+### AVR step rate benchmark ###
+
+The following configuration sequence is used on AVR chips:
+```
+PINS arduino
+allocate_oids count=3
+config_stepper oid=0 step_pin=ar29 dir_pin=ar28 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=ar27 dir_pin=ar26 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=ar23 dir_pin=ar22 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `01d2183f` with gcc version `avr-gcc
+(GCC) 5.4.0`. Both the 16Mhz and 20Mhz tests were run using simulavr
+configured for an atmega644p (previous tests have confirmed simulavr
+results match tests on both a 16Mhz at90usb and a 16Mhz atmega2560).
+
+| avr              | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 104   |
+| 2 stepper        | 296   |
+| 3 stepper        | 472   |
+
+### Arduino Due step rate benchmark ###
+
+The following configuration sequence is used on the Due:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PB27 dir_pin=PA21 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PB26 dir_pin=PC30 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA21 dir_pin=PC30 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| sam3x8e              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 388   |
+| 2 stepper            | 405   |
+| 3 stepper            | 576   |
+| 1 stepper (no delay) | 77    |
+| 3 stepper (no delay) | 299   |
+
+### Duet Maestro step rate benchmark ###
+
+The following configuration sequence is used on the Duet Maestro:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PC26 dir_pin=PC18 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PC26 dir_pin=PA8 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PC26 dir_pin=PB4 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| sam4s8c              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 527   |
+| 2 stepper            | 535   |
+| 3 stepper            | 638   |
+| 1 stepper (no delay) | 70    |
+| 3 stepper (no delay) | 254   |
+
+### Duet Wifi step rate benchmark ###
+
+The following configuration sequence is used on the Duet Wifi:
+```
+allocate_oids count=4
+config_stepper oid=0 step_pin=PD6 dir_pin=PD11 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PD7 dir_pin=PD12 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PD8 dir_pin=PD13 min_stop_interval=0 invert_step=0
+config_stepper oid=3 step_pin=PD5 dir_pin=PA1 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+
+```
+
+The test was last run on commit `59a60d68` with gcc version
+`arm-none-eabi-gcc 7.3.1 20180622 (release)
+[ARM/embedded-7-branch revision 261907]`.
+
+| sam4e8e          | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 519   |
+| 2 stepper        | 520   |
+| 3 stepper        | 525   |
+| 4 stepper        | 703   |
+
+### Beaglebone PRU step rate benchmark ###
+
+The following configuration sequence is used on the PRU:
+```
+PINS beaglebone
+allocate_oids count=3
+config_stepper oid=0 step_pin=P8_13 dir_pin=P8_12 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=P8_15 dir_pin=P8_14 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=P8_19 dir_pin=P8_18 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `b161a69e` with gcc version `pru-gcc
+(GCC) 8.0.0 20170530 (experimental)`.
+
+| pru              | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 861   |
+| 2 stepper        | 853   |
+| 3 stepper        | 883   |
+
+### STM32F042 step rate benchmark ###
+
+The following configuration sequence is used on the STM32F042:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PA0 dir_pin=PA1 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PA2 dir_pin=PA3 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA6 dir_pin=PA7 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `c105adc8` with gcc version
+`arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1`.
+
+| stm32f042        | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 308   |
+| 2 stepper        | 638   |
+| 3 stepper        | 1021  |
+
+### STM32F103 step rate benchmark ###
+
+The following configuration sequence is used on the STM32F103:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PC13 dir_pin=PB5 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PB3 dir_pin=PB6 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA4 dir_pin=PB7 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`.
+
+| stm32f103            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 347   |
+| 2 stepper            | 372   |
+| 3 stepper            | 600   |
+| 1 stepper (no delay) | 71    |
+| 3 stepper (no delay) | 288   |
+
+### STM32F4 step rate benchmark ###
+
+The following configuration sequence is used on the STM32F4:
+```
+allocate_oids count=4
+config_stepper oid=0 step_pin=PA5 dir_pin=PB5 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 min_stop_interval=0 invert_step=0
+config_stepper oid=3 step_pin=PB3 dir_pin=PB8 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The STM32F407 results
+were obtained by running an STM32F407 binary on an STM32F446 (and thus
+using a 168Mhz clock).
+
+| stm32f446            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 757   |
+| 2 stepper            | 761   |
+| 3 stepper            | 757   |
+| 4 stepper            | 767   |
+| 1 stepper (no delay) | 51    |
+| 3 stepper (no delay) | 226   |
+
+| stm32f407            | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 709   |
+| 2 stepper            | 714   |
+| 3 stepper            | 709   |
+| 4 stepper            | 729   |
+| 1 stepper (no delay) | 52    |
+| 3 stepper (no delay) | 226   |
+
+### LPC176x step rate benchmark ###
+
+The following configuration sequence is used on the LPC176x:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=P1.20 dir_pin=P1.18 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=P1.21 dir_pin=P1.18 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=P1.23 dir_pin=P1.18 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0`. The 120Mhz LPC1769
+results were obtained by overclocking an LPC1768 to 120Mhz.
+
+| lpc1768              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 448   |
+| 2 stepper            | 450   |
+| 3 stepper            | 523   |
+| 1 stepper (no delay) | 56    |
+| 3 stepper (no delay) | 240   |
+
+| lpc1769              | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 525   |
+| 2 stepper            | 526   |
+| 3 stepper            | 545   |
+| 1 stepper (no delay) | 56    |
+| 3 stepper (no delay) | 240   |
+
+### SAMD21 step rate benchmark ###
+
+The following configuration sequence is used on the SAMD21:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PA27 dir_pin=PA20 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PB3 dir_pin=PA21 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA17 dir_pin=PA21 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0` on a SAMD21G18
+micro-controller.
+
+| samd21               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 277   |
+| 2 stepper            | 410   |
+| 3 stepper            | 664   |
+| 1 stepper (no delay) | 83    |
+| 3 stepper (no delay) | 321   |
+
+### SAMD51 step rate benchmark ###
+
+The following configuration sequence is used on the SAMD51:
+```
+allocate_oids count=4
+config_stepper oid=0 step_pin=PA22 dir_pin=PA20 min_stop_interval=0 invert_step=0
+config_stepper oid=1 step_pin=PA22 dir_pin=PA21 min_stop_interval=0 invert_step=0
+config_stepper oid=2 step_pin=PA22 dir_pin=PA19 min_stop_interval=0 invert_step=0
+config_stepper oid=3 step_pin=PA22 dir_pin=PA18 min_stop_interval=0 invert_step=0
+finalize_config crc=0
+```
+
+The test was last run on commit `8d4a5c16` with gcc version
+`arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0` on a SAMD51G19A
+micro-controller.
+
+| samd51               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 516   |
+| 2 stepper            | 520   |
+| 3 stepper            | 519   |
+| 4 stepper            | 655   |
+| 1 stepper (no delay) | 41    |
+| 3 stepper (no delay) | 197   |
+
+## Command dispatch benchmark ##
+
+The command dispatch benchmark tests how many "dummy" commands the
+micro-controller can process. It is primarily a test of the hardware
+communication mechanism. The test is run using the console.py tool
+(described in [Debugging.md](Debugging.md)). The following is
+cut-and-paste into the console.py terminal window:
+```
+DELAY {clock + 2*freq} get_uptime
+FLOOD 100000 0.0 end_group
+get_uptime
+```
+
+When the test completes, determine the difference between the clocks
+reported in the two "uptime" response messages. The total number of
+commands per second is then `100000 * mcu_frequency / clock_diff`.
+
+Note that this test may saturate the USB/CPU capacity of a Raspberry
+Pi. The benchmarks below are with console.py running on a desktop
+class machine with the device connected via a high-speed hub.
+
+| MCU                 | Rate | Build    | Build compiler      |
+| ------------------- | ---- | -------- | ------------------- |
+| pru (shared memory) |   5K | b161a69e | pru-gcc (GCC) 8.0.0 20170530 (experimental) |
+| stm32f042 (CAN)     |  18K | c105adc8 | arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1 |
+| atmega2560 (serial) |  23K | b161a69e | avr-gcc (GCC) 4.8.1 |
+| sam3x8e (serial)    |  23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| at90usb1286 (USB)   |  75K | 01d2183f | avr-gcc (GCC) 5.4.0 |
+| samd21 (USB)        | 223K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| stm32f103 (USB)     | 355K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| sam3x8e (USB)       | 418K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| lpc1768 (USB)       | 534K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| lpc1769 (USB)       | 628K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| sam4s8c (USB)       | 650K | 8d4a5c16 | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| samd51 (USB)        | 864K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+| stm32f446 (USB)     | 870K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
+
+Host Benchmarks
+===============
+
+It is possible to run timing tests on the host software using the
+"batch mode" processing mechanism (described in
+[Debugging.md](Debugging.md)). This is typically done by choosing a
+large and complex G-Code file and timing how long it takes for the
+host software to process it. For example:
+```
+time ~/klippy-env/bin/python ./klippy/klippy.py config/example.cfg -i something_complex.gcode -o /dev/null -d out/klipper.dict
+```

docs/Bootloaders.md

@@ -0,0 +1,440 @@
+This document provides information on common bootloaders found on
+micro-controllers that Klipper supports.
+
+The bootloader is 3rd-party software that runs on the micro-controller
+when it is first powered on. It is typically used to flash a new
+application (eg, Klipper) to the micro-controller without requiring
+specialized hardware. Unfortunately, there is no industry wide
+standard for flashing a micro-controller, nor is there a standard
+bootloader that works across all micro-controllers. Worse, it is
+common for each bootloader to require a different set of steps to
+flash an application.
+
+If one can flash a bootloader to a micro-controller then one can
+generally also use that mechanism to flash an application, but care
+should be taken when doing this as one may inadvertently remove the
+bootloader. In contrast, a bootloader will generally only permit a
+user to flash an application. It is therefore recommended to use a
+bootloader to flash an application where possible.
+
+This document attempts to describe common bootloaders, the steps
+needed to flash a bootloader, and the steps needed to flash an
+application.  This document is not an authoritative reference; it is
+intended as a collection of useful information that the Klipper
+developers have accumulated.
+
+AVR micro-controllers
+=====================
+
+In general, the Arduino project is a good reference for bootloaders
+and flashing procedures on the 8-bit Atmel Atmega micro-controllers.
+In particular, the "boards.txt" file:
+[https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt](https://github.com/arduino/Arduino/blob/1.8.5/hardware/arduino/avr/boards.txt)
+is a useful reference.
+
+To flash a bootloader itself, the AVR chips require an external
+hardware flashing tool (which communicates with the chip using
+SPI). This tool can be purchased (for example, do a web search for
+"avr isp", "arduino isp", or "usb tiny isp"). It is also possible to
+use another Arduino or Raspberry Pi to flash an AVR bootloader (for
+example, do a web search for "program an avr using raspberry pi"). The
+examples below are written assuming an "AVR ISP Mk2" type device is in
+use.
+
+The "avrdude" program is the most common tool used to flash atmega
+chips (both bootloader flashing and application flashing).
+
+## Atmega2560 ##
+
+This chip is typically found in the "Arduino Mega" and is very common
+in 3d printer boards.
+
+To flash the bootloader itself use something like:
+```
+wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/stk500v2/stk500boot_v2_mega2560.hex'
+
+avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xD8:m -U lfuse:w:0xFF:m
+avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U flash:w:stk500boot_v2_mega2560.hex
+avrdude -cavrispv2 -patmega2560 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
+```
+
+To flash an application use something like:
+```
+avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
+```
+
+## Atmega1280 ##
+
+This chip is typically found in earlier versions of the "Arduino
+Mega".
+
+To flash the bootloader itself use something like:
+```
+wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/atmega/ATmegaBOOT_168_atmega1280.hex'
+
+avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xF5:m -U hfuse:w:0xDA:m -U lfuse:w:0xFF:m
+avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U flash:w:ATmegaBOOT_168_atmega1280.hex
+avrdude -cavrispv2 -patmega1280 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
+```
+
+To flash an application use something like:
+```
+avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
+```
+
+## Atmega1284p ##
+
+This chip is commonly found in "Melzi" style 3d printer boards.
+
+To flash the bootloader itself use something like:
+```
+wget 'https://github.com/Lauszus/Sanguino/raw/1.0.2/bootloaders/optiboot/optiboot_atmega1284p.hex'
+
+avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xDE:m -U lfuse:w:0xFF:m
+avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega1284p.hex
+avrdude -cavrispv2 -patmega1284p -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
+```
+
+To flash an application use something like:
+```
+avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
+```
+
+Note that a number of "Melzi" style boards come preloaded with a
+bootloader that uses a baud rate of 57600. In this case, to flash an
+application use something like this instead:
+```
+avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
+```
+
+## At90usb1286 ##
+
+This document does not cover the method to flash a bootloader to the
+At90usb1286 nor does it cover general application flashing to this
+device.
+
+The Teensy++ device from pjrc.com comes with a proprietary bootloader.
+It requires a custom flashing tool from
+[https://github.com/PaulStoffregen/teensy_loader_cli](https://github.com/PaulStoffregen/teensy_loader_cli).
+One can flash an application with it using something like:
+
+```
+teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v
+```
+
+## Atmega168 ##
+
+The atmega168 has limited flash space. If using a bootloader, it is
+recommended to use the Optiboot bootloader. To flash that bootloader
+use something like:
+```
+wget 'https://github.com/arduino/Arduino/raw/1.8.5/hardware/arduino/avr/bootloaders/optiboot/optiboot_atmega168.hex'
+
+avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -e -u -U lock:w:0x3F:m -U efuse:w:0x04:m -U hfuse:w:0xDD:m -U lfuse:w:0xFF:m
+avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U flash:w:optiboot_atmega168.hex
+avrdude -cavrispv2 -patmega168 -P/dev/ttyACM0 -b115200 -U lock:w:0x0F:m
+```
+
+To flash an application via the Optiboot bootloader use something
+like:
+```
+avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
+```
+
+SAM3 micro-controllers (Arduino Due)
+====================================
+
+It is not common to use a bootloader with the SAM3 mcu. The chip
+itself has a ROM that allows the flash to be programmed from 3.3V
+serial port or from USB.
+
+To enable the ROM, the "erase" pin is held high during a reset, which
+erases the flash contents, and causes the ROM to run. On an Arduino
+Due, this sequence can be accomplished by setting a baud rate of 1200
+on the "programming usb port" (the USB port closest to the power
+supply).
+
+The code at
+[https://github.com/shumatech/BOSSA](https://github.com/shumatech/BOSSA)
+can be used to program the SAM3. It is recommended to use version 1.9
+or later.
+
+To flash an application use something like:
+```
+bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b
+bossac -U -p /dev/ttyACM0 -R
+```
+
+SAM4 micro-controllers (Duet Wifi)
+====================================
+
+It is not common to use a bootloader with the SAM4 mcu. The chip
+itself has a ROM that allows the flash to be programmed from 3.3V
+serial port or from USB.
+
+To enable the ROM, the "erase" pin is held high during a reset, which
+erases the flash contents, and causes the ROM to run.
+
+The code at
+[https://github.com/shumatech/BOSSA](https://github.com/shumatech/BOSSA)
+can be used to program the SAM4. It is necessary to use version
+`1.8.0` or higher.
+
+To flash an application use something like:
+```
+bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin
+```
+
+SAMD21 micro-controllers (Arduino Zero)
+=======================================
+
+The SAMD21 bootloader is flashed via the ARM Serial Wire Debug (SWD)
+interface. This is commonly done with a dedicated SWD hardware dongle.
+Alternatively, one can use a
+[Raspberry Pi with OpenOCD](#running-openocd-on-the-raspberry-pi).
+
+To flash a bootloader with OpenOCD use a chip config similar to:
+```
+set CHIPNAME at91samd21g18
+source [find target/at91samdXX.cfg]
+```
+Obtain a bootloader - for example:
+```
+wget 'https://github.com/arduino/ArduinoCore-samd/raw/1.8.3/bootloaders/zero/samd21_sam_ba.bin'
+```
+Flash with OpenOCD commands similar to:
+```
+at91samd bootloader 0
+program samd21_sam_ba.bin verify
+```
+
+The most common bootloader on the SAMD21 is the one found on the
+"Arduino Zero". It uses an 8KiB bootloader (the application must be
+compiled with a start address of 8KiB). One can enter this bootloader
+by double clicking the reset button. To flash an application use
+something like:
+```
+bossac -U -p /dev/ttyACM0 --offset=0x2000 -w out/klipper.bin -v -b -R
+```
+
+In contrast, the "Arduino M0" uses a 16KiB bootloader (the application
+must be compiled with a start address of 16KiB). To flash an
+application on this bootloader, reset the micro-controller and run the
+flash command within the first few seconds of boot - something like:
+```
+avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i
+```
+
+SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
+========================================================
+
+Like the SAMD21, the SAMD51 bootloader is flashed via the ARM Serial
+Wire Debug (SWD) interface. To flash a bootloader with
+[OpenOCD on a Raspberry Pi](#running-openocd-on-the-raspberry-pi) use
+a chip config similar to:
+```
+set CHIPNAME at91samd51g19
+source [find target/atsame5x.cfg]
+```
+Obtain a bootloader - several bootloaders are available from
+[https://github.com/adafruit/uf2-samdx1/releases/latest](https://github.com/adafruit/uf2-samdx1/releases/latest). For example:
+```
+wget 'https://github.com/adafruit/uf2-samdx1/releases/download/v3.7.0/bootloader-itsybitsy_m4-v3.7.0.bin'
+```
+Flash with OpenOCD commands similar to:
+```
+at91samd bootloader 0
+program bootloader-itsybitsy_m4-v3.7.0.bin verify
+at91samd bootloader 16384
+```
+
+The SAMD51 uses a 16KiB bootloader (the application must be compiled
+with a start address of 16KiB). To flash an application use something
+like:
+```
+bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R
+```
+
+STM32F103 micro-controllers (Blue Pill devices)
+===============================================
+
+The STM32F103 devices have a ROM that can flash a bootloader or
+application via 3.3V serial. To access this ROM, one should connect
+the "boot 0" pin to high and "boot 1" pin to low, and then reset the
+device. The "stm32flash" package can then be used to flash the device
+using something like:
+```
+stm32flash -w out/klipper.bin -v -g 0 /dev/ttyAMA0
+```
+
+Note that if one is using a Raspberry Pi for the 3.3V serial, the
+stm32flash protocol uses a serial parity mode which the Raspberry Pi's
+"miniuart" does not support. See
+[https://www.raspberrypi.org/documentation/configuration/uart.md](https://www.raspberrypi.org/documentation/configuration/uart.md)
+for details on enabling the full uart on the Raspberry Pi GPIO pins.
+
+After flashing, set both "boot 0" and "boot 1" back to low so that
+future resets boot from flash.
+
+## STM32F103 with stm32duino bootloader ##
+
+The "stm32duino" project has a USB capable bootloader - see:
+[https://github.com/rogerclarkmelbourne/STM32duino-bootloader](https://github.com/rogerclarkmelbourne/STM32duino-bootloader)
+
+This bootloader can be flashed via 3.3V serial with something like:
+```
+wget 'https://github.com/rogerclarkmelbourne/STM32duino-bootloader/raw/master/binaries/generic_boot20_pc13.bin'
+
+stm32flash -w generic_boot20_pc13.bin -v -g 0 /dev/ttyAMA0
+```
+
+This bootloader uses 8KiB of flash space (the application must be
+compiled with a start address of 8KiB). Flash an application with
+something like:
+```
+dfu-util -d 1eaf:0003 -a 2 -R -D out/klipper.bin
+```
+
+The bootloader typically runs for only a short period after boot. It
+may be necessary to time the above command so that it runs while the
+bootloader is still active (the bootloader will flash a board led
+while it is running). Alternatively, set the "boot 0" pin to low and
+"boot 1" pin to high to stay in the bootloader after a reset.
+
+LPC176x micro-controllers (Smoothieboards)
+==========================================
+
+This document does not describe the method to flash a bootloader
+itself - see:
+[http://smoothieware.org/flashing-the-bootloader](http://smoothieware.org/flashing-the-bootloader)
+for further information on that topic.
+
+It is common for Smoothieboards to come with a bootloader from:
+[https://github.com/triffid/LPC17xx-DFU-Bootloader](https://github.com/triffid/LPC17xx-DFU-Bootloader).
+When using this bootloader the application must be compiled with a
+start address of 16KiB. The easiest way to flash an application with
+this bootloader is to copy the application file (eg,
+`out/klipper.bin`) to a file named `firmware.bin` on an SD card, and
+then to reboot the micro-controller with that SD card.
+
+Running OpenOCD on the Raspberry PI
+===================================
+
+OpenOCD is a software package that can perform low-level chip flashing
+and debugging. It can use the GPIO pins on a Raspberry Pi to
+communicate with a variety of ARM chips.
+
+This section describes how one can install and launch OpenOCD. It is
+derived from the instructions at:
+[https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi](https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi)
+
+Begin by downloading and compiling the software (each step may take
+several minutes and the "make" step may take 30+ minutes):
+
+```
+sudo apt-get update
+sudo apt-get install autoconf libtool telnet
+mkdir ~/openocd
+cd ~/openocd/
+git clone http://openocd.zylin.com/openocd
+cd openocd
+./bootstrap
+./configure --enable-sysfsgpio --enable-bcm2835gpio --prefix=/home/pi/openocd/install
+make
+make install
+```
+
+## Configure OpenOCD
+
+Create an OpenOCD config file:
+
+```
+nano ~/openocd/openocd.cfg
+```
+
+Use a config similar to the following:
+
+```
+# Uses RPi pins: GPIO25 for SWDCLK, GPIO24 for SWDIO, GPIO18 for nRST
+source [find interface/raspberrypi2-native.cfg]
+bcm2835gpio_swd_nums 25 24
+bcm2835gpio_srst_num 18
+transport select swd
+
+# Set the chip (at91samd51j19 in this example)
+set CHIPNAME at91samd51j19
+source [find target/atsame5x.cfg]
+
+# Set the adapter speed
+adapter_khz 40
+adapter_nsrst_delay 100
+adapter_nsrst_assert_width 100
+
+init
+targets
+reset halt
+```
+
+## Wire the Raspberry Pi to the target chip
+
+Poweroff both the the Raspberry Pi and the target chip before wiring!
+Verify the target chip uses 3.3V prior to connecting to a Raspberry
+Pi!
+
+Connect GND, SWDCLK, SWDIO, and RST on the target chip to GND, GPIO25,
+GPIO24, and GPIO18 respectively on the Raspberry Pi.
+
+Then power up the Raspberry Pi and provide power to the target chip.
+
+## Run OpenOCD
+
+Run OpenOCD:
+
+```
+cd ~/openocd/
+sudo ~/openocd/install/bin/openocd -f ~/openocd/openocd.cfg
+```
+
+The above should cause OpenOCD to emit some text messages and then
+wait (it should not immediately return to the Unix shell prompt). If
+OpenOCD exits on its own or if it continues to emit text messages then
+double check the wiring.
+
+Once OpenOCD is running and is stable, one can send it commands via
+telnet. Open another ssh session and run the following:
+
+```
+telnet 127.0.0.1 4444
+```
+
+(One can exit telnet by pressing ctrl+] and then running the "quit"
+command.)
+
+## OpenOCD and gdb
+
+It is possible to use OpenOCD with gdb to debug Klipper. The following
+commands assume one is running gdb on a desktop class machine.
+
+Add the following to the OpenOCD config file:
+
+```
+bindto 0.0.0.0
+gdb_port 44444
+```
+
+Restart OpenOCD on the Raspberry Pi and then run the following Unix
+command on the desktop machine:
+
+```
+cd /path/to/klipper/
+gdb out/klipper.elf
+```
+
+Within gdb run:
+
+```
+target remote octopi:44444
+```
+
+(Replace "octopi" with the host name of the Raspberry Pi.) Once gdb is
+running it is possible to set breakpoints and to inspect registers.

docs/CNAME

@@ -0,0 +1 @@
+www.klipper3d.org

docs/Code_Overview.md

@@ -5,20 +5,22 @@ Directory Layout
 ================
 
 The **src/** directory contains the C source for the micro-controller
-code. The **src/avr/** directory contains specific code for Atmel
+code. The **src/avr/**, **src/sam3/**, **src/samd21/**,
-ATmega micro-controllers. The **src/sam3x8e/** directory contains code
+**src/lpc176x/**, **src/stm32f1/**, **src/pru/**, and **src/linux/**
-specific to the Arduino Due style ARM micro-controllers. The
+directories contain architecture specific micro-controller code. The
-**src/pru/** directory contains code specific to the Beaglebone's
+**src/simulator/** contains code stubs that allow the micro-controller
-on-board PRU micro-controller. The **src/simulator/** contains code
+to be test compiled on other architectures. The **src/generic/**
-stubs that allow the micro-controller to be test compiled on other
+directory contains helper code that may be useful across different
-architectures. The **src/generic/** directory contains helper code
+architectures. The build arranges for includes of "board/somefile.h"
-that may be useful across different host architectures. The build
+to first look in the current architecture directory (eg,
-arranges for includes of "board/somefile.h" to first look in the
+src/avr/somefile.h) and then in the generic directory (eg,
-current architecture directory (eg, src/avr/somefile.h) and then in
+src/generic/somefile.h).
-the generic directory (eg, src/generic/somefile.h).
 
-The **klippy/** directory contains the C and Python source for the
+The **klippy/** directory contains the host software. Most of the host
-host part of the software.
+software is written in Python, however the **klippy/chelper/**
+directory contains some C code helpers. The **klippy/kinematics/**
+directory contains the robot kinematics code. The **klippy/extras/**
+directory contains the host code extensible "modules".
 
 The **lib/** directory contains external 3rd-party library code that
 is necessary to build some targets.
@@ -105,9 +107,9 @@ DECL_COMMAND macro in the micro-controller code).
 
 There are four threads in the Klippy host code. The main thread
 handles incoming gcode commands. A second thread (which resides
-entirely in the **klippy/serialqueue.c** C code) handles low-level IO
+entirely in the **klippy/chelper/serialqueue.c** C code) handles
-with the serial port. The third thread is used to process response
+low-level IO with the serial port. The third thread is used to process
-messages from the micro-controller in the Python code (see
+response messages from the micro-controller in the Python code (see
 **klippy/serialhdl.py**). The fourth thread writes debug messages to
 the log (see **klippy/queuelogger.py**) so that the other threads
 never block on log writes.
@@ -147,7 +149,7 @@ provides further information on the mechanics of moves.
   zero duration.
   * When Move.move() is called, everything about the move is known -
   its start location, its end location, its acceleration, its
-  start/crusing/end velocity, and distance traveled during
+  start/cruising/end velocity, and distance traveled during
   acceleration/cruising/deceleration. All the information is stored in
   the Move() class and is in cartesian space in units of millimeters
   and seconds.
@@ -157,56 +159,65 @@ provides further information on the mechanics of moves.
 
 * The goal of the kinematics classes is to translate the movement in
   cartesian space to movement on each stepper. The kinematics classes
-  are in cartesian.py, corexy.py, delta.py, and extruder.py. The
+  are located in the klippy/kinematics/ directory. The kinematic class
-  kinematic class is given a chance to audit the move
+  is given a chance to audit the move (`ToolHead.move() ->
-  (`ToolHead.move() -> kin.check_move()`) before it goes on the
+  kin.check_move()`) before it goes on the look-ahead queue, but once
-  look-ahead queue, but once the move arrives in *kin*.move() the
+  the move arrives in *kin*.move() the kinematic class is required to
-  kinematic class is required to handle the move as specified. The
+  handle the move as specified. Note that the extruder is handled in
-  kinematic classes translate the three parts of each move
+  its own kinematic class. Since the Move() class specifies the exact
-  (acceleration, constant "cruising" velocity, and deceleration) to
+  movement time and since step pulses are sent to the micro-controller
-  the associated movement on each stepper. Note that the extruder is
+  with specific timing, stepper movements produced by the extruder
-  handled in its own kinematic class. Since the Move() class specifies
+  class will be in sync with head movement even though the code is
-  the exact movement time and since step pulses are sent to the
+  kept separate.
-  micro-controller with specific timing, stepper movements produced by
-  the extruder class will be in sync with head movement even though
-  the code is kept separate.
 
-* For efficiency reasons, the stepper pulse times are generated in C
+* Klipper uses an
-  code. The code flow is: `kin.move() -> MCU_Stepper.step_const() ->
+  [iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
-  stepcompress_push_const()`, or for delta kinematics:
+  to generate the step times for each stepper. For efficiency reasons,
-  `DeltaKinematics.move() -> MCU_Stepper.step_delta() ->
+  the stepper pulse times are generated in C code. The code flow is:
-  stepcompress_push_delta()`. The MCU_Stepper code just performs unit
+  `kin.move() -> MCU_Stepper.step_itersolve() ->
-  and axis transformation (millimeters to step distances), and calls
+  itersolve_gen_steps()` (in klippy/chelper/itersolve.c). The goal of
-  the C code. The C code calculates the stepper step times for each
+  the iterative solver is to find step times given a function that
-  movement and fills an array (struct stepcompress.queue) with the
+  calculates a stepper position from a time. This is done by
-  corresponding micro-controller clock counter times for every
+  repeatedly "guessing" various times until the stepper position
-  step. Here the "micro-controller clock counter" value directly
+  formula returns the desired position of the next step on the
-  corresponds to the micro-controller's hardware counter - it is
+  stepper. The feedback produced from each guess is used to improve
-  relative to when the micro-controller was last powered up.
+  future guesses so that the process rapidly converges to the desired
+  time. The kinematic stepper position formulas are located in the
+  klippy/chelper/ directory (eg, kin_cart.c, kin_corexy.c,
+  kin_delta.c, kin_extruder.c).
+
+* After the iterative solver calculates the step times they are added
+  to an array: `itersolve_gen_steps() -> queue_append()` (in
+  klippy/chelper/stepcompress.c). The array (struct
+  stepcompress.queue) stores the corresponding micro-controller clock
+  counter times for every step. Here the "micro-controller clock
+  counter" value directly corresponds to the micro-controller's
+  hardware counter - it is relative to when the micro-controller was
+  last powered up.
 
 * The next major step is to compress the steps: `stepcompress_flush()
-  -> compress_bisect_add()` (in stepcompress.c). This code generates
+  -> compress_bisect_add()` (in klippy/chelper/stepcompress.c). This
-  and encodes a series of micro-controller "queue_step" commands that
+  code generates and encodes a series of micro-controller "queue_step"
-  correspond to the list of stepper step times built in the previous
+  commands that correspond to the list of stepper step times built in
-  stage. These "queue_step" commands are then queued, prioritized, and
+  the previous stage. These "queue_step" commands are then queued,
-  sent to the micro-controller (via stepcompress.c:steppersync and
+  prioritized, and sent to the micro-controller (via
-  serialqueue.c:serialqueue).
+  stepcompress.c:steppersync and serialqueue.c:serialqueue).
 
 * Processing of the queue_step commands on the micro-controller starts
-  in command.c which parses the command and calls
+  in src/command.c which parses the command and calls
-  `command_queue_step()`. The command_queue_step() code (in stepper.c)
+  `command_queue_step()`. The command_queue_step() code (in
-  just appends the parameters of each queue_step command to a per
+  src/stepper.c) just appends the parameters of each queue_step
-  stepper queue. Under normal operation the queue_step command is
+  command to a per stepper queue. Under normal operation the
-  parsed and queued at least 100ms before the time of its first
+  queue_step command is parsed and queued at least 100ms before the
-  step. Finally, the generation of stepper events is done in
+  time of its first step. Finally, the generation of stepper events is
-  `stepper_event()`. It's called from the hardware timer interrupt at
+  done in `stepper_event()`. It's called from the hardware timer
-  the scheduled time of the first step. The stepper_event() code
+  interrupt at the scheduled time of the first step. The
-  generates a step pulse and then reschedules itself to run at the
+  stepper_event() code generates a step pulse and then reschedules
-  time of the next step pulse for the given queue_step parameters. The
+  itself to run at the time of the next step pulse for the given
-  parameters for each queue_step command are "interval", "count", and
+  queue_step parameters. The parameters for each queue_step command
-  "add". At a high-level, stepper_event() runs the following, 'count'
+  are "interval", "count", and "add". At a high-level, stepper_event()
-  times: `do_step(); next_wake_time = last_wake_time + interval;
+  runs the following, 'count' times: `do_step(); next_wake_time =
-  interval += add;`
+  last_wake_time + interval; interval += add;`
 
 The above may seem like a lot of complexity to execute a
 movement. However, the only really interesting parts are in the
@@ -251,16 +262,26 @@ The following may also be useful:
   will have been instantiated. The "gcode" and "pins" modules will
   always be available, but for other modules it is a good idea to
   defer the lookup.
-* Define a `printer_state()` method if the code needs to be called
+* Register event handlers using the `printer.register_event_handler()`
-  during printer setup and/or shutdown. This method is called twice
+  method if the code needs to be called during "events" raised by
-  during setup (with "connect" and then "ready") and may also be
+  other printer objects. Each event name is a string, and by
-  called at run-time (with "shutdown" or "disconnect"). It is common
+  convention it is the name of the main source module that raises the
-  to perform "printer object" lookup during the "connect" and "ready"
+  event along with a short name for the action that is occurring (eg,
-  phases.
+  "klippy:connect"). The parameters passed to each event handler are
+  specific to the given event (as are exception handling and execution
+  context). Two common startup events are:
+  * klippy:connect - This event is generated after all printer objects
+    are instantiated. It is commonly used to lookup other printer
+    objects, to verify config settings, and to perform an initial
+    "handshake" with printer hardware.
+  * klippy:ready - This event is generated after all connect handlers
+    have completed successfully. It indicates the printer is
+    transitioning to a state ready to handle normal operations. Do not
+    raise an error in this callback.
 * If there is an error in the user's config, be sure to raise it
-  during the `load_config()` or `printer_state("connect")` phases. Use
+  during the `load_config()` or "connect event" phases. Use either
-  either `raise config.error("my error")` or `raise
+  `raise config.error("my error")` or `raise printer.config_error("my
-  printer.config_error("my error")` to report the error.
+  error")` to report the error.
 * Use the "pins" module to configure a pin on a micro-controller. This
   is typically done with something similar to
   `printer.lookup_object("pins").setup_pin("pwm",
@@ -275,8 +296,8 @@ The following may also be useful:
   printer object returned from the `load_config()` function. This is
   important as otherwise the RESTART command may not perform as
   expected. Also, for similar reasons, if any external files (or
-  sockets) are opened then be sure to close them from the
+  sockets) are opened then be sure to register a "klippy:disconnect"
-  `printer_state("disconnect")` callback.
+  event handler and close them from that callback.
 * Avoid accessing the internal member variables (or calling methods
   that start with an underscore) of other printer objects. Observing
   this convention makes it easier to manage future changes.
@@ -291,84 +312,91 @@ This section provides some tips on adding support to Klipper for
 additional types of printer kinematics. This type of activity requires
 excellent understanding of the math formulas for the target
 kinematics. It also requires software development skills - though one
-should only need to update the host software (which is written in
+should only need to update the host software.
-Python).
 
 Useful steps:
-1. Start by studying the [above section](#code-flow-of-a-move-command)
+1. Start by studying the
-   and the [Kinematics document](Kinematics.md).
+   "[code flow of a move](#code-flow-of-a-move-command)" section and
-2. Review the existing kinematic classes in cartesian.py, corexy.py,
+   the [Kinematics document](Kinematics.md).
-   and delta.py. The kinematic classes are tasked with converting a
+2. Review the existing kinematic classes in the klippy/kinematics/
-   move in cartesian coordinates to the movement on each stepper. One
+   directory. The kinematic classes are tasked with converting a move
+   in cartesian coordinates to the movement on each stepper. One
    should be able to copy one of these files as a starting point.
-3. Implement the `get_postion()` method in the new kinematics
+3. Implement the C stepper kinematic position functions for each
-   class. This method converts the current stepper position of each
+   stepper if they are not already available (see kin_cart.c,
-   stepper axis (stored in millimeters) to a position in cartesian
+   kin_corexy.c, and kin_delta.c in klippy/chelper/). The function
-   space (also in millimeters).
+   should call `move_get_coord()` to convert a given move time (in
-4. Implement the `set_postion()` method. This is the inverse of
+   seconds) to a cartesian coordinate (in millimeters), and then
-   get_position() - it sets each axis position (in millimeters) given
+   calculate the desired stepper position (in millimeters) from that
-   a position in cartesian coordinates.
+   cartesian coordinate.
-5. Implement the `move()` method. The goal of the move() method is to
+4. Implement the `calc_position()` method in the new kinematics class.
-   convert a move defined in cartesian space to a series of stepper
+   This method calculates the position of the toolhead in cartesian
-   step times that implement the requested movement.
+   coordinates from the current position of each stepper. It does not
-   * The `move()` method is passed a "print_time" parameter (which
+   need to be efficient as it is typically only called during homing
-     stores a time in seconds) and a "move" class instance that fully
+   and probing operations.
-     defines the movement. The goal is to repeatedly invoke the
+5. Other methods. Implement the `move()`, `check_move()`, `home()`,
-     `stepper.step()` method with the time (relative to print_time)
+   `motor_off()`, `set_position()`, and `get_steppers()` methods.
-     that each stepper should step at to obtain the desired motion.
+   These functions are typically used to provide kinematic specific
-   * One "trick" to help with the movement calculations is to imagine
+   checks.  However, at the start of development one can use
-     there is a physical rail between `move.start_pos` and
+   boiler-plate code here.
-     `move.end_pos` that confines the print head so that it can only
+6. Implement test cases. Create a g-code file with a series of moves
-     move along this straight line of motion. Then, if the head is
-     confined to that imaginary rail, the head is at `move.start_pos`,
-     only one stepper is enabled (all other steppers can move freely),
-     and the given stepper is stepped a single step, then one can
-     imagine that the head will move along the line of movement some
-     distance. Determine the formula converting this step distance to
-     distance along the line of movement. Once one has the distance
-     along the line of movement, one can figure out the time that the
-     head should be at that position (using the standard formulas for
-     velocity and acceleration). This time is the ideal step time for
-     the given stepper and it can be passed to the `stepper.step()`
-     method.
-   * The `stepper.step()` method must always be called with an
-     increasing time for a given stepper (steps must be scheduled in
-     the order they are to be executed). A common error during
-     kinematic development is to receive an "Internal error in
-     stepcompress" failure - this is generally due to the step()
-     method being invoked with a time earlier than the last scheduled
-     step. For example, if the last step in move1 is scheduled at a
-     time greater than the first step in move2 it will generally
-     result in the above error.
-   * Fractional steps. Be aware that a move request is given in
-     cartesian space and it is not confined to discreet
-     locations. Thus a move's start and end locations may translate to
-     a location on a stepper axis that is between two steps (a
-     fractional step). The code must handle this. The preferred
-     approach is to schedule the next step at the time a move would
-     position the stepper axis at least half way towards the next
-     possible step location. Incorrect handling of fractional steps is
-     a common cause of "Internal error in stepcompress" failures.
-6. Other methods. The `home()`, `check_move()`, and other methods
-   should also be implemented. However, at the start of development
-   one can use empty code here.
-7. Implement test cases. Create a g-code file with a series of moves
    that can test important cases for the given kinematics. Follow the
    [debugging documentation](Debugging.md) to convert this g-code file
    to micro-controller commands. This is useful to exercise corner
    cases and to check for regressions.
-8. Optimize if needed. One may notice that the existing kinematic
+
-   classes do not call `stepper.step()`. This is purely an
+Porting to a new micro-controller
-   optimization - the inner loop of the kinematic calculations were
+=================================
-   moved to C to reduce load on the host cpu. All of the existing
+
-   kinematic classes started development using `stepper.step()` and
+This section provides some tips on porting Klipper's micro-controller
-   then were later optimized. The g-code to mcu command translation
+code to a new architecture. This type of activity requires good
-   (described in the previous step) is a useful tool during
+knowledge of embedded development and hands-on access to the target
-   optimization - if a code change is purely an optimization then it
+micro-controller.
-   should not impact the resulting text representation of the mcu
+
-   commands (though minor changes in output due to floating point
+Useful steps:
-   rounding are possible). So, one can use this system to detect
+1. Start by identifying any 3rd party libraries that will be used
-   regressions.
+   during the port. Common examples include "CMSIS" wrappers and
+   manufacturer "HAL" libraries. All 3rd party code needs to be GNU
+   GPLv3 compatible. The 3rd party code should be committed to the
+   Klipper lib/ directory. Update the lib/README file with information
+   on where and when the library was obtained. It is preferable to
+   copy the code into the Klipper repository unchanged, but if any
+   changes are required then those changes should be listed explicitly
+   in the lib/README file.
+2. Create a new architecture sub-directory in the src/ directory and
+   add initial Kconfig and Makefile support. Use the existing
+   architectures as a guide. The src/simulator provides a basic
+   example of a minimum starting point.
+3. The first main coding task is to bring up communication support to
+   the target board. This is the most difficult step in a new port.
+   Once basic communication is working, the remaining steps tend to be
+   much easier. It is typical to use an RS-232 style serial port
+   during initial development as these types of hardware devices are
+   generally easier to enable and control. During this phase, make
+   liberal use of helper code from the src/generic/ directory (check
+   how src/simulator/Makefile includes the generic C code into the
+   build). It is also necessary to define timer_read_time() (which
+   returns the current system clock) in this phase, but it is not
+   necessary to fully support timer irq handling.
+4. Get familiar with the the console.py tool (as described in the
+   [debugging document](Debugging.md)) and verify connectivity to the
+   micro-controller with it. This tool translates the low-level
+   micro-controller communication protocol to a human readable form.
+5. Add support for timer dispatch from hardware interrupts. See
+   Klipper
+   [commit 970831ee](https://github.com/KevinOConnor/klipper/commit/970831ee0d3b91897196e92270d98b2a3067427f)
+   as an example of steps 1-5 done for the LPC176x architecture.
+6. Bring up basic GPIO input and output support. See Klipper
+   [commit c78b9076](https://github.com/KevinOConnor/klipper/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54)
+   as an example of this.
+7. Bring up additional peripherals - for example see Klipper commit
+   [65613aed](https://github.com/KevinOConnor/klipper/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27),
+   [c812a40a](https://github.com/KevinOConnor/klipper/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5),
+   and
+   [c381d03a](https://github.com/KevinOConnor/klipper/commit/c381d03aad5c3ee761169b7c7bced519cc14da29).
+8. Create a sample Klipper config file in the config/ directory. Test
+   the micro-controller with the main klippy.py program.
+9. Consider adding build test cases in the test/ directory.
 
 Time
 ====
@@ -396,7 +424,7 @@ software:
   to convert from a "print time" to the main micro-controller's
   hardware clock by multiplying the print time by the mcu's statically
   configured frequency rate. The high-level host code uses print times
-  to calculates almost all physical actions (eg, head movement, heater
+  to calculate almost all physical actions (eg, head movement, heater
   changes, etc.). Within the host code, print times are generally
   stored in variables named *print_time* or *move_time*.
 * MCU clock. This is the hardware clock counter on each
@@ -424,8 +452,8 @@ Some things to be aware of when reviewing the code:
   conversion is never ambiguous. The host converts from 64bit clocks
   to 32bit clocks by simply truncating the high-order bits. To ensure
   there is no ambiguity in this conversion, the
-  **klippy/serialqueue.c** code will buffer messages until they are
+  **klippy/chelper/serialqueue.c** code will buffer messages until
-  within 2^31 clock ticks of their target time.
+  they are within 2^31 clock ticks of their target time.
 * Multiple micro-controllers: The host software supports using
   multiple micro-controllers on a single printer. In this case, the
   "MCU clock" of each micro-controller is tracked separately. The

docs/Command_Templates.md

@@ -0,0 +1,249 @@
+This document provides information on implementing G-Code command
+sequences in gcode_macro (and similar) config sections.
+
+### Formatting of G-Code in the config
+
+Indentation is important when defining a macro in the config file. To
+specify a multi-line G-Code sequence it is important for each line to
+have proper indentation. For example:
+
+```
+[gcode_macro blink_led]
+gcode:
+  SET_PIN PIN=my_led VALUE=1
+  G4 P2000
+  SET_PIN PIN=my_led VALUE=0
+```
+
+Note how the `gcode:` config option always starts at the beginning of
+the line and subsequent lines in the G-Code macro never start at the
+beginning.
+
+### Save/Restore state for G-Code moves
+
+Unfortunately, the G-Code command language can be challenging to use.
+The standard mechanism to move the toolhead is via the `G1` command
+(the `G0` command is an alias for `G1` and it can be used
+interchangeably with it). However, this command relies on the "G-Code
+parsing state" setup by `M82`, `M83`, `G90`, `G91`, `G92`, and
+previous `G1` commands.  When creating a G-Code macro it is a good
+idea to always explicitly set the G-Code parsing state prior to
+issuing a `G1` command. (Otherwise, there is a risk the `G1` command
+will make an undesirable request.)
+
+A common way to accomplish that is to wrap the `G1` moves in
+`SAVE_GCODE_STATE`, `G91`, and `RESTORE_GCODE_STATE`. For example:
+
+```
+[gcode_macro MOVE_UP]
+gcode:
+  SAVE_GCODE_STATE NAME=my_move_up_state
+  G91
+  G1 Z10 F300
+  RESTORE_GCODE_STATE NAME=my_move_up_state
+```
+
+The `G91` command places the G-Code parsing state into "relative move
+mode" and the `RESTORE_GCODE_STATE` command restores the state to what
+it was prior to entering the macro. Be sure to specify an explicit
+speed (via the `F` parameter) on the first `G1` command.
+
+### Template expansion
+<!-- {% raw %} -->
+
+The gcode_macro `gcode:` config section is evaluated using the Jinja2
+template language. One can evaluate expressions at run-time by
+wrapping them in `{ }` characters or use conditional statements
+wrapped in `{% %}`. See the
+[Jinja2 documentation](http://jinja.pocoo.org/docs/2.10/templates/)
+for further information on the syntax.
+
+This is most often used to inspect parameters passed to the macro when
+it is called. These parameters are available via the `params`
+pseudo-variable. For example, if the macro:
+
+```
+[gcode_macro SET_PERCENT]
+gcode:
+  M117 Now at { params.VALUE|float * 100 }%
+```
+
+were invoked as `SET_PERCENT VALUE=.2` it would evaluate to `M117 Now
+at 20%`. Note that parameter names are always in upper-case when
+evaluated in the macro and are always passed as strings. If performing
+math then they must be explicitly converted to integers or floats.
+
+An example of a complex macro:
+```
+[gcode_macro clean_nozzle]
+gcode:
+  SAVE_GCODE_STATE NAME=clean_nozzle_state
+  G90
+  G0 Z15 F300
+  {% for wipe in range(8) %}
+    {% for coordinate in [(275,4),(235,4)] %}
+      G0 X{coordinate[0]} Y{coordinate[1] + 0.25 * wipe} Z9.7 F12000
+    {% endfor %}
+  {% endfor %}
+  RESTORE_GCODE_STATE NAME=clean_nozzle_state
+```
+<!-- {% endraw %} -->
+
+#### The "printer" Variable
+
+It is possible to inspect (and alter) the current state of the printer
+via the `printer` pseudo-variable. For example:
+
+```
+[gcode_macro slow_fan]
+gcode:
+  M106 S{ printer.fan.speed * 0.9 * 255}
+```
+
+Important! Macros are first evaluated in entirety and only then are
+the resulting commands executed. If a macro issues a command that
+alters the state of the printer, the results of that state change will
+not be visible during the evaluation of the macro. This can also
+result in subtle behavior when a macro generates commands that call
+other macros, as the called macro is evaluated when it is invoked
+(which is after the entire evaluation of the calling macro).
+
+By convention, the name immediately following `printer` is the name of
+a config section. So, for example, `printer.fan` refers to the fan
+object created by the `[fan]` config section. There are some
+exceptions to this rule - notably the `gcode` and `toolhead` objects.
+If the config section contains spaces in it, then one can access it
+via the `[ ]` accessor - for example:
+`printer["generic_heater my_chamber_heater"].temperature`.
+
+Some printer objects allow one to alter the state of the printer. By
+convention, these objects use an `action_` prefix. For example,
+`printer.gcode.action_emergency_stop()` would cause the printer to go
+into a shutdown state. These actions are taken at the time that the
+macro is evaluated, which may be a significant amount of time before
+the generated commands are executed.
+
+The following are common printer attributes:
+- `printer.fan.speed`: The fan speed as a float between 0.0 and 1.0.
+- `printer.gcode.action_respond_info(msg)`: Write the given `msg` to
+  the /tmp/printer pseudo-terminal. Each line of `msg` will be sent
+  with a "// " prefix.
+- `printer.gcode.action_respond_error(msg)`: Write the given `msg` to
+  the /tmp/printer pseudo-terminal. The first line of `msg` will be
+  sent with a "!! " prefix and subsequent lines will have a "// "
+  prefix.
+- `printer.gcode.action_emergency_stop(msg)`: Transition the printer
+  to a shutdown state. The `msg` parameter is optional, it may be
+  useful to describe the reason for the shutdown.
+- `printer.gcode.gcode_position`: The current position of the toolhead
+  relative to the current G-Code origin. It is possible to access the
+  x, y, z, and e components of this position (eg,
+  `printer.gcode.gcode_position.x`).
+- `printer["gcode_macro <macro_name>"].<variable>`: The current value
+  of a gcode_macro variable.
+- `printer.<heater>.temperature`: The last reported temperature (in
+  Celsius as a float) for the given heater. Available heaters are:
+  `heater_bed` and `heater_generic <config_name>`.
+- `printer.<heater>.target`: The current target temperature (in
+  Celsius as a float) for the given heater.
+- `printer.pause_resume.is_paused`: Returns true if a PAUSE command
+  has been executed without a corresponding RESUME.
+- `printer.toolhead.position`: The last commanded position of the
+  toolhead relative to the coordinate system specified in the config
+  file. It is possible to access the x, y, z, and e components of this
+  position (eg, `printer.toolhead.position.x`).
+
+The above list is subject to change - if using an attribute be sure to
+review the [Config Changes document](Config_Changes.md) when upgrading
+the Klipper software. The above list is not exhaustive.  Other
+attributes may be available (via `get_status()` methods defined in the
+software). However, undocumented attributes may change without notice
+in future Klipper releases.
+
+### Variables
+
+The SET_GCODE_VARIABLE command may be useful for saving state between
+macro calls. For example:
+
+```
+[gcode_macro start_probe]
+variable_bed_temp: 0
+gcode:
+  # Save target temperature to bed_temp variable
+  SET_GCODE_VARIABLE MACRO=start_probe VARIABLE=bed_temp VALUE={printer.heater_bed.target}
+  # Disable bed heater
+  M140
+  # Perform probe
+  PROBE
+  # Call finish_probe macro at completion of probe
+  finish_probe
+
+[gcode_macro finish_probe]
+gcode:
+  # Restore temperature
+  M140 S{printer["gcode_macro start_probe"].bed_temp}
+```
+
+Be sure to take the timing of macro evaluation and command execution
+into account when using SET_GCODE_VARIABLE.
+
+### Delayed Gcodes
+
+The [delayed_gcode] configuration option can be used to execute a delayed
+gcode sequence:
+
+```
+[delayed_gcode clear_display]
+gcode:
+  M117
+
+[gcode_macro load_filament]
+gcode:
+ G91
+ G1 E50
+ G90
+ M400
+ M117 Load Complete!
+ UPDATE_DELAYED_GCODE ID=clear_display DURATION=10
+```
+
+When the `load_filament` macro above executes, it will display a
+"Load Complete!" message after the extrusion is finished.  The
+last line of gcode enables the "clear_display" delayed_gcode, set
+to execute in 10 seconds.
+
+The `initial_duration` config option can be set to execute the
+delayed_gcode on printer startup.  The countdown begins when the
+printer enters the "ready" state.  For example, the below delayed_gcode
+will execute 5 seconds after the printer is ready, initializing
+the display with a "Welcome!" message:
+
+```
+[delayed_gcode welcome]
+initial_duration: 5.
+gcode:
+  M117 Welcome!
+```
+
+Its possible for a delayed gcode to repeat by updating itself in
+the gcode option:
+
+```
+[delayed_gcode report_temp]
+initial_duration: 2.
+gcode:
+  {printer.gcode.action_respond_info(
+    "Extruder Temp: %.1f" %
+    (printer.extruder0.temperature))}
+  UPDATE_DELAYED_GCODE ID=report_temp DURATION=2
+
+```
+
+The above delayed_gcode will send "// Extruder Temp: [ex0_temp]" to
+Octoprint every 2 seconds.  This can be canceled with the following
+gcode:
+
+
+```
+UPDATE_DELAYED_GCODE ID=report_temp DURATION=0
+```

docs/Config_Changes.md

@@ -0,0 +1,96 @@
+This document covers recent software changes to the config file that
+are not backwards compatible. It is a good idea to review this
+document when upgrading the Klipper software.
+
+All dates in this document are approximate.
+
+# Changes
+
+20191003: The move_to_previous option in [safe_z_homing] now defaults
+to False.  (It was effectively False prior to 20190918.)
+
+20190918: The zhop option in [safe_z_homing] is always re-applied
+after Z axis homing completed. This might need users to update custom
+scripts based on this module.
+
+20190806: The SET_NEOPIXEL command has been renamed to SET_LED.
+
+20190726: The mcp4728 digital-to-analog code has changed. The default
+i2c_address is now 0x60 and the voltage reference is now relative to
+the mcp4728's internal 2.048 volt reference.
+
+20190710: The z_hop option was removed from the [firmware_retract]
+config section. The z_hop support was incomplete and could cause
+incorrect behavior with several common slicers.
+
+20190710: The optional parameters of the PROBE_ACCURACY command have
+changed. It may be necessary to update any macros or scripts that use
+that command.
+
+20190628: All configuration options have been removed from the
+[skew_correction] section.  Configuration for skew_correction
+is now done via the SET_SKEW gcode.  See skew_correction.md
+for recommended usage.
+
+20190607: The "variable_X" parameters of gcode_macro (along with the
+VALUE parameter of SET_GCODE_VARIABLE) are now parsed as Python
+literals. If a value needs to be assigned a string then wrap the value
+in quotes so that it is evaluated as a string.
+
+20190606: The "samples", "samples_result", and "sample_retract_dist"
+config options have been moved to the "probe" config section. These
+options are no longer supported in the "delta_calibrate", "bed_tilt",
+"bed_mesh", "screws_tilt_adjust", "z_tilt", or "quad_gantry_level"
+config sections.
+
+20190528: The magic "status" variable in gcode_macro template
+evaluation has been renamed to "printer".
+
+20190520: The SET_GCODE_OFFSET command has changed; update any g-code
+macros accordingly. The command will no longer apply the requested
+offset to the next G1 command. The old behavior may be approximated by
+using the new "MOVE=1" parameter.
+
+20190404: The Python host software packages were updated. Users will
+need to rerun the ~/klipper/scripts/install-octopi.sh script (or
+otherwise upgrade the python dependencies if not using a standard
+OctoPi installation).
+
+20190404: The i2c_bus and spi_bus parameters (in various config
+sections) now take a bus name instead of a number.
+
+20190404: The sx1509 config parameters have changed. The 'address'
+parameter is now 'i2c_address' and it must be specified as a decimal
+number. Where 0x3E was previously used, specify 62.
+
+20190328: The min_speed value in [temperature_fan] config
+will now be respected and the fan will always run at this
+speed or higher in PID mode.
+
+20190322: The default value for "driver_HEND" in [tmc2660] config
+sections was changed from 6 to 3. The "driver_VSENSE" field was
+removed (it is now automatically calculated from run_current).
+
+20190310: The [controller_fan] config section now always takes a name
+(such as [controller_fan my_controller_fan]).
+
+20190308: The "driver_BLANK_TIME_SELECT" field in [tmc2130] and
+[tmc2208] config sections has been renamed to "driver_TBL".
+
+20190308: The [tmc2660] config section has changed. A new
+sense_resistor config parameter must now be provided. The meaning of
+several of the driver_XXX parameters has changed.
+
+20190228: Users of SPI or I2C on SAMD21 boards must now specify the
+bus pins via a [samd_sercom] config section.
+
+20190224: The bed_shape option has been removed from bed_mesh.  The
+radius option has been renamed to bed_radius.  Users with round beds
+should supply the bed_radius and round_probe_count options.
+
+20190107: The i2c_address parameter in the mcp4451 config section
+changed. This is a common setting on Smoothieboards. The new value is
+half the old value (88 should be changed to 44, and 90 should be
+changed to 45).
+
+20181220: Klipper v0.7.0 released

docs/Config_checks.md

@@ -81,27 +81,38 @@ require a change to the pullup setting of the pin (the '^' at the
 start of the endstop_pin name - most printers will use a pullup
 resistor and the '^' should be present).
 
-### Verify stepper motor direction
+### Verify stepper motors
 
-Make sure the printer.cfg file does not have "homing_speed" set for
+Use the STEPPER_BUZZ command to verify the connectivity of each
-any axis (or set it to a value of 5 or less).
+stepper motor. Start by manually positioning the given axis to a
+midway point and then run `STEPPER_BUZZ STEPPER=stepper_x` . The
+STEPPER_BUZZ command will cause the given stepper to move one
+millimeter in a positive direction and then it will return to its
+starting position. (If the endstop is defined at position_endstop=0
+then at the start of each movement the stepper will move away from the
+endstop.) It will perform this oscillation ten times.
 
-On cartesian style printers, manually move the X axis to a midway
+If the stepper does not move at all, then verify the "enable_pin" and
-point, issue a G28X0 command, and verify that the X motor moves slowly
+"step_pin" settings for the stepper. If the stepper motor moves but
-towards the endstop defined for that axis. If the motor moves in the
+does not return to its original position then verify the "dir_pin"
-wrong direction issue an M112 command to abort the move. A wrong
+setting. If the stepper motor oscillates in an incorrect direction,
-direction generally indicates that the "dir_pin" for the axis needs to
+then it generally indicates that the "dir_pin" for the axis needs to
 be inverted. This is done by adding a '!' to the "dir_pin" in the
-printer config file (or removing it if one is already there). For
+printer config file (or removing it if one is already there). If the
-example, change "dir_pin: xyz" to "dir_pin: !xyz". Then RESTART and
+motor moves significantly more or significantly less than one
-retest the axis. If the axis does not move at all, then verify the
+millimeter then verify the "step_distance" setting.
-"enable_pin" and "step_pin" settings for the axis. For cartesian style
-printers, repeat the test for the Y and Z axis with G28Y0 and G28Z0.
 
-For delta style printers, manually move all three carriages to a
+Run the above test for each stepper motor defined in the config
-midway point and then issue a G28 command. Verify all three motors
+file. (Set the STEPPER parameter of the STEPPER_BUZZ command to the
-move simultaneously upwards. If not, issue an M112 command and follow
+name of the config section that is to be tested.) If there is no
-the troubleshooting steps in the preceding paragraph.
+filament in the extruder then one can use STEPPER_BUZZ to verify the
+extruder motor connectivity (use STEPPER=extruder). Otherwise, it's
+best to test the extruder motor separately (see the next section).
+
+After verifying all endstops and verifying all stepper motors the
+homing mechanism should be tested. Issue a G28 command to home all
+axes.  Remove power from the printer if it does not home properly.
+Rerun the endstop and stepper motor verification steps if necessary.
 
 ### Verify extruder motor
 
@@ -128,8 +139,8 @@ To calibrate the extruder, navigate to the OctoPrint terminal tab and
 run the PID_CALIBRATE command. For example: `PID_CALIBRATE
 HEATER=extruder TARGET=170`
 
-At the completion of the tuning test, update the printer.cfg file with
+At the completion of the tuning test run `SAVE_CONFIG` to update the
-the recommended pid_Kp, pid_Ki, and pid_Kd values.
+printer.cfg file the new PID settings.
 
 If the printer has a heated bed and it supports being driven by PWM
 (Pulse Width Modulation) then it is recommended to use PID control for
@@ -141,7 +152,13 @@ command is: `PID_CALIBRATE HEATER=heater_bed TARGET=60`
 ### Next steps
 
 This guide is intended to help with basic verification of pin settings
-in the Klipper configuration file. It may be necessary to perform
+in the Klipper configuration file. Be sure to read the
-detailed printer calibration - a number of guides are available online
+[bed leveling](Bed_Level.md) guide. Also see the [Slicers](Slicers.md)
-to help with this (for example, do a web search for "3d printer
+document for information on configuring a slicer with Klipper.
-calibration").
+
+After one has verified that basic printing works, it is a good idea to
+consider calibrating [pressure advance](Pressure_Advance.md).
+
+It may be necessary to perform other types of detailed printer
+calibration - a number of guides are available online to help with
+this (for example, do a web search for "3d printer calibration").

docs/Contact.md

@@ -4,26 +4,32 @@ developers.
 Issue reporting
 ===============
 
-In order to report a problem or request a change in behavior, it is
+It is very important to attach the Klipper log file to all
-necessary to collect the Klipper log file. The first step is to
+reports. The log file has been engineered to answer common questions
-**issue an M112 command** in the OctoPrint terminal window immediately
+the Klipper developers have about the software and its environment
-after the undesirable event occurs. This causes Klipper to go into a
+(software version, hardware type, configuration, event timing, and
-"shutdown state" and it will cause additional debugging information to
+hundreds of other questions). **The developers need the Klipper log
-be written to the log file.
+file to provide any meaningful assistance**; only this log file
+provides the necessary information.
 
-Issue requests are submitted through Github.  **All issues must
+On a problem report the first step is to **issue an M112 command** in
+the OctoPrint terminal window immediately after the undesirable event
+occurs. This causes Klipper to go into a "shutdown state" and it will
+cause additional debugging information to be written to the log file.
+
+Issue requests are submitted through Github. **All Github issues must
 include the full /tmp/klippy.log log file from the session that
-produced the error.** An "scp" and/or "sftp" utility is needed to
+produced the event being reported.** An "scp" and/or "sftp" utility is
-acquire this log file. The "scp" utility comes standard with Linux and
+needed to acquire this log file. The "scp" utility comes standard with
-MacOS desktops. There are freely available scp utilities for other
+Linux and MacOS desktops. There are freely available scp utilities for
-desktops (eg, WinSCP).
+other desktops (eg, WinSCP).
 
-Use the scp utility to copy the `/tmp/klippy.log` file from the host
+Use the scp utility to copy the `/tmp/klippy.log` file from the
-machine to your desktop. It is a good idea to compress the klippy.log
+Raspberry Pi to your desktop. It is a good idea to compress the
-file before posting it (eg, using zip or gzip). Open a new issue at
+klippy.log file before posting it (eg, using zip or gzip). Open a new
-https://github.com/KevinOConnor/klipper/issues , provide a description
+issue at https://github.com/KevinOConnor/klipper/issues , provide a
-of the problem, and **attach the `klippy.log` file to the issue**:
+description of the problem, and **attach the `klippy.log` file to the
-![attach-issue](img/attach-issue.png)
+issue**: ![attach-issue](img/attach-issue.png)
 
 Mailing list
 ============

docs/Debugging.md

@@ -1,4 +1,4 @@
-The Klippy host code has some tools to help in debugging.
+This document describes some of the Klipper debugging tools.
 
 Translating gcode files to micro-controller commands
 ====================================================
@@ -147,11 +147,14 @@ sudo apt-get install python-matplotlib
 Then graphs can be produced with:
 
 ```
-~/klipper/scripts/graphstats.py /tmp/klippy.log loadgraph.png
+~/klipper/scripts/graphstats.py /tmp/klippy.log -o loadgraph.png
 ```
 
 One can then view the resulting **loadgraph.png** file.
 
+Different graphs can be produced. For more information run:
+`~/klipper/scripts/graphstats.py --help`
+
 Extracting information from the klippy.log file
 ===============================================
 
@@ -171,3 +174,24 @@ The script will extract the printer config file and will extract MCU
 shutdown information. The information dumps from an MCU shutdown (if
 present) will be reordered by timestamp to assist in diagnosing cause
 and effect scenarios.
+
+Running the regression tests
+============================
+
+The main Klipper GitHub repository uses TravisCI to run a series of
+regression tests. It can be useful to run some of these tests locally.
+
+The source code "whitespace check" can be run with:
+```
+./scripts/check_whitespace.sh
+```
+
+The Klippy regression test suite requires "data dictionaries" from
+many platforms. The easiest way to obtain them is to
+[download them from github](https://github.com/KevinOConnor/klipper/issues/1438).
+Once the data dictionaries are downloaded, use the following to run
+the regression suite:
+```
+tar xfz klipper-dict-20??????.tar.gz
+~/klippy-env/bin/python ~/klipper/scripts/test_klippy.py -d dict/ ~/klipper/test/klippy/*.test
+```

docs/Delta_Calibrate.md

@@ -0,0 +1,230 @@
+This document describes Klipper's automatic calibration system for
+"delta" style printers.
+
+Delta calibration involves finding the tower endstop positions, tower
+angles, delta radius, and delta arm lengths. These settings control
+printer motion on a delta printer. Each one of these parameters has a
+non-obvious and non-linear impact and it is difficult to calibrate
+them manually. In contrast, the software calibration code can provide
+excellent results with just a few minutes of time. No special probing
+hardware is necessary.
+
+Ultimately, the delta calibration is dependent on the precision of the
+tower endstop switches. If one is using Trinamic stepper motor drivers
+then consider enabling [endstop phase](Endstop_Phase.md) detection to
+improve the accuracy of those switches.
+
+Automatic vs manual probing
+===========================
+
+Klipper supports calibrating the delta parameters via a manual probing
+method or via an automatic Z probe.
+
+A number of delta printer kits come with automatic Z probes that are
+not sufficiently accurate (specifically, small differences in arm
+length can cause effector tilt which can skew an automatic probe). If
+using an automatic probe then first
+[calibrate the probe](Probe_Calibrate.md) and then check for a
+[probe location bias](Probe_Calibrate.md#location-bias-check). If the
+automatic probe has a bias of more than 25 microns (.025mm) then use
+manual probing instead. Manual probing only takes a few minutes and it
+eliminates error introduced by the probe.
+
+Basic delta calibration
+=======================
+
+Klipper has a DELTA_CALIBRATE command that can perform basic delta
+calibration. This command probes seven different points on the bed and
+calculates new values for the tower angles, tower endstops, and delta
+radius.
+
+In order to perform this calibration the initial delta parameters (arm
+lengths, radius, and endstop positions) must be provided and they
+should have an accuracy to within a few millimeters. Most delta
+printer kits will provide these parameters - configure the printer
+with these initial defaults and then go on to run the DELTA_CALIBRATE
+command as described below. If no defaults are available then search
+online for a delta calibration guide that can provide a basic starting
+point.
+
+During the delta calibration process it may be necessary for the
+printer to probe below what would otherwise be considered the plane of
+the bed. It is typical to permit this during calibration by updating
+the config so that the printer's `minimum_z_position=-5`. (Once
+calibration completes, one can remove this setting from the config.)
+
+There are two ways to perform the probing - manual probing
+(`DELTA_CALIBRATE METHOD=manual`) and automatic probing
+(`DELTA_CALIBRATE`). The manual probing method will move the head near
+the bed and then wait for the user to follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
+actual distance between the nozzle and bed at the given location.
+
+To perform the basic probe, make sure the config has a
+[delta_calibrate] section defined and then run the tool:
+```
+G28
+DELTA_CALIBRATE METHOD=manual
+```
+After probing the seven points new delta parameters will be
+calculated.  Save and apply these parameters by running:
+```
+SAVE_CONFIG
+```
+
+The basic calibration should provide delta parameters that are
+accurate enough for basic printing. If this is a new printer, this is
+a good time to print some basic objects and verify general
+functionality.
+
+Enhanced delta calibration
+==========================
+
+The basic delta calibration generally does a good job of calculating
+delta parameters such that the nozzle is the correct distance from the
+bed. However, it does not attempt to calibrate X and Y dimensional
+accuracy. It's a good idea to perform an enhanced delta calibration to
+verify dimensional accuracy.
+
+This calibration procedure requires printing a test object and
+measuring parts of that test object with digital calipers.
+
+Prior to running an enhanced delta calibration one must run the basic
+delta calibration (via the DELTA_CALIBRATE command) and save the
+results (via the SAVE_CONFIG command).
+
+Use a slicer to generate G-Code from the
+[docs/prints/calibrate_size.stl](prints/calibrate_size.stl) file.
+Slice the object using a slow speed (eg, 40mm/s). If possible, use a
+stiff plastic (such as PLA) for the object. The object has a diameter
+of 140mm. If this is too large for the printer then one can scale it
+down (but be sure to uniformly scale both the X and Y axes). If the
+printer supports significantly larger prints then this object can also
+be increased in size. A larger size can improve the measurement
+accuracy, but good print adhesion is more important than a larger
+print size.
+
+Print the test object and wait for it to fully cool. The commands
+described below must be run with the same printer settings used to
+print the calibration object (don't run DELTA_CALIBRATE between
+printing and measuring, or do something that would otherwise change
+the printer configuration).
+
+If possible, perform the measurements described below while the object
+is still attached to the print bed, but don't worry if the part
+detaches from the bed - just try to avoid bending the object when
+performing the measurements.
+
+Start by measuring the distance between the center pillar and the
+pillar next to the "A" label (which should also be pointing towards
+the "A" tower).
+
+![delta-a-distance](img/delta-a-distance.jpg)
+
+Then go counterclockwise and measure the distances between the center
+pillar and the other pillars (distance from center to pillar across
+from C label, distance from center to pillar with B label, etc.).
+
+![delta_cal_e_step1](img/delta_cal_e_step1.png)
+
+Enter these parameters into Klipper with a comma separated list of
+floating point numbers:
+```
+DELTA_ANALYZE CENTER_DISTS=<a_dist>,<far_c_dist>,<b_dist>,<far_a_dist>,<c_dist>,<far_b_dist>
+```
+Provide the values without spaces between them.
+
+Then measure the distance between the A pillar and the pillar across
+from the C label.
+
+![delta-ab-distance](img/delta-outer-distance.jpg)
+
+Then go counterclockwise and measure the distance between the pillar
+across from C to the B pillar, the distance between the B pillar and
+the pillar across from A, and so on.
+
+![delta_cal_e_step2](img/delta_cal_e_step2.png)
+
+Enter these parameters into Klipper:
+```
+DELTA_ANALYZE OUTER_DISTS=<a_to_far_c>,<far_c_to_b>,<b_to_far_a>,<far_a_to_c>,<c_to_far_b>,<far_b_to_a>
+```
+
+At this point it is okay to remove the object from the bed. The final
+measurements are of the pillars themselves. Measure the size of the
+center pillar along the A spoke, then the B spoke, and then the C
+spoke.
+
+![delta-a-pillar](img/delta-a-pillar.jpg)
+
+![delta_cal_e_step3](img/delta_cal_e_step3.png)
+
+Enter them into Klipper:
+```
+DELTA_ANALYZE CENTER_PILLAR_WIDTHS=<a>,<b>,<c>
+```
+
+The final measurements are of the outer pillars. Start by measuring
+the distance of the A pillar along the line from A to the pillar
+across from C.
+
+![delta-ab-pillar](img/delta-outer-pillar.jpg)
+
+Then go counterclockwise and measure the remaining outer pillars
+(pillar across from C along the line to B, B pillar along the line to
+pillar across from A, etc.).
+
+![delta_cal_e_step4](img/delta_cal_e_step4.png)
+
+And enter them into Klipper:
+```
+DELTA_ANALYZE OUTER_PILLAR_WIDTHS=<a>,<far_c>,<b>,<far_a>,<c>,<far_b>
+```
+
+If the object was scaled to a smaller or larger size then provide the
+scale factor that was used when slicing the object:
+```
+DELTA_ANALYZE SCALE=1.0
+```
+(A scale value of 2.0 would mean the object is twice its original
+size, 0.5 would be half its original size.)
+
+Finally, perform the enhanced delta calibration by running:
+```
+DELTA_ANALYZE CALIBRATE=extended
+```
+This command can take several minutes to complete. After completion it
+will calculate updated delta parameters (delta radius, tower angles,
+endstop positions, and arm lengths). Use the SAVE_CONFIG command to
+save and apply the settings:
+```
+SAVE_CONFIG
+```
+
+The SAVE_CONFIG command will save both the updated delta parameters
+and information from the distance measurements. Future DELTA_CALIBRATE
+commands will also utilize this distance information. Do not attempt
+to reenter the raw distance measurements after running SAVE_CONFIG, as
+this command changes the printer configuration and the raw
+measurements no longer apply.
+
+Additional notes
+----------------
+
+* If the delta printer has good dimensional accuracy then the distance
+  between any two pillars should be around 74mm and the width of every
+  pillar should be around 9mm. (Specifically, the goal is for the
+  distance between any two pillars minus the width of one of the
+  pillars to be exactly 65mm.) Should there be a dimensional
+  inaccuracy in the part then the DELTA_ANALYZE routine will calculate
+  new delta parameters using both the distance measurements and the
+  previous height measurements from the last DELTA_CALIBRATE command.
+
+* DELTA_ANALYZE may produce delta parameters that are surprising. For
+  example, it may suggest arm lengths that do not match the printer's
+  actual arm lengths. Despite this, testing has shown that
+  DELTA_ANALYZE often produces superior results. It is believed that
+  the calculated delta parameters are able to account for slight
+  errors elsewhere in the hardware. For example, small differences in
+  arm length may result in a tilt to the effector and some of that
+  tilt may be accounted for by adjusting the arm length parameters.

docs/Endstop_Phase.md

@@ -0,0 +1,125 @@
+This document describes Klipper's stepper phase adjusted endstop
+system. This functionality can improve the accuracy of traditional
+endstop switches. It is most useful when using a Trinamic stepper
+motor driver that has run-time configuration.
+
+A typical endstop switch has an accuracy of around 100 microns. (Each
+time an axis is homed the switch may trigger slightly earlier or
+slightly later.) Although this is a relatively small error, it can
+result in unwanted artifacts. In particular, this positional deviation
+may be noticeable when printing the first layer of an object. In
+contrast, typical stepper motors can obtain significantly higher
+precision.
+
+The stepper phase adjusted endstop mechanism can use the precision of
+the stepper motors to improve the precision of the endstop switches.
+When a stepper motor moves it cycles through a series of phases until
+in completes four "full steps". So, a stepper motor using 16
+micro-steps would have 64 phases and when moving in a positive
+direction it would cycle through phases: 0, 1, 2, ... 61, 62, 63, 0,
+1, 2, etc. Crucially, when the stepper motor is at a particular
+position on a linear rail it should always be at the same stepper
+phase. Thus, when a carriage triggers the endstop switch the stepper
+controlling that carriage should always be at the same stepper motor
+phase. Klipper's endstop phase system combines the stepper phase with
+the endstop trigger to improve the accuracy of the endstop.
+
+In order to use this functionality it is necessary to be able to
+identify the phase of the stepper motor. If one is using Trinamic
+TMC2130, TMC2208, TMC2224 or TMC2660 drivers in run-time configuration
+mode (ie, not stand-alone mode) then Klipper can query the stepper
+phase from the driver. (It is also possible to use this system on
+traditional stepper drivers if one can reliably reset the stepper
+drivers - see below for details.)
+
+Calibrating endstop phases
+==========================
+
+If using Trinamic stepper motor drivers with run-time configuration
+then one can calibrate the endstop phases using the
+ENDSTOP_PHASE_CALIBRATE command. Start by adding the following to the
+config file:
+```
+[endstop_phase]
+```
+
+Then RESTART the printer and run a `G28` command followed by an
+`ENDSTOP_PHASE_CALIBRATE` command. Then move the toolhead to a new
+location and run `G28` again. Try moving the toolhead to several
+different locations and rerun `G28` from each position. Run at least
+five `G28` commands.
+
+After performing the above, the `ENDSTOP_PHASE_CALIBRATE` command will
+often report the same (or nearly the same) phase for the stepper. This
+phase can be saved in the config file so that all future G28 commands
+use that phase. (So, in future homing operations, Klipper will obtain
+the same position even if the endstop triggers a little earlier or a
+little later.)
+
+To save the endstop phase for a particular stepper motor, run
+something like the following:
+```
+ENDSTOP_PHASE_CALIBRATE STEPPER=stepper_z
+```
+
+Run the above for all the steppers one wishes to save. Typically, one
+would use this on stepper_z for cartesian and corexy printers, and for
+stepper_a, stepper_b, and stepper_c on delta printers. Finally, run
+the following to update the configuration file with the data:
+```
+SAVE_CONFIG
+```
+
+Additional notes
+----------------
+
+* This feature is most useful on delta printers and on the Z endstop
+  of cartesian/corexy printers. It is possible to use this feature on
+  the XY endstops of cartesian printers, but that isn't particularly
+  useful as a minor error in X/Y endstop position is unlikely to
+  impact print quality. It is not valid to use this feature on the XY
+  endstops of corexy printers (as the XY position is not determined by
+  a single stepper on corexy kinematics). It is not valid to use this
+  feature on a printer using a "probe:z_virtual_endstop" Z endstop (as
+  the stepper phase is only stable if the endstop is at a static
+  location on a rail).
+
+* After calibrating the endstop phase, if the endstop is later moved
+  or adjusted then it will be necessary to recalibrate the endstop.
+  Remove the calibration data from the config file and rerun the steps
+  above.
+
+* In order to use this system the endstop must be accurate enough to
+  identify the stepper position within two "full steps". So, for
+  example, if a stepper is using 16 micro-steps with a step distance
+  of 0.005mm then the endstop must have an accuracy of at least
+  0.160mm. If one gets "Endstop stepper_z incorrect phase" type error
+  messages than in may be due to an endstop that is not sufficiently
+  accurate. If recalibration does not help then disable endstop phase
+  adjustments by removing them from the config file.
+
+* If one is using a traditional stepper controlled Z axis (as on a
+  cartesian or corexy printer) along with traditional bed leveling
+  screws then it is also possible to use this system to arrange for
+  each print layer to be performed on a "full step" boundary. To
+  enable this feature be sure the G-Code slicer is configured with a
+  layer height that is a multiple of a "full step", manually enable
+  the endstop_align_zero option in the endstop_phase config section
+  (see config/example-extras.cfg for further details), and then
+  re-level the bed screws.
+
+* It is possible to use this system with traditional (non-Trinamic)
+  stepper motor drivers. However, doing this requires making sure that
+  the stepper motor drivers are reset every time the micro-controller
+  is reset. (If the two are always reset together then Klipper can
+  determine the stepper phase by tracking the total number of steps it
+  has commanded the stepper to move.) Currently, the only way to do
+  this reliably is if both the micro-controller and stepper motor
+  drivers are powered solely from USB and that USB power is provided
+  from a host running on a Raspberry Pi. In this situation one can
+  specify an mcu config with "restart_method: rpi_usb" - that option
+  will arrange for the micro-controller to always be reset via a USB
+  power reset, which would arrange for both the micro-controller and
+  stepper motor drivers to be reset together. If using this mechanism,
+  one would then need to manually configure the "endstop_phase" config
+  sections (see config/example-extras.cfg for the details).

docs/FAQ.md

@@ -4,15 +4,24 @@ Frequently asked questions
 1. [How can I donate to the project?](#how-can-i-donate-to-the-project)
 2. [How do I calculate the step_distance parameter in the printer config file?](#how-do-i-calculate-the-step_distance-parameter-in-the-printer-config-file)
 3. [Where's my serial port?](#wheres-my-serial-port)
-4. [The "make flash" command doesn't work](#the-make-flash-command-doesnt-work)
+4. [When the micro-controller restarts the device changes to /dev/ttyUSB1](#when-the-micro-controller-restarts-the-device-changes-to-devttyusb1)
-5. [How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-rate)
+5. [The "make flash" command doesn't work](#the-make-flash-command-doesnt-work)
-6. [Can I run Klipper on something other than a Raspberry Pi 3?](#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
+6. [How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-rate)
-7. [Why can't I move the stepper before homing the printer?](#why-cant-i-move-the-stepper-before-homing-the-printer)
+7. [Can I run Klipper on something other than a Raspberry Pi 3?](#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
-8. [Why is the Z position_endstop set to 0.5 in the default configs?](#why-is-the-z-position_endstop-set-to-05-in-the-default-configs)
+8. [Can I run multiple instances of Klipper on the same host machine?](#can-i-run-multiple-instances-of-klipper-on-the-same-host-machine)
-9. [I converted my config from Marlin and the X/Y axes work fine, but I just get a screeching noise when homing the Z axis](#i-converted-my-config-from-marlin-and-the-xy-axes-work-fine-but-i-just-get-a-screeching-noise-when-homing-the-z-axis)
+9. [Do I have to use OctoPrint?](#do-i-have-to-use-octoprint)
-10. [When I set "restart_method=command" my AVR device just hangs on a restart](#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-restart)
+10. [Why can't I move the stepper before homing the printer?](#why-cant-i-move-the-stepper-before-homing-the-printer)
-11. [Will the heaters be left on if the Raspberry Pi crashes?](#will-the-heaters-be-left-on-if-the-raspberry-pi-crashes)
+11. [Why is the Z position_endstop set to 0.5 in the default configs?](#why-is-the-z-position_endstop-set-to-05-in-the-default-configs)
-12. [How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-software)
+12. [I converted my config from Marlin and the X/Y axes work fine, but I just get a screeching noise when homing the Z axis](#i-converted-my-config-from-marlin-and-the-xy-axes-work-fine-but-i-just-get-a-screeching-noise-when-homing-the-z-axis)
+13. [My TMC motor driver turns off in the middle of a print](#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print)
+14. [I keep getting random "Lost communication with MCU" errors](#i-keep-getting-random-lost-communication-with-mcu-errors)
+15. [My Raspberry Pi keeps rebooting during prints](#my-raspberry-pi-keeps-rebooting-during-prints)
+16. [When I set "restart_method=command" my AVR device just hangs on a restart](#when-i-set-restart_methodcommand-my-avr-device-just-hangs-on-a-restart)
+17. [Will the heaters be left on if the Raspberry Pi crashes?](#will-the-heaters-be-left-on-if-the-raspberry-pi-crashes)
+18. [How do I convert a Marlin pin number to a Klipper pin name?](#how-do-i-convert-a-marlin-pin-number-to-a-klipper-pin-name)
+19. [How do I cancel an M109/M190 "wait for temperature" request?](#how-do-i-cancel-an-m109m190-wait-for-temperature-request)
+20. [How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-software)
+21. [Can I find out whether the printer has lost steps?](#can-i-find-out-whether-the-printer-has-lost-steps)
 
 ### How can I donate to the project?
 
@@ -30,13 +39,21 @@ each motor driver pulse. It can also be calculated from the axis
 pitch, motor step angle, and driver microstepping. If unsure, do a web
 search for "calculate steps per mm" to find an online calculator.
 
+Klipper uses step_distance instead of steps_per_mm in order to use
+consistent units of measurement in the config file. (The config uses
+millimeters for all distance measurements.) It is believed that
+steps_per_mm originated as an optimization on old 8-bit
+micro-controllers (the desire to use a multiply instead of a divide in
+some low-level code). Continuing to configure this one distance in
+units of "inverse millimeters" is felt to be quirky and unnecessary.
+
 ### Where's my serial port?
 
 The general way to find a USB serial port is to run `ls -l
 /dev/serial/by-id/` from an ssh terminal on the host machine. It will
 likely produce output similar to the following:
 ```
-lrwxrwxrwx 1 root root 13 Jan 3 22:15 usb-UltiMachine__ultimachine.com__RAMBo_12345678912345678912-if00 -> ../../ttyACM0
+lrwxrwxrwx 1 root root 13 Jun  1 21:12 usb-1a86_USB2.0-Serial-if00-port0 -> ../../ttyUSB0
 ```
 
 The name found in the above command is stable and it is possible to
@@ -44,18 +61,28 @@ use it in the config file and while flashing the micro-controller
 code. For example, a flash command might look similar to:
 ```
 sudo service klipper stop
-make flash FLASH_DEVICE=/dev/serial/by-id/usb-UltiMachine__ultimachine.com__RAMBo_12345678912345678912-if00
+make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
 sudo service klipper start
 ```
 and the updated config might look like:
 ```
 [mcu]
-serial: /dev/serial/by-id/usb-UltiMachine__ultimachine.com__RAMBo_12345678912345678912-if00
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
 ```
 
 Be sure to copy-and-paste the name from the "ls" command that you ran
 above as the name will be different for each printer.
 
+If you are using multiple micro-controllers and they do not have
+unique ids (common on boards with a CH340 USB chip) then follow the
+directions above using the directory `/dev/serial/by-path/` instead.
+
+### When the micro-controller restarts the device changes to /dev/ttyUSB1
+
+Follow the directions in the
+"[Where's my serial port?](#wheres-my-serial-port)" section to prevent
+this from occurring.
+
 ### The "make flash" command doesn't work
 
 The code attempts to flash the device using the most common method for
@@ -72,25 +99,26 @@ and make sure FLASH_DEVICE is set correctly for your board (see the
 
 However, if "make flash" just doesn't work for your board, then you
 will need to manually flash. See if there is a config file in the
-[config directory](../config) with specific instructions for flashing
+[config directory](https://github.com/KevinOConnor/klipper/tree/master/config)
-the device. Also, check the board manufacturer's documentation to see
+with specific instructions for flashing the device. Also, check the
-if it describes how to flash the device. Finally, on AVR devices, it
+board manufacturer's documentation to see if it describes how to flash
-may be possible to manually flash the device using
+the device. Finally, it may be possible to manually flash the device
-[avrdude](http://www.nongnu.org/avrdude/) with custom command-line
+using tools such as "avrdude" or "bossac" - see the
-parameters - see the avrdude documentation for further information.
+[bootloader document](Bootloaders.md) for additional information.
 
 ### How do I change the serial baud rate?
 
-The default baud rate is 250000 in both the Klipper micro-controller
+The recommended baud rate for Klipper is 250000. This baud rate works
-configuration and in the Klipper host software. This works on almost
+well on all micro-controller boards that Klipper supports. If you've
-all micro-controllers and it is the recommended setting. (Most online
+found an online guide recommending a different baud rate, then ignore
-guides that refer to a baud rate of 115200 are outdated.)
+that part of the guide and continue with the default value of 250000.
 
-If you need to change the baud rate, then the new rate will need to be
+If you want to change the baud rate anyway, then the new rate will
-configured in the micro-controller (during **make menuconfig**) and
+need to be configured in the micro-controller (during **make
-that updated code will need to be flashed to the micro-controller. The
+menuconfig**) and that updated code will need to be compiled and
-Klipper printer.cfg file will also need to be updated to match that
+flashed to the micro-controller. The Klipper printer.cfg file will
-baud rate (see the example.cfg file for details).  For example:
+also need to be updated to match that baud rate (see the example.cfg
+file for details).  For example:
 ```
 [mcu]
 baud: 250000
@@ -100,6 +128,11 @@ The baud rate shown on the OctoPrint web page has no impact on the
 internal Klipper micro-controller baud rate. Always set the OctoPrint
 baud rate to 250000 when using Klipper.
 
+The Klipper micro-controller baud rate is not related to the baud rate
+of the micro-controller's bootloader. See the
+[bootloader document](Bootloaders.md) for additional information on
+bootloaders.
+
 ### Can I run Klipper on something other than a Raspberry Pi 3?
 
 The recommended hardware is a Raspberry Pi 2 or a Raspberry
@@ -112,8 +145,8 @@ machines (the printer may move faster than OctoPrint can send movement
 commands) when printing directly from OctoPrint. If you wish to run on
 one one of these slower boards anyway, consider using the
 "virtual_sdcard" feature (see
-[config/example-extras.cfg](../config/example-extras.cfg) for details)
+[config/example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
-when printing.
+for details) when printing.
 
 For running on the Beaglebone, see the
 [Beaglebone specific installation instructions](beaglebone.md).
@@ -123,8 +156,41 @@ only requires Python running on a Linux (or similar)
 computer. However, if you wish to run it on a different machine you
 will need Linux admin knowledge to install the system prerequisites
 for that particular machine. See the
-[install-octopi.sh](../scripts/install-octopi.sh) script for further
+[install-octopi.sh](https://github.com/KevinOConnor/klipper/tree/master/scripts/install-octopi.sh)
-information on the necessary Linux admin steps.
+script for further information on the necessary Linux admin steps.
+
+### Can I run multiple instances of Klipper on the same host machine?
+
+It is possible to run multiple instances of the Klipper host software,
+but doing so requires Linux admin knowledge. The Klipper installation
+scripts ultimately cause the following Unix command to be run:
+```
+~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log
+```
+One can run multiple instances of the above command as long as each
+instance has its own printer config file, its own log file, and its
+own pseudo-tty. For example:
+```
+~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer2.cfg -l /tmp/klippy2.log -I /tmp/printer2
+```
+
+If you choose to do this, you will need to implement the necessary
+start, stop, and installation scripts (if any). The
+[install-octopi.sh](https://github.com/KevinOConnor/klipper/tree/master/scripts/install-octopi.sh)
+script and the
+[klipper-start.sh](https://github.com/KevinOConnor/klipper/tree/master/scripts/klipper-start.sh)
+script may be useful as examples.
+
+### Do I have to use OctoPrint?
+
+The Klipper software is not dependent on OctoPrint. It is possible to
+use alternative software to send commands to Klipper, but doing so
+requires Linux admin knowledge.
+
+Klipper creates a "virtual serial port" via the "/tmp/printer" file,
+and it emulates a classic 3d-printer serial interface via that file.
+In general, alternative software may work with Klipper as long as it
+can be configured to use "/tmp/printer" for the printer serial port.
 
 ### Why can't I move the stepper before homing the printer?
 
@@ -143,6 +209,14 @@ Settings->GCODE Scripts
 If you want to move the head after a print finishes, consider adding
 the desired movement to the "custom g-code" section of your slicer.
 
+If the printer requires some additional movement as part of the homing
+process itself (or fundamentally does not have a homing process) then
+consider using a homing_override section in the config file. If you
+need to move a stepper for diagnostic or debugging purposes then
+consider adding a force_move section to the config file. See
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+for further details on these options.
+
 ### Why is the Z position_endstop set to 0.5 in the default configs?
 
 For cartesian style printers the Z position_endstop specifies how far
@@ -190,6 +264,85 @@ a higher speed. So, for a Z axis with a very precise step_distance the
 actual obtainable max_z_velocity may be smaller than what is
 configured in Marlin.
 
+### My TMC motor driver turns off in the middle of a print
+
+Short answer: Do not use the TMC2208 driver in "standalone mode" with
+Klipper! Do not use the TMC2224 driver in "stealthchop standalone
+mode" with Klipper!
+
+Long answer: Klipper implements very precise timing.
+
+![tmc2208](img/tmc2208.svg.png)
+
+In the above picture, if Klipper is requested to move along the red
+line and if each black line represents the nominal location to step a
+stepper, then in the middle of that movement Klipper will arrange to
+take a step, change the step direction, and then step back. Klipper
+can perform this step, direction change, and step back in a very small
+amount of time.
+
+It is our current understanding that the TMC2208 and TMC2224 will
+react poorly to this when they are in "stealthchop" mode. (It is not
+believed any other TMC drivers are impacted.) It is believed that when
+the driver sees the two step requests in a small time frame that it
+dramatically increases current in anticipation of high acceleration.
+That high current can trip the driver's internal "over current"
+detection which causes the driver to disable itself.
+
+This pattern of steps can occur on all stepper motors and on all
+robot kinematics.
+
+The TMC2208 and TMC2224 do work well with Klipper when run-time
+configuration mode is used (that is, when a wire is routed from the
+micro-controller to the PDN-UART pin and the printer config file has a
+corresponding [tmc2208] config section). When using run-time
+configuration, either configure the drivers to use "spreadcycle mode"
+or configure them to use "stealthchop mode" with a reasonable
+"stealthchop threshold". If one wishes to exclusively use
+"stealthchop" mode with run-time UART configuration then make sure the
+stealthchop_threshold is no more than about 10% greater than the
+maximum velocity of the given axis. It is speculated that with a
+reasonable stealthchop threshold, then if Klipper sends a "step,
+direction change, step back" sequence, the driver will briefly
+transition from stealthchop mode, to spreadcycle mode, and back to
+stealthchop mode, which should be harmless.
+
+### I keep getting random "Lost communication with MCU" errors
+
+This is commonly caused by hardware errors on the USB connection
+between the host machine and the micro-controller. Things to look for:
+- Use a good quality USB cable between the host machine and
+  micro-controller. Make sure the plugs are secure.
+- If using a Raspberry Pi, use a
+  [good quality power supply](https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md)
+  for the Raspberry Pi and use a
+  [good quality USB cable](https://www.raspberrypi.org/forums/viewtopic.php?p=589877#p589877)
+  to connect that power supply to the Pi. If you get "under voltage"
+  warnings from OctoPrint, this is related to the power supply and it
+  must be fixed.
+- Make sure the printer's power supply is not being overloaded. (Power
+  fluctuations to the micro-controller's USB chip may result in resets
+  of that chip.)
+- Verify stepper, heater, and other printer wires are not crimped or
+  frayed. (Printer movement may place stress on a faulty wire causing
+  it to lose contact, briefly short, or generate excessive noise.)
+- There have been reports of high USB noise when both the printer's
+  power supply and the host's 5V power supply are mixed. (If you find
+  that the micro-controller powers on when either the printer's power
+  supply is on or the USB cable is plugged in, then it indicates the
+  5V power supplies are being mixed.) It may help to configure the
+  micro-controller to use power from only one source. (Alternatively,
+  if the micro-controller board can not configure its power source,
+  one may modify a USB cable so that it does not carry 5V power
+  between the host and micro-controller.)
+
+### My Raspberry Pi keeps rebooting during prints
+
+This is most likely do to voltage fluctuations. Follow the same
+troubleshooting steps for a
+["Lost communication with MCU"](#i-keep-getting-random-lost-communication-with-mcu-errors)
+error.
+
 ### When I set "restart_method=command" my AVR device just hangs on a restart
 
 Some old versions of the AVR bootloader have a known bug in watchdog
@@ -202,8 +355,7 @@ power is removed).
 The workaround is to use a restart_method other than "command" or to
 flash an updated bootloader to the AVR device. Flashing a new
 bootloader is a one time step that typically requires an external
-programmer - search the web to find the instructions for your
+programmer - see [Bootloaders](Bootloaders.md) for further details.
-particular device.
 
 ### Will the heaters be left on if the Raspberry Pi crashes?
 
@@ -216,6 +368,79 @@ off all heaters and stepper motors.
 See the "config_digital_out" command in the
 [MCU commands](MCU_Commands.md) document for further details.
 
+In addition, the micro-controller software is configured with a
+minimum and maximum temperature range for each heater at startup (see
+the min_temp and max_temp parameters in the
+[example.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example.cfg)
+file for details). If the micro-controller detects that the
+temperature is outside of that range then it will also enter a
+"shutdown" state.
+
+Separately, the host software also implements code to check that
+heaters and temperature sensors are functioning correctly. See the
+"verify_heater" section of the
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+for further details.
+
+### How do I convert a Marlin pin number to a Klipper pin name?
+
+Short answer: In some cases one can use Klipper's `pin_map: arduino`
+feature. Otherwise, for "digital" pins, one method is to search for
+the requested pin in Marlin's fastio header files. The Atmega2560 and
+Atmega1280 chips use
+[fastio_1280.h](https://github.com/MarlinFirmware/Marlin/blob/1.1.9/Marlin/fastio_1280.h),
+while the Atmega644p and Atmega1284p chips use
+[fastio_644.h](https://github.com/MarlinFirmware/Marlin/blob/1.1.9/Marlin/fastio_644.h).
+For example, if you are looking to translate Marlin's digital pin
+number 23 on an atmega2560 then one could find the following line in
+Marlin's fastio_1280.h file:
+```
+#define DIO23_PIN PINA1
+```
+The `DIO23` indicates the line is for Marlin's pin 23 and the `PINA1`
+indicates the pin uses the hardware name of `PA1`. Klipper uses the
+hardware names (eg, `PA1`).
+
+Long answer: Klipper uses the standard pin names defined by the
+micro-controller. On the Atmega chips these hardware pins have names
+like `PA4`, `PC7`, or `PD2`.
+
+Long ago, the Arduino project decided to avoid using the standard
+hardware names in favor of their own pin names based on incrementing
+numbers - these Arduino names generally look like `D23` or `A14`. This
+was an unfortunate choice that has lead to a great deal of confusion.
+In particular the Arduino pin numbers frequently don't translate to
+the same hardware names. For example, `D21` is `PD0` on one common
+Arduino board, but is `PC7` on another common Arduino board.
+
+In order to support 3d printers based on real Arduino boards, Klipper
+supports the Arduino pin aliases. This feature is enabled by adding
+`pin_map: arduino` to the [mcu] section of the config file. When these
+aliases are enabled, Klipper understands pin names that start with the
+prefix "ar" (eg, Arduino pin `D23` is Klipper alias `ar23`) and the
+prefix "analog" (eg, Arduino pin `A14` is Klipper alias `analog14`).
+Klipper does not use the Arduino names directly because we feel a name
+like D7 is too easily confused with the hardware name PD7.
+
+Marlin primarily follows the Arduino pin numbering scheme.  However,
+Marlin supports a few chips that Arduino does not support and in some
+cases it supports pins that Arduino boards do not expose. In these
+cases, Marlin chose their own pin numbering scheme. Klipper does not
+support these custom pin numbers - check Marlin's fastio headers (see
+above) to translate these pin numbers to their standard hardware
+names.
+
+### How do I cancel an M109/M190 "wait for temperature" request?
+
+Navigate to the OctoPrint terminal tab and issue an M112 command in
+the terminal box. The M112 command will cause Klipper to enter into a
+"shutdown" state, and it will cause OctoPrint to disconnect from
+Klipper. Navigate to the OctoPrint connection area and click on
+"Connect" to cause OctoPrint to reconnect. Navigate back to the
+terminal tab and issue a FIRMWARE_RESTART command to clear the Klipper
+error state.  After completing this sequence, the previous heating
+request will be canceled and a new print may be started.
+
 ### How do I upgrade to the latest software?
 
 The general way to upgrade is to ssh into the Raspberry Pi and run:
@@ -230,6 +455,10 @@ Then one can recompile and flash the micro-controller code. For
 example:
 
 ```
+make menuconfig
+make clean
+make
+
 sudo service klipper stop
 make flash FLASH_DEVICE=/dev/ttyACM0
 sudo service klipper start
@@ -250,3 +479,25 @@ follow the full upgrade steps outlined above. Note that the RESTART
 and FIRMWARE_RESTART g-code commands do not load new software - the
 above "sudo service klipper restart" and "make flash" commands are
 needed for a software change to take effect.
+
+When upgrading the software, be sure to check the
+[config changes](Config_Changes.md) document for information on
+software changes that may require updates to your printer.cfg file.
+
+### Can I find out whether the printer has lost steps?
+
+In a way, yes. Home the printer, issue a `GET_POSITION` command, run
+your print, home again and issue another `GET_POSITION`. Then compare
+the values in the `mcu:` line.
+
+This might be helpful to tune settings like stepper motor currents,
+accelerations and speeds without needing to actually print something
+and waste filament: just run some high-speed moves in between the
+`GET_POSITION` commands.
+
+Note that endstop switches themselves tend to trigger at slightly
+different positions, so a difference of a couple of microsteps is
+likely the result of endstop inaccuracies. A stepper motor itself can
+only lose steps in increments of 4 full steps. (So, if one is using 16
+microsteps, then a lost step on the stepper would result in the "mcu:"
+step counter being off by a multiple of 64 microsteps.)

docs/Features.md

@@ -20,12 +20,21 @@ Klipper has several compelling features:
   stepper event timing remains precise even at high speeds which
   improves overall stability.
 
+* Klipper supports printers with multiple micro-controllers. For
+  example, one micro-controller could be used to control an extruder,
+  while another controls the printer's heaters, while a third controls
+  the rest of the printer. The Klipper host software implements clock
+  synchronization to account for clock drift between
+  micro-controllers. No special code is needed to enable multiple
+  micro-controllers - it just requires a few extra lines in the config
+  file.
+
 * Configuration via simple config file. There's no need to reflash the
   micro-controller to change a setting. All of Klipper's configuration
   is stored in a standard config file which can be easily edited. This
   makes it easier to setup and maintain the hardware.
 
-* Portable code. Klipper works on both ARM and AVR
+* Portable code. Klipper works on ARM, AVR, and PRU based
   micro-controllers. Existing "reprap" style printers can run Klipper
   without hardware modification - just add a Raspberry Pi. Klipper's
   internal code layout makes it easier to support other
@@ -33,37 +42,22 @@ Klipper has several compelling features:
 
 * Simpler code. Klipper uses a very high level language (Python) for
   most code. The kinematics algorithms, the G-code parsing, the
-  heating and thermistor algorithms, etc. are all written in
+  heating and thermistor algorithms, etc. are all written in Python.
-  Python. This makes it easier to develop new functionality.
+  This makes it easier to develop new functionality.
 
-* Advanced features:
+* Klipper uses an "iterative solver" to calculate precise step times
-  * Klipper implements the "pressure advance" algorithm for
+  from simple kinematic equations. This makes porting Klipper to new
-    extruders. When properly tuned, pressure advance reduces extruder
+  types of robots easier and it keeps timing precise even with complex
-    ooze.
+  kinematics (no "line segmentation" is needed).
-  * Klipper supports printers with multiple micro-controllers. For
-    example, one micro-controller could be used to control an
-    extruder, while another could control the printer's heaters, while
-    a third controls the rest of the printer. The Klipper host
-    software implements clock synchronization to account for clock
-    drift between micro-controllers. No special code is needed to
-    enable multiple micro-controllers - it just requires a few extra
-    lines in the config file.
-  * Klipper also implements a novel "stepper phase endstop" algorithm
-    that can dramatically improve the accuracy of typical endstop
-    switches. When properly tuned it can improve a print's first layer
-    bed adhesion.
-  * Support for limiting the top speed of short "zigzag" moves to
-    reduce printer vibration and noise. See the
-    [kinematics](Kinematics.md) document for more information.
 
-To get started with Klipper, read the [installation](Installation.md)
+Additional features
-guide.
+===================
-
-Common features supported by Klipper
-====================================
 
 Klipper supports many standard 3d printer features:
 
+* Klipper implements the "pressure advance" algorithm for extruders.
+  When properly tuned, pressure advance reduces extruder ooze.
+
 * Works with Octoprint. This allows the printer to be controlled using
   a regular web-browser. The same Raspberry Pi that runs Klipper can
   also run Octoprint.
@@ -72,16 +66,62 @@ Klipper supports many standard 3d printer features:
   typical "slicers" are supported. One may continue to use Slic3r,
   Cura, etc. with Klipper.
 
-* Constant speed acceleration support. All printer moves will
+* Support for multiple extruders. Extruders with shared heaters and
-  gradually accelerate from standstill to cruising speed and then
+  extruders on independent carriages (IDEX) are also supported.
-  decelerate back to a standstill.
 
-* "Look-ahead" support. The incoming stream of G-Code movement
+* Support for cartesian, delta, and corexy style printers.
-  commands are queued and analyzed - the acceleration between
+
+* Automatic bed leveling support. Klipper can be configured for basic
+  bed tilt detection or full mesh bed leveling. If the bed uses
+  multiple Z steppers then Klipper can also level by independently
+  manipulating the Z steppers. Most Z height probes are supported,
+  including servo activated probes.
+
+* Automatic delta calibration support. The calibration tool can
+  perform basic height calibration as well as an enhanced X and Y
+  dimension calibration. The calibration can be done with a Z height
+  probe or via manual probing.
+
+* Support for common temperature sensors (eg, common thermistors,
+  AD595, AD849x, PT100, MAX6675, MAX31855, MAX31856, MAX31865). Custom
+  thermistors and custom analog temperature sensors can also be
+  configured.
+
+* Basic thermal heater protection enabled by default.
+
+* Support for standard fans, nozzle fans, and temperature controlled
+  fans. No need to keep fans running when the printer is idle.
+
+* Support for run-time configuration of TMC2130, TMC2208/TMC2224,
+  TMC2209, TMC2660, and TMC5160 stepper motor drivers. There is also
+  support for current control of traditional stepper drivers via
+  AD5206, MCP4451, MCP4728, MCP4018, and PWM pins.
+
+* Support for common LCD displays attached directly to the printer. A
+  default menu is also available.
+
+* Constant acceleration and "look-ahead" support. All printer moves
+  will gradually accelerate from standstill to cruising speed and then
+  decelerate back to a standstill. The incoming stream of G-Code
+  movement commands are queued and analyzed - the acceleration between
   movements in a similar direction will be optimized to reduce print
   stalls and improve overall print time.
 
-* Support for cartesian, delta, and corexy style printers.
+* Klipper implements a "stepper phase endstop" algorithm that can
+  improve the accuracy of typical endstop switches. When properly
+  tuned it can improve a print's first layer bed adhesion.
+
+* Support for limiting the top speed of short "zigzag" moves to reduce
+  printer vibration and noise. See the [kinematics](Kinematics.md)
+  document for more information.
+
+* Sample configuration files are available for many common printers.
+  Check the
+  [config directory](https://github.com/KevinOConnor/klipper/tree/master/config/)
+  for a list.
+
+To get started with Klipper, read the [installation](Installation.md)
+guide.
 
 Step Benchmarks
 ===============
@@ -90,13 +130,24 @@ Below are the results of stepper performance tests. The numbers shown
 represent total number of steps per second on the micro-controller.
 
 | Micro-controller                | Fastest step rate | 3 steppers active |
-| ----------------- | ----------------- | ----------------- |
+| ------------------------------- | ----------------- | ----------------- |
-| 20Mhz AVR         | 189K              | 125K              |
+| 16Mhz AVR                       | 154K              | 102K              |
-| 16Mhz AVR         | 151K              | 100K              |
+| 20Mhz AVR                       | 192K              | 127K              |
-| Arduino Due (ARM) | 382K              | 337K              |
+| Arduino Zero (SAMD21)           | 234K              | 217K              |
-| Beaglebone PRU    | 689K              | 689K              |
+| "Blue Pill" (STM32F103)         | 387K              | 360K              |
+| Arduino Due (SAM3X8E)           | 438K              | 438K              |
+| Duet2 Maestro (SAM4S8C)         | 564K              | 564K              |
+| Smoothieboard (LPC1768)         | 574K              | 574K              |
+| Smoothieboard (LPC1769)         | 661K              | 661K              |
+| Beaglebone PRU                  | 680K              | 680K              |
+| Duet2 Wifi/Eth (SAM4E8E)        | 686K              | 686K              |
+| Adafruit Metro M4 (SAMD51)      | 733K              | 694K              |
+| BigTreeTech SKR Pro (STM32F407) | 922K              | 711K              |
 
 On AVR platforms, the highest achievable step rate is with just one
-stepper stepping. On the Due, the highest step rate is with two
+stepper stepping. On the SAMD21 and STM32F103 the highest step rate is
-simultaneous steppers stepping. On the PRU, the highest step rate is
+with two simultaneous steppers stepping. On the SAM3X8E, SAM4S8C,
-with three simultaneous steppers.
+SAM4E8E, LPC176x, and PRU the highest step rate is with three
+simultaneous steppers. On the SAMD51 and STM32F4 the highest step rate
+is with four simultaneous steppers. (Further details on the benchmarks
+are available in the [Benchmarks document](Benchmarks.md).)

docs/G-Codes.md

@@ -15,17 +15,21 @@ Klipper supports the following standard G-Code commands:
 - Set position: `G92 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>]`
 - Set speed factor override percentage: `M220 S<percent>`
 - Set extrude factor override percentage: `M221 S<percent>`
+- Set acceleration: `M204 S<value>`
 - Get extruder temperature: `M105`
 - Set extruder temperature: `M104 [T<index>] [S<temperature>]`
 - Set extruder temperature and wait: `M109 [T<index>] S<temperature>`
+  - Note: M109 always waits for temperature to settle at requested
+    value
 - Set bed temperature: `M140 [S<temperature>]`
 - Set bed temperature and wait: `M190 S<temperature>`
+  - Note: M190 always waits for temperature to settle at requested
+    value
 - Set fan speed: `M106 S<value>`
 - Turn fan off: `M107`
 - Emergency stop: `M112`
 - Get current position: `M114`
 - Get firmware version: `M115`
-- Set home offset: `M206 [X<pos>] [Y<pos>] [Z<pos>]`
 
 For further details on the above commands see the
 [RepRap G-Code documentation](http://reprap.org/wiki/G-code).
@@ -36,6 +40,12 @@ their standard configurations. It is not a goal to support every
 possible G-Code command. Instead, Klipper prefers human readable
 ["extended G-Code commands"](#extended-g-code-commands).
 
+If one requires a less common G-Code command then it may be possible
+to implement it with a custom Klipper gcode_macro (see
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+for details). For example, one might use this to implement: `G10`,
+`G11`, `G12`, `G29`, `G30`, `G31`, `M42`, `M80`, `M81`, etc.
+
 ## G-Code SD card commands
 
 Klipper also supports the following standard G-Code commands if the
@@ -48,6 +58,21 @@ Klipper also supports the following standard G-Code commands if the
 - Set SD position: `M26 S<offset>`
 - Report SD print status: `M27`
 
+## G-Code display commands
+
+The following standard G-Code commands are available if a "display"
+config section is enabled:
+- Display Message: `M117 <message>`
+- Set build percentage: `M73 P<percent>`
+
+## Other available G-Code commands
+
+The following standard G-Code commands are currently available, but
+using them is not recommended:
+- Offset axes: `M206 [X<offset>] [Y<offset>] [Z<offset>]` (Use
+  SET_GCODE_OFFSET instead.)
+- Get Endstop Status: `M119` (Use QUERY_ENDSTOPS instead.)
+
 # Extended G-Code Commands
 
 Klipper uses "extended" G-Code commands for general configuration and
@@ -64,6 +89,38 @@ The following standard commands are supported:
   verify that an endstop is working correctly.
 - `GET_POSITION`: Return information on the current location of the
   toolhead.
+- `SET_GCODE_OFFSET [X=<pos>|X_ADJUST=<adjust>]
+  [Y=<pos>|Y_ADJUST=<adjust>] [Z=<pos>|Z_ADJUST=<adjust>]
+  [MOVE=1 [MOVE_SPEED=<speed>]]`: Set a positional offset to apply to
+  future G-Code commands. This is commonly used to virtually change
+  the Z bed offset or to set nozzle XY offsets when switching
+  extruders. For example, if "SET_GCODE_OFFSET Z=0.2" is sent, then
+  future G-Code moves will have 0.2mm added to their Z height. If the
+  X_ADJUST style parameters are used, then the adjustment will be
+  added to any existing offset (eg, "SET_GCODE_OFFSET Z=-0.2" followed
+  by "SET_GCODE_OFFSET Z_ADJUST=0.3" would result in a total Z offset
+  of 0.1). If "MOVE=1" is specified then a toolhead move will be
+  issued to apply the given offset (otherwise the offset will take
+  effect on the next absolute G-Code move that specifies the given
+  axis). If "MOVE_SPEED" is specified then the toolhead move will be
+  performed with the given speed (in mm/s); otherwise the toolhead
+  move will use the last specified G-Code speed.
+- `SAVE_GCODE_STATE [NAME=<state_name>]`: Save the current
+  g-code coordinate parsing state. Saving and restoring the g-code
+  state is useful in scripts and macros. This command saves the
+  current g-code absolute coordinate mode (G90/G91), absolute extrude
+  mode (M82/M83), origin (G92), offset (SET_GCODE_OFFSET), speed
+  override (M220), extruder override (M221), move speed, current XYZ
+  position, and relative extruder "E" position. If NAME is provided it
+  allows one to name the saved state to the given string. If NAME is
+  not provided it defaults to "default".
+- `RESTORE_GCODE_STATE [NAME=<state_name>]
+  [MOVE=1 [MOVE_SPEED=<speed>]]`: Restore a state previously saved via
+  SAVE_GCODE_STATE. If "MOVE=1" is specified then a toolhead move will
+  be issued to move back to the previous XYZ position. If "MOVE_SPEED"
+  is specified then the toolhead move will be performed with the given
+  speed (in mm/s); otherwise the toolhead move will use the restored
+  g-code speed.
 - `PID_CALIBRATE HEATER=<config_name> TARGET=<temperature>
   [WRITE_FILE=1]`: Perform a PID calibration test. The specified
   heater will be enabled until the specified target temperature is
@@ -71,6 +128,48 @@ The following standard commands are supported:
   cycles. If the WRITE_FILE parameter is enabled, then the file
   /tmp/heattest.txt will be created with a log of all temperature
   samples taken during the test.
+- `TURN_OFF_HEATERS`: Turn off all heaters.
+- `SET_VELOCITY_LIMIT [VELOCITY=<value>] [ACCEL=<value>]
+  [ACCEL_TO_DECEL=<value>] [SQUARE_CORNER_VELOCITY=<value>]`: Modify
+  the printer's velocity limits. Note that one may only set values
+  less than or equal to the limits specified in the config file.
+- `SET_HEATER_TEMPERATURE HEATER=<heater_name> [TARGET=<target_temperature>]`:
+  Sets the target temperature for a heater. If a target temperature is
+  not supplied, the target is 0.
+- `SET_PRESSURE_ADVANCE [EXTRUDER=<config_name>] [ADVANCE=<pressure_advance>]
+  [ADVANCE_LOOKAHEAD_TIME=<pressure_advance_lookahead_time>]`:
+  Set pressure advance parameters. If EXTRUDER is not specified, it
+  defaults to the active extruder.
+- `STEPPER_BUZZ STEPPER=<config_name>`: Move the given stepper forward
+  one mm and then backward one mm, repeated 10 times. This is a
+  diagnostic tool to help verify stepper connectivity.
+- `MANUAL_PROBE [SPEED=<speed>]`: Run a helper script useful for
+  measuring the height of the nozzle at a given location. If SPEED is
+  specified, it sets the speed of TESTZ commands (the default is
+  5mm/s). During a manual probe, the following additional commands are
+  available:
+  - `ACCEPT`: This command accepts the current Z position and
+  concludes the manual probing tool.
+  - `ABORT`: This command terminates the manual probing tool.
+  - `TESTZ Z=<value>`: This command moves the nozzle up or down by the
+    amount specified in "value". For example, `TESTZ Z=-.1` would move
+    the nozzle down .1mm while `TESTZ Z=.1` would move the nozzle up
+    .1mm. The value may also be `+`, `-`, `++`, or `--` to move the
+    nozzle up or down an amount relative to previous attempts.
+- `Z_ENDSTOP_CALIBRATE [SPEED=<speed>]`: Run a helper script useful
+  for calibrating a Z position_endstop config setting. See the
+  MANUAL_PROBE command for details on the parameters and the
+  additional commands available while the tool is active.
+- `TUNING_TOWER COMMAND=<command> PARAMETER=<name> START=<value>
+  FACTOR=<value> [BAND=<value>]`: A tool for tuning a parameter on
+  each Z height during a print. The tool will run the given COMMAND
+  with the given PARAMETER assigned to the value using the formula
+  `value = start + factor * z_height`. If BAND is provided then the
+  adjustment will only be made every BAND millimeters of z height - in
+  that case the formula used is `value = start + factor *
+  ((floor(z_height / band) + .5) * band)`.
+- `SET_IDLE_TIMEOUT [TIMEOUT=<timeout>]`:  Allows the user to set the
+  idle timeout (in seconds).
 - `RESTART`: This will cause the host software to reload its config
   and perform an internal reset. This command will not clear error
   state from the micro-controller (see FIRMWARE_RESTART) nor will it
@@ -78,49 +177,190 @@ The following standard commands are supported:
   [the FAQ](FAQ.md#how-do-i-upgrade-to-the-latest-software)).
 - `FIRMWARE_RESTART`: This is similar to a RESTART command, but it
   also clears any error state from the micro-controller.
+- `SAVE_CONFIG`: This command will overwrite the main printer config
+  file and restart the host software. This command is used in
+  conjunction with other calibration commands to store the results of
+  calibration tests.
 - `STATUS`: Report the Klipper host software status.
 - `HELP`: Report the list of available extended G-Code commands.
 
+## G-Code Macro Commands
+
+The following command is available when a "gcode_macro" config section
+is enabled:
+- `SET_GCODE_VARIABLE MACRO=<macro_name> VARIABLE=<name>
+  VALUE=<value>`: This command allows one to change the value of a
+  gcode_macro variable at run-time. The provided VALUE is parsed as a
+  Python literal.
+
 ## Custom Pin Commands
 
 The following command is available when an "output_pin" config section
 is enabled:
 - `SET_PIN PIN=config_name VALUE=<value>`
 
+## Neopixel and Dotstar Commands
+
+The following command is available when "neopixel" or "dotstar" config
+sections are enabled:
+- `SET_LED LED=<config_name> INDEX=<index> RED=<value> GREEN=<value>
+  BLUE=<value>`: This sets the LED output. Each color <value> must be
+  between 0.0 and 1.0. If multiple LED chips are daisy-chained then
+  one may specify INDEX to alter the color of just the given chip (1
+  for the first chip, 2 for the second, etc.). If INDEX is not
+  provided then all LEDs in the daisy-chain will be set to the
+  provided color.
+
 ## Servo Commands
 
 The following commands are available when a "servo" config section is
 enabled:
-- `SET_SERVO SERVO=config_name WIDTH=<seconds>`
+- `SET_SERVO SERVO=config_name [WIDTH=<seconds>] [ENABLE=<0|1>]`
-- `SET_SERVO SERVO=config_name ANGLE=<degrees>`
+- `SET_SERVO SERVO=config_name [ANGLE=<degrees>] [ENABLE=<0|1>]`
+
+## Manual stepper Commands
+
+The following command is available when a "manual_stepper" config
+section is enabled:
+- `MANUAL_STEPPER STEPPER=config_name [ENABLE=[0|1]]
+  [SET_POSITION=<pos>] [SPEED=<speed>] [ACCEL=<accel>]
+  [MOVE=<pos> [STOP_ON_ENDSTOP=1]]`: This command will alter the state
+  of the stepper. Use the ENABLE parameter to enable/disable the
+  stepper. Use the SET_POSITION parameter to force the stepper to
+  think it is at the given position. Use the MOVE parameter to request
+  a movement to the given position. If SPEED and/or ACCEL is specified
+  then the given values will be used instead of the defaults specified
+  in the config file. If an ACCEL of zero is specified then no
+  acceleration will be preformed. If STOP_ON_ENDSTOP is specified then
+  the move will end early should the endstop report as triggered (use
+  STOP_ON_ENDSTOP=-1 to stop early should the endstop report not
+  triggered).
 
 ## Probe
 
 The following commands are available when a "probe" config section is
 enabled:
-- `PROBE`: Move the nozzle downwards until the probe triggers.
+- `PROBE [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
+  [SAMPLE_RETRACT_DIST=<mm>] [SAMPLES_TOLERANCE=<mm>]
+  [SAMPLES_TOLERANCE_RETRIES=<count>]
+  [SAMPLES_RESULT=median|average]`: Move the nozzle downwards until
+  the probe triggers. If any of the optional parameters are provided
+  they override their equivalent setting in the probe config section
+  (see
+  [example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+  for details).
 - `QUERY_PROBE`: Report the current status of the probe ("triggered"
   or "open").
+- `PROBE_ACCURACY [PROBE_SPEED=<mm/s>] [SAMPLES=<count>]
+  [SAMPLE_RETRACT_DIST=<mm>]`: Calculate the maximum, minimum,
+  average, median, and standard deviation of multiple probe
+  samples. By default, 10 SAMPLES are taken. Otherwise the optional
+  parameters default to their equivalent setting in the probe config
+  section.
+- `PROBE_CALIBRATE [SPEED=<speed>] [<probe_parameter>=<value>]`: Run a
+  helper script useful for calibrating the probe's z_offset. See the
+  PROBE command for details on the optional probe parameters. See the
+  MANUAL_PROBE command for details on the SPEED parameter and the
+  additional commands available while the tool is active.
+
+## BLTouch
+
+The following command is available when a "bltouch" config section is
+enabled:
+- `BLTOUCH_DEBUG COMMAND=<command>`: This sends a command to the
+  BLTouch. It may be useful for debugging. Available commands are:
+  pin_down, touch_mode, pin_up, self_test, reset.
+
+See [Working with the BL-Touch](BLTouch.md) for more details.
 
 ## Delta Calibration
 
 The following commands are available when the "delta_calibrate" config
 section is enabled:
-- `DELTA_CALIBRATE`: This command will probe seven points on the bed
+- `DELTA_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`: This
-  and recommend updated endstop positions, tower angles, and radius.
+  command will probe seven points on the bed and recommend updated
-  - `NEXT`: If manual bed probing is enabled, then one can use this
+  endstop positions, tower angles, and radius. See the PROBE command
-    command to move to the next probing point during a DELTA_CALIBRATE
+  for details on the optional probe parameters. If METHOD=manual is
-    operation.
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+- `DELTA_ANALYZE`: This command is used during enhanced delta
+  calibration. See [Delta Calibrate](Delta_Calibrate.md) for details.
 
 ## Bed Tilt
 
 The following commands are available when the "bed_tilt" config
 section is enabled:
-- `BED_TILT_CALIBRATE`: This command will probe the points specified
+- `BED_TILT_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`:
-  in the config and then recommend updated x and y tilt adjustments.
+  This command will probe the points specified in the config and then
-  - `NEXT`: If manual bed probing is enabled, then one can use this
+  recommend updated x and y tilt adjustments. See the PROBE command
-    command to move to the next probing point during a
+  for details on the optional probe parameters. If METHOD=manual is
-    BED_TILT_CALIBRATE operation.
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+
+## Mesh Bed Leveling
+
+The following commands are available when the "bed_mesh" config
+section is enabled:
+- `BED_MESH_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`:
+  This command probes the bed using generated points specified by the
+  parameters in the config. After probing, a mesh is generated and
+  z-movement is adjusted according to the mesh. See the PROBE command
+  for details on the optional probe parameters. If METHOD=manual is
+  specified then the manual probing tool is activated - see the
+  MANUAL_PROBE command above for details on the additional commands
+  available while this tool is active.
+- `BED_MESH_OUTPUT`: This command outputs the current probed z values
+  and current mesh values to the terminal.
+- `BED_MESH_MAP`: This command probes the bed in a similar fashion
+  to BED_MESH_CALIBRATE, however no mesh is generated.  Instead,
+  the probed z values are serialized to json and output to the
+  terminal.  This allows octoprint plugins to easily capture the
+  data and generate maps approximating the bed's surface.  Note
+  that although no mesh is generated, any currently stored mesh
+  will be cleared.
+- `BED_MESH_CLEAR`: This command clears the mesh and removes all
+  z adjustment.  It is recommended to put this in your end-gcode.
+- `BED_MESH_PROFILE LOAD=<name> SAVE=<name> REMOVE=<name>`: This
+  command provides profile management for mesh state.  LOAD will
+  restore the mesh state from the profile matching the supplied name.
+  SAVE will save the current mesh state to a profile matching the
+  supplied name.  Remove will delete the profile matching the
+  supplied name from persistent memory.  Note that after SAVE or
+  REMOVE operations have been run the SAVE_CONFIG gcode must be run
+  to make the changes to peristent memory permanent.
+
+## Bed Screws Helper
+
+The following commands are available when the "bed_screws" config
+section is enabled:
+- `BED_SCREWS_ADJUST`: This command will invoke the bed screws
+  adjustment tool. It will command the nozzle to different locations
+  (as defined in the config file) and allow one to make adjustments to
+  the bed screws so that the bed is a constant distance from the
+  nozzle.
+
+## Bed Screws Tilt adjust Helper
+
+The following commands are available when the "screws_tilt_adjust"
+config section is enabled:
+- `SCREWS_TILT_CALCULATE [<probe_parameter>=<value>]`: This command
+  will invoke the bed screws adjustment tool. It will command the
+  nozzle to different locations (as defined in the config file)
+  probing the z height and calculate the number of knob turns to
+  adjust the bed level. See the PROBE command for details on the
+  optional probe parameters.
+  IMPORTANT: You MUST always do a G28 before using this command.
+
+## Z Tilt
+
+The following commands are available when the "z_tilt" config section
+is enabled:
+- `Z_TILT_ADJUST [<probe_parameter>=<value>]`: This command will probe
+  the points specified in the config and then make independent
+  adjustments to each Z stepper to compensate for tilt. See the PROBE
+  command for details on the optional probe parameters.
 
 ## Dual Carriages
 
@@ -129,3 +369,164 @@ section is enabled:
 - `SET_DUAL_CARRIAGE CARRIAGE=[0|1]`: This command will set the active
   carriage. It is typically invoked from the activate_gcode and
   deactivate_gcode fields in a multiple extruder configuration.
+
+## TMC2130, TMC2660, TMC2208, TMC2209 and TMC5160
+
+The following commands are available when any of the "tmcXXXX" config sections is enabled:
+- `DUMP_TMC STEPPER=<name>`: This command will read the TMC driver
+  registers and report their values.
+- `INIT_TMC STEPPER=<name>`: This command will intitialize the TMC
+  registers. Needed to re-enable the driver if power to the chip is
+  turned off then back on.
+- `SET_TMC_CURRENT STEPPER=<name> CURRENT=<amps> HOLDCURRENT=<amps>`:
+  This will adjust the run and hold currents of the TMC driver.
+  HOLDCURRENT is applicable only to the tmc2130, tmc2208, tmc2209 and tmc5160.
+- `SET_TMC_FIELD STEPPER=<name> FIELD=<field> VALUE=<value>`: This will
+  alter the value of the specified register field of the TMC driver.
+  This command is intended for low-level diagnostics and debugging only because
+  changing the fields during run-time can lead to undesired and potentially
+  dangerous behavior of your printer. Permanent changes should be made using
+  the printer configuration file instead. No sanity checks are performed for the
+  given values.
+
+## Endstop adjustments by stepper phase
+
+The following commands are available when an "endstop_phase" config
+section is enabled:
+- `ENDSTOP_PHASE_CALIBRATE [STEPPER=<config_name>]`: If no STEPPER
+  parameter is provided then this command will reports statistics on
+  endstop stepper phases during past homing operations. When a STEPPER
+  parameter is provided it arranges for the given endstop phase
+  setting to be written to the config file (in conjunction with the
+  SAVE_CONFIG command).
+
+## Force movement
+
+The following commands are available when the "force_move" config
+section is enabled:
+- `FORCE_MOVE STEPPER=<config_name> DISTANCE=<value> VELOCITY=<value>
+  [ACCEL=<value>]`: This command will forcibly move the given stepper
+  the given distance (in mm) at the given constant velocity (in
+  mm/s). If ACCEL is specified and is greater than zero, then the
+  given acceleration (in mm/s^2) will be used; otherwise no
+  acceleration is performed. No boundary checks are performed; no
+  kinematic updates are made; other parallel steppers on an axis will
+  not be moved. Use caution as an incorrect command could cause
+  damage! Using this command will almost certainly place the low-level
+  kinematics in an incorrect state; issue a G28 afterwards to reset
+  the kinematics. This command is intended for low-level diagnostics
+  and debugging.
+- `SET_KINEMATIC_POSITION [X=<value>] [Y=<value>] [Z=<value>]`: Force
+  the low-level kinematic code to believe the toolhead is at the given
+  cartesian position. This is a diagnostic and debugging command; use
+  SET_GCODE_OFFSET and/or G92 for regular axis transformations. If an
+  axis is not specified then it will default to the position that the
+  head was last commanded to. Setting an incorrect or invalid position
+  may lead to internal software errors. This command may invalidate
+  future boundary checks; issue a G28 afterwards to reset the
+  kinematics.
+
+## Send message (respond) to host
+
+The following commands are availabe when the "respond" config section is
+enabled.
+  - `M118 <message>`: echo the message prepended with the configured default
+    prefix (or `echo: ` if no prefix is configured).
+  - `RESPOND MSG="<message>"`: echo the message prepended with the configured default
+    prefix (or `echo: ` if no prefix is configured).
+  - `RESPOND TYPE=echo MSG="<message>"`: echo the message prepended with `echo: `.
+  - `RESPOND TYPE=command MSG="<message>"`: echo the message prepended with `// `.
+    Octopint can be configured to respond to these messages (e.g.
+    `RESPOND TYPE=command MSG=action:pause`).
+  - `RESPOND TYPE=error MSG="<message>"`: echo the message prepended with `!! `.
+  - `RESPOND PREFIX=<prefix> MSG="<message>"`: echo the message prepended with `<prefix>`
+    (The `PREFIX` parameter will take priority over the `TYPE` parameter)
+
+## Pause Resume
+
+The following commands are available when the "pause_resume" config section
+is enabled:
+  - `PAUSE`:  Pauses the current print.  The current position is captured for
+  restoration upon resume.
+  - `RESUME [VELOCITY=<value>]`: Resumes the print from a pause, first restoring
+  the previously captured position.  The VELOCITY parameter determines the speed
+  at which the tool should return to the original captured position.
+  - `CLEAR_PAUSE`:  Clears the current paused state without resuming the print.
+  This is useful if one decides to cancel a print after a PAUSE.  It is recommended
+  to add this to your start gcode to make sure the paused state is fresh for each
+  print.
+
+## Filament Sensor
+
+The following command is available when the "filament_switch_sensor" config
+section is enabled.
+ - `QUERY_FILAMENT_SENSOR SENSOR=<sensor_name>`: Queries the current status of
+  the filament sensor.  The data displayed on the terminal will depend on the
+  sensor type defined in the confguration.
+ - `SET_FILAMENT_SENSOR SENSOR=<sensor_name> ENABLE=[0|1]`:  Sets the
+   filament sensor on/off.  If ENABLE is set to 0, the filament sensor will
+   be disabled, if set to 1 it is enabled.
+
+## Firmware Retraction
+
+The following commands are available when the "firmware_retraction"
+config section is enabled.  These commands allow you to utilise the
+firmware retraction feature available in many slicers, to reduce
+stringing during non-extrusion moves from one part of the print to
+another.  Appropriately configuring pressure advance reduces the length
+of retraction required.
+ - `SET_RETRACTION [RETRACT_LENGTH=<mm>] [RETRACT_SPEED=<mm/s>]
+   [UNRETRACT_EXTRA_LENGTH=<mm>] [UNRETRACT_SPEED=<mm/s>]`: Adjust the
+   parameters used by firmware retraction. RETRACT_LENGTH determines
+   the length of filament to retract and unretract. The speed of
+   retraction is adjusted via RETRACT_SPEED, and is typically set
+   relatively high. The speed of unretraction is adjusted via
+   UNRETRACT_SPEED, and is not particularly critical, although often
+   lower than RETRACT_SPEED. In some cases it is useful to add a small
+   amount of additional length on unretraction, and this is set via
+   UNRETRACT_EXTRA_LENGTH. SET_RETRACTION is commonly set as part of
+   slicer per-filament configuration, as different filaments require
+   different parameter settings.
+ - `GET_RETRACTION`: Queries the current parameters used by firmware
+   retraction and displays them on the terminal.
+ - `G10`: Retracts the extruder using the currently configured
+   parameters.
+ - `G11`: Unretracts the extruder using the currently configured
+   parameters.
+
+## Skew Correction
+
+The following commands are available when the "skew_correction" config
+section is enabled.
+  - `SET_SKEW [XY=<ac_length,bd_length,ad_length>] [XZ=<ac,bd,ad>]
+    [YZ=<ac,bd,ad>] [CLEAR=<0|1>]`:  Configures the [skew_correction] module
+    with measurements (in mm) taken from a calibration print.  One may
+    enter measurements for any combination of planes, planes not entered will
+    retain their current value.  If `CLEAR=1` is entered then all skew
+    correction will be disabled.
+  - `GET_CURRENT_SKEW`: Reports the current printer skew for each plane in
+    both radians and degrees.  The skew is calculated based on parameters
+    provided via the `SET_SKEW` gcode.
+  - `CALC_MEASURED_SKEW [AC=<ac_length>] [BD=<bd_length>] [AD=<ad_length>]`:
+    Calculates and reports the skew (in radians and degrees) based on a
+    measured print.  This can be useful for determining the printer's current
+    skew after correction has been applied.  It may also be useful before
+    correction is applied to determine if skew correction is necessary.   See
+    skew_correction.md for details on skew calibration objects and
+    measurements.
+  - `SKEW_PROFILE [LOAD=<name>] [SAVE=<name>] [REMOVE=<name>]`: Profile
+    management for skew_correction.  LOAD will restore skew state from the
+    profile matching the supplied name. SAVE will save the current skew state
+    to a profile matching the supplied name.  Remove will delete the profile
+    matching the supplied name from persistent memory.  Note that after SAVE
+    or REMOVE operations have been run the SAVE_CONFIG gcode must be run
+    to make the changes to peristent memory permanent.
+
+## Delayed GCode
+
+The following command is enabled if a [delayed_gcode] config section has
+been enabled:
+  - `UPDATE_DELAYED_GCODE [ID=<name>] [DURATION=<seconds>]`:  Updates the
+    delay duration for the identified [delayed_gcode] and starts the timer
+    for gcode execution.  A value of 0 will cancel a pending delayed gcode
+    from executing.

docs/Installation.md

@@ -5,19 +5,20 @@ Raspberry Pi 2 or Raspberry Pi 3 computer be used as the host machine
 [FAQ](FAQ.md#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
 for other machines).
 
-Klipper currently supports Atmel ATmega based micro-controllers,
+Klipper currently supports a number of Atmel ATmega based
-Arduino Due (Atmel SAM3x8e ARM micro-controller), and
+micro-controllers,
+[ARM based micro-controllers](Features.md#step-benchmarks), and
 [Beaglebone PRU](beaglebone.md) based printers.
 
 Prepping an OS image
 ====================
 
 Start by installing [OctoPi](https://github.com/guysoft/OctoPi) on the
-Raspberry Pi computer. Use OctoPi v0.14.0 or later - see the
+Raspberry Pi computer. Use OctoPi v0.16.0 or later - see the
 [octopi releases](https://github.com/guysoft/OctoPi/releases) for
 release information. One should verify that OctoPi boots and that the
 OctoPrint web server works. After connecting to the OctoPrint web
-page, follow the prompt to upgrade OctoPrint to v1.3.5 or later.
+page, follow the prompt to upgrade OctoPrint to v1.3.11 or later.
 
 After installing OctoPi and upgrading OctoPrint, it will be necessary
 to ssh into the target machine to run a handful of system commands. If
@@ -50,42 +51,65 @@ make menuconfig
 ```
 
 Select the appropriate micro-controller and review any other options
-provided. For boards with serial ports, the default baud rate is
+provided. Once configured, run:
-250000 (see the [FAQ](FAQ.md#how-do-i-change-the-serial-baud-rate) if
-changing). Once configured, run:
 
 ```
 make
 ```
 
-Finally, for common micro-controllers, the code can be flashed with:
+It is necessary to determine the serial port connected to the
+micro-controller. For micro-controllers that connect via USB, run the
+following:
+
+```
+ls /dev/serial/by-id/*
+```
+
+It should report something similar to the following:
+
+```
+/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+```
+
+It's common for each printer to have its own unique serial port name.
+This unique name will be used when flashing the micro-controller. It's
+possible there may be multiple lines in the above output - if so,
+choose the line corresponding to the micro-controller (see the
+[FAQ](FAQ.md#wheres-my-serial-port) for more information).
+
+For common micro-controllers, the code can be flashed with something
+similar to:
 
 ```
 sudo service klipper stop
-make flash FLASH_DEVICE=/dev/ttyACM0
+make flash FLASH_DEVICE=/dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
 sudo service klipper start
 ```
 
+Be sure to update the FLASH_DEVICE with the printer's unique serial
+port name.
+
 When flashing for the first time, make sure that OctoPrint is not
 connected directly to the printer (from the OctoPrint web page, under
-the "Connection" section, click "Disconnect"). The most common
+the "Connection" section, click "Disconnect").
-communication device is **/dev/ttyACM0** - see the
-[FAQ](FAQ.md#wheres-my-serial-port) for other possibilities.
 
 Configuring OctoPrint to use Klipper
 ====================================
 
 The OctoPrint web server needs to be configured to communicate with
 the Klipper host software. Using a web browser, login to the OctoPrint
-web page, and navigate to the Settings tab. Then configure the
+web page and then configure the following items:
-following items:
 
-Under "Serial Connection" in "Additional serial ports" add
+Navigate to the Settings tab (the wrench icon at the top of the
+page). Under "Serial Connection" in "Additional serial ports" add
 "/tmp/printer". Then click "Save".
 
 Enter the Settings tab again and under "Serial Connection" change the
-"Serial Port" setting to "/tmp/printer". Unselect the "Not only cancel
+"Serial Port" setting to "/tmp/printer".
-ongoing prints but also disconnect..." checkbox. Click "Save".
+
+In the Settings tab, navigate to the "Behavior" sub-tab and select the
+"Cancel any ongoing prints but stay connected to the printer"
+option. Click "Save".
 
 From the main page, under the "Connection" section (at the top left of
 the page) make sure the "Serial Port" is set to "/tmp/printer" and
@@ -103,11 +127,11 @@ Configuring Klipper
 
 The Klipper configuration is stored in a text file on the Raspberry
 Pi. Take a look at the example config files in the
-[config directory](../config/). The
+[config directory](https://github.com/KevinOConnor/klipper/tree/master/config/). The
-[example.cfg](../config/example.cfg) file contains documentation on
+[example.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example.cfg)
-command parameters and it can also be used as an initial config file
+file contains documentation on command parameters and it can also be
-template. However, for most printers, one of the other config files
+used as an initial config file template. However, for most printers,
-may be a more concise starting point.
+one of the other config files may be a more concise starting point.
 
 Arguably the easiest way to update the Klipper configuration file is
 to use a desktop editor that supports editing files over the "scp"
@@ -128,6 +152,17 @@ nano ~/printer.cfg
 Make sure to review and update each setting that is appropriate for
 the hardware.
 
+It's common for each printer to have its own unique name for the
+micro-controller. The name may change after flashing Klipper, so rerun
+the `ls /dev/serial/by-id/*` command and then update the config file
+with the unique name. For example, update the `[mcu]` section to look
+something similar to:
+
+```
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+```
+
 After creating and editing the file it will be necessary to issue a
 "restart" command in the OctoPrint web terminal to load the config. A
 "status" command will report the printer is ready if the Klipper
@@ -146,7 +181,7 @@ In addition to common g-code commands, Klipper supports a few extended
 commands - "status" and "restart" are examples of these commands. Use
 the "help" command to get a list of other extended commands.
 
-After Klipper reports that the "printer is ready" go on to the
+After Klipper reports that the printer is ready go on to the
 [config check document](Config_checks.md) to perform some basic checks
 on the pin definitions in the config file.
 

docs/Kinematics.md

@@ -87,6 +87,10 @@ small junction speed is permitted.
 The junction speeds are determined using "approximated centripetal
 acceleration". Best
 [described by the author](https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/).
+However, in Klipper, junction speeds are configured by specifying the
+desired speed that a 90° corner should have (the "square corner
+velocity"), and the junction speeds for other angles are derived from
+that.
 
 Klipper implements look-ahead between moves that have similar extruder
 flow rates. Other moves are relatively rare and implementing
@@ -139,15 +143,32 @@ tracked in millimeters, seconds, and in cartesian coordinate space.
 It's the task of the kinematic classes to convert from this generic
 coordinate system to the hardware specifics of the particular printer.
 
-In general, the code determines each step time by first calculating
+Klipper uses an
-where along the line of movement the head would be if a step is
+[iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
-taken. It then calculates what time the head should be at that
+to generate the step times for each stepper. The code contains the
-position. Determining the time along the line of movement can be done
+formulas to calculate the ideal cartesian coordinates of the head at
-using the formulas for constant acceleration and constant velocity:
+each moment in time, and it has the kinematic formulas to calculate
+the ideal stepper positions based on those cartesian coordinates. With
+these formulas, Klipper can determine the ideal time that the stepper
+should be at each step position. The given steps are then scheduled at
+these calculated times.
 
+The key formula to determine how far a move should travel under
+constant acceleration is:
 ```
-time = sqrt(2*distance/accel + (start_velocity/accel)^2) - start_velocity/accel
+move_distance = (start_velocity + .5 * accel * move_time) * move_time
-time = distance/cruise_velocity
+```
+and the key formula for movement with constant velocity is:
+```
+move_distance = cruise_velocity * move_time
+```
+
+The key formulas for determining the cartesian coordinate of a move
+given a move distance is:
+```
+cartesian_x_position = start_x + move_distance * total_x_movement / total_movement
+cartesian_y_position = start_y + move_distance * total_y_movement / total_movement
+cartesian_z_position = start_z + move_distance * total_z_movement / total_movement
 ```
 
 Cartesian Robots
@@ -157,54 +178,35 @@ Generating steps for cartesian printers is the simplest case. The
 movement on each axis is directly related to the movement in cartesian
 space.
 
+Key formulas:
+```
+stepper_x_position = cartesian_x_position
+stepper_y_position = cartesian_y_position
+stepper_z_position = cartesian_z_position
+```
+
+CoreXY Robots
+----------------
+
+Generating steps on a CoreXY machine is only a little more complex
+than basic cartesian robots. The key formulas are:
+```
+stepper_a_position = cartesian_x_position + cartesian_y_position
+stepper_b_position = cartesian_x_position - cartesian_y_position
+stepper_z_position = cartesian_z_position
+```
+
 Delta Robots
 ------------
 
-To generate step times on Delta printers it is necessary to correlate
+Step generation on a delta robot is based on Pythagoras's theorem:
-the movement in cartesian space with the movement on each stepper
-tower.
-
-To simplify the math, for each stepper tower, the code calculates the
-location of a "virtual tower" that is along the line of movement.
-This virtual tower is chosen at the point where the line of movement
-(extended infinitely in both directions) would be closest to the
-actual tower.
-
-![delta-tower](img/delta-tower.svg.png)
-
-It is then possible to calculate where the head will be along the line
-of movement after each step is taken on the virtual tower.
-
-![virtual-tower](img/virtual-tower.svg.png)
-
-The key formula is Pythagoras's theorem:
 ```
-distance_to_tower^2 = arm_length^2 - tower_height^2
+stepper_position = (sqrt(arm_length^2
+                         - (cartesian_x_position - tower_x_position)^2
+                         - (cartesian_y_position - tower_y_position)^2)
+                    + cartesian_z_position)
 ```
 
-One complexity is that if the print head passes the virtual tower
-location then the stepper direction must be reversed. In this case
-forward steps will be taken at the start of the move and reverse steps
-will be taken at the end of the move.
-
-### Delta movements beyond simple XY plane ###
-
-Movement calculation is more complicated if a single move contains
-both XY movement and Z movement. These moves are rare, but they must
-still be handled correctly. A virtual tower along the line of movement
-is still calculated, but in this case the tower is not at a 90 degree
-angle relative to the line of movement:
-
-![xy+z-tower](img/xy+z-tower.svg.png)
-
-The code continues to calculate step times using the same general
-scheme as delta moves within an XY plane, but the slope of the tower
-must also be used in the calculations.
-
-Should the move contain only Z movement (ie, no XY movement at all)
-then the same math is used - just in this case the tower is parallel
-to the line of movement.
-
 ### Stepper motor acceleration limits ###
 
 With delta kinematics it is possible for a move that is accelerating
@@ -236,8 +238,10 @@ independently from the step time calculations of the print head
 movement.
 
 Basic extruder movement is simple to calculate. The step time
-generation uses the same constant acceleration and constant velocity
+generation uses the same formulas that cartesian robots use:
-formulas that cartesian robots use.
+```
+stepper_position = requested_e_position
+```
 
 ### Pressure advance ###
 
@@ -264,7 +268,7 @@ through the nozzle orifice (as in
 key idea is that the relationship between filament, pressure, and flow
 rate can be modeled using a linear coefficient:
 ```
-extra_filament = pressure_advance_coefficient * extruder_velocity
+stepper_position = requested_e_position + pressure_advance_coefficient * nominal_extruder_velocity
 ```
 
 See the [pressure advance](Pressure_Advance.md) document for

docs/MCU_Commands.md

@@ -12,7 +12,11 @@ format of commands and their transmission. The commands here are
 described using their "printf" style syntax - for those unfamiliar
 with that format, just note that where a '%...' sequence is seen it
 should be replaced with an actual integer. For example, a description
-with "count=%c" could be replaced with the text "count=10".
+with "count=%c" could be replaced with the text "count=10". Note that
+parameters that are considered "enumerations" (see the above protocol
+document) take a string value which is automatically converted to an
+integer value for the micro-controller. This is common with parameters
+named "pin" (or that have a suffix of "_pin").
 
 Startup Commands
 ================
@@ -23,14 +27,6 @@ commands available for that purpose. Unlike most micro-controller
 commands, these commands run as soon as they are received and they do
 not require any particular setup.
 
-Several of these commands will take a "pin=%u" parameter. The
-low-level micro-controller software uses integer encodings of the
-hardware pin numbers, but to make things more readable the host will
-translate human readable pin names (eg, "PA3") to their equivalent
-integer encodings. By convention, any parameter named "pin" or that
-has a "_pin" suffix will use pin name translation by the
-host.
-
 Common startup commands:
 
 * `set_digital_out pin=%u value=%c` : This command immediately
@@ -49,13 +45,6 @@ Common startup commands:
   and 255 indicating a full on state. This command may be useful for
   enabling CPU and nozzle cooling fans.
 
-* `send_spi_message pin=%u msg=%*s` : This command can be used to
-  transmit messages to a serial-peripheral-interface (SPI) component
-  connected to the micro-controller. It has been used to configure the
-  startup settings of AD5206 digipots. The 'pin' parameter specifies
-  the chip select line to use during the transmission. The 'msg'
-  indicates the binary message to transmit to the given chip.
-
 Low-level micro-controller configuration
 ========================================
 
@@ -151,9 +140,9 @@ This section lists some commonly used config commands.
   special hardware support (other than the ability to configure the
   pin as a digital output GPIO). Because the output switching is
   implemented in the micro-controller software, it is recommended that
-  the cycle_ticks parameter correspond to a time of 10ms or
+  the cycle_ticks parameter correspond to a time of 10ms or greater.
-  greater. See the description of the 'set_pwm_out' and
+  See the description of the 'set_pwm_out' and 'config_digital_out'
-  'config_digital_out' commands for parameter description.
+  commands for parameter description.
 
 * `config_analog_in oid=%c pin=%u` : This command is used to configure
   a pin in analog input sampling mode. Once configured, the pin can be
@@ -172,15 +161,31 @@ This section lists some commonly used config commands.
   clock ticks since the last step. It is used as a check on the
   maximum stepper velocity that a stepper may have before stopping.
 
-* `config_end_stop oid=%c pin=%c pull_up=%c stepper_count=%c` : This
+* `config_endstop oid=%c pin=%c pull_up=%c stepper_count=%c` : This
   command creates an internal "endstop" object. It is used to specify
   the endstop pins and to enable "homing" operations (see the
-  end_stop_home command below). The command will configure the
+  endstop_home command below). The command will configure the
   specified pin in digital input mode. The 'pull_up' parameter
   determines whether hardware provided pullup resistors for the pin
   (if available) will be enabled. The 'stepper_count' parameter
   specifies the maximum number of steppers that this endstop may need
-  to halt during a homing operation (see end_stop_home below).
+  to halt during a homing operation (see endstop_home below).
+
+* `config_spi oid=%c bus=%u pin=%u mode=%u rate=%u shutdown_msg=%*s` :
+  This command creates an internal SPI object. It is used with
+  spi_transfer and spi_send commands (see below).  The "bus"
+  identifies the SPI bus to use (if the micro-controller has more than
+  one SPI bus available). The "pin" specifies the chip select (CS) pin
+  for the device. The "mode" is the SPI mode (should be between 0 and
+  3). The "rate" parameter specifies the SPI bus rate (in cycles per
+  second). Finally, the "shutdown_msg" is an SPI command to send to
+  the given device should the micro-controller go into a shutdown
+  state.
+
+* `config_spi_without_cs oid=%c bus=%u mode=%u rate=%u
+  shutdown_msg=%*s` : This command is similar to config_spi, but
+  without a CS pin definition. It is useful for SPI devices that do
+  not have a chip select line.
 
 Common commands
 ===============
@@ -198,7 +203,7 @@ only of interest to developers looking to gain insight into Klipper.
   a hardware PWM output pin. See the 'schedule_digital_out' and
   'config_pwm_out' commands for more info.
 
-* `schedule_soft_pwm_out oid=%c clock=%u value=%hu` : Schedules a
+* `schedule_soft_pwm_out oid=%c clock=%u on_ticks=%u` : Schedules a
   change to a software PWM output pin. See the 'schedule_digital_out'
   and 'config_soft_pwm_out' commands for more info.
 
@@ -217,11 +222,11 @@ only of interest to developers looking to gain insight into Klipper.
   pins attached to thermistors controlling heaters - it can be used to
   check that a heater is within a temperature range.
 
-* `get_status` : This command causes the micro-controller to generate
+* `get_clock` : This command causes the micro-controller to generate a
-  a "status" response message. The host sends this command once a
+  "clock" response message. The host sends this command once a second
-  second to obtain the value of the micro-controller clock and to
+  to obtain the value of the micro-controller clock and to estimate
-  estimate the drift between host and micro-controller clocks. It
+  the drift between host and micro-controller clocks. It enables the
-  enables the host to accurately estimate the micro-controller clock.
+  host to accurately estimate the micro-controller clock.
 
 Stepper commands
 ----------------
@@ -255,9 +260,9 @@ Stepper commands
   number of steps generated with dir=1 minus the total number of steps
   generated with dir=0.
 
-* `end_stop_home oid=%c clock=%u sample_ticks=%u sample_count=%c
+* `endstop_home oid=%c clock=%u sample_ticks=%u sample_count=%c
   rest_ticks=%u pin_value=%c` : This command is used during stepper
-  "homing" operations. To use this command a 'config_end_stop' command
+  "homing" operations. To use this command a 'config_endstop' command
   with the same 'oid' parameter must have been issued during
   micro-controller configuration. When this command is invoked, the
   micro-controller will sample the endstop pin every 'rest_ticks'
@@ -283,3 +288,15 @@ It is the responsibility of the host to ensure that there is available
 space in the queue before sending a queue_step command. The host does
 this by calculating when each queue_step command completes and
 scheduling new queue_step commands accordingly.
+
+SPI Commands
+------------
+
+* `spi_transfer oid=%c data=%*s` : This command causes the
+  micro-controller to send 'data' to the spi device specified by 'oid'
+  and it generates a "spi_transfer_response" response message with the
+  data returned during the transmission.
+
+* `spi_send oid=%c data=%*s` : This command is similar to
+  "spi_transfer", but it does not generate a "spi_transfer_response"
+  message.

docs/Manual_Level.md

@@ -0,0 +1,185 @@
+This document describes tools for calibrating a Z endstop and for
+performing adjustments to bed leveling screws.
+
+# Calibrating a Z endstop
+
+An accurate Z endstop position is critical to obtaining high quality
+prints.
+
+Note, though, the accuracy of the Z endstop switch itself can be a
+limiting factor. If one is using Trinamic stepper motor drivers then
+consider enabling [endstop phase](Endstop_Phase.md) detection to
+improve the accuracy of the switch.
+
+To perform a Z endstop calibration, home the printer, move the head to
+a position near the center of the bed, navigate to the OctoPrint
+terminal tab, and run:
+```
+Z_ENDSTOP_CALIBRATE
+```
+Then follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
+actual distance between the nozzle and bed at the given location. Once
+those steps are complete one can `ACCEPT` the position and save the
+results to the config file with:
+```
+SAVE_CONFIG
+```
+
+It's preferable to use a Z endstop switch on the opposite end of the Z
+axis from the bed. (Homing away from the bed is more robust as then it
+is generally always safe to home the Z.) However, if one must home
+towards the bed it is recommended to adjust the endstop so that it
+triggers a small distance (eg, .5mm) above the bed. Almost all endstop
+switches can safely be depressed a small distance beyond their trigger
+point. When this is done, one should find that the
+`Z_ENDSTOP_CALIBRATE` command reports a small positive value (eg,
+.5mm) for the Z position_endstop. Triggering the endstop while it is
+still some distance from the bed reduces the risk of inadvertent bed
+crashes.
+
+Some printers have the ability to manually adjust the location of the
+physical endstop switch. However, it's recommended to perform Z
+endstop positioning in software with Klipper - once the physical
+location of the endstop is in a convenient location, one can make any
+further adjustments by running Z_ENDSTOP_CALIBRATE or by manually
+updating the Z position_endstop in the configuration file.
+
+# Adjusting bed leveling screws
+
+The secret to getting good bed leveling with bed leveling screws is to
+utilize the printer's high precision motion system during the bed
+leveling process itself. This is done by commanding the nozzle to a
+position near each bed screw and then adjusting that screw until the
+bed is a set distance from the nozzle. Klipper has a tool to assist
+with this. In order to use the tool it is necessary to specify each
+screw XY location.
+
+This is done by creating a `[bed_screws]` config section. For example,
+it might look something similar to:
+```
+[bed_screws]
+screw1: 100,50
+screw2: 100,150
+screw3: 150,100
+```
+
+If a bed screw is under the bed, then specify the XY position directly
+above the screw. If the screw is outside the bed then specify an XY
+position closest to the screw that is still within the range of the
+bed.
+
+Once the config file is ready, run `RESTART` to load that config, and
+then one can start the tool by running:
+```
+BED_SCREWS_ADJUST
+```
+
+This tool will move the printer's nozzle to each screw XY location and
+then move the nozzle to a Z=0 height. At this point one can use the
+"paper test" to adjust the bed screw directly under the nozzle. See
+the information described in
+["the paper test"](Bed_Level.md#the-paper-test), but adjust the bed
+screw instead of commanding the nozzle to different heights. Adjust
+the bed screw until there is a small amount of friction when pushing
+the paper back and forth.
+
+Once the screw is adjusted so that a small amount of friction is felt,
+run either the `ACCEPT` or `ADJUSTED` command. Use the `ADJUSTED`
+command if the bed screw needed an adjustment (typically anything more
+than about 1/8th of a turn of the screw). Use the `ACCEPT` command if
+no significant adjustment is necessary. Both commands will cause the
+tool to proceed to the next screw. (When an `ADJUSTED` command is
+used, the tool will schedule an additional cycle of bed screw
+adjustments; the tool completes successfully when all bed screws are
+verified to not require any significant adjustments.) One can use the
+`ABORT` command to exit the tool early.
+
+This system works best when the printer has a flat printing surface
+(such as glass) and has straight rails. Upon successful completion of
+the bed leveling tool the bed should be ready for printing.
+
+## Fine grained bed screw adjustments
+
+If the printer uses three bed screws and all three screws are under
+the bed, then it may be possible to perform a second "high precision"
+bed leveling step. This is done by commanding the nozzle to locations
+where the bed moves a larger distance with each bed screw adjustment.
+
+For example, consider a bed with screws at locations A, B, and C:
+
+![bed_screws](img/bed_screws.svg.png)
+
+For each adjustment made to the bed screw at location C, the bed will
+swing along a pendulum defined by the remaining two bed screws (shown
+here as a green line). In this situation, each adjustment to the bed
+screw at C will move the bed at position D a further amount than
+directly at C. It is thus possible to make an improved C screw
+adjustment when the nozzle is at position D.
+
+To enable this feature, one would determine the additional nozzle
+coordinates and add them to the config file. For example, it might
+look like:
+```
+[bed_screws]
+screw1: 100,50
+screw1_fine_adjust: 0,0
+screw2: 100,150
+screw2_fine_adjust: 300,300
+screw3: 150,100
+screw3_fine_adjust: 0,100
+```
+
+When this feature is enabled, the `BED_SCREWS_ADJUST` tool will first
+prompt for coarse adjustments directly above each screw position, and
+once those are accepted, it will prompt for fine adjustments at the
+additional locations. Continue to use `ACCEPT` and `ADJUSTED` at each
+position.
+
+# Adjusting bed leveling screws using the bed probe
+
+This is another way to calibrate the bed level using the bed probe. To
+use it you must have a Z probe (BL Touch, Inductive sensor, etc).
+
+To enable this feature, one would determine the nozzle coordinates
+near the screws and add them to the config file. For example, it might
+look like:
+
+```
+[screws_tilt_adjust]
+screw1: -5,30
+screw1_name: front left screw
+screw2: 155,30
+screw2_name: front right screw
+screw3: 155,190
+screw3_name: rear right screw
+screw4: -5,190
+screw4_name: rear left screw
+horizontal_move_z: 10.
+speed: 50.
+screw_thread: CW-M3
+```
+
+The screw1 is always the reference point for the others, so the system
+assumes that screw1 is in the correct height. Always run `G28` first
+and then run `SCREWS_TILT_CALCULATE` - it should produce output
+similar to:
+```
+Send: G28
+Recv: ok
+Send: SCREWS_TILT_CALCULATE
+Recv: // front left screw (Base): X -5.0, Y 30.0, Z 2.48750
+Recv: // front right screw : X 155.0, Y 30.0, Z 2.36000 : Adjust -> CW 01:15
+Recv: // rear right screw : X 155.0, Y 190.0, Z 2.71500 : Adjust -> CCW 00:50
+Recv: // read left screw : X -5.0, Y 190.0, Z 2.47250 : Adjust -> CW 00:02
+Recv: ok
+```
+This means that:
+
+    - front left screw is the reference point you must not change it.
+    - front right screw must be turned clockwise 1 full turn and a quarter turn
+    - rear right screw must be turned counter-clockwise 50 minutes
+    - read left screw must be turned clockwise 2 minutes (not need it's ok)
+
+Repeat the process several times until you get a good level bed -
+normally when all adjustments are below 6 minutes.

docs/Overview.md

@@ -1,43 +1,71 @@
-Welcome to the Klipper documentation. There are two parts to Klipper -
+Welcome to the Klipper documentation. If new to Klipper, start with
-code that runs on a micro-controller and code that runs on a "host"
+the [features](Features.md) and [installation](Installation.md)
-machine. The host code is intended to run on a low-cost
+documents.
-general-purpose machine such as a Raspberry Pi, while the
-micro-controller code is intended to run on commodity micro-controller
-chips. Read [features](Features.md) for reasons to use Klipper. See
-[installation](Installation.md) to get started with Klipper. See
-[config checks](Config_checks.md) for a guide to verify basic pin
-settings in the config file.
 
-The Klipper configuration is stored in a simple text file on the host
+# Overview information
-machine. The [config/example.cfg](../config/example.cfg) file serves
-as a reference for the config file. The
-[Pressure Advance](Pressure_Advance.md) document contains information
-on tuning the pressure advance config.
 
-The [kinematics](Kinematics.md) document provides some technical
+- [Features](Features.md): A high-level list of features in Klipper.
-details on how Klipper implements motion. The [FAQ](FAQ.md) answers
+- [FAQ](FAQ.md): Frequently asked questions.
-some common questions. The [G-Codes](G-Codes.md) document lists
+- [Releases](Releases.md): The history of Klipper releases.
-currently supported run-time commands.
+- [Config changes](Config_Changes.md): Recent software changes that
+may require users to update their printer config file.
+- [Contact](Contact.md): Information on bug reporting and general
+communication with the Klipper developers.
 
-The history of Klipper releases is available at
+# Configuration and Tuning Guides
-[releases](Releases.md). See [contact](Contact.md) for information on
-bug reporting and general communication with the developers.
 
-Developer Documentation
+- [Installation](Installation.md): Guide to installing Klipper.
-=======================
+  - [config/example.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example.cfg)
+    a reference for the config file.
+- [Config checks](Config_checks.md): Verify basic pin settings in the
+  config file.
+- [Bed level](Bed_Level.md): Information on "bed leveling" in Klipper.
+  - [Delta calibrate](Delta_Calibrate.md): Calibration of delta
+    kinematics.
+  - [Probe calibrate](Probe_Calibrate.md): Calibration of automatic Z
+    probes.
+  - [BL-Touch](BLTouch.md): Configure a "BL-Touch" Z probe.
+  - [Manual level](Manual_Level.md): Calibration of Z endstops (and
+    similar).
+  - [Endstop phase](Endstop_Phase.md): Stepper assisted Z endstop
+    positioning.
+- [Pressure advance](Pressure_Advance.md): Calibrate extruder
+  pressure.
+- [Slicers](Slicers.md): Configure "slicer" software for Klipper.
+- [Command Templates](Command_Templates.md): G-Code macros and
+  conditional evaluation.
+- [Sensorless homing](Sensorless_Homing.md): Configuring tmc2130
+  sensorless homing.
+- [Skew correction](skew_correction.md): Adjustments for axes not
+  perfectly square.
+- [G-Codes](G-Codes.md): Information on commands supported by Klipper.
 
-There are also several documents available for developers interested
+# Developer Documentation
-in understanding how Klipper works. Start with the
-[code overview](Code_Overview.md) document - it provides information
-on the structure and layout of the Klipper code. See the
-[contributing](CONTRIBUTING.md) document to submit improvements to Klipper.
 
-See [protocol](Protocol.md) for information on the low-level messaging
+- [Code overview](Code_Overview.md): Developers should read this
-protocol between host and micro-controller. See also
+  first.
-[MCU commands](MCU_Commands.md) for a description of low-level
+- [Kinematics](Kinematics.md): Technical details on how Klipper
-commands implemented in the micro-controller software.
+  implements motion.
+- [Protocol](Protocol.md): Information on the low-level messaging
+  protocol between host and micro-controller.
+- [MCU commands](MCU_Commands.md): A description of low-level commands
+  implemented in the micro-controller software.
+- [Debugging](Debugging.md): Information on how to test and debug
+  Klipper.
+- [Benchmarks](Benchmarks.md): Information on the Klipper benchmark
+  method.
+- [Contributing](CONTRIBUTING.md): Information on how to submit
+  improvements to Klipper.
+- [Packaging](Packaging.md): Information on building OS packages.
 
-See [debugging](Debugging.md) for information on how to test and debug
+# Device Specific Documents
-Klipper.
 
-See [todo](Todo.md) for information on possible future code features.
+- [Bootloaders](Bootloaders.md): Developer information on
+  micro-controller flashing.
+- [stm32f1](stm32f1.md): Information on the STM32F1 micro-controller
+  port.
+- [Beaglebone](beaglebone.md): Details for running Klipper on the
+  Beaglebone PRU.
+- [stm32f0](stm32f0_CAN.md): Information on the STM32F0 micro-controller
+  port.
+- [TSL1401CL filament width sensor](TSL1401CL_Filament_Width_Sensor.md)

docs/Packaging.md

@@ -0,0 +1,31 @@
+# Packaging klipper
+
+Klipper is somewhat of a packaging anomaly among python programs, as it doesn't
+use setuptools to build and install. Some notes regarding how best to package it
+are as follows:
+
+## C modules
+
+Klipper uses a C module to handle some kinematics calculations more quickly.
+This module needs to be compiled at packaging time to avoid introducing a
+runtime dependency on a compiler. To compile the C module, run `python2
+klippy/chelper/__init__.py`.
+
+## Compiling python code
+
+Many distributions have a policy of compiling all python code before packaging
+to improve startup time. You can do this by running `python2 -m compileall
+klippy`.
+
+## Versioning
+
+If you are building a package of Klipper from git, it is usual practice not to
+ship a .git directory, so the versioning must be handled without git.  To do
+this, use the script shipped in `scripts/make_version.py` which should be run as
+follows: `python2 scripts/make_version.py YOURDISTRONAME > klippy/.version`.
+
+## Sample packaging script
+
+klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build
+script) available at
+https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-git.

docs/Pressure_Advance.md

@@ -1,36 +1,36 @@
 This document provides information on tuning the "pressure advance"
-configuration variables for a particular nozzle and filament. The
+configuration variable for a particular nozzle and filament. The
 pressure advance feature can be helpful in reducing ooze. For more
 information on how pressure advance is implemented see the
 [kinematics](Kinematics.md) document.
 
-Prerequisites
-=============
-
-In order to tune the pressure advance setting the printer must be
-configured and operational. The tuning test involves printing objects
-and inspecting the differences between objects. In particular, the
-extruder
-[E steps](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#E_steps)
-and
-[nozzle temperature](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#Nozzle_Temperature)
-should be tuned prior to tuning pressure advance.
-
 Tuning pressure advance
 =======================
 
 Pressure advance does two useful things - it reduces ooze during
 non-extrude moves and it reduces blobbing during cornering. This guide
 uses the second feature (reducing blobbing during cornering) as a
-mechanism for measuring and tuning the pressure advance configuration.
+mechanism for tuning.
 
-Start by changing the extruder section of the config file so that
+In order to calibrate pressure advance the printer must be configured
-pressure_advance is set to 0.0. (Make sure to issue a RESTART command
+and operational. The tuning test involves printing objects and
-after each update to the config file so that the new configuration
+inspecting the differences between objects. It is a good idea to read
-takes effect.) Then print at least 10 layers of a large hollow square
+this document in full prior to running the test.
-at high speed (eg, 100mm/s). See
+
-[docs/prints/square.stl](prints/square.stl) file for an STL file that
+Use a slicer to generate g-code for the large hollow square found in
-one may use. While the object is printing, make a note of which
+[docs/prints/square.stl](prints/square.stl). Use a high speed (eg,
+100mm/s) and a coarse layer height (the layer height should be around
+75% of the nozzle diameter). It is fine to use a low infill (eg, 10%).
+
+Prepare for the test by issuing the following G-Code commands:
+`SET_VELOCITY_LIMIT SQUARE_CORNER_VELOCITY=1 ACCEL=500` and
+`SET_PRESSURE_ADVANCE ADVANCE_LOOKAHEAD_TIME=0`. These commands make
+the nozzle travel slower through corners and they emphasize the
+effects of extruder pressure.
+
+For the first print use a pressure advance of zero by running
+`SET_PRESSURE_ADVANCE ADVANCE=0.000`. Then print at least 10 layers of
+the test object. While the object is printing, make a note of which
 direction the head is moving during external perimeters. What many
 people see here is blobbing occurring at the corners - extra filament
 at the corner in the direction the head travels followed by a possible
@@ -41,15 +41,13 @@ lack of filament on the side immediately after that corner:
 This blobbing is the result of pressure in the extruder being released
 as a blob when the head slows down to corner.
 
-The next step is to set pressure_advance_lookahead_time to 0.0, slowly
+The next step is to increase pressure advance (start with
-increase pressure_advance (eg, start with 0.05), and reprint the test
+`SET_PRESSURE_ADVANCE ADVANCE=0.050`) and reprint the test object.
-object. (Be sure to issue RESTART between each config change.) The
+With pressure advance, the extruder will retract when the head slows
-goal is to attempt to eliminate the blobbing during cornering. (With
+down, thus countering the pressure buildup and ideally eliminate the
-pressure advance, the extruder will retract when the head slows down,
+blobbing.
-thus countering the pressure buildup and ideally eliminate the
-blobbing.)
 
-If a test run is done with a pressure_advance setting that is too
+If a test run is done with a pressure advance setting that is too
 high, one typically sees a dimple in the corner followed by possible
 blobbing after the corner (too much filament is retracted during slow
 down and then too much filament is extruded during the following speed
@@ -57,41 +55,89 @@ up after cornering):
 
 ![corner-dimple](img/corner-dimple.jpg)
 
-The goal is to find the smallest pressure_advance value that results
+The goal is to find the smallest pressure advance value that results
 in good quality corners:
 
 ![corner-good](img/corner-good.jpg)
 
-Typical pressure_advance values are between 0.05 and 0.20 (the high
+Typical pressure advance values are between 0.050 and 1.000 (the high
 end usually only with bowden extruders). If there is no significant
-improvement seen after increasing pressure_advance to 0.20, then
+improvement after gradually increasing pressure advance to 1.000, then
 pressure advance is unlikely to improve the quality of prints. Return
-to a default configuration with pressure_advance disabled.
+to a default configuration with pressure advance disabled.
-
-It is not unusual for one corner of the test print to be consistently
-different than the other three corners. This typically occurs when the
-slicer arranges to always change Z height at that corner.  If this
-occurs, then ignore that corner and tune pressure_advance using the
-other three corners.
-
-Once a good pressure_advance value is found, return
-pressure_advance_lookahead_time to its default (0.010). This parameter
-controls how far in advance to check if a head slow-down is
-immediately followed by a speed-up - it reduces pointless pressure
-changes in the head. It's possible to tune this - higher values will
-decrease the number of pressure changes in the nozzle at the expense
-of permitting more blobbing during cornering. (Tuning this value is
-unlikely to impact ooze.) The default of 10ms should work well on most
-printers.
 
 Although this tuning exercise directly improves the quality of
 corners, it's worth remembering that a good pressure advance
-configuration can reduce ooze throughout the print.
+configuration also reduces ooze throughout the print.
 
-Finally, once pressure_advance is tuned in Klipper, it may still be
+At the completion of this test, update the extruder's pressure_advance
-useful to configure a small retract value in the slicer (eg, 0.75mm)
+setting in the configuration file and issue a RESTART command. The
-and to utilize the slicer's "wipe on retract option" if available.
+RESTART command will also return the acceleration, cornering speeds,
-These slicer settings may help counteract ooze caused by filament
+and look-ahead times to their normal values.
-cohesion (filament pulled out of the nozzle due to the stickiness of
+
-the plastic). It is recommended to disable the slicer's "z-lift on
+Important Notes
-retract" option.
+===============
+
+* The pressure advance value is dependent on the extruder, the nozzle,
+  and the filament. It is common for filament from different
+  manufactures or with different pigments to require significantly
+  different pressure advance values. Therefore, one should calibrate
+  pressure advance on each printer and with each spool of filament.
+
+* Printing temperature and extrusion rates can impact pressure
+  advance.  Be sure to tune the extruder
+  [E steps](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#E_steps)
+  and
+  [nozzle temperature](http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide#Nozzle_Temperature)
+  prior to tuning pressure advance.
+
+* It is not unusual for one corner of the test print to be
+  consistently different than the other three corners. This typically
+  occurs when the slicer arranges to always change Z height at that
+  corner. If this occurs, then ignore that corner and tune pressure
+  advance using the other three corners.
+
+* Check for warping at the corners during the test prints (the corners
+  detaching from the bed and rising a small distance upwards during
+  the print). If one corner appears warped then ignore that corner
+  when tuning. If significant warping is seen throughout the test then
+  typical solutions are to reduce the slicer's first layer speed,
+  adjust the bed temperature, and/or to use the slicer's brim feature.
+  Pressure advance itself is unlikely to impact warping, but this
+  tuning test is sensitive to it.
+
+* If a high pressure advance value (eg, over 0.200) is used then one
+  may find that the extruder skips when returning to the printer's
+  normal acceleration. The pressure advance system accounts for
+  pressure by pushing in extra filament during acceleration and
+  retracting that filament during deceleration. With a high
+  acceleration and high pressure advance the extruder may not have
+  enough torque to push the required filament. If this occurs, either
+  use a lower acceleration value or disable pressure advance.
+
+* The pressure_advance_lookahead_time parameter controls how far in
+  advance to check if a head slow-down is immediately followed by a
+  speed-up - it reduces pointless pressure changes in the head. It is
+  recommended to follow the steps above so that it is set to zero
+  during tuning and to use the default (0.010) during normal prints.
+  It is possible to tune this setting - higher values will reduce the
+  amount of pressure change in the nozzle during cornering, but
+  setting it too high can cause blobbing during cornering. (Tuning
+  this value is unlikely to impact ooze.) The default of 10ms should
+  work well on most printers.
+
+* Once pressure advance is tuned in Klipper, it may still be useful to
+  configure a small retract value in the slicer (eg, 0.75mm) and to
+  utilize the slicer's "wipe on retract option" if available. These
+  slicer settings may help counteract ooze caused by filament cohesion
+  (filament pulled out of the nozzle due to the stickiness of the
+  plastic). It is recommended to disable the slicer's "z-lift on
+  retract" option.
+
+* Configuring pressure advance results in extra extruder movement
+  during move acceleration and deceleration. That extra movement is
+  not further constrained by any other other configuration parameter.
+  The pressure advance settings only impact extruder movement; they do
+  not alter toolhead XYZ movement or look-ahead calculations. A change
+  in pressure advance will not change the path or timing of the
+  toolhead nor will it change the overall printing time.

docs/Probe_Calibrate.md

@@ -0,0 +1,185 @@
+This document describes the method for calibrating the x, y, and z
+offsets of an "automatic z probe" in Klipper. This is useful for users
+that have a `[probe]` or `[bltouch]` section in their config file.
+
+# Calibrating probe X and Y offsets
+
+To calibrate the X and Y offset, navigate to the OctoPrint "Control"
+tab, home the printer, and then use the OctoPrint jogging buttons to
+move the head to a position near the center of the bed.
+
+Place a piece of blue painters tape (or similar) on the bed underneath
+the probe. Navigate to the OctoPrint "Terminal" tab and issue a PROBE
+command:
+```
+PROBE
+```
+Place a mark on the tape directly under where the probe is (or use a
+similar method to note the location on the bed).
+
+Issue a `GET_POSITION` command and record the toolhead XY location
+reported by that command. For example if one sees:
+```
+Recv: // toolhead: X:46.500000 Y:27.000000 Z:15.000000 E:0.000000
+```
+then one would record a probe X position of 46.5 and probe Y position
+of 27.
+
+After recording the probe position, issue a series of G1 commands
+until the nozzle is directly above the mark on the bed. For example,
+one might issue:
+```
+G1 F300 X57 Y30 Z15
+```
+to move the nozzle to an X position of 57 and Y of 30. Once one finds
+the position directly above the mark, use the `GET_POSITION` command
+to report that position. This is the nozzle position.
+
+The x_offset is then the `nozzle_x_position - probe_x_position` and
+y_offset is similarly the `nozzle_y_position - probe_y_position`.
+Update the printer.cfg file with the given values, remove the
+tape/marks from the bed, and then issue a `RESTART` command so that
+the new values take effect.
+
+# Calibrating probe Z offset
+
+Providing an accurate probe z_offset is critical to obtaining high
+quality prints. The z_offset is the distance between the nozzle and
+bed when the probe triggers. The Klipper `PROBE_CALIBRATE` tool can be
+used to obtain this value - it will run an automatic probe to measure
+the probe's Z trigger position and then start a manual probe to obtain
+the nozzle Z height. The probe z_offset will then be calculated from
+these measurements.
+
+Start by homing the printer and then move the head to a position near
+the center of the bed. Navigate to the OctoPrint terminal tab and run
+the `PROBE_CALIBRATE` command to start the tool.
+
+This tool will perform an automatic probe, then lift the head, move
+the nozzle over the location of the probe point, and start the manual
+probe tool. If the nozzle does not move to a position above the
+automatic probe point, then `ABORT` the manual probe tool and perform
+the XY probe offset calibration described above.
+
+Once the manual probe tool starts, follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test)) to determine the
+actual distance between the nozzle and bed at the given location. Once
+those steps are complete one can `ACCEPT` the position and save the
+results to the config file with:
+```
+SAVE_CONFIG
+```
+
+# Repeatability check
+
+After calibrating the probe X, Y, and Z offsets it is a good idea to
+verify that the probe provides repeatable results. Start by homing the
+printer and then move the head to a position near the center of the
+bed. Navigate to the OctoPrint terminal tab and run the
+`PROBE_ACCURACY` command.
+
+This command will run the probe ten times and produce output similar
+to the following:
+```
+Recv: // probe accuracy: at X:0.000 Y:0.000 Z:10.000
+Recv: // and read 10 times with speed of 5 mm/s
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe at -0.003,0.005 is z=2.519448
+Recv: // probe at -0.003,0.005 is z=2.506948
+Recv: // probe accuracy results: maximum 2.519448, minimum 2.506948, range 0.012500, average 2.513198, median 2.513198, standard deviation 0.006250
+```
+
+Ideally the tool will report an identical maximum and minimum value.
+(That is, ideally the probe obtains an identical result on all ten
+probes.) However, it's normal for the minimum and maximum values
+to differ by one Z step_distance or up to 5 microns (.005mm).
+The distance between the minimum and the maximum value is called the
+range. So, in the above example, since the printer uses a
+Z step_distance of .0125, a range of 0.012500 would be considered normal.
+
+If the results of the test show a range value that is greater than
+25 microns (.025mm) then the probe does not have sufficient accuracy
+for typical bed leveling procedures. It may be possible to tune the
+probe speed and/or probe start height to improve the repeatability
+of the probe. The `PROBE_ACCURACY` command allows one to run tests
+with different parameters to see their impact - see
+the [G-Codes document](G-Codes.md) for further details. If the probe
+generally obtains repeatable results but has an occasional outlier,
+then it may be possible to account for that by using multiple samples
+on each probe - read the description of the probe `samples` config
+parameters in the
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+file for more details.
+
+If new probe speed, samples count, or other settings are needed, then
+update the printer.cfg file and issue a `RESTART` command. If so, it
+is a good idea to
+[calibrate the z_offset](#calibrating-probe-z-offset) again. If
+repeatable results can not be obtained then don't use the probe for
+bed leveling. Klipper has several manual probing tools that can be
+used instead - see the [Bed Level document](Bed_Level.md) for further
+details.
+
+# Location Bias Check
+
+Some probes can have a systemic bias that corrupts the results of the
+probe at certain toolhead locations. For example, if the probe mount
+tilts slightly when moving along the Y axis then it could result in
+the probe reporting biased results at different Y positions.
+
+This is a common issue with probes on delta printers, however it can
+occur on all printers.
+
+One can check for a location bias by using the `PROBE_CALIBRATE`
+command to measuring the probe z_offset at various X and Y
+locations. Ideally, the probe z_offset would be a constant value at
+every printer location.
+
+For delta printers, try measuring the z_offset at a position near the
+A tower, at a position near the B tower, and at a position near the C
+tower. For cartesian, corexy, and similar printers, try measuring the
+z_offset at positions near the four corners of the bed.
+
+Before starting this test, first calibrate the probe X, Y, and Z
+offsets as described at the beginning of this document. Then home the
+printer and navigate to the first XY position. Follow the steps at
+[calibrating probe Z offset](#calibrating-probe-z-offset) to run the
+`PROBE_CALIBRATE` command, `TESTZ` commands, and `ACCEPT` command, but
+do not run `SAVE_CONFIG`. Note the reported z_offset found. Then
+navigate to the other XY positions, repeat these `PROBE_CALIBRATE`
+steps, and note the reported z_offset.
+
+If the difference between the minimum reported z_offset and the
+maximum reported z_offset is greater than 25 microns (.025mm) then the
+probe is not suitable for typical bed leveling procedures. See the
+[Bed Level document](Bed_Level.md) for manual probe alternatives.
+
+# Temperature Bias
+
+Many probes have a systemic bias when probing at different
+temperatures. For example, the probe may consistently trigger at a
+lower height when the probe is at a higher temperature.
+
+It is recommended to run the bed leveling tools at a consistent
+temperature to account for this bias. For example, either always run
+the tools when the printer is at room temperature, or always run the
+tools after the printer has obtained a consistent print temperature.
+In either case, it is a good idea to wait several minutes after the
+desired temperature is reached, so that the printer apparatus is
+consistently at the desired temperature.
+
+To check for a temperature bias, start with the printer at room
+temperature and then home the printer, move the head to a position
+near the center of the bed, and run the `PROBE_ACCURACY` command. Note
+the results. Then, without homing or disabling the stepper motors,
+heat the printer nozzle and bed to printing temperature, and run the
+`PROBE_ACCURACY` command again. Ideally, the command will report
+identical results. As above, if the probe does have a temperature bias
+then be careful to always use the probe at a consistent temperature.

docs/Protocol.md

@@ -6,8 +6,8 @@ then processed at the receiving side. An example series of commands in
 uncompressed human-readable format might look like:
 
 ```
-set_digital_out pin=86 value=1
+set_digital_out pin=PA3 value=1
-set_digital_out pin=85 value=1
+set_digital_out pin=PA7 value=1
 schedule_digital_out oid=8 clock=4000000 value=0
 queue_step oid=7 interval=7458 count=10 add=331
 queue_step oid=7 interval=11717 count=4 add=1281
@@ -44,26 +44,26 @@ The micro-controller software declares a "command" by using the
 DECL_COMMAND() macro in the C code. For example:
 
 ```
-DECL_COMMAND(command_set_digital_out, "set_digital_out pin=%u value=%c");
+DECL_COMMAND(command_update_digital_out, "update_digital_out oid=%c value=%c");
 ```
 
-The above declares a command named "set_digital_out". This allows the
+The above declares a command named "update_digital_out". This allows
-host to "invoke" this command which would cause the
+the host to "invoke" this command which would cause the
-command_set_digital_out() C function to be executed in the
+command_update_digital_out() C function to be executed in the
 micro-controller. The above also indicates that the command takes two
-integer parameters. When the command_set_digital_out() C code is
+integer parameters. When the command_update_digital_out() C code is
 executed, it will be passed an array containing these two integers -
-the first corresponding to the 'pin' and the second corresponding to
+the first corresponding to the 'oid' and the second corresponding to
 the 'value'.
 
 In general, the parameters are described with printf() style syntax
 (eg, "%u"). The formatting directly corresponds to the human-readable
-view of commands (eg, "set_digital_out pin=86 value=1"). In the above
+view of commands (eg, "update_digital_out oid=7 value=1"). In the
-example, "value=" is a parameter name and "%c" indicates the parameter
+above example, "value=" is a parameter name and "%c" indicates the
-is an integer. Internally, the parameter name is only used as
+parameter is an integer. Internally, the parameter name is only used
-documentation. In this example, the "%c" is also used as documentation
+as documentation. In this example, the "%c" is also used as
-to indicate the expected integer is 1 byte in size (the declared
+documentation to indicate the expected integer is 1 byte in size (the
-integer size does not impact the parsing or encoding).
+declared integer size does not impact the parsing or encoding).
 
 The micro-controller build will collect all commands declared with
 DECL_COMMAND(), determine their parameters, and arrange for them to be
@@ -99,7 +99,7 @@ invoked, and it may invoke sendf() at any time from a task handler.
 
 ### Output responses
 
-To simplify debugging, there is also has an output() C function. For
+To simplify debugging, there is also an output() C function. For
 example:
 
 ```
@@ -109,17 +109,46 @@ output("The value of %u is %s with size %u.", x, buf, buf_len);
 The output() function is similar in usage to printf() - it is intended
 to generate and format arbitrary messages for human consumption.
 
+Declaring enumerations
+----------------------
+
+Enumerations allow the host code to use string identifiers for
+parameters that the micro-controller handles as integers. They are
+declared in the micro-controller code - for example:
+
+```
+DECL_ENUMERATION("spi_bus", "spi", 0);
+
+DECL_ENUMERATION_RANGE("pin", "PC0", 16, 8);
+```
+
+If the first example, the DECL_ENUMERATION() macro defines an
+enumeration for any command/response message with a parameter name of
+"spi_bus" or parameter name with a suffix of "_spi_bus". For those
+parameters the string "spi" is a valid value and it will be
+transmitted with an integer value of zero.
+
+It's also possible to declare an enumeration range. In the second
+example, a "pin" parameter (or any parameter with a suffix of "_pin")
+would accept PC0, PC1, PC2, ..., PC7 as valid values. The strings will
+be transmitted with integers 16, 17, 18, ..., 23.
+
 Declaring constants
 -------------------
 
 Constants can also be exported. For example, the following:
 
 ```
-DECL_CONSTANT(SERIAL_BAUD, 250000);
+DECL_CONSTANT("SERIAL_BAUD", 250000);
 ```
 
 would export a constant named "SERIAL_BAUD" with a value of 250000
-from the micro-controller to the host.
+from the micro-controller to the host. It is also possible to declare
+a constant that is a string - for example:
+
+```
+DECL_CONSTANT_STR("MCU", "pru");
+```
 
 Low-level message encoding
 ==========================
@@ -171,28 +200,29 @@ As an example, the following four commands might be placed in a single
 message block:
 
 ```
-set_digital_out pin=86 value=1
+update_digital_out oid=6 value=1
-set_digital_out pin=85 value=0
+update_digital_out oid=5 value=0
 get_config
-get_status
+get_clock
 ```
 
 and encoded into the following eight VLQ integers:
 
 ```
-<id_set_digital_out><86><1><id_set_digital_out><85><0><id_get_config><id_get_status>
+<id_update_digital_out><6><1><id_update_digital_out><5><0><id_get_config><id_get_clock>
 ```
 
 In order to encode and parse the message contents, both the host and
 micro-controller must agree on the command ids and the number of
 parameters each command has. So, in the above example, both the host
-and micro-controller would know that "id_set_digital_out" is always
+and micro-controller would know that "id_update_digital_out" is always
-followed by two parameters, and "id_get_config" and "id_get_status"
+followed by two parameters, and "id_get_config" and "id_get_clock"
 have zero parameters. The host and micro-controller share a "data
-dictionary" that maps the command descriptions (eg, "set_digital_out
+dictionary" that maps the command descriptions (eg,
-pin=%u value=%c") to their integer command-ids. When processing the
+"update_digital_out oid=%c value=%c") to their integer
-data, the parser will know to expect a specific number of VLQ encoded
+command-ids. When processing the data, the parser will know to expect
-parameters following a given command id.
+a specific number of VLQ encoded parameters following a given command
+id.
 
 The message contents for blocks sent from micro-controller to host
 follow the same format. The identifiers in these messages are
@@ -277,24 +307,9 @@ dictionary. Once all chunks are obtained the host will assemble the
 chunks, uncompress the data, and parse the contents.
 
 In addition to information on the communication protocol, the data
-dictionary also contains the software version, constants (as defined
+dictionary also contains the software version, enumerations (as
-by DECL_CONSTANT), and static strings.
+defined by DECL_ENUMERATION), and constants (as defined by
-
+DECL_CONSTANT).
-Static Strings
---------------
-
-To reduce bandwidth the data dictionary also contains a set of static
-strings known to the micro-controller. This is useful when sending
-messages from micro-controller to host. For example, if the
-micro-controller were to run:
-
-```
-shutdown("Unable to handle command");
-```
-
-The error message would be encoded and sent using a single VLQ. The
-host uses the data dictionary to resolve VLQ encoded static string ids
-to their associated human-readable strings.
 
 Message flow
 ============

docs/Releases.md

@@ -1,6 +1,81 @@
 History of Klipper releases. Please see
 [installation](Installation.md) for information on installing Klipper.
 
+Klipper 0.8.0
+=============
+
+Available on 20191021. Major changes in this release:
+* New G-Code command template support. G-Code in the config file is
+  now evaluated with the Jinja2 template language.
+* Improvements to Trinamic stepper drivers:
+  * New support for TMC2209 and TMC5160 drivers.
+  * Improved DUMP_TMC, SET_TMC_CURRENT, and INIT_TMC G-Code commands.
+  * Improved support for TMC UART handling with an analog mux.
+* Improved homing, probing, and bed leveling support:
+  * New manual_probe, bed_screws, screws_tilt_adjust, skew_correction,
+    safe_z_home modules added.
+  * Enhanced multi-sample probing with median, average, and retry
+    logic.
+  * Improved documentation for BL-Touch, probe calibration, endstop
+    calibration, delta calibration, sensorless homing, and endstop
+    phase calibration.
+  * Improved homing support on a large Z axis.
+* Many Klipper micro-controller improvements:
+  * Klipper ported to: SAM3X8C, SAM4S8C, SAMD51, STM32F042, STM32F4
+  * New USB CDC driver implementations on SAM3X, SAM4, STM32F4.
+  * Enhanced support for flashing Klipper over USB.
+  * Software SPI support.
+  * Greatly improved temperature filtering on the LPC176x.
+  * Early output pin settings can be configured in the
+    micro-controller.
+* New website with the Klipper documentation: http://klipper3d.org/
+  * Klipper now has a logo.
+* Experimental support for polar and "cable winch" kinematics.
+* The config file can now include other config files.
+* Many additional modules added: board_pins, controller_fan,
+  delayed_gcode, dotstar, filament_switch_sensor, firmware_retraction,
+  gcode_arcs, gcode_button, heater_generic, manual_stepper, mcp4018,
+  mcp4728, neopixel, pause_resume, respond, temperature_sensor
+  tsl1401cl_filament_width_sensor, tuning_tower
+* Many additional commands added: RESTORE_GCODE_STATE,
+  SAVE_GCODE_STATE, SET_GCODE_VARIABLE, SET_HEATER_TEMPERATURE,
+  SET_IDLE_TIMEOUT, SET_TEMPERATURE_FAN_TARGET
+* Several bug fixes and code cleanups.
+
+Klipper 0.7.0
+=============
+
+Available on 20181220. Major changes in this release:
+* Klipper now supports "mesh" bed leveling
+* New support for "enhanced" delta calibration (calibrates print x/y
+  dimensions on delta printers)
+* Support for run-time configuration of Trinamic stepper motor drivers
+  (tmc2130, tmc2208, tmc2660)
+* Improved temperature sensor support: MAX6675, MAX31855, MAX31856,
+  MAX31865, custom thermistors, common pt100 style sensors
+* Several new modules: temperature_fan, sx1509, force_move, mcp4451,
+  z_tilt, quad_gantry_level, endstop_phase, bltouch
+* Several new commands added: SAVE_CONFIG, SET_PRESSURE_ADVANCE,
+  SET_GCODE_OFFSET, SET_VELOCITY_LIMIT, STEPPER_BUZZ, TURN_OFF_HEATERS,
+  M204, custom g-code macros
+* Expanded LCD display support:
+  * Support for run-time menus
+  * New display icons
+  * Support for "uc1701" and "ssd1306" displays
+* Additional micro-controller support:
+  * Klipper ported to: LPC176x (Smoothieboards), SAM4E8E (Duet2),
+    SAMD21 (Arduino Zero), STM32F103 ("Blue pill" devices), atmega32u4
+  * New Generic USB CDC driver implemented on AVR, LPC176x, SAMD21, and
+    STM32F103
+  * Performance improvements on ARM processors
+* The kinematics code was rewritten to use an "iterative solver"
+* New automatic test cases for the Klipper host software
+* Many new example config files for common off-the-shelf printers
+* Documentation updates for bootloaders, benchmarking,
+    micro-controller porting, config checks, pin mapping, slicer
+    settings, packaging, and more
+* Several bug fixes and code cleanups
+
 Klipper 0.6.0
 =============
 

docs/Sensorless_Homing.md

@@ -0,0 +1,112 @@
+# Sensorless Homing
+Sensorless homing allows to home an axis without the need for a physical limit switch. Instead, the carriage on the axis is moved into the mechanical limit making the stepper motor lose steps. The stepper driver senses the lost steps and indicates this to the controlling MCU (Klipper) by toggling a pin. This information can be used by Klipper as end stop for the axis.
+
+This guide covers the setup of sensorless homing for the X axis of your (cartesian) printer. However, it works the same with all other axes (that require an end stop). You should configure and tune it for one axis at a time.
+
+## Prerequisites
+A few prerequisites are needed to use sensorless homing:
+
+1. StallGuard capable TMCxxxx stepper driver
+2. SPI / UART interface of the TMCxxxx wired to MCU (stand-alone mode does not work)
+3. DIAG1/DIAG pin of TMCxxxx connected to the MCU
+
+
+## Limitations
+Be sure that your mechanical components are able to handle the load of the carriage bumping into the limit of the axis repeatedly. Especially spindles (on the Z axis) might generate a lot of force. Homing a Z axis by bumping the nozzle into the printing surface might not be a good idea.
+
+Further, sensorless homing might not be accurate enough for you printer. While homing X and Y axes on a cartesian machine can work well, homing the Z axis is generally not accurate enough and results in inconsistent first layer height. Homing a delta printer sensorless is not advisable due to missing accuracy.
+
+Further, the stall detection of the stepper driver is dependant on the mechanical load on the motor, the motor current and the motor temperature (coil resistance).
+
+Sensorless homing works best at medium motor speeds. For very slow speeds (less than 10 RPM) the motor does not generate significant back EMF and the TMC cannot reliably detect motor stalls. Further, at very high speeds, the back EMF of the motor approaches the supply voltage of the motor, so the TMC cannot detect stalls anymore. It is advised to have a look in the datasheet of your specific TMCs. There you can also find more details on limitations of this setup.
+
+## Configuration
+To enable sensorless homing add a section to configure the TMC stepper driver to your `printer.cfg`.
+
+In this guide we'll be using a TMC2130. The configuration however is simailar to the other TMCs with StallGuard:
+
+```
+[tmc2130 stepper_x]
+cs_pin:        # chip select pin of the SPI interface
+microsteps:    # number of microsteps per full step of the motor
+run_current:   # value in amps
+diag1_pin: !   # pin on the MCU where DIAG1 is connected (active low)
+driver_SGT:    # tuning value for sensorless homing
+```
+
+The above snippet configures a TMC2130 for the stepper on the X axis. Make sure to fill in the missing values based on your configuration.
+
+The `driver_SGT` value describes the threshhold when the driver reports a stall. Values have to be in between -64 (most sensitive) and 64 (least sensitive). On some TMCs like the TMC2209 this value doesn't exist in this form as the hehavior is different to the TMC2130. In the case of the TMC2209 the threshold is defined by the `driver_SGTHRS` value in the config and go from 0 (least sensitive) to 255 (most sensitive). Have a look at the datasheet of your specific TMC to avoid mistakes.
+
+If you have a CoreXY machine, you can configure one stepper driver for X and the other for Y homing as you would on a cartesian printer. Be aware that Klipper needs both `DIAG1` pins connected to the MCU. It is not sufficient to use only one signal from one of the stepper drivers (as it is possible on e.g. Marlin).
+
+The `diag1_pin` of the TMC2130 is configured as open-collector pin. This means, the stepper driver pulls the pin low to indicate a stalled motor (active low) and the pin must be inverted by adding a `!` in front of the pin name. Further, you need a pull-up resistor on the connection. If your PCB has no external pull-up, you can enable the internal pull-up of your MCU by adding a `^` in front of the pin name. The resulting line might look like this:
+
+```
+diag1_pin: ^!PA1  # DIAG1 connected to PA1, internal pull-up is enabled, signal is active low
+```
+
+By configuring the `diag1_pin`, Klipper allows you to use a special virtual end stop for the axis. You can use this instead of a physical end stop pin by changing the `endstop_pin` of the corresponding axis:
+
+```
+[stepper_x]
+...
+endstop_pin: tmc2130_stepper_x:virtual_endstop  # use the virtual end stop generated by the [tmc2130 stepper_x] section of this config file
+...
+homing_retract_dist: 0
+...
+```
+
+The name of the virtual end stop pin is derived from the name of the TMC2130 section. The `homing_retract_dist` setting should be set to zero to disable the second homing move as a second pass is not needed, and attempts to do so are error prone.
+
+ATTENTION: This guide only mentions the mandatory parameters and the ones needed to set up sensorless homing. There are many other options to configure on a TMC2130, make sure to take a look at `config/example-extras.cfg` for all the available options.
+
+## Testing of SPI/UART communication
+Now that the stepper driver is configured, let's make sure that Klipper can communicate with the TMC2130 by sending the following extended G-Code command to the printer:
+
+```
+DUMP_TMC stepper=stepper_x
+```
+
+This command tells Klipper to read a few registers via SPI from the TMC2130. If everything works correctly, the output should look similar to this (in OctoPrint terminal tab):
+
+```
+Send: DUMP_TMC stepper=stepper_x
+Recv: // GCONF:          00000004
+Recv: // GSTAT:          00000001
+Recv: // IOIN:           11000078
+Recv: // TSTEP:          000fffff
+Recv: // XDIRECT:        00000000
+Recv: // MSCNT:          00000010
+Recv: // MSCURACT:       00f60018
+Recv: // CHOPCONF:       15008384
+Recv: // DRV_STATUS:     800d0000
+Recv: // PWM_SCALE:      00000000
+Recv: // LOST_STEPS:     00000000
+```
+
+The actual register values might differ based the configuration of your TMC2130. If the register values are all `ffffffff` or look otherwise bogus (for example, `LOST_STEPS` should be always `00000000` here) make sure that the SPI is wired and configured correctly.
+
+## Homing and Tuning
+
+Let's try the first sensorless homing now. It will likely not work as intended. There are three possible outcomes of this experiment:
+
+1. The axis stops moving before hitting the mechanical limit or does not move at all
+2. The axis homes correctly (which is unlikely at this point)
+3. The axis bumps into the mechanical limit and keeps moving while making horrible noise
+
+If the third outcome happens to you, disable the stepper (by cutting the power or issuing a `M112` emergency stop).
+
+Ok, now that you know what can happen, let's try it out. Put the carriage somewhere in the middle of the X axis. Home the X axis by sending the following G-Code command to Klipper and observe the outcome:
+
+```
+G28 X
+```
+
+If the axis stopped early (first outcome), the stepper driver detected a motor stall even though there was none. To trigger stall detection at a higher load, increase the value of `driver_SGT` (for example from 0 to 5). The values can be any interger between `-64` and `63`. The higher the value, the later it triggers stall detection.
+
+If your axis did not stop (third outcome), the stepper driver was not able to detect the stall, because the load on the motor still seemed reasonable to the driver. To trigger stall detection at a lighter load, decrease the value of `driver_SGT`.
+
+Even if your axis homed correctly, it might be worth to try a few different values for `driver_SGT`. If you think that it bumps too hard into the mechanical limit, try to decrease the value by 1 or 2.
+
+At this point, your axis should be able to home based on the stall detection of the TMC2130. Congratulations! You can now proceed with the next axis of your printer.

docs/Slicers.md

@@ -0,0 +1,78 @@
+This document provides some tips for configuring a "slicer"
+application for use with Klipper. Common slicers used with Klipper are
+Slic3r, Cura, Simplify3D, etc.
+
+# Set the G-Code flavor to Marlin
+
+Many slicers have an option to configure the "G-Code flavor". The
+default is frequently "Marlin" and that works well with Klipper. The
+"Smoothieware" setting also works well with Klipper.
+
+# Klipper gcode_macro
+
+Slicers will often allow one to configure "Start G-Code" and "End
+G-Code" sequences. It is often convenient to define custom macros in
+the Klipper config file instead - such as: `[gcode_macro START_PRINT]`
+and `[gcode_macro END_PRINT]`. Then one can just run START_PRINT and
+END_PRINT in the slicer's configuration. Defining these actions in the
+Klipper configuration may make it easier to tweak the printer's start
+and end steps as changes do not require re-slicing.
+
+See the
+[example-extras.cfg](https://github.com/KevinOConnor/klipper/tree/master/config/example-extras.cfg)
+file for details on defining a gcode_macro.
+
+# Large retraction settings may require tuning Klipper
+
+The maximum speed and acceleration of retraction moves are controlled
+in Klipper by the `max_extrude_only_velocity` and
+`max_extrude_only_accel` config settings. These settings have a
+default value that should work well on many printers. However, if one
+has configured a large retraction in the slicer (eg, 5mm or greater)
+then one may find they limit the desired speed of retractions.
+
+If using a large retraction, consider tuning Klipper's
+[pressure advance](Pressure_Advance.md) instead. Otherwise, if one
+finds the toolhead seems to "pause" during retraction and priming,
+then consider explicitly defining `max_extrude_only_velocity` and
+`max_extrude_only_accel` in the Klipper config file.
+
+# Do not enable "coasting"
+
+The "coasting" feature is likely to result in poor quality prints with
+Klipper. Consider using Klipper's
+[pressure advance](Pressure_Advance.md) instead.
+
+Specifically, if the slicer dramatically changes the extrusion rate
+between moves then Klipper will perform deceleration and acceleration
+between moves. This is likely to make blobbing worse, not better.
+
+In contrast, it is okay (and often helpful) to use a slicer's
+"retract" setting, "wipe" setting, and/or "wipe on retract" setting.
+
+# Disable "PreloadVE" on KISSlicer
+
+If using KISSlicer slicing software then set "PreloadVE" to
+zero. Consider using Klipper's [pressure advance](Pressure_Advance.md)
+instead.
+
+# Disable any "advanced extruder pressure" settings
+
+Some slicers advertise an "advanced extruder pressure" capability. It
+is recommended to keep these options disabled when using Klipper as
+they are likely to result in poor quality prints. Consider using
+Klipper's [pressure advance](Pressure_Advance.md) instead.
+
+Specifically, these slicer settings can instruct the firmware to make
+wild changes to the extrusion rate in the hope that the firmware will
+approximate those requests and the printer will roughly obtain a
+desirable extruder pressure. Klipper, however, utilizes precise
+kinematic calculations and timing. When Klipper is commanded to make
+significant changes to the extrusion rate it will plan out the
+corresponding changes to velocity, acceleration, and extruder
+movement - which is not the slicer's intent. The slicer may even
+command excessive extrusion rates to the point that it triggers
+Klipper's maximum extrusion cross-section check.
+
+In contrast, it is okay (and often helpful) to use a slicer's
+"retract" setting, "wipe" setting, and/or "wipe on retract" setting.

docs/TSL1401CL_Filament_Width_Sensor.md

@@ -0,0 +1,31 @@
+This document describes Filament Width Sensor host module. Hardware used for developing this host module is based on TSL1401CL linear sensor array but it can work with any sensor array that has analog output. You can find designs at [thingiverse.com](https://www.thingiverse.com/search?q=filament%20width%20sensor)
+
+## How does it work?
+Sensor generates analog output based on calculated filament width. Output voltage always equals to detected filament width (Ex. 1.65v, 1.70v, 3.0v). Host module monitors voltage changes and adjusts extrusion multiplier.
+
+## Configuration
+    [tsl1401cl_filament_width_sensor]
+    pin: analog5
+    # Analog input pin for sensor output on Ramps board
+
+    default_nominal_filament_diameter: 1.75
+    # This parameter is in millimeters (mm)
+
+    max_difference: 0.2
+    #  Maximum allowed filament diameter difference in millimeters (mm)
+    #  If difference between nominal filament diameter and sensor output is more
+    #  than +- max_difference, extrusion multiplier set back to %100
+
+    measurement_delay 100
+    #  The distance from sensor to the melting chamber/hot-end in millimeters (mm).
+    #  The filament between the sensor and the hot-end will be treated as the default_nominal_filament_diameter.
+    #  Host module works with FIFO logic. It keeps each sensor value and position in
+    #  an array and POP them back in correct position.
+
+Sensor readings done with 10 mm intervals by default. If necessary you are free to change this setting by editing ***MEASUREMENT_INTERVAL_MM*** parameter in **filament_width_sensor.py** file.
+
+## Commands
+**QUERY_FILAMENT_WIDTH** - Return the current measured filament width as result
+**RESET_FILAMENT_WIDTH_SENSOR** – Clear all sensor readings. Can be used after filament change.
+**DISABLE_FILAMENT_WIDTH_SENSOR** – Turn off the filament width sensor and stop using it to do flow control
+**ENABLE_FILAMENT_WIDTH_SENSOR** - Turn on the filament width sensor and start using it to do flow control

docs/Todo.md

@@ -1,84 +0,0 @@
-There are several features still to be implemented in Klipper. In no
-particular order:
-
-Host user interaction
-=====================
-
-* See if there is a better way to report errors. Octoprint sometimes
-  doesn't highlight an error (one has to look in the terminal tab to
-  find the error) and errors written to the log can be non-obvious to
-  a user.
-
-* Improve gcode interface:
-
- * Provide a better way to handle print nozzle z offsets. The M206
-   command is cryptic to use and it is too easy to set the value
-   incorrectly or to forget to set it.
-
- * Provide a way to temporarily disable endstop checks so that a user
-   can issue commands that potentially move the head past
-   position_min/position_max.
-
-* Improve logging:
-
- * Possibly collate and report the statistics messages in the log in a
-   more friendly way.
-
-* Possibly support a mechanism for the host to limit maximum velocity
-  so that the mcu is never requested to step at a higher rate than it
-  can support.
-
-Safety features
-===============
-
-* Support loading a valid step range into the micro-controller
-  software after homing. This would provide a sanity check in the
-  micro-controller that would reduce the risk of the host commanding a
-  stepper motor past its valid step range. To maintain high
-  efficiency, the micro-controller would only need to check
-  periodically (eg, every 100ms) that the stepper is in range.
-
- * Possibly support periodically querying the endstop switches and use
-   multiple step ranges depending on the switch state. This would
-   enable runtime endstop detection. (However, it's unclear if runtime
-   endstop detection is a good idea because of spurious signals caused
-   by electrical noise.)
-
-Testing features
-================
-
-* Complete the host based simulator. It's possible to compile the
-  micro-controller for a "host simulator", but that simulator doesn't
-  do anything currently. It would be useful to expand the code to
-  support more error checks, kinematic simulations, and improved
-  logging.
-
-Documentation
-=============
-
-* Add documentation describing how to perform bed-leveling accurately
-  in Klipper. Improve description of stepper phase based bed leveling.
-
-Hardware features
-=================
-
-* Port to additional micro-controller architectures:
- * Smoothieboard / NXP LPC1769 (ARM cortex-M3)
-
-* Support for additional kinematics: scara, etc.
-
-* Possible support for touch panels attached to the micro-controller.
-  (In general, it would be preferable to attach touch panels to the
-  host system and have octoprint interact with the panel directly, but
-  it would also be useful to handle panels already hardwired to the
-  micro-controller.)
-
-Misc features
-=============
-
-* Possibly support a "feed forward PID" that takes into account the
-  amount of plastic being extruded. If the extrude rate changes
-  significantly during a print it can cause heating bumps that the PID
-  overcompensates for. The temperature change due to the extrusion
-  rate could be modeled to eliminate these bumps and make the
-  extrusion temperature more consistent.

docs/_config.yml

@@ -0,0 +1,4 @@
+# This is a Jekyll config file that is used by "github pages" to
+# produce the https://www.klipper3d.org/ website.
+include: CONTRIBUTING.md
+google_analytics: UA-138371409-1

docs/_layouts/README

@@ -0,0 +1,5 @@
+This directory defines the https://www.klipper3d.org/ website. The
+site is hosted using "github pages" (which uses Jekyll to
+automatically convert the markdown files in the docs/ directory to
+html). In addition to the files in this directory, the docs/CNAME and
+docs/_config.yml file also control the website generation.

docs/_layouts/default.html

@@ -0,0 +1,122 @@
+<!DOCTYPE html>
+<html>
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
+  {% seo %}
+
+  <!-- Bootstrap css -->
+  <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
+
+  <!-- Fixup markdown code blocks -->
+  <style>
+    .markdown-body pre {
+        background-color: #f6f8fa;
+        line-height: 1.45;
+        overflow: auto;
+        padding: 16px;
+    }
+    .markdown-body code, .markdown-body tt {
+        background-color: rgba(27,31,35,.1);
+        color: inherit;
+        border-radius: 3px;
+        font-size: 85%;
+        margin: 0;
+        padding: .2em .4em;
+    }
+    .markdown-body pre code {
+        padding: 0;
+        background: transparent;
+    }
+
+    .markdown-body table td, .markdown-body table th {
+        border: 1px solid #dfe2e5;
+        padding: 6px 13px;
+    }
+    .markdown-body table tr {
+        background-color: #fff;
+        border-top: 1px solid #c6cbd1;
+    }
+    .markdown-body table tr:nth-child(2n) {
+        background-color: #f6f8fa;
+    }
+    .markdown-body table {
+        margin-bottom: 16px;
+    }
+  </style>
+</head>
+<body>
+
+  <!-- Navbar at top of page -->
+  <nav class="navbar navbar-expand-md navbar-light bg-light">
+    <a class="navbar-brand" href="/">
+      <img src="img/klipper-logo-small.png" alt="Klipper">
+    </a>
+    <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarNavAltMarkup" aria-controls="navbarNavAltMarkup" aria-expanded="false" aria-label="Toggle navigation">
+      <span class="navbar-toggler-icon"></span>
+    </button>
+    <div class="collapse navbar-collapse" id="navbarNavAltMarkup">
+      <div class="navbar-nav ml-auto">
+        <a class="nav-item nav-link" href="Overview.html">Documentation</a>
+        <a class="nav-item nav-link" href="https://github.com/KevinOConnor/klipper">Github</a>
+      </div>
+    </div>
+  </nav>
+
+  <div class="container-fluid">
+    <div class="row">
+
+      <!-- Sidebar for table of contents -->
+      <nav class="d-none d-md-block col-md-3 bg-light">
+        <ul id="toc" class="px-0" style="list-style: none">
+        </ul>
+      </nav>
+
+      <!-- Main markdown contents -->
+      <main class="col-md-9 ml-md-auto px-4">
+        <div class="markdown-body" style="max-width: 800px">
+          {{ content }}
+        </div>
+      </main>
+
+    </div>
+  </div>
+
+  <!-- Google analytics javascript -->
+  {% if site.google_analytics %}
+    <script>
+      (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
+      (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
+      m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
+      })(window,document,'script','//www.google-analytics.com/analytics.js','ga');
+      ga('create', '{{ site.google_analytics }}', 'auto');
+      ga('send', 'pageview');
+    </script>
+  {% endif %}
+
+  <!-- Bootstrap / jquery javascript -->
+  <script src="https://code.jquery.com/jquery-3.3.1.slim.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" crossorigin="anonymous"></script>
+  <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js" integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1" crossorigin="anonymous"></script>
+  <script src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js" integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM" crossorigin="anonymous"></script>
+
+  <!-- Javascript to automatically add table of contents -->
+  <style>
+    .toc-item {
+        font-size: 80%;
+        line-height: 80%;
+        padding-top: .5em;
+        padding-bottom: .5em;
+    }
+  </style>
+  <script>
+  $('.markdown-body').find('h1, h2, h3, h4, h5, h6').each(function() {
+    var $item = $(this);
+    var $id = $(this).attr('id');
+    var li = $('<li class="toc-item"/>');
+    var a = $('<a/>', {text: $item.text(), href: '#' + $id, title: $item.text()});
+    a.appendTo(li);
+    $('#toc').append(li);
+  });
+  </script>
+</body>
+</html>

docs/_layouts/home.html

@@ -0,0 +1,16 @@
+---
+# This file defines the main https://www.klipper3d.org/ page.
+layout: default
+---
+<p class="text-center"><img src="img/klipper-logo.png"/></p>
+
+<p>Klipper is a 3d-Printer firmware. It combines the power of a general
+purpose computer with one or more micro-controllers. See the
+<a href="/Features.html">features</a> document for more information on why you
+should use Klipper.</p>
+
+<p>To begin using Klipper start by <a href="/Installation.html">installing</a> it.</p>
+
+<p>Klipper is Free Software. Read the <a href="/Overview.html">documentation</a> or
+view
+<a href="https://github.com/KevinOConnor/klipper">the Klipper code on github</a>.</p>