docs: Update release notes for v0.7.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

@@ -0,0 +1,26 @@
+# This is a travis-ci.org continuous integration configuration file.
+language: c
+
+addons:
+  apt:
+    packages:
+      # AVR GCC packages
+      - gcc-avr
+      - avr-libc
+      # 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
+
+script: ./scripts/travis-build.sh

Makefile

@@ -1,6 +1,6 @@
 # Klipper build system
 #
-# Copyright (C) 2016  Kevin O'Connor <kevin@koconnor.net>
+# Copyright (C) 2016,2017  Kevin O'Connor <kevin@koconnor.net>
 #
 # This file may be distributed under the terms of the GNU GPLv3 license.
 
@@ -22,7 +22,7 @@ OBJCOPY=$(CROSS_PREFIX)objcopy
 OBJDUMP=$(CROSS_PREFIX)objdump
 STRIP=$(CROSS_PREFIX)strip
 CPP=cpp
-PYTHON=python
+PYTHON=python2
 
 # Source files
 src-y =
@@ -32,18 +32,15 @@ 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-y := -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-y += -flto -fwhole-program -fno-use-linker-plugin
+CFLAGS += -flto -fwhole-program -fno-use-linker-plugin
 
-LDFLAGS-y := -Wl,--gc-sections -fno-whole-program
+CFLAGS_klipper.elf = $(CFLAGS) -Wl,--gc-sections
 
 CPPFLAGS = -I$(OUT) -P -MD -MT $@
 
-CFLAGS = $(CFLAGS-y)
-LDFLAGS = $(LDFLAGS-y)
-
 # Default targets
 target-y := $(OUT)klipper.elf
 
@@ -77,23 +74,18 @@ $(OUT)board-link: $(KCONFIG_CONFIG)
 	$(Q)mkdir -p $(OUT)board-generic
 	$(Q)ln -Tsf $(PWD)/src/generic $(OUT)board-generic/board
 
-$(OUT)declfunc.lds: src/declfunc.lds.S
-	@echo "  Precompiling $@"
-	$(Q)$(CPP) $(CPPFLAGS) -D__ASSEMBLY__ $< -o $@
+$(OUT)%.o.ctr: $(OUT)%.o
+	$(Q)$(OBJCOPY) -j '.compile_time_request' -O binary $^ $@
 
-$(OUT)klipper.o: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)declfunc.lds
-	@echo "  Linking $@"
-	$(Q)$(CC) $(CFLAGS) -Wl,-r -Wl,-T,$(OUT)declfunc.lds -nostdlib $(patsubst %.c, $(OUT)src/%.o,$(src-y)) -o $@
-
-$(OUT)compile_time_request.o: $(OUT)klipper.o ./scripts/buildcommands.py
+$(OUT)compile_time_request.o: $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) ./scripts/buildcommands.py
 	@echo "  Building $@"
-	$(Q)$(OBJCOPY) -j '.compile_time_request' -O binary $< $(OUT)klipper.o.compile_time_request
-	$(Q)$(PYTHON) ./scripts/buildcommands.py -d $(OUT)klipper.dict $(OUT)klipper.o.compile_time_request $(OUT)compile_time_request.c
+	$(Q)cat $(patsubst %.c, $(OUT)src/%.o.ctr,$(src-y)) > $(OUT)klipper.compile_time_request
+	$(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)$(CC) $(CFLAGS) -c $(OUT)compile_time_request.c -o $@
 
-$(OUT)klipper.elf: $(OUT)klipper.o $(OUT)compile_time_request.o
+$(OUT)klipper.elf: $(patsubst %.c, $(OUT)src/%.o,$(src-y)) $(OUT)compile_time_request.o
 	@echo "  Linking $@"
-	$(Q)$(CC) $(CFLAGS) $(LDFLAGS) $^ -o $@
+	$(Q)$(CC) $^ $(CFLAGS_klipper.elf) -o $@
 
 ################ Kconfig rules
 

config/avrsim.cfg

@@ -1,7 +1,7 @@
 # Support for internal testing with the "simulavr" program.  To use
 # this config, compile the firmware for an AVR atmega644p, disable the
 # AVR watchdog timer, set the MCU frequency to 20000000, and set the
-# serial baud rate to 115200.
+# serial baud rate to 250000.
 
 [stepper_x]
 # Pins: PA5, PA4, PA1
@@ -42,11 +42,11 @@ step_pin: ar19
 dir_pin: ar18
 enable_pin: ar25
 step_distance: .004242
-max_velocity: 200000
-max_accel: 3000
+nozzle_diameter: 0.500
+filament_diameter: 3.500
 heater_pin: ar4
-thermistor_pin: analog1
-thermistor_type: EPCOS 100K B57560G104F
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog7
 control: pid
 pid_Kp: 22.2
 pid_Ki: 1.08
@@ -57,19 +57,17 @@ max_temp: 210
 
 [heater_bed]
 heater_pin: ar3
-thermistor_pin: analog0
-thermistor_type: EPCOS 100K B57560G104F
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog0
 control: watermark
 min_temp: 0
 max_temp: 110
 
 [fan]
 pin: ar14
-hard_pwm: 1
 
 [mcu]
 serial: /tmp/pseudoserial
-baud: 250000
 pin_map: arduino
 
 [printer]

config/example-corexy.cfg

@@ -0,0 +1,81 @@
+# This file serves as documentation for config parameters of corexy
+# style printers. One may copy and edit this file to configure a new
+# corexy printer. Only parameters unique to corexy printers are
+# described here - see the "example.cfg" file for description of
+# common config parameters.
+
+# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
+# FIRST. Incorrectly configured parameters may cause damage.
+
+# The stepper_x section is used to describe the X axis as well as the
+# stepper controlling the X+Y movement.
+[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
+
+[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: corexy
+#   This option must be "corexy" for corexy printers.
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30

config/example-delta.cfg

@@ -9,48 +9,58 @@
 
 # The stepper_a section describes the stepper controlling the front
 # left tower (at 210 degrees). This section also controls the homing
-# parameters (homing_speed, homing_retract_dist) and maximum tower
-# length (position_max) for all towers.
+# parameters (homing_speed, homing_retract_dist) for all towers.
 [stepper_a]
 step_pin: ar54
 dir_pin: ar55
 enable_pin: !ar38
 step_distance: .01
 endstop_pin: ^ar2
-homing_speed: 50.0
+homing_speed: 50
 position_endstop: 297.05
-position_max: 297.55
+#   Distance (in mm) between the nozzle and the bed when the nozzle is
+#   in the center of the build area and the endstop triggers. This
+#   parameter must be provided for stepper_a; for stepper_b and
+#   stepper_c this parameter defaults to the value specified for
+#   stepper_a.
+arm_length: 333.0
+#   Length (in mm) of the diagonal rod that connects this tower to the
+#   print head. This parameter must be provided for stepper_a; for
+#   stepper_b and stepper_c this parameter defaults to the value
+#   specified for stepper_a.
+#angle:
+#   This option specifies the angle (in degrees) that the tower is
+#   at. The default is 210 for stepper_a, 330 for stepper_b, and 90
+#   for stepper_c.
 
 # The stepper_b section describes the stepper controlling the front
-# right tower (at 330 degrees)
+# right tower (at 330 degrees).
 [stepper_b]
 step_pin: ar60
 dir_pin: ar61
 enable_pin: !ar56
 step_distance: .01
 endstop_pin: ^ar15
-position_endstop: 297.05
 
 # The stepper_c section describes the stepper controlling the rear
-# tower (at 90 degrees)
+# tower (at 90 degrees).
 [stepper_c]
 step_pin: ar46
 dir_pin: ar48
 enable_pin: !ar62
 step_distance: .01
 endstop_pin: ^ar19
-position_endstop: 297.05
 
 [extruder]
 step_pin: ar26
 dir_pin: ar28
 enable_pin: !ar24
 step_distance: .0022
-max_velocity: 200
-max_accel: 3000
+nozzle_diameter: 0.400
+filament_diameter: 1.750
 heater_pin: ar10
-thermistor_pin: analog13
-thermistor_type: ATC Semitec 104GT-2
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
 control: pid
 pid_Kp: 22.2
 pid_Ki: 1.08
@@ -60,36 +70,62 @@ max_temp: 250
 
 [heater_bed]
 heater_pin: ar8
-thermistor_pin: analog14
-thermistor_type: EPCOS 100K B57560G104F
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
 control: watermark
 min_temp: 0
 max_temp: 130
 
-# Extruder print fan (omit section if fan not present)
+# Print cooling fan (omit section if fan not present).
 #[fan]
 #pin: ar9
-#hard_pwm: 1
 
 [mcu]
 serial: /dev/ttyACM0
-baud: 250000
 pin_map: arduino
 
 [printer]
 kinematics: delta
-#   This option must be "delta" for linear delta printers
+#   This option must be "delta" for linear delta printers.
 max_velocity: 300
+#   Maximum velocity (in mm/s) of the toolhead relative to the
+#   print. This parameter must be specified.
 max_accel: 3000
-max_z_velocity: 200
+#   Maximum acceleration (in mm/s^2) of the toolhead relative to the
+#   print. This parameter must be specified.
+max_z_velocity: 150
 #   For delta printers this limits the maximum velocity (in mm/s) of
 #   moves with z axis movement. This setting can be used to reduce the
 #   maximum speed of up/down moves (which require a higher step rate
-#   than other moves on a delta printer).
-delta_arm_length: 333.0
-#   Length (in mm) of the diagonal rods that connect the linear axes
-#   to the print head
+#   than other moves on a delta printer). The default is to use
+#   max_velocity for max_z_velocity.
+#minimum_z_position: 0
+#   The minimum Z position that the user may command the head to move
+#   to.  The default is 0.
 delta_radius: 174.75
 #   Radius (in mm) of the horizontal circle formed by the three linear
 #   axis towers. This parameter may also be calculated as:
 #    delta_radius = smooth_rod_offset - effector_offset - carriage_offset
+#   This parameter must be provided.
+
+# The delta_calibrate section enables a DELTA_CALIBRATE extended
+# g-code command that can calibrate the tower endstop positions and
+# angles.
+[delta_calibrate]
+radius: 50
+#   Radius (in mm) of the area that may be probed. This is the radius
+#   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 calibration.
+#   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.
+#samples: 1
+#   The number of times to probe each point.  The probed z-values will
+#   be averaged. The default is to probe 1 time.
+#sample_retract_dist: 2.0
+#   The distance (in mm) to retract between each sample if sampling
+#   more than once. The default is 2mm.

config/example-menu.cfg

@@ -0,0 +1,186 @@
+# 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]
+#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 or on exit from edit mode.
+#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 > 1s 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.
+
+#[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.
+#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.

config/example-multi-mcu.cfg

@@ -0,0 +1,87 @@
+# This file contains an example configuration with three
+# micro-controllers simultaneously controlling a single printer.
+
+# See both the example.cfg and example-extras.cfg file for a
+# description of available parameters.
+
+
+# The main micro-controller is used as the timing source for all the
+# micro-controllers on the printer. Typically, both the X and Y axes
+# are connected to the main micro-controller.
+[mcu]
+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/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/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0
+pin_map: arduino
+
+[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: zboard:ar46
+dir_pin: zboard:ar48
+enable_pin: !zboard:ar62
+step_distance: .0025
+endstop_pin: ^zboard:ar18
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: auxboard:ar26
+dir_pin: auxboard:ar28
+enable_pin: !auxboard:ar24
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: auxboard:ar10
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: auxboard:analog13
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: auxboard:ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: auxboard:analog14
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: auxboard:ar9
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100

config/example.cfg

@@ -1,6 +1,9 @@
 # This file serves as documentation for config parameters. One may
 # copy and edit this file to configure a new cartesian style
-# printer. For delta style printers, see the "example-delta.cfg" file.
+# printer. For delta style printers, see the "example-delta.cfg"
+# file. For corexy/h-bot style printers, see the "example-corexy.cfg"
+# file. Only common config sections are described here - see the
+# "example-extras.cfg" file for configuring less common devices.
 
 # DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
 # FIRST. Incorrectly configured parameters may cause damage.
@@ -16,76 +19,70 @@
 
 
 # The stepper_x section is used to describe the stepper controlling
-# the X axis in a cartesian robot
+# the X axis in a cartesian robot.
 [stepper_x]
-step_pin: ar29
-#   Step GPIO pin (triggered high)
-dir_pin: !ar28
-#   Direction GPIO pin (high indicates positive direction)
-enable_pin: !ar25
-#   Enable pin (default is enable high; use ! to indicate enable low)
+step_pin: ar54
+#   Step GPIO pin (triggered high). This parameter must be provided.
+dir_pin: ar55
+#   Direction GPIO pin (high indicates positive direction). This
+#   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
+#   driver must always be enabled.
 step_distance: .0225
-#   Distance in mm that each step causes the axis to travel
-endstop_pin: ^ar0
-#   Endstop switch detection pin
-homing_speed: 50.0
-#   Maximum velocity (in mm/s) of the stepper when homing
-homing_retract_dist: 5.0
-#   Distance to backoff (in mm) before homing a second time during homing
-homing_positive_dir: False
-#   If true, homes in a positive direction (away from zero)
-homing_stepper_phases: 0
-#   One may optionally set this to the number of phases of the stepper
-#   motor driver (which is the number of micro-steps multiplied by
-#   four). When set, the phase of the stepper driver will be used
-#   during homing to improve the accuracy of the endstop switch.
-homing_endstop_accuracy: 0.200
-#   Sets the expected accuracy (in mm) of the endstop. This represents
-#   the maximum error distance the endstop may trigger (eg, if an
-#   endstop may occasionally trigger 100um early or up to 100um late
-#   then set this to 0.200 for 200um). This setting is used with
-#   homing_stepper_phases and is only useful if that parameter is also
-#   configured.
-#homing_endstop_phase: 0
-#   This specifies the phase of the stepper motor driver to expect
-#   when hitting the endstop. This setting is only meaningful if
-#   homing_stepper_phases is also set. Only set this value if one is
-#   sure the stepper motor driver is reset every time the mcu is
-#   reset. If this is not set, but homing_stepper_phases is set, then
-#   the stepper phase will be detected on the first home and that
-#   phase will be used on all subsequent homes.
-position_min: -0.25
+#   Distance in mm that each step causes the axis to travel. This
+#   parameter must be provided.
+endstop_pin: ^ar3
+#   Endstop switch detection pin. This parameter must be provided for
+#   the X, Y, and Z steppers on cartesian style printers.
+#position_min: 0
 #   Minimum valid distance (in mm) the user may command the stepper to
-#   move to
+#   move to.  The default is 0mm.
 position_endstop: 0
-#   Location of the endstop (in mm)
+#   Location of the endstop (in mm). This parameter must be provided
+#   for the X, Y, and Z steppers on cartesian style printers.
 position_max: 200
 #   Maximum valid distance (in mm) the user may command the stepper to
-#   move to
+#   move to. This parameter must be provided for the X, Y, and Z
+#   steppers on cartesian style printers.
+#homing_speed: 5.0
+#   Maximum velocity (in mm/s) of the stepper when homing. The default
+#   is 5mm/s.
+#homing_retract_dist: 5.0
+#   Distance to backoff (in mm) before homing a second time during
+#   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
+#   default is true if position_endstop is near position_max and false
+#   if near position_min.
 
 # The stepper_y section is used to describe the stepper controlling
 # the Y axis in a cartesian robot. It has the same settings as the
-# stepper_x section
+# stepper_x section.
 [stepper_y]
-step_pin: ar27
-dir_pin: ar26
-enable_pin: !ar25
+step_pin: ar60
+dir_pin: !ar61
+enable_pin: !ar56
 step_distance: .0225
-endstop_pin: ^ar1
-position_min: -0.25
+endstop_pin: ^ar14
 position_endstop: 0
 position_max: 200
 
 # The stepper_z section is used to describe the stepper controlling
 # the Z axis in a cartesian robot. It has the same settings as the
-# stepper_x section
+# stepper_x section.
 [stepper_z]
-step_pin: ar23
-dir_pin: !ar22
-enable_pin: !ar25
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
 step_distance: .005
-endstop_pin: ^ar2
-position_min: 0.1
+endstop_pin: ^ar18
 position_endstop: 0.5
 position_max: 200
 
@@ -93,119 +90,223 @@ position_max: 200
 # controlling the printer extruder and the heater parameters for the
 # nozzle. The stepper configuration has the same settings as the
 # stepper_x section and the heater configuration has the same settings
-# as the heater_bed section
+# as the heater_bed section (described below).
 [extruder]
-step_pin: ar19
-dir_pin: ar18
-enable_pin: !ar25
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
 step_distance: .004242
-max_velocity: 200000
-#   Maximum velocity (in mm/s) of the extruder motor for extrude only
-#   moves.
-max_accel: 3000
-#   Maximum acceleration (in mm/s^2) of the extruder motor for extrude
-#   only moves.
-#
-# The remaining variables describe the extruder heater
-pressure_advance: 0.0
+nozzle_diameter: 0.500
+#   Diameter of the nozzle orifice (in mm). This parameter must be
+#   provided.
+filament_diameter: 3.500
+#   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 (in mm^2) of an extrusion cross section (eg,
+#   extrusion width multiplied by layer height). This setting prevents
+#   excessive amounts of extrusion during relatively small XY moves.
+#   If a move requests an extrusion rate that would exceed this value
+#   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 a retraction or
+#   extrude-only move may have. If a retraction or extrude-only move
+#   requests a distance greater than this value it will cause an error
+#   to be returned. The default is 50mm.
+#max_extrude_only_velocity:
+#max_extrude_only_accel:
+#   Maximum velocity (in mm/s) and acceleration (in mm/s^2) of the
+#   extruder motor for retractions and extrude-only moves. These
+#   settings do not place any limit on normal printing moves. If not
+#   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
 #   during deceleration. It is measured in millimeters per
-#   millimeter/second
-heater_pin: ar4
-#   PWM output pin controlling the heater
-thermistor_pin: analog1
-#   Analog input pin connected to thermistor
-thermistor_type: EPCOS 100K B57560G104F
-#   Type of thermistor (see klippy/heater.py for available types)
-pullup_resistor: 4700
-#   The resistance (in ohms) of the pullup attached to the thermistor
+#   millimeter/second. The default is 0, which disables pressure
+#   advance.
+#pressure_advance_lookahead_time: 0.010
+#   A time (in seconds) to "look ahead" at future extrusion moves when
+#   calculating pressure advance. This is used to reduce the
+#   application of pressure advance during cornering moves that would
+#   otherwise cause retraction followed immediately by pressure
+#   buildup. This setting only applies if pressure_advance is
+#   non-zero. The default is 0.010 (10 milliseconds).
+#
+# The remaining variables describe the extruder heater.
+heater_pin: ar10
+#   PWM output pin controlling the heater. This parameter must be
+#   provided.
+#max_power: 1.0
+#   The maximum power (expressed as a value from 0.0 to 1.0) that the
+#   heater_pin may be set to. The value 1.0 allows the pin to be set
+#   fully 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 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", "Honeywell 100K
+#   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.
+#pullup_resistor: 4700
+#   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.
+#adc_voltage: 5.0
+#   The ADC comparison voltage. This parameter is only valid when the
+#   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)
+#   Control algorithm (either pid or watermark). This parameter must
+#   be provided.
 pid_Kp: 22.2
-#   Kp is the "proportional" constant for the pid
+#   Kp is the "proportional" constant for the pid. This parameter must
+#   be provided for PID heaters.
 pid_Ki: 1.08
-#   Ki is the "integral" constant for the pid
+#   Ki is the "integral" constant for the pid. This parameter must be
+#   provided for PID heaters.
 pid_Kd: 114
-#   Kd is the "derivative" constant for the pid
-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
-pid_integral_max: 255
-#   The maximum "windup" the integral term may accumulate
-min_extrude_temp: 170
+#   Kd is the "derivative" constant for the pid. This parameter must
+#   be provided for PID heaters.
+#pid_integral_max:
+#   The maximum "windup" the integral term may accumulate. The default
+#   is to use the same value as max_power.
+#pwm_cycle_time: 0.100
+#   Time in seconds for each software PWM cycle of the heater. It is
+#   not recommended to set this unless there is an electrical
+#   requirement to switch the heater faster than 10 times a second.
+#   The default is 0.100 seconds.
+#min_extrude_temp: 170
 #   The minimum temperature (in Celsius) at which extruder move
-#   commands may be issued
+#   commands may be issued. The default is 170 Celsius.
 min_temp: 0
-#   Minimum temperature in Celsius (mcu will shutdown if not met)
 max_temp: 210
-#   Maximum temperature (mcu will shutdown if temperature is above
-#   this value)
+#   The maximum range of valid temperatures (in Celsius) that the
+#   heater must remain within. This controls a safety feature
+#   implemented in the micro-controller code - should the measured
+#   temperature ever fall outside this range then the micro-controller
+#   will go into a shutdown state. This check can help detect some
+#   heater and sensor hardware failures. Set this range just wide
+#   enough so that reasonable temperatures do not result in an
+#   error. These parameters must be provided.
 
 # The heater_bed section describes a heated bed (if present - omit
 # section if not present).
 [heater_bed]
-heater_pin: ar3
-thermistor_pin: analog0
-thermistor_type: EPCOS 100K B57560G104F
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
 control: watermark
-max_delta: 2.0
-#   The number of degrees in Celsius above the target temperature
-#   before disabling the heater as well as the number of degrees below
-#   the target before re-enabling the heater.
+#max_delta: 2.0
+#   On 'watermark' controlled heaters this is the number of degrees in
+#   Celsius above the target temperature before disabling the heater
+#   as well as the number of degrees below the target before
+#   re-enabling the heater. The default is 2 degrees Celsius.
 min_temp: 0
 max_temp: 110
 
-# Extruder print fan (omit section if fan not present)
+# Print cooling fan (omit section if fan not present).
 [fan]
-pin: ar14
-#   PWM output pin controlling the heater
-hard_pwm: 1
-#   Set this value to force hardware PWM instead of software PWM. Set
-#   to 1 to force a hardware PWM at the fastest rate; set to a higher
-#   number (eg, 1024) to force hardware PWM with the given cycle time
-#   in clock ticks.
-kick_start_time: 0.100
+pin: ar9
+#   PWM output pin controlling the fan. This parameter must be
+#   provided.
+#max_power: 1.0
+#   The maximum power (expressed as a value from 0.0 to 1.0) that the
+#   pin may be set to. The value 1.0 allows the pin to be set fully
+#   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. 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
+#   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)
+#   it (helps get the fan spinning). The default is 0.100 seconds.
 
-# Micro-controller information
+# Micro-controller information.
 [mcu]
 serial: /dev/ttyACM0
-#   The serial port to connect to the MCU
-baud: 250000
-#   The baud rate to use
+#   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
-#   This option may be used to enable Arduino pin name aliases
-custom:
-#   This option may be used to specify a set of custom
-#   micro-controller commands to be sent at the start of the
-#   connection. It may be used to configure the initial settings of
-#   LEDs, to configure micro-stepping pins, to configure a digipot,
-#   etc.
+#   This option may be used to enable Arduino pin name aliases. The
+#   default is to not enable the aliases.
+#restart_method:
+#   This controls the mechanism the host will use to reset the
+#   micro-controller. The choices are 'arduino', 'rpi_usb', and
+#   'command'. The 'arduino' method (toggle DTR) is common on Arduino
+#   boards and clones. The 'rpi_usb' method is useful on Raspberry Pi
+#   boards with micro-controllers powered over USB - it briefly
+#   disables power to all USB ports to accomplish a micro-controller
+#   reset. The 'command' method involves sending a Klipper command to
+#   the micro-controller so that it can reset itself. The default is
+#   'arduino' if the micro-controller communicates over a serial port,
+#   'command' otherwise.
 
-# The printer section controls high level printer settings
+# The printer section controls high level printer settings.
 [printer]
 kinematics: cartesian
-#   This option must be "cartesian" for cartesian printers
+#   This option must be "cartesian" for cartesian printers.
 max_velocity: 500
 #   Maximum velocity (in mm/s) of the toolhead (relative to the
-#   print)
+#   print). This parameter must be specified.
 max_accel: 3000
 #   Maximum acceleration (in mm/s^2) of the toolhead (relative to the
-#   print)
-max_z_velocity: 250
+#   print). This parameter must be specified.
+#max_accel_to_decel:
+#   A pseudo acceleration (in mm/s^2) controlling how fast the
+#   toolhead may go from acceleration to deceleration. It is used to
+#   reduce the top speed of short zig-zag moves (and thus reduce
+#   printer vibration from these moves). The default is half of
+#   max_accel.
+max_z_velocity: 25
 #   For cartesian printers this sets the maximum velocity (in mm/s) of
 #   movement along the z axis. This setting can be used to restrict
-#   the maximum speed of the z stepper motor on cartesian printers.
+#   the maximum speed of the z stepper motor on cartesian
+#   printers. The default is to use max_velocity for max_z_velocity.
 max_z_accel: 30
 #   For cartesian printers this sets the maximum acceleration (in
 #   mm/s^2) of movement along the z axis. It limits the acceleration
-#   of the z stepper motor on cartesian printers.
-motor_off_time: 60
-#   Time (in seconds) of idle time before the printer will try to
-#   disable active motors.
-junction_deviation: 0.02
-#   Distance (in mm) used to control the internal approximated
-#   centripetal velocity cornering algorithm. A larger number will
-#   permit higher "cornering speeds" at the junction of two moves.
+#   of the z stepper motor on cartesian printers. The default is to
+#   use max_accel for max_z_accel.
+#square_corner_velocity: 5.0
+#   The maximum velocity (in mm/s) that the toolhead may travel a 90
+#   degree corner at. A non-zero value can reduce changes in extruder
+#   flow rates by enabling instantaneous velocity changes of the
+#   toolhead during cornering. This value configures the internal
+#   centripetal velocity cornering algorithm; corners with angles
+#   larger than 90 degrees will have a higher cornering velocity while
+#   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-cramps.cfg

@@ -0,0 +1,89 @@
+# This file contains an example configuration for a Beaglebone PRU
+# micro-controller attached to a CRAMPS board.
+
+# THIS FILE HAS NOT BEEN TESTED - PROCEED WITH CAUTION!
+
+# NOTE: Klipper does not alter the input/output state of the
+# Beaglebone pins and it does not control their pull-up resistors.  In
+# order to set the pin state one must use a "device tree overlay" or
+# use the config-pin program.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: P8_13
+dir_pin: P8_12
+enable_pin: !P9_14
+step_distance: .0125
+endstop_pin: ^P8_8
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P8_15
+dir_pin: P8_14
+enable_pin: !P9_14
+step_distance: .0125
+endstop_pin: ^P8_10
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P8_19
+dir_pin: P8_18
+enable_pin: !P9_14
+step_distance: .0025
+endstop_pin: ^P9_13
+position_endstop: 0
+position_max: 200
+
+[extruder]
+step_pin: P9_16
+dir_pin: P9_12
+enable_pin: !P9_14
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: P9_15
+sensor_type: EPCOS 100K B57560G104F
+pullup_resistor: 2000
+sensor_pin: host:analog5
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: P8_11
+sensor_type: EPCOS 100K B57560G104F
+pullup_resistor: 2000
+sensor_pin: host:analog4
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: P9_41
+
+[mcu]
+serial: /dev/rpmsg_pru30
+pin_map: beaglebone
+
+[mcu host]
+serial: /tmp/klipper_host_mcu
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[output_pin machine_enable]
+pin: P9_23
+value: 1
+shutdown_value: 0

config/generic-duet2.cfg

@@ -0,0 +1,362 @@
+# This file contains common pin mappings for Duet2 boards. 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    |  PA25    |  PD21     |  PA17*       |  PC28       |
+# 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]
+#address: 0x3E
+#
+## 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
+# Pins marked with two asterisks (**) share pins with drive E6.
+# 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 # shared between all steppers
+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: 1 # All TMC2660 drivers are connected to USART1, which is bus 1 on the sam4e port
+microsteps: 16
+interpolate: True # 1/16 micro-steps interpolated to 1/256
+run_current: 1.000
+idle_current_percent: 20
+
+[stepper_y]
+step_pin: PD7
+dir_pin: !PD12
+enable_pin: !PC6
+step_distance: .0125
+endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[tmc2660 stepper_y]
+cs_pin: PC9
+spi_bus: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+idle_current_percent: 20
+
+[stepper_z]
+step_pin: PD8
+dir_pin: PD13
+enable_pin: !PC6
+step_distance: .0025
+endstop_pin: ^PD29
+position_endstop: 0.5
+position_max: 200
+
+[tmc2660 stepper_z]
+cs_pin: PC10
+spi_bus: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+#On drive E4
+[stepper_z1]
+step_pin: PD0
+dir_pin: PD16
+enable_pin: !PC6
+step_distance: .0025
+
+[tmc2660 stepper_z1]
+cs_pin: PD25
+spi_bus: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+#On drive E5
+[stepper_z2]
+step_pin: PD3
+dir_pin: !PD17
+enable_pin: !PC6
+step_distance: .0025
+
+[tmc2660 stepper_z2]
+cs_pin: PD26
+spi_bus: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+#On drive E6
+[stepper_z3]
+step_pin: PD21
+dir_pin: !PA25
+enable_pin: !PC6
+step_distance: .0025
+
+[tmc2660 stepper_z3]
+cs_pin: PC28
+spi_bus: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+#On drive E0
+[extruder0]
+step_pin: PD5
+dir_pin: PA1
+enable_pin: !PC6
+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: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+#On drive E1
+[extruder1]
+step_pin: PD4
+dir_pin: PD9
+enable_pin: !PC6
+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: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+# On drive E2
+[extruder2]
+step_pin: PD2
+dir_pin: !PD28
+enable_pin: !PC6
+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: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+# On drive E3
+[extruder3]
+step_pin: PD1
+dir_pin: !PD22
+enable_pin: !PC6
+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: 1
+microsteps: 16
+interpolate: True
+run_current: 1.000
+
+[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/ttyACM0
+restart_method: command
+
+[sx1509 duex]
+address: 0x3E # 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-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-melzi.cfg

@@ -0,0 +1,79 @@
+# This file contains common pin mappings for Melzi v2.0 boards. 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: 200
+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: 200
+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: 200
+
+[extruder]
+step_pin: PB1
+dir_pin: PB0
+enable_pin: !PD6
+step_distance: .002
+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: 250
+
+[heater_bed]
+heater_pin: PD2
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PA6
+control: watermark
+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

config/generic-mini-rambo.cfg

@@ -0,0 +1,109 @@
+# This file contains common pin mappings for Mini-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: PL1
+enable_pin: !PA7
+step_distance: .005
+endstop_pin: ^PB6
+#endstop_pin: ^PC7
+position_endstop: 0
+position_max: 250
+
+[stepper_y]
+step_pin: PC1
+dir_pin: !PL0
+enable_pin: !PA6
+step_distance: .005
+endstop_pin: ^PB5
+#endstop_pin: ^PA2
+position_endstop: 0
+position_max: 210
+
+[stepper_z]
+step_pin: PC2
+dir_pin: PL2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PB4
+#endstop_pin: ^PA1
+position_endstop: 0.5
+position_max: 200
+
+[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
+
+[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
+
+[output_pin stepper_xy_current]
+pin: PL3
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.3
+
+[output_pin stepper_z_current]
+pin: PL4
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.3
+
+[output_pin stepper_e_current]
+pin: PL5
+pwm: True
+scale: 2.0
+cycle_time: .000030
+hardware_pwm: True
+static_value: 1.25
+
+[static_digital_output stepper_config]
+pins:
+    PG1, PG0,
+    PK7, PG2,
+    PK6, PK5,
+    PK3, PK4
+
+[static_digital_output yellow_led]
+pins: !PB7

config/generic-printrboard.cfg

@@ -0,0 +1,76 @@
+# This file contains common pin mappings for Printrboard boards (rev B
+# through D). To use this config the firmware should be compiled for
+# the AVR at90usb1286.
+
+# Note that the "make flash" command is unlikely to work on the
+# Printrboard. See the RepRap Printrboard wiki page for instructions
+# on flashing.
+
+# See the example.cfg file for a description of available parameters.
+
+[stepper_x]
+step_pin: PA0
+dir_pin: !PA1
+enable_pin: !PE7
+step_distance: .0125
+endstop_pin: ^PE3
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PA2
+dir_pin: PA3
+enable_pin: !PE6
+step_distance: .0125
+endstop_pin: ^PB0
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PA4
+dir_pin: !PA5
+enable_pin: !PC7
+step_distance: .0025
+endstop_pin: ^PE4
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PA6
+dir_pin: PA7
+enable_pin: !PC3
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF1
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PC4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF0
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PC6
+
+[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-radds.cfg

@@ -0,0 +1,109 @@
+# 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
+
+# "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

@@ -0,0 +1,126 @@
+# This file contains common pin mappings for 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: PL1
+enable_pin: !PA7
+step_distance: .0125
+endstop_pin: ^PB6
+#endstop_pin: ^PA2
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC1
+dir_pin: !PL0
+enable_pin: !PA6
+step_distance: .0125
+endstop_pin: ^PB5
+#endstop_pin: ^PA1
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: PC2
+dir_pin: PL2
+enable_pin: !PA5
+step_distance: .0025
+endstop_pin: ^PB4
+#endstop_pin: ^PC7
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: PC3
+dir_pin: PL6
+enable_pin: !PA4
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PH6
+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
+
+#[extruder1]
+#step_pin: PC4
+#dir_pin: PL7
+#enable_pin: !PA3
+#heater_pin: PH4
+#sensor_pin: PF1
+#...
+
+[heater_bed]
+heater_pin: PE5
+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
+
+[ad5206 stepper_digipot]
+enable_pin: PD7
+# Scale the config so that the channel value can be specified in amps.
+# (For Rambo v1.0d boards, use 1.56 instead.)
+scale: 2.08
+# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
+channel_1: 1.34
+channel_2: 1.0
+channel_4: 1.1
+channel_5: 1.1
+channel_6: 1.1
+
+# Enable 16 micro-steps on steppers X, Y, Z, E0, E1
+[static_digital_output stepper_config]
+pins:
+    PG1, PG0,
+    PK7, PG2,
+    PK6, PK5,
+    PK3, PK4,
+    PK1, PK2
+
+[static_digital_output yellow_led]
+pins: !PB7
+
+# "RepRapDiscount 2004 Smart Controller" type displays
+#[display]
+#lcd_type: hd44780
+#rs_pin: PG4
+#e_pin: PG3
+#d4_pin: PJ2
+#d5_pin: PJ3
+#d6_pin: PJ7
+#d7_pin: PJ4
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: PG4
+#sclk_pin: PJ2
+#sid_pin: PG3

config/generic-ramps.cfg

@@ -0,0 +1,105 @@
+# This file contains common pin mappings for RAMPS (v1.3 and later)
+# boards. RAMPS boards typically use a firmware compiled for the AVR
+# atmega2560 (though other AVR chips are also possible).
+
+# 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
+#endstop_pin: ^ar2
+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
+#endstop_pin: ^ar15
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^ar18
+#endstop_pin: ^ar19
+position_endstop: 0.5
+position_max: 200
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .002
+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
+
+#[extruder1]
+#step_pin: ar36
+#dir_pin: ar34
+#enable_pin: !ar30
+#heater_pin: ar9
+#sensor_pin: analog15
+#...
+
+[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: 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: ar16
+#e_pin: ar17
+#d4_pin: ar23
+#d5_pin: ar25
+#d6_pin: ar27
+#d7_pin: ar29
+#encoder_pins: ^ar31, ^ar33
+#click_pin: ^!ar35
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+#[display]
+#lcd_type: st7920
+#cs_pin: ar16
+#sclk_pin: ar23
+#sid_pin: ar17
+#encoder_pins: ^ar31, ^ar33
+#click_pin: ^!ar35

config/generic-re-arm.cfg

@@ -0,0 +1,106 @@
+# This file contains common pin mappings for Re-Arm. To use this
+# config, the firmware should be compiled for the LPC176x.
+
+# The "make flash" command does not work on the Re-Arm.  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 Re-Arm
+# with that SD card.
+
+# 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

@@ -0,0 +1,134 @@
+# This file contains an example configuration for the Replicape rev B3
+# board. To use this config, one must compile and install the
+# micro-controller code for the "Beaglebone PRU", and then compile and
+# install the micro-controller code a second time for a "Linux
+# process".
+
+# NOTE: Klipper does not alter the input/output state of the
+# Beaglebone pins and it does not control their pull-up resistors.
+# Typically the correct settings are automatically applied when the
+# Beaglebone detects the Replicape board, but if changes are needed
+# they must be specified in a "device tree overlay" or via the
+# config-pin program.
+
+# See the example.cfg file for a description of available parameters.
+
+[mcu]
+serial: /dev/rpmsg_pru30
+pin_map: beaglebone
+
+[mcu host]
+serial: /tmp/klipper_host_mcu
+
+# The "replicape" config section adds "replicape:stepper_x_enable"
+# virtual stepper enable pins (for steppers x, y, z, e, and h) and
+# "replicape:power_x" PWM output pins (for hotbed, e, h, fan0, fan1,
+# fan2, and fan3) that may then be used elsewhere in the config file.
+[replicape]
+revision: B3
+#   The replicape hardware revision. Currently only revision "B3" is
+#   supported. This parameter must be provided.
+#enable_pin: !P9_41
+#   The replicape global enable pin. The default is !P9_41.
+host_mcu: host
+#   The name of the mcu config section that communicates with the
+#   Klipper "linux process" mcu instance. This parameter must be
+#   provided.
+#standstill_power_down: False
+#   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,
+#   spread2, 4, 16, spread4, spread16, stealth4, and stealth16. The
+#   default is disable.
+stepper_x_current: 0.5
+#   The configured maximum current (in Amps) of the stepper motor
+#   driver. This parameter must be provided if the stepper is not in a
+#   disable mode.
+#stepper_x_chopper_off_time_high: False
+#   This parameter controls the CFG0 pin of the stepper motor driver
+#   (True sets CFG0 high, False sets it low). The default is False.
+#stepper_x_chopper_hysteresis_high: False
+#   This parameter controls the CFG4 pin of the stepper motor driver
+#   (True sets CFG4 high, False sets it low). The default is False.
+#stepper_x_chopper_blank_time_high: True
+#   This parameter controls the CFG5 pin of the stepper motor driver
+#   (True sets CFG5 high, False sets it low). The default is True.
+stepper_y_microstep_mode: spread16
+stepper_y_current: 0.5
+stepper_z_microstep_mode: spread16
+stepper_z_current: 0.5
+stepper_e_microstep_mode: 16
+stepper_e_current: 0.5
+
+[stepper_x]
+step_pin: P8_17
+dir_pin: P8_26
+enable_pin: replicape:stepper_x_enable
+step_distance: .0125
+endstop_pin: ^P9_25
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_y]
+step_pin: P8_12
+dir_pin: P8_19
+enable_pin: replicape:stepper_y_enable
+step_distance: .0125
+endstop_pin: ^P9_23
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[stepper_z]
+step_pin: P8_13
+dir_pin: P8_14
+enable_pin: replicape:stepper_z_enable
+step_distance: .0025
+endstop_pin: ^P9_13
+position_endstop: 0
+position_max: 200
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30
+
+[extruder]
+step_pin: P9_12
+dir_pin: P8_15
+enable_pin: replicape:stepper_e_enable
+step_distance: .002
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: replicape:power_e
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: host:analog4
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: replicape:power_hotbed
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: host:analog6
+control: watermark
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: replicape:power_fan0

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: ar3
+#enable_pin: !ar27
+#heater_pin: ar9
+#sensor_pin: analog14
+#...
+
+#[extruder2]
+#step_pin: ar29
+#dir_pin: ar6
+#enable_pin: !ar39
+#heater_pin: ar9
+#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,115 @@
+# This file contains common pin mappings for Smoothieboard. To use
+# this config, the firmware should be compiled for the LPC176x.
+
+# The "make flash" command does not work on the Smoothieboard.
+# 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 Smoothieboard with that SD card.
+
+# 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: 88
+# 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: 90
+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-2018.cfg

@@ -0,0 +1,222 @@
+# This file is an example configuration for the Voron 2 CoreXY printer
+# running on two RAMPS boards. This file was created by "Maglin".
+# X/Y/E steppers/endstops/thermisters/heaters are on one MCU/RAMPS
+# board while Z steppers/mechanical switch/endstop_pin are on the
+# second MCU/RAMPS labeled z.
+
+# 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 parameters.
+
+[mcu]
+# mcu for X/Y/E steppers main MCU
+serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
+pin_map: arduino
+
+[mcu z]
+# mcu for the Z steppers
+serial: /dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.0-port0
+pin_map: arduino
+
+[stepper_x]
+# use preceding ! to invert logic and ^ to activate internal 5V pullup
+# this is for all pin definitions.  Not all pins have interal pullups
+step_pin: ar54
+dir_pin: ar55
+enable_pin: !ar38
+step_distance: 0.0125
+endstop_pin: ^ar2
+position_min: 0
+position_endstop: 248
+position_max: 248
+homing_speed: 50
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: 0.0125
+endstop_pin: ^ar15
+position_min: -5
+position_endstop: 245
+position_max: 245
+homing_speed: 50
+
+[stepper_z]
+# X stepper pins on MCU Z
+step_pin: z:ar54
+dir_pin: z:ar55
+enable_pin: !z:ar38
+step_distance: 0.00625
+# probe:z_virtual_endstop is a virtual pin definition only available if
+# a probe section is defined
+#endstop_pin: probe:z_virtual_endstop
+# mechanical switch on mcu Z X min endstop pin
+endstop_pin: ^z:ar3
+position_endstop: -0.376
+position_min: -5
+position_max: 245
+homing_speed: 12
+
+[stepper_z1]
+# Y stepper pins on MCU Z
+step_pin: z:ar60
+dir_pin: !z:ar61
+enable_pin: !z:ar56
+step_distance: 0.00625
+
+[stepper_z2]
+# Z stepper pins on MCU Z
+step_pin: z:ar46
+dir_pin: z:ar48
+enable_pin: !z:ar62
+step_distance: 0.00625
+
+[stepper_z3]
+# E0 stepper pins on MCU Z
+step_pin: z:ar26
+dir_pin: !z:ar28
+enable_pin: !z:ar24
+step_distance: 0.00625
+
+# extended G-Code command Z_TILT_ADJUST can be used to level gantry
+[z_tilt]
+# belt locations from origin 0,0
+z_positions:
+    -56,-17
+    -56,322
+    311,322
+    311,-17
+# probing locations for gantry leveling
+points:
+    50,50
+    50,195
+    195,195
+    195,50
+# travel speed between probe points
+speed: 150
+# Move Z to this position for safe probing
+horizontal_move_z: 15
+
+# this is required for gantry leveling and replaces your G28 command
+# with the gcode used here.  Used to home X/Y/Z with mechanical switches
+[homing_override]
+set_position_z: 0
+gcode:
+    G90
+    G0 Z15 F600
+    G28 X0 Y0
+    G0 X248 Y225 F3000
+    G28 Z
+    G0 Z15 F6000
+
+# macro to level the gantry.  use G32 in the terminal to call
+[gcode_macro g32]
+gcode:
+    Z_TILT_ADJUST
+    Z_TILT_ADJUST
+    Z_TILT_ADJUST
+    G28
+    G0 X125 Y125 Z125 F3600
+
+# Use print_start for you slicer starting script
+[gcode_macro print_start]
+gcode:
+    G1 X0 Y15 Z0.3 F7000
+    G92 E0
+    G1 E14 F600
+    G92 E0
+    G1 X60.0 E9.0 F1000.0
+    G1 X100.0 E12.5 F1000.0
+    G1 E12 F1000.0
+    G92 E-0.5
+
+# Use print_end for you slicer ending script
+[gcode_macro print_end]
+gcode:
+    M104 S0
+    M140 S0
+    M107
+    G92 E0
+    G91
+    G1 Z10 E-10 F3000
+    G90
+    G0 X125 Y245 F1000
+
+[extruder]
+# on E0 stepper pins of main MCU
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: 0.003339
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+max_extrude_only_distance: 100.0
+heater_pin: ar10
+max_power: 1.0
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_Kp: 21.759
+pid_Ki: 1.107
+pid_Kd: 106.889
+min_temp: 0
+max_temp: 300
+
+# thermally controlled hotend fan
+[heater_fan my_nozzle_fan]
+# Located on Z MCU on fan D9
+pin: z:ar9
+
+[probe]
+# Z_Min pins on MCU Z (must be on same MCU as steppers)
+pin: ^!z:ar18
+z_offset: 1.15
+speed: 2.0
+
+[heater_bed]
+heater_pin: ar8
+# NTC 100K MGB18-104F39050L32 is for Kenovo thermistors
+sensor_type: NTC 100K MGB18-104F39050L32
+sensor_pin: analog14
+# pid gives you better control over bed heat
+control: pid
+pid_Kp: 63.832
+pid_Ki: 3.404
+pid_Kd: 299.213
+min_temp: 0
+max_temp: 130
+
+# print cooling fan
+[fan]
+# On z MCU on extruder heater pin D10
+pin: z:ar10
+
+# "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
+
+# "RepRapDiscount 128x64 Full Graphic Smart Controller" type displays
+[display]
+lcd_type: st7920
+cs_pin: ar16
+sclk_pin: ar23
+sid_pin: ar17
+
+[printer]
+# settings below are the max and can't be commanded over in gcode
+kinematics: corexy
+max_velocity: 500
+max_accel: 3000
+max_z_velocity: 100
+max_z_accel: 50
+
+[idle_timeout]
+# high motor off time so I don't have to relevel gantry often
+timeout: 6000

config/makergear-m2-2012.cfg

@@ -1,106 +0,0 @@
-# Support for Makergear M2 printers circa 2012 that have the RAMBo
-# v1.0d electronics along with the V3A extruder.  The electronics use
-# Allegro A4984 stepper drivers with 1/8th micro-stepping.  To use
-# this config, the firmware should be compiled for the AVR atmega2560.
-
-[stepper_x]
-step_pin: PC0
-dir_pin: !PL1
-enable_pin: !PA7
-step_distance: .0225
-endstop_pin: ^!PB6
-homing_speed: 50.0
-homing_stepper_phases: 32
-homing_endstop_accuracy: .200
-position_min: -0.25
-position_endstop: 0.0
-position_max: 200
-
-[stepper_y]
-step_pin: PC1
-dir_pin: PL0
-enable_pin: !PA6
-step_distance: .0225
-endstop_pin: ^!PB5
-homing_speed: 50.0
-homing_stepper_phases: 32
-homing_endstop_accuracy: .200
-position_min: -0.25
-position_endstop: 0.0
-position_max: 250
-
-[stepper_z]
-step_pin: PC2
-dir_pin: !PL2
-enable_pin: !PA5
-step_distance: .005
-endstop_pin: ^!PB4
-homing_speed: 4.0
-homing_retract_dist: 2.0
-homing_stepper_phases: 32
-homing_endstop_accuracy: .050
-position_min: 0.1
-position_endstop: 0.7
-position_max: 200
-
-[extruder]
-step_pin: PC3
-dir_pin: PL6
-enable_pin: !PA4
-step_distance: .004242
-max_velocity: 200000
-max_accel: 3000
-pressure_advance: 0.07
-heater_pin: PH6
-thermistor_pin: PF0
-thermistor_type: EPCOS 100K B57560G104F
-control: pid
-pid_Kp: 7.0
-pid_Ki: 0.1
-pid_Kd: 12
-min_temp: 0
-max_temp: 210
-
-[heater_bed]
-heater_pin: PE5
-thermistor_pin: PF2
-thermistor_type: EPCOS 100K B57560G104F
-control: watermark
-min_temp: 0
-max_temp: 100
-
-[fan]
-pin: PH5
-hard_pwm: 1
-
-[mcu]
-serial: /dev/ttyACM0
-baud: 250000
-custom:
-  # Nozzle fan
-  set_pwm_out pin=PH3 cycle_ticks=1 value=155
-  # Turn off yellow led
-  set_digital_out pin=PB7 value=0
-  # Stepper micro-step pins
-  set_digital_out pin=PG1 value=1
-  set_digital_out pin=PG0 value=1
-  set_digital_out pin=PK7 value=1
-  set_digital_out pin=PG2 value=1
-  set_digital_out pin=PK6 value=1
-  set_digital_out pin=PK5 value=1
-  set_digital_out pin=PK3 value=1
-  set_digital_out pin=PK4 value=1
-  # Initialize digipot
-  send_spi_message pin=PD7 msg=0487 # X = ~0.75A
-  send_spi_message pin=PD7 msg=0587 # Y = ~0.75A
-  send_spi_message pin=PD7 msg=0387 # Z = ~0.75A
-  send_spi_message pin=PD7 msg=00A5 # E0
-  send_spi_message pin=PD7 msg=017D # E1
-
-[printer]
-kinematics: cartesian
-max_velocity: 500
-max_accel: 3000
-max_z_velocity: 250
-max_z_accel: 30
-motor_off_time: 600

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

@@ -0,0 +1,88 @@
+# This file contains common pin mappings for Anet A8 printer from 2016
+# and 2017. 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: .01
+endstop_pin: ^!PC2
+position_endstop: -30
+position_max: 220
+position_min: -30
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PD6
+step_distance: .01
+endstop_pin: ^!PC3
+position_endstop: -8
+position_min: -8
+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.5
+position_max: 240
+homing_speed: 20
+
+[extruder]
+step_pin: PB1
+dir_pin: PB0
+enable_pin: !PD6
+step_distance: .0105
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PA7
+control: pid
+pid_Kp: 2.151492
+pid_Ki: 0.633897
+pid_Kd: 230.042965
+min_temp: 0
+max_temp: 250
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PA6
+control: watermark
+min_temp: 0
+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: 100
+
+[display]
+lcd_type: hd44780
+rs_pin: PA3
+e_pin: PA2
+d4_pin: PD2
+d5_pin: PD3
+d6_pin: PC0
+d7_pin: PC1

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-i3-mega-2017.cfg

@@ -0,0 +1,93 @@
+# This file contains pin mappings for the Anycubic i3 Mega with
+# Ultrabase from 2017. (This config may work on an Anycubic i3 Mega v1
+# prior to the Ultrabase if you comment out the definition of the
+# endstop_pin in the stepper_z1 section.) 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: -5
+position_endstop: -5
+position_max: 210
+homing_speed: 30.0
+
+[stepper_y]
+step_pin: ar60
+dir_pin: ar61
+enable_pin: !ar56
+step_distance: .0125
+endstop_pin: ^!ar42
+position_endstop: 0
+position_max: 210
+homing_speed: 30.0
+
+[stepper_z]
+step_pin: ar46
+dir_pin: ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^!ar18
+position_endstop: 0.0
+position_max: 205
+homing_speed: 5.0
+
+[stepper_z1]
+step_pin: ar36
+dir_pin: ar34
+enable_pin: !ar30
+step_distance: .0025
+endstop_pin: ^!ar43
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .010799
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: ar10
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: analog13
+control: pid
+pid_Kp: 15.717
+pid_Ki: 0.569
+pid_Kd: 108.451
+min_temp: 0
+max_temp: 245
+
+[heater_fan extruder_fan]
+pin: ar44
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_Kp: 74.883
+pid_Ki: 1.809
+pid_Kd: 775.038
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 10
+max_z_accel: 60
+
+[heater_fan stepstick_fan]
+pin: ar7

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

@@ -0,0 +1,90 @@
+# This file contains common pin mappings for the 2017 Creality
+# CR-10. 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: 300
+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: 400
+
+[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: EPCOS 100K B57560G104F
+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-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: EPCOS 100K B57560G104F
+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

@@ -0,0 +1,83 @@
+# This file contains pin mappings for the 2017 Creality CR-10S. 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_endstop: 0
+position_max: 300
+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: 300
+homing_speed: 50
+
+[stepper_z]
+step_pin: ar46
+dir_pin: !ar48
+enable_pin: !ar62
+step_distance: .0025
+endstop_pin: ^ar18
+position_endstop: 0.5
+position_max: 400
+
+[extruder]
+step_pin: ar26
+dir_pin: ar28
+enable_pin: !ar24
+step_distance: .010526
+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
+
+[heater_bed]
+heater_pin: ar8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: analog14
+control: pid
+pid_Kp: 690.34
+pid_Ki: 111.47
+pid_Kd: 1068.83
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: ar9
+
+[mcu]
+serial: /dev/ttyUSB0
+pin_map: arduino
+
+[printer]
+kinematics: cartesian
+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.5
+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-lulzbot-taz6-2017.cfg

@@ -0,0 +1,116 @@
+# This file contains pin mappings for the Lulzbot TAZ 6 circa 2017. 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: PL1
+enable_pin: !PA7
+step_distance: .010000
+endstop_pin: ^PB6
+position_endstop: -20
+position_min: -20
+position_max: 300
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC1
+dir_pin: !PL0
+enable_pin: !PA6
+step_distance: .010000
+endstop_pin: ^PA1
+position_endstop: 306
+position_min: -20
+position_max: 306
+homing_speed: 50
+
+[stepper_z]
+step_pin: PC2
+dir_pin: PL2
+enable_pin: !PA5
+step_distance: 0.000625
+endstop_pin: ^!PB4
+position_endstop: -0.7
+position_min: -1.5
+position_max: 270
+homing_speed: 1
+
+[extruder]
+step_pin: PC3
+dir_pin: !PL6
+enable_pin: !PA4
+step_distance: 0.001182
+nozzle_diameter: 0.400
+filament_diameter: 2.920
+heater_pin: PH6
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PF0
+control: pid
+pid_Kp: 28.79
+pid_Ki: 1.91
+pid_Kd: 108.51
+min_temp: 0
+max_temp: 300
+min_extrude_temp: 140
+
+#[extruder1]
+#step_pin: PC4
+#dir_pin: PL7
+#enable_pin: !PA3
+#heater_pin: PH4
+#sensor_pin: PF1
+#...
+
+[heater_bed]
+heater_pin: PE5
+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: 2
+max_z_accel: 10
+
+[ad5206 stepper_digipot]
+enable_pin: PD7
+scale: 2.08
+# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
+channel_1: 1.34
+channel_2: 1.0
+channel_4: 1.1
+channel_5: 1.1
+channel_6: 1.1
+
+# Enable 16 micro-steps on steppers X, Y, Z, E0, E1
+[static_digital_output stepper_config]
+pins:
+    PG1, PG0,
+    PK7, PG2,
+    PK6, PK5,
+    PK3, PK4,
+    PK1, PK2
+
+[static_digital_output yellow_led]
+pins: !PB7
+
+[display]
+lcd_type: st7920
+cs_pin: PG4
+sclk_pin: PJ2
+sid_pin: PG3

config/printer-makergear-m2-2012.cfg

@@ -0,0 +1,114 @@
+# Support for Makergear M2 printers circa 2012 that have the RAMBo
+# v1.0d electronics along with the V3A extruder.  The electronics use
+# Allegro A4984 stepper drivers with 1/8th micro-stepping.  To use
+# this config, the firmware should be compiled for the AVR atmega2560.
+
+[stepper_x]
+step_pin: PC0
+dir_pin: !PL1
+enable_pin: !PA7
+step_distance: .0225
+endstop_pin: ^!PB6
+position_endstop: 0.0
+position_max: 200
+homing_speed: 50
+
+[endstop_phase stepper_x]
+phases: 32
+endstop_accuracy: .200
+
+[stepper_y]
+step_pin: PC1
+dir_pin: PL0
+enable_pin: !PA6
+step_distance: .0225
+endstop_pin: ^!PB5
+position_endstop: 0.0
+position_max: 250
+homing_speed: 50
+
+[endstop_phase stepper_y]
+phases: 32
+endstop_accuracy: .200
+
+[stepper_z]
+step_pin: PC2
+dir_pin: !PL2
+enable_pin: !PA5
+step_distance: .005
+endstop_pin: ^!PB4
+position_min: 0.1
+position_endstop: 0.7
+position_max: 200
+homing_retract_dist: 2.0
+
+[endstop_phase stepper_z]
+phases: 32
+endstop_accuracy: .070
+
+[extruder]
+step_pin: PC3
+dir_pin: PL6
+enable_pin: !PA4
+step_distance: .004242
+nozzle_diameter: 0.350
+filament_diameter: 1.750
+pressure_advance: 0.07
+heater_pin: PH6
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF0
+control: pid
+pid_Kp: 7.0
+pid_Ki: 0.1
+pid_Kd: 12
+min_temp: 0
+max_temp: 210
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF2
+control: watermark
+min_temp: 0
+max_temp: 100
+
+[fan]
+pin: PH5
+
+[heater_fan nozzle_fan]
+pin: PH3
+max_power: 0.61
+cycle_time: .000030
+hardware_pwm: True
+
+[mcu]
+serial: /dev/ttyACM0
+
+[printer]
+kinematics: cartesian
+max_velocity: 500
+max_accel: 3000
+max_z_velocity: 25
+max_z_accel: 30
+
+[ad5206 stepper_digipot]
+enable_pin: PD7
+# Scale the config so that the channel value can be specified in amps
+scale: 1.56
+# Channel 1 is E0, 2 is E1, 3 is unused, 4 is Z, 5 is X, 6 is Y
+channel_1: 1.0
+channel_2: 0.75
+channel_4: 0.82
+channel_5: 0.82
+channel_6: 0.82
+
+# Enable 8 micro-steps on steppers X, Y, Z, E0
+[static_digital_output stepper_config]
+pins:
+    PG1, PG0,
+    PK7, PG2,
+    PK6, PK5,
+    PK3, PK4
+
+[static_digital_output yellow_led]
+pins: !PB7

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-seemecnc-rostock-max-v2-2015.cfg

@@ -0,0 +1,94 @@
+# This file constains the pin mappings for the SeeMeCNC Rostock Max
+# (version 2) delta printer from 2015. 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: PC0
+dir_pin: !PL1
+enable_pin: !PA7
+step_distance: .0125
+endstop_pin: ^PA2
+homing_speed: 50
+position_endstop: 380
+arm_length: 290.800
+
+[stepper_b]
+step_pin: PC1
+dir_pin: PL0
+enable_pin: !PA6
+step_distance: .0125
+endstop_pin: ^PA1
+
+[stepper_c]
+step_pin: PC2
+dir_pin: !PL2
+enable_pin: !PA5
+step_distance: .0125
+endstop_pin: ^PC7
+
+[extruder]
+step_pin: PC3
+dir_pin: !PL6
+enable_pin: !PA4
+step_distance: .010793
+nozzle_diameter: 0.500
+filament_diameter: 1.750
+heater_pin: PH6
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PF0
+control: pid
+pid_Kp: 20.9700
+pid_Ki: 1.3400
+pid_Kd: 80.5600
+min_temp: 0
+max_temp: 300
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PF2
+control: pid
+pid_Kp: 46.510
+pid_Ki: 1.040
+pid_Kd: 500.000
+min_temp: 0
+max_temp: 300
+
+[fan]
+pin: PH5
+
+[heater_fan nozzle_cooling_fan]
+pin: PH4
+heater: extruder
+
+[mcu]
+serial: /dev/ttyACM0
+
+[printer]
+kinematics: delta
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 150
+delta_radius: 174.75
+
+[ad5206 stepper_digipot]
+enable_pin: PD7
+scale: 2.08
+channel_1: 1.34
+channel_2: 1.0
+channel_4: 1.1
+channel_5: 1.1
+channel_6: 1.1
+
+[static_digital_output stepper_config]
+pins:
+    PG1, PG0,
+    PK7, PG2,
+    PK6, PK5,
+    PK3, PK4,
+    PK1, PK2
+
+[static_digital_output yellow_led]
+pins: !PB7

config/printer-tronxy-x5s-2018.cfg

@@ -0,0 +1,94 @@
+# This file contains pin mappings for the Tronxy X5S (circa 2017). 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: 330
+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: 310
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB3
+dir_pin: PB2
+enable_pin: !PD6
+step_distance: .0025
+endstop_pin: ^!PC4
+position_endstop: 0.5
+position_max: 400
+
+[extruder]
+step_pin: PB1
+dir_pin: PB0
+enable_pin: !PD6
+step_distance: .0111
+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
+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
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: corexy
+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
+
+# buttons are:
+# 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,104 @@
+# 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
+
+# N.B. No support for the Display as yet. SSD1309 OLED graphical
+# display connected with i2C.

config/printer-wanhao-duplicator-i3-plus-2017.cfg

@@ -0,0 +1,78 @@
+# This file contains pin mappings for the Wanhao Duplicator i3 Plus
+# (circa 2017).  To use this config, the firmware should be compiled
+# for the AVR atmega2560.
+# Pin numbers and other parameters were extracted from the
+# official Marlin source available at:
+# https://github.com/garychen99/Duplicator-i3-plus
+
+# 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: !PK1
+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: ^!PA1
+position_endstop: 0.5
+position_max: 180
+
+[extruder]
+step_pin: PF4
+dir_pin: PF5
+enable_pin: !PF3
+step_distance: 0.010417
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PF1
+control: pid
+pid_Kp: 30.850721
+pid_Ki: .208175
+pid_Kd: 192.298728
+min_temp: 0
+max_temp: 260
+
+[heater_bed]
+heater_pin: PE5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK6
+control: pid
+pid_Kp: 64.095903
+pid_Ki: 1.649830
+pid_Kd: 622.531455
+min_temp: 0
+max_temp: 110
+
+[fan]
+pin: PE3
+
+[mcu]
+serial: /dev/ttyUSB0
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 800
+max_z_velocity: 5
+max_z_accel: 100

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

@@ -0,0 +1,169 @@
+# This file contains pin mappings and other appropriate default
+# parameters for a Wanhao Duplicator i3 v2.1 and its clones (Monoprice
+# Maker Select, Cocoon Create, etc.).
+#
+# 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:
+#
+# - 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:
+#   /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_ABCD1234-if00-port0
+#
+# - Configure klipper to compile firmware for the AVR atmega1284p
+#
+# - At this point, "make flash FLASH_DEVICE=..." should successfully
+#   flash your printer board. Use the /dev/serial/by-id/ format for
+#   FLASH_DEVICE to ensure consistent results.
+#   See https://github.com/KevinOConnor/klipper/blob/master/docs/FAQ.md#the-make-flash-command-doesnt-work
+#   if you have problems.
+#
+# - Copy this sample file you are currently reading to ~/printer.cfg,
+#   and customize the following parameters:
+#   * [extruder] > step_distance
+#
+#     This is the inverse of "E steps" (extruder steps per mm) from the stock
+#     Wanhao Repetier-based firmware.
+#     (See https://3dprinterwiki.info/extruder-steps/ )
+#
+#     For example, if your E-steps are set to 107.0 steps per mm,
+#     then step_distance should be (1 / 107.0) ~= .009346
+#
+#   * [extruder] > PID parameters (pid_Kp, pid_Ki, pid_Kd)
+#   * [heater_bed] > PID parameters (pid_Kp, pid_Ki, pid_Kd)
+#
+#     PID values from stock Wanhao firmware (Repetier) do not
+#     translate directly to klipper. You will need to run klipper's
+#     PID autotune function for the extruder and bed. After getting the
+#     klipper firmware up and running, run the PID_CALIBRATE procedures
+#     by sending these commands via octoprint terminal (one per autotune):
+#
+#        extruder:   PID_CALIBRATE HEATER=extruder TARGET=<temp>
+#        heated bed: PID_CALIBRATE HEATER=heater_bed TARGET=<temp>
+#
+#     After the autotune process completes, PID parameter results
+#     can be found in the Octoprint terminal tab (if you're quick)
+#     or in /tmp/klippy.log.
+#
+#     Enter the PID parameters into the appropriate sections of ~/printer.cfg .
+#
+#   * [extruder] > max_temp
+#   * [heater_bed] > max_temp
+#
+#     The max temps included in this printer config are limited to 230 for extruder
+#     and 70 for heated bed. If your printer has been modified to handle higher temps
+#     (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
+#     for best results.
+#
+# - Power cycle the Wanhao Duplicator i3
+#
+# - Issue the command "RESTART" via the Octoprint terminal tab (similar to
+#   how you would send a manual gcode command, but send the word RESTART).
+#   This tells klipper to reload its config file and do an internal reset.
+#   You should then see a status screen appear on the printer's LCD.
+#
+# - Be sure to follow these instructions before attempting any prints:
+#   https://github.com/KevinOConnor/klipper/blob/master/docs/Config_checks.md
+
+[stepper_x]
+step_pin: PD7
+dir_pin: PC5
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^!PC2
+position_endstop: 0
+position_max: 200
+homing_speed: 40
+
+[stepper_y]
+step_pin: PC6
+dir_pin: PC7
+enable_pin: !PD6
+step_distance: .0125
+endstop_pin: ^!PC3
+position_endstop: 0
+position_max: 200
+homing_speed: 40
+
+[stepper_z]
+step_pin: PB3
+dir_pin: !PB2
+enable_pin: !PA5
+step_distance: 0.0025
+endstop_pin: ^!PC4
+position_endstop: 0.5
+position_max: 180
+homing_speed: 2
+
+[extruder]
+step_pin: PB1
+dir_pin: !PB0
+enable_pin: !PD6
+step_distance: .009346
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PD5
+sensor_type: NTC 100K beta 3950
+sensor_pin: PA7
+control: pid
+pid_Kp: 18.214030
+pid_Ki: 0.616380
+pid_Kd: 134.556146
+min_temp: 0
+max_temp: 230
+
+[heater_bed]
+heater_pin: PD4
+sensor_type: NTC 100K beta 3950
+sensor_pin: PA6
+control: pid
+pid_Kp: 71.321
+pid_Ki: 1.989
+pid_Kd: 639.210
+min_temp: 0
+max_temp: 70
+
+[fan]
+pin: PB4
+
+[mcu]
+serial: /dev/ttyUSB0
+restart_method: command
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 1000
+max_z_velocity: 2
+max_z_accel: 100
+
+[display]
+lcd_type: st7920
+cs_pin: PC1
+sclk_pin: PD3
+sid_pin: PC0
+encoder_pins: ^PA2, ^PA1
+click_pin: ^!PA3

config/sample-macros.cfg

@@ -0,0 +1,36 @@
+# This file provides examples of Klipper G-Code macros.  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.
+
+
+# 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.
+# as it is based on a PWM duty cycle, 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
+#   Allows for a default 1kHz tone if S is omitted
+#default_parameter_P=100
+#   Allows for a default 10ms duration is P is omitted
+#gcode:  SET_PIN PIN=BEEPER_pin VALUE={S}
+#        G4 P{P}
+#        SET_PIN PIN=BEEPER_pin VALUE=0

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: 5
+axes: z
+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
+
+# 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/Bootloaders.md

@@ -0,0 +1,272 @@
+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
+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 . 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 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 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, it appears one can use a Raspberry Pi with OpenOCD as a
+programmer (see:
+https://learn.adafruit.com/programming-microcontrollers-using-openocd-on-raspberry-pi
+).
+
+Unfortunately, there are two common bootloaders deployed on the
+SAMD21. One comes standard with the "Arduino Zero" and the other comes
+standard with the "Arduino M0".
+
+The Arduino Zero uses an 8KiB bootloader (the application must be
+compiled with a start address of 8KiB). One can enter the bootloader
+by double clicking the reset button. To flash an application use
+something like:
+```
+bossac -U -p "$(FLASH_DEVICE)" --offset=0x2000 -w out/klipper.bin -v -b -R
+```
+
+The Arduino M0 uses a 16KiB bootloader (the application must be
+compiled with a start address of 16KiB). To flash an application,
+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
+```
+
+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 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
+
+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 for
+further information on that topic.
+
+It is common for Smoothieboards to come with a bootloader from:
+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.

docs/CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing to Klipper
+
+Thank you for contributing to Klipper! Please take a moment to read
+this document.
+
+## Creating a new issue
+
+Please see the [contact page](Contact.md) for information on creating
+an issue. In particular, **we need the klippy.log file** attached to
+bug reports. Also, be sure to read the [FAQ](FAQ.md) to see if a
+similar issue has already been raised.
+
+## Submitting a pull request
+
+Contributions of Code and documentation are managed through github
+pull requests.  Each commit should have a commit message formatted
+similar to the following:
+
+```
+module: Capitalized, short (50 chars or less) summary
+
+More detailed explanatory text, if necessary.  Wrap it to about 75
+characters or so.  In some contexts, the first line is treated as the
+subject of an email and the rest of the text as the body.  The blank
+line separating the summary from the body is critical (unless you omit
+the body entirely); tools like rebase can get confused if you run the
+two together.
+
+Further paragraphs come after blank lines..
+
+Signed-off-by: My Name <myemail@example.org>
+```
+
+It is important to have a "Signed-off-by" line on each commit - it
+certifies that you agree to the
+[developer certificate of origin](developer-certificate-of-origin). It
+must contain your real name (sorry, no pseudonyms or anonymous
+contributions) and contain a current email address.

docs/Code_Overview.md

@@ -8,16 +8,20 @@ The **src/** directory contains the C source for the micro-controller
 code. The **src/avr/** directory contains specific code for Atmel
 ATmega micro-controllers. The **src/sam3x8e/** directory contains code
 specific to the Arduino Due style ARM micro-controllers. The
-**src/simulator/** contains code stubs that allow the micro-controller
-to be test compiled on other architectures. The **src/generic/**
-directory contains helper code that may be useful across different
-host architectures. The build arranges for includes of
-"board/somefile.h" to first look in the current architecture directory
-(eg, src/avr/somefile.h) and then in the generic directory (eg,
-src/generic/somefile.h).
+**src/pru/** directory contains code specific to the Beaglebone's
+on-board PRU micro-controller. The **src/simulator/** contains code
+stubs that allow the micro-controller to be test compiled on other
+architectures. The **src/generic/** directory contains helper code
+that may be useful across different host architectures. The build
+arranges for includes of "board/somefile.h" to first look in the
+current architecture directory (eg, src/avr/somefile.h) and then in
+the generic directory (eg, src/generic/somefile.h).
 
-The **klippy/** directory contains the C and Python source for the
-host part of the firmware.
+The **klippy/** directory contains the host software. Most of the host
+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.
@@ -28,6 +32,8 @@ files.
 The **scripts/** directory contains build-time scripts useful for
 compiling the micro-controller code.
 
+The **test/** directory contains automated test cases.
+
 During compilation, the build may create an **out/** directory. This
 contains temporary build time objects. The final micro-controller
 object that is built is **out/klipper.elf.hex** on AVR and
@@ -43,10 +49,12 @@ all functions that have been tagged with the DECL_INIT() macro. It
 then goes on to repeatedly run all functions tagged with the
 DECL_TASK() macro.
 
-One of the main task functions is command_task() located in
-**src/command.c**. This function processes incoming serial commands
-and runs the associated command function for them. Command functions
-are declared using the DECL_COMMAND() macro.
+One of the main task functions is command_dispatch() located in
+**src/command.c**. This function is called from the board specific
+input/output code (eg, **src/avr/serial.c**) and it runs the command
+functions associated with the commands found in the input
+stream. Command functions are declared using the DECL_COMMAND() macro
+(see the [protocol](Protocol.md) document for more information).
 
 Task, init, and command functions always run with interrupts enabled
 (however, they can temporarily disable interrupts if needed). These
@@ -54,13 +62,13 @@ functions should never pause, delay, or do any work that lasts more
 than a few micro-seconds. These functions schedule work at specific
 times by scheduling timers.
 
-Timer functions are scheduled by calling sched_timer() (located in
+Timer functions are scheduled by calling sched_add_timer() (located in
 **src/sched.c**). The scheduler code will arrange for the given
 function to be called at the requested clock time. Timer interrupts
 are initially handled in an architecture specific interrupt handler
-(eg, **src/avr/timer.c**), but this just calls sched_timer_kick()
-located in **src/sched.c**. The timer interrupt leads to execution of
-schedule timer functions.  Timer functions always run with interrupts
+(eg, **src/avr/timer.c**) which calls sched_timer_dispatch() located
+in **src/sched.c**. The timer interrupt leads to execution of schedule
+timer functions. Timer functions always run with interrupts
 disabled. The timer functions should always complete within a few
 micro-seconds. At completion of the timer event, the function may
 choose to reschedule itself.
@@ -74,7 +82,7 @@ interrupts disabled.
 Much of the functionality of the micro-controller involves working
 with General-Purpose Input/Output pins (GPIO). In order to abstract
 the low-level architecture specific code from the high-level task
-code, all GPIO events are implemented in architectures specific
+code, all GPIO events are implemented in architecture specific
 wrappers (eg, **src/avr/gpio.c**). The code is compiled with gcc's
 "-flto -fwhole-program" optimization which does an excellent job of
 inlining functions across compilation units, so most of these tiny
@@ -92,17 +100,355 @@ some functionality in C code.
 Initial execution starts in **klippy/klippy.py**. This reads the
 command-line arguments, opens the printer config file, instantiates
 the main printer objects, and starts the serial connection. The main
-execution of gcode commands is in the process_commands() method in
-**klippy/gcode.py**. This code translates the gcode commands into
+execution of G-code commands is in the process_commands() method in
+**klippy/gcode.py**. This code translates the G-code commands into
 printer object calls, which frequently translate the actions to
 commands to be executed on the micro-controller (as declared via the
 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
-with the serial port. The third thread is used to process response
-messages from the micro-controller in the Python code (see
+entirely in the **klippy/chelper/serialqueue.c** C code) handles
+low-level IO with the serial port. The third thread is used to process
+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.
+
+Code flow of a move command
+===========================
+
+A typical printer movement starts when a "G1" command is sent to the
+Klippy host and it completes when the corresponding step pulses are
+produced on the micro-controller. This section outlines the code flow
+of a typical move command. The [kinematics](Kinematics.md) document
+provides further information on the mechanics of moves.
+
+* Processing for a move command starts in gcode.py. The goal of
+  gcode.py is to translate G-code into internal calls. Changes in
+  origin (eg, G92), changes in relative vs absolute positions (eg,
+  G90), and unit changes (eg, F6000=100mm/s) are handled here. The
+  code path for a move is: `process_data() -> process_commands() ->
+  cmd_G1()`. Ultimately the ToolHead class is invoked to execute the
+  actual request: `cmd_G1() -> ToolHead.move()`
+
+* The ToolHead class (in toolhead.py) handles "look-ahead" and tracks
+  the timing of printing actions. The codepath for a move is:
+  `ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() ->
+  Move.set_junction() -> Move.move()`.
+  * ToolHead.move() creates a Move() object with the parameters of the
+  move (in cartesian space and in units of seconds and millimeters).
+  * MoveQueue.add_move() places the move object on the "look-ahead"
+  queue.
+  * MoveQueue.flush() determines the start and end velocities of each
+  move.
+  * Move.set_junction() implements the "trapezoid generator" on a
+  move. The "trapezoid generator" breaks every move into three parts:
+  a constant acceleration phase, followed by a constant velocity
+  phase, followed by a constant deceleration phase. Every move
+  contains these three phases in this order, but some phases may be of
+  zero duration.
+  * When Move.move() is called, everything about the move is known -
+  its start location, its end location, its acceleration, its
+  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.
+
+  The move is then handed off to the kinematics classes: `Move.move()
+  -> kin.move()`
+
+* The goal of the kinematics classes is to translate the movement in
+  cartesian space to movement on each stepper. The kinematics classes
+  are located in the klippy/kinematics/ directory. The kinematic class
+  is given a chance to audit the move (`ToolHead.move() ->
+  kin.check_move()`) before it goes on the look-ahead queue, but once
+  the move arrives in *kin*.move() the kinematic class is required to
+  handle the move as specified. Note that the extruder is handled in
+  its own kinematic class. Since the Move() class specifies the exact
+  movement time and since step pulses are sent to the 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.
+
+* Klipper uses an
+  [iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
+  to generate the step times for each stepper. For efficiency reasons,
+  the stepper pulse times are generated in C code. The code flow is:
+  `kin.move() -> MCU_Stepper.step_itersolve() ->
+  itersolve_gen_steps()` (in klippy/chelper/itersolve.c). The goal of
+  the iterative solver is to find step times given a function that
+  calculates a stepper position from a time. This is done by
+  repeatedly "guessing" various times until the stepper position
+  formula returns the desired position of the next step on the
+  stepper. The feedback produced from each guess is used to improve
+  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 klippy/chelper/stepcompress.c). This
+  code generates and encodes a series of micro-controller "queue_step"
+  commands that correspond to the list of stepper step times built in
+  the previous stage. These "queue_step" commands are then queued,
+  prioritized, and sent to the micro-controller (via
+  stepcompress.c:steppersync and serialqueue.c:serialqueue).
+
+* Processing of the queue_step commands on the micro-controller starts
+  in src/command.c which parses the command and calls
+  `command_queue_step()`. The command_queue_step() code (in
+  src/stepper.c) just appends the parameters of each queue_step
+  command to a per stepper queue. Under normal operation the
+  queue_step command is parsed and queued at least 100ms before the
+  time of its first step. Finally, the generation of stepper events is
+  done in `stepper_event()`. It's called from the hardware timer
+  interrupt at the scheduled time of the first step. The
+  stepper_event() code generates a step pulse and then reschedules
+  itself to run at the time of the next step pulse for the given
+  queue_step parameters. The parameters for each queue_step command
+  are "interval", "count", and "add". At a high-level, stepper_event()
+  runs the following, 'count' times: `do_step(); next_wake_time =
+  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
+ToolHead and kinematic classes. It's this part of the code which
+specifies the movements and their timings. The remaining parts of the
+processing is mostly just communication and plumbing.
+
+Adding a host module
+====================
+
+The Klippy host code has a dynamic module loading capability. If a
+config section named "[my_module]" is found in the printer config file
+then the software will automatically attempt to load the python module
+klippy/extras/my_module.py . This module system is the preferred
+method for adding new functionality to Klipper.
+
+The easiest way to add a new module is to use an existing module as a
+reference - see **klippy/extras/servo.py** as an example.
+
+The following may also be useful:
+* Execution of the module starts in the module level `load_config()`
+  function (for config sections of the form [my_module]) or in
+  `load_config_prefix()` (for config sections of the form
+  [my_module my_name]). This function is passed a "config" object and
+  it must return a new "printer object" associated with the given
+  config section.
+* During the process of instantiating a new printer object, the config
+  object can be used to read parameters from the given config
+  section. This is done using `config.get()`, `config.getfloat()`,
+  `config.getint()`, etc. methods. Be sure to read all values from the
+  config during the construction of the printer object - if the user
+  specifies a config parameter that is not read during this phase then
+  it will be assumed it is a typo in the config and an error will be
+  raised.
+* Use the `config.get_printer()` method to obtain a reference to the
+  main "printer" class. This "printer" class stores references to all
+  the "printer objects" that have been instantiated. Use the
+  `printer.lookup_object()` method to find references to other printer
+  objects. Almost all functionality (even core kinematic modules) are
+  encapsulated in one of these printer objects. Note, though, that
+  when a new module is instantiated, not all other printer objects
+  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
+  during printer setup and/or shutdown. This method is called twice
+  during setup (with "connect" and then "ready") and may also be
+  called at run-time (with "shutdown" or "disconnect"). It is common
+  to perform "printer object" lookup during the "connect" and "ready"
+  phases.
+* 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
+  either `raise config.error("my error")` or `raise
+  printer.config_error("my 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",
+  config.get("my_pin"))`. The returned object can then be commanded at
+  run-time.
+* If the module needs access to system timing or external file
+  descriptors then use `printer.get_reactor()` to obtain access to the
+  global "event reactor" class. This reactor class allows one to
+  schedule timers, wait for input on file descriptors, and to "sleep"
+  the host code.
+* Do not use global variables. All state should be stored in the
+  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
+  `printer_state("disconnect")` 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.
+* If submitting the module for inclusion in the main Klipper code, be
+  sure to place a copyright notice at the top of the module. See the
+  existing modules for the preferred format.
+
+Adding new kinematics
+=====================
+
+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.
+
+Useful steps:
+1. Start by studying the
+   "[code flow of a move](#code-flow-of-a-move-command)" section and
+   the [Kinematics document](Kinematics.md).
+2. Review the existing kinematic classes in the klippy/kinematics/
+   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 C stepper kinematic position functions for each
+   stepper if they are not already available (see kin_cart.c,
+   kin_corexy.c, and kin_delta.c in klippy/chelper/). The function
+   should call `move_get_coord()` to convert a given move time (in
+   seconds) to a cartesian coordinate (in millimeters), and then
+   calculate the desired stepper position (in millimeters) from that
+   cartesian coordinate.
+4. Implement the `calc_position()` method in the new kinematics class.
+   This method calculates the position of the toolhead in cartesian
+   coordinates from the current position of each stepper. It does not
+   need to be efficient as it is typically only called during homing
+   and probing operations.
+5. Other methods. Implement the `move()`, `check_move()`, `home()`,
+   `motor_off()`, `set_position()`, and `get_steppers()` methods.
+   These functions are typically used to provide kinematic specific
+   checks.  However, at the start of development one can use
+   boiler-plate code here.
+6. 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.
+
+Porting to a new micro-controller
+=================================
+
+This section provides some tips on porting Klipper's micro-controller
+code to a new architecture. This type of activity requires good
+knowledge of embedded development and hands-on access to the target
+micro-controller.
+
+Useful steps:
+1. Start by identifying any 3rd party libraries that will be used
+   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
+====
+
+Fundamental to the operation of Klipper is the handling of clocks,
+times, and timestamps. Klipper executes actions on the printer by
+scheduling events to occur in the near future. For example, to turn on
+a fan, the code might schedule a change to a GPIO pin in a 100ms. It
+is rare for the code to attempt to take an instantaneous action. Thus,
+the handling of time within Klipper is critical to correct operation.
+
+There are three types of times tracked internally in the Klipper host
+software:
+* System time. The system time uses the system's monotonic clock - it
+  is a floating point number stored as seconds and it is (generally)
+  relative to when the host computer was last started. System times
+  have limited use in the software - they are primarily used when
+  interacting with the operating system. Within the host code, system
+  times are frequently stored in variables named *eventtime* or
+  *curtime*.
+* Print time. The print time is synchronized to the main
+  micro-controller clock (the micro-controller defined in the "[mcu]"
+  config section). It is a floating point number stored as seconds and
+  is relative to when the main mcu was last restarted. It is possible
+  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
+  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
+  micro-controller. It is stored as an integer and its update rate is
+  relative to the frequency of the given micro-controller. The host
+  software translates its internal times to clocks before transmission
+  to the mcu. The mcu code only ever tracks time in clock
+  ticks. Within the host code, clock values are tracked as 64bit
+  integers, while the mcu code uses 32bit integers. Within the host
+  code, clocks are generally stored in variables with names containing
+  *clock* or *ticks*.
+
+Conversion between the different time formats is primarily implemented
+in the **klippy/clocksync.py** code.
+
+Some things to be aware of when reviewing the code:
+* 32bit and 64bit clocks: To reduce bandwidth and to improve
+  micro-controller efficiency, clocks on the micro-controller are
+  tracked as 32bit integers. When comparing two clocks in the mcu
+  code, the `timer_is_before()` function must always be used to ensure
+  integer rollovers are handled properly. The host software converts
+  32bit clocks to 64bit clocks by appending the high-order bits from
+  the last mcu timestamp it has received - no message from the mcu is
+  ever more than 2^31 clock ticks in the future or past so this
+  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/chelper/serialqueue.c** code will buffer messages until
+  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
+  clocksync.py code handles clock drift between micro-controllers by
+  modifying the way it converts from "print time" to "MCU clock". On
+  secondary mcus, the mcu frequency that is used in this conversion is
+  regularly updated to account for measured drift.

docs/Config_checks.md

@@ -0,0 +1,167 @@
+This document provides a list of steps to help confirm the pin
+settings in the Klipper printer.cfg file.  It is a good idea to run
+through these steps after following the steps in the
+[installation document](Installation.md).
+
+During this guide, it may be necessary to make changes to the Klipper
+config file. Be sure to issue a RESTART command after every change to
+the config file to ensure that the change takes effect (type "restart"
+in the Octoprint terminal tab and then click "Send"). It's also a good
+idea to issue a STATUS command after every RESTART to verify that the
+config file is successfully loaded.
+
+### Verify temperature
+
+Start by verifying that temperatures are being properly
+reported. Navigate to the Octoprint temperature tab.
+
+![octoprint-temperature](img/octoprint-temperature.png)
+
+Verify that the temperature of the nozzle and bed (if applicable) are
+present and not increasing. If it is increasing, remove power from the
+printer. If the temperatures are not accurate, review the
+"sensor_type" and "sensor_pin" settings for the nozzle and/or bed.
+
+### Verify M112
+
+Navigate to the Octoprint terminal tab and issue an M112 command in
+the terminal box. This command requests Klipper to go into a
+"shutdown" state. It will cause Octoprint to disconnect from Klipper -
+navigate to the Connection area and click on "Connect" to cause
+Octoprint to reconnect. Then navigate to the Octoprint temperature tab
+and verify that temperatures continue to update and the temperatures
+are not increasing. If temperatures are increasing, remove power from
+the printer.
+
+The M112 command causes Klipper to go into a "shutdown" state. To
+clear this state, issue a FIRMWARE_RESTART command in the Octoprint
+terminal tab.
+
+### Verify heaters
+
+Navigate to the Octoprint temperature tab and type in 50 followed by
+enter in the "Tool" temperature box. The extruder temperature in the
+graph should start to increase (within about 30 seconds or so). Then
+go to the "Tool" temperature drop-down box and select "Off". After
+several minutes the temperature should start to return to its initial
+room temperature value. If the temperature does not increase then
+verify the "heater_pin" setting in the config.
+
+If the printer has a heated bed then perform the above test again with
+the bed.
+
+### Verify stepper motor enable pin
+
+Verify that all of the printer axes can manually move freely (the
+stepper motors are disabled). If not, issue an M84 command to disable
+the motors. If any of the axes still can not move freely, then verify
+the stepper "enable_pin" configuration for the given axis. On most
+commodity stepper motor drivers, the motor enable pin is "active low"
+and therefore the enable pin should have a "!" before the pin (for
+example, "enable_pin: !ar38").
+
+### Verify endstops
+
+Manually move all the printer axes so that none of them are in contact
+with an endstop. Send a QUERY_ENDSTOPS command via the Octoprint
+terminal tab. It should respond with the current state of all of the
+configured endstops and they should all report a state of "open". For
+each of the endstops, rerun the QUERY_ENDSTOPS command while manually
+triggering the endstop. The QUERY_ENDSTOPS command should report the
+endstop as "TRIGGERED".
+
+If the endstop appears inverted (it reports "open" when triggered and
+vice-versa) then add a "!" to the pin definition (for example,
+"endstop_pin: ^!ar3"), or remove the "!" if there is already one
+present.
+
+If the endstop does not change at all then it generally indicates that
+the endstop is connected to a different pin. However, it may also
+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 motors
+
+Use the STEPPER_BUZZ command to verify the connectivity of each
+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.
+
+If the stepper does not move at all, then verify the "enable_pin" and
+"step_pin" settings for the stepper. If the stepper motor moves but
+does not return to its original position then verify the "dir_pin"
+setting. If the stepper motor oscillates in an incorrect direction,
+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). If the
+motor moves significantly more or significantly less than one
+millimeter then verify the "step_distance" setting.
+
+Run the above test for each stepper motor defined in the config
+file. (Set the STEPPER parameter of the STEPPER_BUZZ command to the
+name of the config section that is to be tested.) If there is no
+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
+
+To test the extruder motor it will be necessary to heat the extruder
+to a printing temperature. Navigate to the Octoprint temperature tab
+and select a target temperature from the temperature drop-down box (or
+manually enter an appropriate temperature). Wait for the printer to
+reach the desired temperature. Then navigate to the Octoprint control
+tab and click the "Extrude" button. Verify that the extruder motor
+turns in the correct direction. If it does not, see the
+troubleshooting tips in the previous section to confirm the
+"enable_pin", "step_pin", and "dir_pin" settings for the extruder.
+
+### Calibrate PID settings
+
+Klipper supports
+[PID control](https://en.wikipedia.org/wiki/PID_controller) for the
+extruder and bed heaters. In order to use this control mechanism it is
+necessary to calibrate the PID settings on each printer. (PID settings
+found in other firmwares or in the example configuration files often
+work poorly.)
+
+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 run `SAVE_CONFIG` to update the
+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
+the bed. (When the bed heater is controlled using the PID algorithm it
+may turn on and off ten times a second, which may not be suitable for
+heaters using a mechanical switch.) A typical bed PID calibration
+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
+detailed printer calibration - a number of guides are available online
+to help with this (for example, do a web search for "3d printer
+calibration").
+
+See the [Slicers](Slicers.md) document for information on configuring
+a slicer with Klipper. If one is using traditional endstop switches
+with Trinamic stepper motor drivers then see the
+[Endstop Phase](Endstop_Phase.md) document. If using a delta printer,
+see the [Delta Calibrate](Delta_Calibrate.md) document.
+
+After one has verified that basic printing works, it is a good idea to
+consider calibrating [pressure advance](Pressure_Advance.md).

docs/Contact.md

@@ -0,0 +1,57 @@
+This page provides information on how to contact the Klipper
+developers.
+
+Issue reporting
+===============
+
+It is very important to attach the Klipper log file to all
+reports. The log file has been engineered to answer common questions
+the Klipper developers have about the software and its environment
+(software version, hardware type, configuration, event timing, and
+hundreds of other questions). **The developers need the Klipper log
+file to provide any meaningful assistance**; only this log file
+provides the necessary information.
+
+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 event being reported.** An "scp" and/or "sftp" utility is
+needed to acquire this log file. The "scp" utility comes standard with
+Linux and MacOS desktops. There are freely available scp utilities for
+other desktops (eg, WinSCP).
+
+Use the scp utility to copy the `/tmp/klippy.log` file from the
+Raspberry Pi to your desktop. It is a good idea to compress the
+klippy.log file before posting it (eg, using zip or gzip). Open a new
+issue at https://github.com/KevinOConnor/klipper/issues , provide a
+description of the problem, and **attach the `klippy.log` file to the
+issue**: ![attach-issue](img/attach-issue.png)
+
+Mailing list
+============
+
+There is a mailing list for general discussions on Klipper. In order
+to send am email to the list, one must first subscribe:
+https://www.freelists.org/list/klipper . Once subscribed, emails may
+be sent to `klipper@freelists.org`.
+
+Archives of the mailing list are available at:
+https://www.freelists.org/archive/klipper/
+
+IRC
+===
+
+One may join the #klipper channel on freenode.net (
+irc://chat.freenode.net:6667 ).
+
+To communicate in this IRC channel one will need an IRC
+client. Configure it to connect to chat.freenode.net on port 6667 and
+join the #klipper channel (`/join #klipper`).
+
+If asking a question on IRC, be sure to ask the question and then stay
+connected to the channel to receive responses. Due to timezone
+differences, it may take several hours before receiving a response.

docs/Debugging.md

@@ -1,17 +1,18 @@
-The Klippy host code has some tools to help in debugging the firmware.
+The Klippy host code has some tools to help in debugging.
 
-Translating gcode files to firmware commands
-============================================
+Translating gcode files to micro-controller commands
+====================================================
 
 The Klippy host code can run in a batch mode to produce the low-level
-firmware commands associated with a gcode file. Inspecting these
-low-level firmware commands is useful when trying to understand the
+micro-controller commands associated with a gcode file. Inspecting
+these low-level commands is useful when trying to understand the
 actions of the low-level hardware. It can also be useful to compare
-the difference in firmware commands after a code change.
+the difference in micro-controller commands after a code change.
 
 To run Klippy in this batch mode, there is a one time step necessary
-to generate the firmware "data dictionary". This is done by compiling
-the firmware code to obtain the **out/klipper.dict** file:
+to generate the micro-controller "data dictionary". This is done by
+compiling the micro-controller code to obtain the **out/klipper.dict**
+file:
 
 ```
 make menuconfig
@@ -34,13 +35,13 @@ output. This output can be translated to readable text with:
 ```
 
 The resulting file **test.txt** contains a human readable list of
-firmware commands.
+micro-controller commands.
 
 The batch mode disables certain response / request commands in order
 to function. As a result, there will be some differences between
-actual firmware commands and the above output. The generated data is
-useful for testing and inspection; it is not useful for sending to a
-real micro-controller.
+actual commands and the above output. The generated data is useful for
+testing and inspection; it is not useful for sending to a real
+micro-controller.
 
 Testing with simulavr
 =====================
@@ -74,25 +75,20 @@ cd /patch/to/klipper
 make menuconfig
 ```
 
-and compile the firmware for an AVR atmega644p, disable the AVR
-watchdog timer, and set the MCU frequency to 20000000. Then one can
-compile Klipper (run `make`) and then start the simulation with:
+and compile the micro-controller software for an AVR atmega644p, set
+the MCU frequency to 20Mhz, and select SIMULAVR software emulation
+support. Then one can compile Klipper (run `make`) and then start the
+simulation with:
 
 ```
 PYTHONPATH=/path/to/simulavr/src/python/ ./scripts/avrsim.py -m atmega644 -s 20000000 -b 250000 out/klipper.elf
 ```
 
-It may be necessary to create a python virtual environment to run
-Klippy on the target machine. To do so, run:
-
-```
-virtualenv ~/klippy-env
-~/klippy-env/bin/pip install cffi==1.6.0 pyserial==2.7
-```
-
 Then, with simulavr running in another window, one can run the
 following to read gcode from a file (eg, "test.gcode"), process it
-with Klippy, and send it to Klipper running in simulavr:
+with Klippy, and send it to Klipper running in simulavr (see
+[installation](Installation.md) for the steps necessary to build the
+python virtual environment):
 
 ```
 ~/klippy-env/bin/python ./klippy/klippy.py config/avrsim.cfg -i test.gcode -v
@@ -119,13 +115,300 @@ gtkwave avrsim.vcd
 ```
 
 Manually sending commands to the micro-controller
--------------------------------------------------
+=================================================
 
-Normally, Klippy would be used to translate gcode commands to Klipper
-commands. However, it's also possible to manually send Klipper
-commands (functions marked with the DECL_COMMAND() macro in the
-Klipper source code). To do so, run:
+Normally, the host klippy.py process would be used to translate gcode
+commands to Klipper micro-controller commands. However, it's also
+possible to manually send these MCU commands (functions marked with
+the DECL_COMMAND() macro in the Klipper source code). To do so, run:
 
 ```
 ~/klippy-env/bin/python ./klippy/console.py /tmp/pseudoserial 250000
 ```
+
+See the "HELP" command within the tool for more information on its
+functionality.
+
+Generating load graphs
+======================
+
+The Klippy log file (/tmp/klippy.log) stores statistics on bandwidth,
+micro-controller load, and host buffer load. It can be useful to graph
+these statistics after a print.
+
+To generate a graph, a one time step is necessary to install the
+"matplotlib" package:
+
+```
+sudo apt-get update
+sudo apt-get install python-matplotlib
+```
+
+Then graphs can be produced with:
+
+```
+~/klipper/scripts/graphstats.py /tmp/klippy.log loadgraph.png
+```
+
+One can then view the resulting **loadgraph.png** file.
+
+Extracting information from the klippy.log file
+===============================================
+
+The Klippy log file (/tmp/klippy.log) also contains debugging
+information. There is a logextract.py script that may be useful when
+analyzing a micro-controller shutdown or similar problem. It is
+typically run with something like:
+
+```
+mkdir work_directory
+cd work_directory
+cp /tmp/klippy.log .
+~/klipper/scripts/logextract.py ./klippy.log
+```
+
+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.
+
+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 above). 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.)}
+```
+
+### 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 `b161a69e` with gcc version `avr-gcc
+(GCC) 4.8.1`. 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).
+On both 16Mhz and 20Mhz the best single stepper result is `SET ticks
+106`, the best dual stepper result is `SET ticks 276`, and the best
+three stepper result is `SET ticks 481`.
+
+### 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 `b161a69e` with gcc version
+`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
+stepper result is `SET ticks 207`, the best dual stepper result is
+`SET ticks 205`, and the best three stepper result is `SET ticks 317`.
+
+### Duet Wifi step rate benchmark ###
+
+The following configuration sequence is used on the Duet Wifi:
+```
+allocate_oids count=3
+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
+finalize_config crc=0
+```
+
+The test was last run on commit `34c3cb5c` with gcc version
+`arm-none-eabi-gcc (15:5.4.1+svn241155-1) 5.4.1 20160919`. The best
+single stepper result is `SET ticks 295`, the best dual stepper result
+is `SET ticks 264`, and the best three stepper result is `SET ticks
+282`.
+
+### 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)`. The best single stepper result
+is `SET ticks 861`, the best dual stepper result is `SET ticks 853`,
+and the best three stepper result is `SET ticks 883`.
+
+### 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 `b161a69e` with gcc version
+`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
+stepper result is `SET ticks 41`, the best dual stepper result is `SET
+ticks 48`, and the best three stepper result is `SET ticks 80`.
+
+### 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 `b161a69e` with gcc version
+`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. For the 100Mhz
+LPC1768, the best single stepper result is `SET ticks 119`, the best
+dual stepper result is `SET ticks 118`, and the best three stepper
+result is `SET ticks 154`. The 120Mhz LPC1769 results were obtained by
+overclocking an LPC1768 to 120Mhz - the best single stepper result is
+`SET ticks 140`, the best dual stepper result is `SET ticks 137`, and
+the best three stepper result is `SET ticks 154`.
+
+### 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 `b161a69e` with gcc version
+`arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0`. The best single
+stepper result is `SET ticks 277`, the best dual stepper result is
+`SET ticks 410`, and the best three stepper result is `SET ticks 664`.
+
+## 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 above). The following is cut-and-paste into the console.py
+terminal window:
+```
+DELAY {clock+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`.
+
+| MCU                 | Rate | Build    | Build compiler      |
+| ------------------- | ---- | -------- | ------------------- |
+| atmega2560 (serial) |  23K | b161a69e | avr-gcc (GCC) 4.8.1 |
+| at90usb1286 (USB)   |  75K | b161a69e | avr-gcc (GCC) 4.8.1 |
+| sam3x8e (serial)    |  23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| pru (shared memory) |   5K | b161a69e | pru-gcc (GCC) 8.0.0 20170530 (experimental) |
+| stm32f103 (USB)     | 335K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| lpc1768 (USB)       | 546K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| lpc1769 (USB)       | 619K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| samd21 (USB)        | 238K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+
+Host Benchmarks
+===============
+
+It is possible to run timing tests on the host software using the
+"batch mode" processing mechanism described above. 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/Delta_Calibrate.md

@@ -0,0 +1,213 @@
+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 to get good results.
+
+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 and
+automatic probing. Automatic probing utilizes a hardware device
+capable of triggering when the toolhead is at a set distance from the
+bed. Manual probing involves using the "paper test" to determine the
+height at each probe point. It is recommended to use manual probing
+for delta calibration. A number of common printer kits come with
+probes that are not sufficiently accurate (specifically, small
+differences in arm length can cause effector tilt which can skew an
+automatic probe). Manual probing only takes a few minutes and it
+eliminates error introduced by the probe.
+
+To perform the basic probe, make sure the config has a
+[delta_calibrate] section defined and run:
+```
+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

@@ -0,0 +1,381 @@
+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. [When the micro-controller restarts the device changes to /dev/ttyUSB1](#when-the-micro-controller-restarts-the-device-changes-to-devttyusb1)
+5. [The "make flash" command doesn't work](#the-make-flash-command-doesnt-work)
+6. [How do I change the serial baud rate?](#how-do-i-change-the-serial-baud-rate)
+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 can't I move the stepper before homing the printer?](#why-cant-i-move-the-stepper-before-homing-the-printer)
+9. [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)
+10. [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)
+11. [My TMC motor driver turns off in the middle of a print](#my-tmc-motor-driver-turns-off-in-the-middle-of-a-print)
+12. [I keep getting random "Lost communication with MCU" errors](#i-keep-getting-random-lost-communication-with-mcu-errors)
+13. [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)
+14. [Will the heaters be left on if the Raspberry Pi crashes?](#will-the-heaters-be-left-on-if-the-raspberry-pi-crashes)
+15. [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)
+16. [How do I upgrade to the latest software?](#how-do-i-upgrade-to-the-latest-software)
+
+### How can I donate to the project?
+
+Thanks. Kevin has a Patreon page at: https://www.patreon.com/koconnor
+
+### How do I calculate the step_distance parameter in the printer config file?
+
+If you know the steps per millimeter for the axis then use a
+calculator to divide 1.0 by steps_per_mm. Then round this number to
+six decimal places and place it in the config (six decimal places is
+nano-meter precision).
+
+The step_distance defines the distance that the axis will travel on
+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.
+
+### 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 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
+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-1a86_USB2.0-Serial-if00-port0
+sudo service klipper start
+```
+and the updated config might look like:
+```
+[mcu]
+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
+each platform. Unfortunately, there is a lot of variance in flashing
+methods, so the "make flash" command may not work on all boards.
+
+If you're having an intermittent failure or you do have a standard
+setup, then double check that Klipper isn't running when flashing
+(sudo service klipper stop), make sure OctoPrint isn't trying to
+connect directly to the device (open the Connection tab in the web
+page and click Disconnect if the Serial Port is set to the device),
+and make sure FLASH_DEVICE is set correctly for your board (see the
+[question above](#wheres-my-serial-port)).
+
+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
+the device. Also, check the board manufacturer's documentation to see
+if it describes how to flash the device. Finally, on AVR devices, it
+may be possible to manually flash the device using
+[avrdude](http://www.nongnu.org/avrdude/) with custom command-line
+parameters - see the avrdude documentation for further information.
+
+### How do I change the serial baud rate?
+
+The recommended baud rate for Klipper is 250000. This baud rate works
+well on all micro-controller boards that Klipper supports. If you've
+found an online guide recommending a different baud rate, then ignore
+that part of the guide and continue with the default value of 250000.
+
+If you want to change the baud rate anyway, then the new rate will
+need to be configured in the micro-controller (during **make
+menuconfig**) and that updated code will need to be compiled and
+flashed to the micro-controller. The Klipper printer.cfg file will
+also need to be updated to match that baud rate (see the example.cfg
+file for details).  For example:
+```
+[mcu]
+baud: 250000
+```
+
+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
+Pi 3.
+
+Klipper will run on a Raspberry Pi 1 and on the Raspberry Pi Zero, but
+these boards don't have enough processing power to run OctoPrint
+well. It's not uncommon for print stalls to occur on these slower
+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)
+when printing.
+
+For running on the Beaglebone, see the
+[Beaglebone specific installation instructions](beaglebone.md).
+
+Klipper has been run on other machines.  The Klipper host software
+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
+information on the necessary Linux admin steps.
+
+### Why can't I move the stepper before homing the printer?
+
+The code does this to reduce the chance of accidentally commanding the
+head into the bed or a wall. Once the printer is homed the software
+attempts to verify each move is within the position_min/max defined in
+the config file. If the motors are disabled (via an M84 or M18
+command) then the motors will need to be homed again prior to
+movement.
+
+If you want to move the head after canceling a print via OctoPrint,
+consider changing the OctoPrint cancel sequence to do that for
+you. It's configured in OctoPrint via a web browser under:
+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](../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
+the nozzle is from the bed when the endstop triggers. If possible, it
+is recommended to use a Z-max endstop and home away from the bed (as
+this reduces the potential for bed collisions). However, if one must
+home towards the bed then it is recommended to position the endstop so
+it triggers when the nozzle is still a small distance away from the
+bed. This way, when homing the axis, it will stop before the nozzle
+touches the bed.
+
+Almost all mechanical switches can still move a small distance
+(eg, 0.5mm) after they are triggered. So, for example, if the
+position_endstop is set to 0.5mm then one may still command the
+printer to move to Z0.2. The position_min config setting (which
+defaults to 0) is used to specify the minimum Z position one may
+command the printer to move to.
+
+Note, the Z position_endstop specifies the distance from the nozzle to
+the bed when the nozzle and bed (if applicable) are hot. It is typical
+for thermal expansion to cause nozzle expansion of around .1mm, which
+is also the typical thickness of a sheet of printer paper. Thus, it is
+common to use the "paper test" to confirm calibration of the Z
+height - check that the bed and nozzle are at room temperature, check
+that there is no plastic on the head or bed, home the printer, place a
+piece of paper between the nozzle and bed, and repeatedly command the
+head to move closer to the bed checking each time if you feel a small
+amount of friction when sliding the paper between bed and nozzle - if
+all is calibrated well a small amount of friction would be felt when
+the height is at Z0.
+
+### 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
+
+Short answer: Try reducing the max_z_velocity setting in the printer
+config. Also, if the Z stepper is moving in the wrong direction, try
+inverting the dir_pin setting in the config (eg, "dir_pin: !xyz"
+instead of "dir_pin: xyz").
+
+Long answer: In practice Marlin can typically only step at a rate of
+around 10000 steps per second. If it is requested to move at a speed
+that would require a higher step rate then Marlin will generally just
+step as fast as it can. Klipper is able to achieve much higher step
+rates, but the stepper motor may not have sufficient torque to move at
+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
+
+There have been reports of some TMC drivers being disabled in the
+middle of a print. (In particular, with the TMC2208 driver.) When this
+issue occurs, the stepper associated with the driver moves freely,
+while the print continues.
+
+It is believed this may be due to "over current" detection within the
+TMC driver. Trinamic has indicated that this could occur if the driver
+is in "stealthChop mode" and an abrupt velocity change occurs. If you
+experience this problem during homing, consider using a slower homing
+speed. If you experience this problem in the middle of a print,
+consider using a lower square_corner_velocity setting.
+
+### 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 for the
+  Raspberry Pi and use a good quality USB cable to connect that power
+  supply to the Pi.
+- 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.)
+- 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.)
+
+### 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
+event handling. This typically manifests when the printer.cfg file has
+restart_method set to "command". When the bug occurs, the AVR device
+will be unresponsive until power is removed and reapplied to the
+device (the power or status LEDs may also blink repeatedly until the
+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
+particular device.
+
+### Will the heaters be left on if the Raspberry Pi crashes?
+
+The software has been designed to prevent that. Once the host enables
+a heater, the host software needs to confirm that enablement every 5
+seconds. If the micro-controller does not receive a confirmation every
+5 seconds it goes into a "shutdown" state which is designed to turn
+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](../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](../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 upgrade to the latest software?
+
+The general way to upgrade is to ssh into the Raspberry Pi and run:
+
+```
+cd ~/klipper
+git pull
+~/klipper/scripts/install-octopi.sh
+```
+
+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
+```
+
+However, it's often the case that only the host software changes. In
+this case, one can update and restart just the host software with:
+
+```
+cd ~/klipper
+git pull
+sudo service klipper restart
+```
+
+If after using this shortcut the software warns about needing to
+reflash the micro-controller or some other unusual error occurs, then
+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.

docs/Features.md

@@ -1,58 +1,63 @@
-Klipper is an experimental 3d printer firmware. It has several
-compelling features:
+Klipper has several compelling features:
 
 * High precision stepper movement. Klipper utilizes an application
   processor (such as a low-cost Raspberry Pi) when calculating printer
   movements. The application processor determines when to step each
   stepper motor, it compresses those events, transmits them to the
   micro-controller, and then the micro-controller executes each event
-  at the requested time.  Each stepper event is scheduled with a
-  precision of no less than 50 micro-seconds. The software does not
-  use kinematic estimations (such as the Bresenham algorithm) -
-  instead it calculates precise step times based on the physics of
-  acceleration and the physics of the machine kinematics. More precise
-  stepper movement translates to quieter and more stable printer
-  operation.
+  at the requested time. Each stepper event is scheduled with a
+  precision of 25 micro-seconds or better. The software does not use
+  kinematic estimations (such as the Bresenham algorithm) - instead it
+  calculates precise step times based on the physics of acceleration
+  and the physics of the machine kinematics. More precise stepper
+  movement translates to quieter and more stable printer operation.
 
 * Best in class performance. Klipper is able to achieve high stepping
   rates on both new and old micro-controllers. Even an old 8bit AVR
-  micro-controller can obtain rates up to 150K steps per second. On
-  more recent ARM micro-controllers, rates over 350K steps per second
-  are possible. Higher stepper rates enable higher print
-  velocities. The stepper event timing remains precise even at high
-  speeds which improves overall stability.
+  micro-controller can obtain rates over 175K steps per second. On
+  more recent micro-controllers, rates over 500K steps per second are
+  possible. Higher stepper rates enable higher print velocities. The
+  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
   micro-controller architectures as well.
 
 * Simpler code. Klipper uses a very high level language (Python) for
-  most code. The kinematics algorithms, the gcode parsing, the heating
-  and thermistor algorithms, etc. are all written in Python. This
-  makes it easier to develop new functionality.
+  most code. The kinematics algorithms, the G-code parsing, the
+  heating and thermistor algorithms, etc. are all written in Python.
+  This makes it easier to develop new functionality.
 
-* Advanced features. Klipper implements the "pressure advance"
-  algorithm for extruders. When properly tuned, pressure advance
-  reduces extruder ooze. 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.
+* Klipper uses an "iterative solver" to calculate precise step times
+  from simple kinematic equations. This makes porting Klipper to new
+  types of robots easier and it keeps timing precise even with complex
+  kinematics (no "line segmentation" is needed).
 
-To get started with Klipper, read the [installation](Installation.md)
-guide.
-
-Common features supported by Klipper
-====================================
+Additional features
+===================
 
 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.
@@ -61,16 +66,60 @@ 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
-  gradually accelerate from standstill to cruising speed and then
-  decelerate back to a standstill.
+* Support for multiple extruders. Extruders with shared heaters and
+  extruders on independent carriages (IDEX) are also supported.
 
-* "Lookahead" support. 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.
 
-* Support for both delta printers and cartesian style printers.
+* 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, 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, and
+  TMC2660 stepper motor drivers. There is also support for current
+  control of traditional stepper drivers via AD5206 and MCP4451
+  digipots.
+
+* 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.
+
+* 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](../config/) for a list.
+
+To get started with Klipper, read the [installation](Installation.md)
+guide.
 
 Step Benchmarks
 ===============
@@ -78,8 +127,20 @@ Step Benchmarks
 Below are the results of stepper performance tests. The numbers shown
 represent total number of steps per second on the micro-controller.
 
-| Micro-controller  | 1 stepper active | 3 steppers active |
-| ----------------- | ---------------- | ----------------- |
-| 20Mhz AVR         | 158.7K           | 103K              |
-| 16Mhz AVR         | 126.9K           | 82K               |
-| Arduino Due (ARM) | 352.9K           | 288K              |
+| Micro-controller            | Fastest step rate | 3 steppers active |
+| --------------------------- | ----------------- | ----------------- |
+| 16Mhz AVR                   | 151K              | 100K              |
+| 20Mhz AVR                   | 189K              | 125K              |
+| Arduino Zero (ARM SAMD21)   | 234K              | 217K              |
+| STM32F103                   | 333K              | 300K              |
+| Arduino Due (ARM SAM3X8E)   | 410K              | 397K              |
+| Smoothieboard (ARM LPC1768) | 487K              | 487K              |
+| Smoothieboard (ARM LPC1769) | 584K              | 584K              |
+| SAM4E8E ARM                 | 638K              | 638K              |
+| Beaglebone PRU              | 680K              | 680K              |
+
+On AVR platforms, the highest achievable step rate is with just one
+stepper stepping. On the STM32F103, Arduino Zero, and Due, the highest
+step rate is with two simultaneous steppers stepping. On the PRU,
+SAM4E8E, and LPC176x the highest step rate is with three simultaneous
+steppers.

docs/Firmware_Commands.md

@@ -1,278 +0,0 @@
-This document provides high-level information on common firmware
-commands. It is not an authoritative reference for these commands, nor
-is it an exclusive list of all available firmware commands.
-
-This document may be useful for users needing to configure a set of
-hardware actions that their printer may require at startup (via the
-"custom" field in the printer config file), and it may be useful for
-developers wishing to obtain a high-level feel for available firmware
-commands.
-
-See the [protocol](Protocol.md) document for more information on the
-format of commands and their low-level 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.
-
-Startup Commands
-================
-
-It may be necessary to take certain one-time actions to configure the
-micro-controller and its peripherals. This section lists common
-commands available for that purpose. Unlike other firmware commands,
-these commands run as soon as they are received by the firmware and
-they do not require any particular setup.
-
-These commands are most useful in the "custom" block of the "mcu"
-section of the printer configuration file. This feature is typically
-used to configure the initial settings of LEDs, to configure
-micro-stepping pins, to configure a digipot, etc.
-
-Several of these commands will take a "pin=%u" parameter. The
-low-level firmware 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
-  configures the given pin as a digital out GPIO and it sets it to
-  either a low level (value=0) or a high level (value=1). This command
-  may be useful for configuring the initial value of LEDs and for
-  configuring the initial value of stepper driver micro-stepping pins.
-
-* set_pwm_out pin=%u cycle_ticks=%u value=%c : This command will
-  immediately configure the given pin to use hardware based
-  pulse-width-modulation (PWM) with the given number of
-  cycle_ticks. The "cycle_ticks" is the number of MCU clock ticks each
-  power on and power off cycle should last. A cycle_ticks value of 1
-  can be used to request the fastest possible cycle time. The "value"
-  parameter is between 0 and 255 with 0 indicating a full off state
-  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.
-
-Firmware configuration
-======================
-
-Most commands in the firmware require an initial setup before they can
-be successfully invoked. This section provides a high-level overview
-of the micro-controller configuration process. This section and the
-following sections are likely only of interest to developers
-interested in the internal details of Klipper.
-
-When the host first connects to the firmware it always starts by
-obtaining the firmware's data dictionary (see [protocol](Protocol.md)
-for more information). After the data dictionary is obtained the host
-will check if the firmware is in a "configured" state and configure it
-if not. Configuration involves the following phases:
-
-* get_config : The host starts by checking if the firmware is already
-  configured. The firmware responds to this command with a "config"
-  response message. At micro-controller power-on the firmware always
-  starts in an unconfigured state. It remains in this state until the
-  host completes the configuration processes (by issuing a
-  finalize_config command). If the firmware is already configured (and
-  is configured with the desired settings) from a previous
-  host/firmware session then no further action is needed by the host
-  and the configuration process ends successfully.
-
-* allocate_oids count=%c : This command is issued to inform the
-  firmware the maximum number of object-ids (oid) that the host
-  requires. It is only valid to issue this command once. An oid is an
-  integer identifier allocated to each stepper, each endstop, and each
-  schedulable gpio pin. The host determines in advance the number of
-  oids it will require to operate the hardware and passes this to the
-  firmware so that the firmware may allocate sufficient memory to
-  store a mapping from oid to internal firmware object.
-
-* config_XXX oid=%c ... : By convention any command starting with the
-  "config_" prefix creates a new firmware object and assigns the given
-  oid to it. For example, the config_digital_out command will
-  configure the specified pin as a digital output GPIO and create an
-  internal object that the host can use to schedule changes to the
-  given GPIO. The oid parameter passed into the config command is
-  selected by the host and must be between zero and the maximum count
-  supplied in the allocate_oids command. The config commands may only
-  be run when the firmware is not in a configured state (ie, prior to
-  the host sending finalize_config) and after the allocate_oids
-  command has been sent.
-
-* finalize_config crc=%u : The finalize_config command transitions the
-  firmware from an unconfigured state to a configured state. The crc
-  parameter passed to the firmware is stored in the firmware and
-  provided back to the host in "config" response messages. By
-  convention, the host takes a 32bit CRC of the firmware configuration
-  it will request and at the start of subsequent host/firmware
-  communication sessions it checks that the CRC stored in the firmware
-  exactly matches its desired CRC. If the CRC does not match then the
-  host knows the firmware has not been configured in the state desired
-  by the host.
-
-Common firmware objects
------------------------
-
-This section lists some commonly used config commands.
-
-* config_digital_out oid=%c pin=%u default_value=%c max_duration=%u :
-  This command creates an internal firmware object for the given GPIO
-  'pin'. The pin will be configured in digital output mode and set to
-  an initial value as specified by 'default_value' (0 for low, 1 for
-  high). Creating a digital_out object allows the host to schedule
-  GPIO updates for the given pin at specified times (see the
-  schedule_digital_out command described below). Should the firmware
-  go into shutdown mode then all configured digital_out objects will
-  be set back to their default values. The 'max_duration' parameter is
-  used to implement a safety check - if it is non-zero then it is the
-  maximum number of clock ticks that the host may set the given GPIO
-  to a non-default value without further updates. For example, if the
-  default_value is zero and the max_duration is 16000 then if the host
-  sets the gpio to a value of one then it must schedule another update
-  to the gpio pin (to either zero or one) within 16000 clock
-  ticks. This safety feature can be used with heater pins to ensure
-  the host does not set the heater to a value of one and then go
-  off-line.
-
-* config_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
-  max_duration=%u : This command creates an internal object for
-  hardware based PWM pins that the host may schedule updates for. Its
-  usage is analogous to config_digital_out - see the description of
-  the 'set_pwm_out' and 'config_digital_out' commands for parameter
-  description.
-
-* config_soft_pwm_out oid=%c pin=%u cycle_ticks=%u default_value=%c
-  max_duration=%u : This command creates an internal firmware object
-  for software implemented PWM. Unlike hardware pwm pins, a software
-  pwm object does not require any special hardware support (other than
-  the ability to configure the pin as a digital output GPIO). Because
-  the output switching is implemented in the software of the firmware,
-  it is recommended that the cycle_ticks parameter correspond to a
-  time of 10ms or greater. See the description of the 'set_pwm_out'
-  and 'config_digital_out' 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
-  sampled at regular interval using the query_analog_in command (see
-  below).
-
-* config_stepper oid=%c step_pin=%c dir_pin=%c min_stop_interval=%u
-  invert_step=%c : This command creates an internal stepper
-  object. The 'step_pin' and 'dir_pin' parameters specify the step and
-  direction pins respectively; this command will configure them in
-  digital output mode. The 'invert_step' parameter specifies whether a
-  step occurs on a rising edge (invert_step=0) or falling edge
-  (invert_step=1). The 'min_stop_interval' implements a safety
-  feature - it is checked when the firmware finishes all moves for a
-  stepper - if it is non-zero it specifies the minimum number of 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_oid=%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
-  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_oid' parameter
-  specifies the oid of an associated stepper for the given endstop -
-  it is used during homing operations.
-
-Common commands
-===============
-
-This section lists some commonly used run-time commands. It is likely
-only of interest to developers looking to gain insight into Klippy.
-
-* schedule_digital_out oid=%c clock=%u value=%c : This command will
-  schedule a change to a digital output GPIO pin at the given clock
-  time. To use this command a 'config_digital_out' command with the
-  same 'oid' parameter must have been issued during firmware
-  configuration.
-
-* schedule_pwm_out oid=%c clock=%u value=%c : Schedules a change to 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=%c : Schedules a change
-  to a software PWM output pin. See the 'schedule_digital_out' and
-  'config_soft_pwm_out' commands for more info.
-
-* query_analog_in oid=%c clock=%u sample_ticks=%u sample_count=%c
-  rest_ticks=%u min_value=%hu max_value=%hu : This command sets up a
-  recurring schedule of analog input samples. To use this command a
-  'config_analog_in' command with the same 'oid' parameter must have
-  been issued during firmware configuration. The samples will start as
-  of 'clock' time, it will report on the obtained value every
-  'rest_ticks' clock ticks, it will over-sample 'sample_count' number
-  of times, and it will pause 'sample_ticks' number of clock ticks
-  between over-sample samples. The 'min_value' and 'max_value'
-  parameters implement a safety feature - the firmware will verify the
-  sampled value (after any oversampling) is always between the
-  supplied range. This is intended for use with 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 firmware to generate a "status"
-  response message. The host sends this command once a second to
-  obtain the value of the micro-controller clock and to estimate the
-  drift between host and micro-controller clocks. It enables the host
-  to accurately estimate the micro-controller clock.
-
-Stepper commands
-----------------
-
-* queue_step oid=%c interval=%u count=%hu add=%hi : This command
-  schedules 'count' number of steps for the given stepper, with
-  'interval' number of clock ticks between each step. The first step
-  will be 'interval' number of clock ticks since the last scheduled
-  step for the given stepper. If 'add' is non-zero then the interval
-  will be adjusted by 'add' amount after each step. This command
-  appends the given interval/count/add sequence to a per-stepper
-  queue. There may be hundreds of these sequences queued during normal
-  operation. New sequence are appended to the end of the queue and as
-  each sequence completes its 'count' number of steps it is popped
-  from the front of the queue. This system allows the firmware to
-  queue potentially hundreds of thousands of steps - all with reliable
-  and predictable schedule times.
-
-* set_next_step_dir oid=%c dir=%c : This command specifies the value
-  of the dir_pin that the next queue_step command will use.
-
-* reset_step_clock oid=%c clock=%u : Normally, step timing is relative
-  to the last step for a given stepper. This command resets the clock
-  so that the next step is relative to the supplied 'clock' time. The
-  host usually only sends this command at the start of a print.
-
-* end_stop_home oid=%c clock=%u rest_ticks=%u pin_value=%c : This
-  command is used during stepper "homing" operations. To use this
-  command a 'config_end_stop' command with the same 'oid' parameter
-  must have been issued during firmware configuration. When invoked,
-  the firmware will sample the endstop pin every 'rest_ticks' clock
-  ticks and check if it has a value equal to 'pin_value'. If the value
-  matches then the movement queue for the associated stepper will be
-  cleared and the stepper will come to an immediate halt. The host
-  uses this command to implement homing - the host instructs the
-  endstop to sample for the endstop trigger and then it issues a
-  series of queue_step commands to the stepper to move it towards the
-  endstop. Once the stepper hits the endstop, the trigger will be
-  detected, the movement halted, and the host notified.
-
-### Move queue
-
-Each queue_step command utilizes an entry in the firmware "move
-queue". The firmware allocates this queue when it receives the
-"finalize_config" command, and it reports the number of available
-queue entries in "config" response messages.
-
-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.

docs/G-Codes.md

@@ -0,0 +1,275 @@
+This document describes the commands that Klipper supports. These are
+commands that one may enter into the OctoPrint terminal tab.
+
+# G-Code commands
+
+Klipper supports the following standard G-Code commands:
+- Move (G0 or G1): `G1 [X<pos>] [Y<pos>] [Z<pos>] [E<pos>] [F<speed>]`
+- Dwell: `G4 P<milliseconds>`
+- Move to origin: `G28 [X] [Y] [Z]`
+- Turn off motors: `M18` or `M84`
+- Wait for current moves to finish: `M400`
+- Select tool: `T<index>`
+- Use absolute/relative distances for extrusion: `M82`, `M83`
+- Use absolute/relative coordinates: `G90`, `G91`
+- 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`
+
+For further details on the above commands see the
+[RepRap G-Code documentation](http://reprap.org/wiki/G-code).
+
+Klipper's goal is to support the G-Code commands produced by common
+3rd party software (eg, OctoPrint, Printrun, Slic3r, Cura, etc.) in
+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](../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
+"virtual_sdcard" config section is enabled:
+- List SD card: `M20`
+- Initialize SD card: `M21`
+- Select SD file: `M23 <filename>`
+- Start/resume SD print: `M24`
+- Pause SD print: `M25`
+- 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
+status.  These extended commands all follow a similar format - they
+start with a command name and may be followed by one or more
+parameters. For example: `SET_SERVO SERVO=myservo ANGLE=5.3`. In this
+document, the commands and parameters are shown in uppercase, however
+they are not case sensitive. (So, "SET_SERVO" and "set_servo" both run
+the same command.)
+
+The following standard commands are supported:
+- `QUERY_ENDSTOPS`: Probe the axis endstops and report if they are
+  "triggered" or in an "open" state. This command is typically used to
+  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>]`: 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).
+- `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
+  reached, and then the heater will be turned off and on for several
+  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_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.
+- `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
+  load new software (see
+  [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.
+
+## Custom Pin Commands
+
+The following command is available when an "output_pin" config section
+is enabled:
+- `SET_PIN PIN=config_name VALUE=<value>`
+
+## Servo Commands
+
+The following commands are available when a "servo" config section is
+enabled:
+- `SET_SERVO SERVO=config_name [WIDTH=<seconds>] [ENABLE=<0|1>]`
+- `SET_SERVO SERVO=config_name [ANGLE=<degrees>] [ENABLE=<0|1>]`
+
+## Probe
+
+The following commands are available when a "probe" config section is
+enabled:
+- `PROBE`: Move the nozzle downwards until the probe triggers.
+- `QUERY_PROBE`: Report the current status of the probe ("triggered"
+  or "open").
+
+## 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.
+
+## Delta Calibration
+
+The following commands are available when the "delta_calibrate" config
+section is enabled:
+- `DELTA_CALIBRATE [METHOD=manual]`: This command will probe seven
+  points on the bed and recommend updated endstop positions, tower
+  angles, and radius.
+  - `NEXT`: If manual bed probing is enabled, then one can use this
+    command to move to the next probing point during a DELTA_CALIBRATE
+    operation.
+- `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 [METHOD=manual]`: This command will probe the
+  points specified in the config and then recommend updated x and y
+  tilt adjustments.
+  - `NEXT`: If manual bed probing is enabled, then one can use this
+    command to move to the next probing point during a
+    BED_TILT_CALIBRATE operation.
+
+## Mesh Bed Leveling
+
+The following commands are available when the "bed_mesh" config
+section is enabled:
+- `BED_MESH_CALIBRATE [METHOD=manual]`: 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.
+  - `NEXT`: If manual bed probing is enabled, then one can use this
+    command to move to the next probing point during a
+    BED_MESH_CALIBRATE operation.
+- `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.
+
+## Z Tilt
+
+The following commands are available when the "z_tilt" config section
+is enabled:
+- `Z_TILT_ADJUST`: This command will probe the points specified in the
+  config and then make independent adjustments to each Z stepper to
+  compensate for tilt.
+
+## Dual Carriages
+
+The following command is available when the "dual_carriage" config
+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
+
+The following command is available when the "tmc2130" config section
+is enabled:
+- `DUMP_TMC STEPPER=<name>`: This command will read the TMC2130 driver
+  registers and report their 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>`: This command will forcibly move the given stepper
+  the given distance (in mm) at the given constant velocity (in
+  mm/s). 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.

docs/Installation.md

@@ -1,113 +1,82 @@
-Klipper is currently in an experimental state. These instructions
-assume the software will run on a Raspberry Pi computer in conjunction
-with OctoPrint. Klipper supports Atmel ATmega based micro-controllers
-and Arduino Due (Atmel SAM3x8e ARM micro-controllers) printers.
+These instructions assume the software will run on a Raspberry Pi
+computer in conjunction with OctoPrint. It is recommended that a
+Raspberry Pi 2 or Raspberry Pi 3 computer be used as the host machine
+(see the
+[FAQ](FAQ.md#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3)
+for other machines).
 
-It is recommended that a Raspberry Pi 2 or Raspberry Pi 3 computer be
-used as the host. The software will run on a first generation
-Raspberry Pi, but the combined load of OctoPrint, Klipper, and a web
-cam (if applicable) can overwhelm its CPU leading to print stalls.
+Klipper currently supports Atmel ATmega based micro-controllers,
+Arduino Due (Atmel SAM3x8e ARM micro-controller), Smoothieboard (ARM
+LPC176x), 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.13.0 or later - see the
+Raspberry Pi computer. Use OctoPi v0.14.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.0 or later.
+page, follow the prompt to upgrade OctoPrint to v1.3.7 or later.
 
-After installing OctoPi and upgrading OctoPrint, ssh into the target
-machine (ssh pi@octopi -- password is "raspberry") and run the
-following commands:
-
-```
-sudo apt-get update
-sudo apt-get install libncurses-dev
-sudo apt-get install avrdude gcc-avr binutils-avr avr-libc # AVR toolchain
-sudo apt-get install bossa-cli libnewlib-arm-none-eabi # ARM toolchain
-```
-
-The host software (Klippy) requires a one-time setup - run as the
-regular "pi" user:
-
-```
-virtualenv ~/klippy-env
-~/klippy-env/bin/pip install cffi==1.6.0 pyserial==3.2.1 greenlet==0.4.10
-```
-
-Building Klipper
-================
-
-To obtain Klipper, run the following command on the target machine:
+After installing OctoPi and upgrading OctoPrint, it will be necessary
+to ssh into the target machine to run a handful of system commands. If
+using a Linux or MacOS desktop, then the "ssh" software should already
+be installed on the desktop. There are free ssh clients available for
+other desktops (eg,
+[PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/)). Use the
+ssh utility to connect to the Raspberry Pi (ssh pi@octopi -- password
+is "raspberry") and run the following commands:
 
 ```
 git clone https://github.com/KevinOConnor/klipper
-cd klipper/
+./klipper/scripts/install-octopi.sh
 ```
 
-To compile the micro-controller code, start by configuring it:
+The above will download Klipper, install some system dependencies,
+setup Klipper to run at system startup, and start the Klipper host
+software. It will require an internet connection and it may take a few
+minutes to complete.
+
+Building and flashing the micro-controller
+==========================================
+
+To compile the micro-controller code, start by running these commands
+on the Raspberry Pi:
 
 ```
+cd ~/klipper/
 make menuconfig
 ```
 
-Select the appropriate micro-controller and serial baud rate. Once
-configured, run:
+Select the appropriate micro-controller and review any other options
+provided. For boards with serial ports, the recommended baud rate is
+250000 (see the [FAQ](FAQ.md#how-do-i-change-the-serial-baud-rate)
+before changing). Once configured, run:
 
 ```
 make
 ```
 
-Ignore any warnings you may see about "misspelled signal handler" (it
-is due to a bug fixed in gcc v4.8.3).
-
-Installing Klipper on an AVR micro-controller
----------------------------------------------
-
-The avrdude package can be used to install the micro-controller code
-on an AVR ATmega chip. The exact syntax of the avrdude command is
-different for each micro-controller. The following is an example
-command for atmega2560 chips:
+Finally, for common micro-controllers, the code can be flashed with:
 
 ```
-example-only$ avrdude -C/etc/avrdude.conf -v -patmega2560 -cwiring -P/dev/ttyACM0 -b115200 -D -Uflash:w:/home/pi/klipper/out/klipper.elf.hex:i
+sudo service klipper stop
+make flash FLASH_DEVICE=/dev/ttyACM0
+sudo service klipper start
 ```
 
-Installing Klipper on an Arduino Due
-------------------------------------
+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
+communication device is **/dev/ttyACM0** - see the
+[FAQ](FAQ.md#wheres-my-serial-port) for other possibilities.
 
-Klipper currently uses the Arduino Due USB programming port (it will
-not work when connected to the application USB port). The programming
-port is the USB port closest to the power supply. To flash Klipper to
-the Due connect it to the host machine and run:
-
-```
-stty -F /dev/ttyACM0 1200
-bossac -i -p ttyACM0 -R -e -w -v -b ~/klipper/out/klipper.bin
-```
-
-Setting up the printer configuration
+Configuring OctoPrint to use Klipper
 ====================================
 
-It is necessary to configure the printer. This is done by modifying a
-configuration file that resides on the host. Start by copying an
-example configuration and editing it.  For example:
-
-```
-cp ~/klipper/config/example.cfg ~/printer.cfg
-nano printer.cfg
-```
-
-Make sure to look at and update each setting that is appropriate for
-the hardware.
-
-Configuring OctoPrint to use Klippy
-===================================
-
 The OctoPrint web server needs to be configured to communicate with
-the Klippy host software. Using a web-browser, login to the OctoPrint
+the Klipper host software. Using a web browser, login to the OctoPrint
 web page, and navigate to the Settings tab. Then configure the
 following items:
 
@@ -115,40 +84,76 @@ 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". Change the Baudrate field to
-250000 (this buad rate field is not related to the firmware baudrate
-and may be safely left at 250000). Unselect the "Not only cancel
-ongoing prints but also disconnect..." checkbox.
+"Serial Port" setting to "/tmp/printer". Navigate to the "Behavior"
+sub-tab and select the "Cancel any ongoing prints but stay connected
+to the printer" option. Click "Save".
 
-Under the "Features" tab, unselect "Enable SD support". Then click
-"Save".
-
-Running the host software
-=========================
-
-The host software is executed by running the following as the regular
-"pi" user:
-
-```
-~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log < /dev/null > /dev/null 2>&1 &
-```
-
-Once Klippy is running, use a web-browser and navigate to the
-OctoPrint web site. Under the "Connection" tab (on the left of the
-main page) make sure the "Serial Port" is set to "/tmp/printer" and
+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
 click "Connect". (If "/tmp/printer" is not an available selection then
 try reloading the page.)
 
 Once connected, navigate to the "Terminal" tab and type "status"
-(without the quotes) into the command entry box and click "Send". If
-the Klippy config file was successfully read, and the micro-controller
-was successfully found and configured, then this command will report
-that the printer is ready. Klippy reports error messages via this
-terminal tab. The "status" command can be used to re-report error
-messages.
+(without the quotes) into the command entry box and click "Send". The
+terminal window will likely report there is an error opening the
+config file - that means OctoPrint is successfully communicating with
+Klipper. Proceed to the next section.
 
-In addition to common g-code commands, Klippy supports a few extended
-commands - "status" is an example of one of these commands. Use the
-"help" command to get a list of other extended commands. In
-particular, note the "restart" command - use this command to reload
-the Klippy config file after any changes.
+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
+[example.cfg](../config/example.cfg) file contains documentation on
+command parameters and it can also be used as an initial config file
+template. However, for most printers, 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"
+and/or "sftp" protocols. There are freely available tools that support
+this (eg, Notepad++, WinSCP, and Cyberduck). Use one of the example
+config files as a starting point and save it as a file named
+"printer.cfg" in the home directory of the pi user (ie,
+/home/pi/printer.cfg).
+
+Alternatively, one can also copy and edit the file directly on the
+Raspberry Pi via ssh - for example:
+
+```
+cp ~/klipper/config/example.cfg ~/printer.cfg
+nano ~/printer.cfg
+```
+
+Make sure to review and update each setting that is appropriate for
+the hardware.
+
+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
+config file is successfully read and the micro-controller is
+successfully found and configured. It is not unusual to have
+configuration errors during the initial setup - update the printer
+config file and issue "restart" until "status" reports the printer is
+ready.
+
+Klipper reports error messages via the OctoPrint terminal tab. The
+"status" command can be used to re-report error messages. The default
+Klipper startup script also places a log in **/tmp/klippy.log** which
+provides more detailed information.
+
+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
+[config check document](Config_checks.md) to perform some basic checks
+on the pin definitions in the config file.
+
+Contacting the developers
+=========================
+
+Be sure to see the [FAQ](FAQ.md) for answers to some common questions.
+See the [contact page](Contact.md) to report a bug or to contact the
+developers.

docs/Kinematics.md

@@ -0,0 +1,302 @@
+This document provides an overview of how Klipper implements robot
+motion (its [kinematics](https://en.wikipedia.org/wiki/Kinematics)).
+The contents may be of interest to both developers interested in
+working on the Klipper software as well as users interested in better
+understanding the mechanics of their machines.
+
+Acceleration
+============
+
+Klipper implements a constant acceleration scheme whenever the print
+head changes velocity - the velocity is gradually changed to the new
+speed instead of suddenly jerking to it. Klipper always enforces
+acceleration between the tool head and the print. The filament leaving
+the extruder can be quite fragile - rapid jerks and/or extruder flow
+changes lead to poor quality and poor bed adhesion. Even when not
+extruding, if the print head is at the same level as the print then
+rapid jerking of the head can cause disruption of recently deposited
+filament. Limiting speed changes of the print head (relative to the
+print) reduces risks of disrupting the print.
+
+It is also important to limit acceleration so that the stepper motors
+do not skip or put excessive stress on the machine. Klipper limits the
+torque on each stepper by virtue of limiting the acceleration of the
+print head. Enforcing acceleration at the print head naturally also
+limits the torque of the steppers that move the print head (the
+inverse is not always true).
+
+Klipper implements constant acceleration. The key formula for constant
+acceleration is:
+```
+velocity(time) = start_velocity + accel*time
+```
+
+Trapezoid generator
+===================
+
+Klipper uses a traditional "trapezoid generator" to model the motion
+of each move - each move has a start speed, it accelerates to a
+cruising speed at constant acceleration, it cruises at a constant
+speed, and then decelerates to the end speed using constant
+acceleration.
+
+![trapezoid](img/trapezoid.svg.png)
+
+It's called a "trapezoid generator" because a velocity diagram of the
+move looks like a trapezoid.
+
+The cruising speed is always greater than or equal to both the start
+speed and the end speed. The acceleration phase may be of zero
+duration (if the start speed is equal to the cruising speed), the
+cruising phase may be of zero duration (if the move immediately starts
+decelerating after acceleration), and/or the deceleration phase may be
+of zero duration (if the end speed is equal to the cruising speed).
+
+![trapezoids](img/trapezoids.svg.png)
+
+Look-ahead
+==========
+
+The "look-ahead" system is used to determine cornering speeds between
+moves.
+
+Consider the following two moves contained on an XY plane:
+
+![corner](img/corner.svg.png)
+
+In the above situation it is possible to fully decelerate after the
+first move and then fully accelerate at the start of the next move,
+but that is not ideal as all that acceleration and deceleration would
+greatly increase the print time and the frequent changes in extruder
+flow would result in poor print quality.
+
+To solve this, the "look-ahead" mechanism queues multiple incoming
+moves and analyzes the angles between moves to determine a reasonable
+speed that can be obtained during the "junction" between two moves. If
+the next move is nearly in the same direction then the head need only
+slow down a little (if at all).
+
+![lookahead](img/lookahead.svg.png)
+
+However, if the next move forms an acute angle (the head is going to
+travel in nearly a reverse direction on the next move) then only a
+small junction speed is permitted.
+
+![lookahead](img/lookahead-slow.svg.png)
+
+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
+look-ahead between them is unnecessary.
+
+Key formula for look-ahead:
+```
+end_velocity^2 = start_velocity^2 + 2*accel*move_distance
+```
+
+Smoothed look-ahead
+-------------------
+
+Klipper also implements a mechanism for smoothing out the motions of
+short "zigzag" moves. Consider the following moves:
+
+![zigzag](img/zigzag.svg.png)
+
+In the above, the frequent changes from acceleration to deceleration
+can cause the machine to vibrate which causes stress on the machine
+and increases the noise. To reduce this, Klipper tracks both regular
+move acceleration as well as a virtual "acceleration to deceleration"
+rate. Using this system, the top speed of these short "zigzag" moves
+are limited to smooth out the printer motion:
+
+![smoothed](img/smoothed.svg.png)
+
+Specifically, the code calculates what the velocity of each move would
+be if it were limited to this virtual "acceleration to deceleration"
+rate (half the normal acceleration rate by default). In the above
+picture the dashed gray lines represent this virtual acceleration rate
+for the first move. If a move can not reach its full cruising speed
+using this virtual acceleration rate then its top speed is reduced to
+the maximum speed it could obtain at this virtual acceleration
+rate. For most moves the limit will be at or above the move's existing
+limits and no change in behavior is induced. For short zigzag moves,
+however, this limit reduces the top speed. Note that it does not
+change the actual acceleration within the move - the move continues to
+use the normal acceleration scheme up to its adjusted top-speed.
+
+Generating steps
+================
+
+Once the look-ahead process completes, the print head movement for the
+given move is fully known (time, start position, end position,
+velocity at each point) and it is possible to generate the step times
+for the move. This process is done within "kinematic classes" in the
+Klipper code. Outside of these kinematic classes, everything is
+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.
+
+Klipper uses an
+[iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm)
+to generate the step times for each stepper. The code contains the
+formulas to calculate the ideal cartesian coordinates of the head at
+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:
+```
+move_distance = (start_velocity + .5 * accel * move_time) * move_time
+```
+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
+----------------
+
+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
+------------
+
+Step generation on a delta robot is based on Pythagoras's theorem:
+```
+stepper_position = (sqrt(arm_length^2
+                         - (cartesian_x_position - tower_x_position)^2
+                         - (cartesian_y_position - tower_y_position)^2)
+                    + cartesian_z_position)
+```
+
+### Stepper motor acceleration limits ###
+
+With delta kinematics it is possible for a move that is accelerating
+in cartesian space to require an acceleration on a particular stepper
+motor greater than the move's acceleration. This can occur when a
+stepper arm is more horizontal than vertical and the line of movement
+passes near that stepper's tower. Although these moves could require a
+stepper motor acceleration greater than the printer's maximum
+configured move acceleration, the effective mass moved by that stepper
+would be smaller. Thus the higher stepper acceleration does not result
+in significantly higher stepper torque and it is therefore considered
+harmless.
+
+However, to avoid extreme cases, Klipper enforces a maximum ceiling on
+stepper acceleration of three times the printer's configured maximum
+move acceleration. (Similarly, the maximum velocity of the stepper is
+limited to three times the maximum move velocity.) In order to enforce
+this limit, moves at the extreme edge of the build envelope (where a
+stepper arm may be nearly horizontal) will have a lower maximum
+acceleration and velocity.
+
+Extruder kinematics
+-------------------
+
+Klipper implements extruder motion in its own kinematic class. Since
+the timing and speed of each print head movement is fully known for
+each move, it's possible to calculate the step times for the extruder
+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 formulas that cartesian robots use:
+```
+stepper_position = requested_e_position
+```
+
+### Pressure advance ###
+
+Experimentation has shown that it's possible to improve the modeling
+of the extruder beyond the basic extruder formula. In the ideal case,
+as an extrusion move progresses, the same volume of filament should be
+deposited at each point along the move and there should be no volume
+extruded after the move. Unfortunately, it's common to find that the
+basic extrusion formulas cause too little filament to exit the
+extruder at the start of extrusion moves and for excess filament to
+extrude after extrusion ends. This is often referred to as "ooze".
+
+![ooze](img/ooze.svg.png)
+
+The "pressure advance" system attempts to account for this by using a
+different model for the extruder. Instead of naively believing that
+each mm^3 of filament fed into the extruder will result in that amount
+of mm^3 immediately exiting the extruder, it uses a model based on
+pressure. Pressure increases when filament is pushed into the extruder
+(as in [Hooke's law](https://en.wikipedia.org/wiki/Hooke%27s_law)) and
+the pressure necessary to extrude is dominated by the flow rate
+through the nozzle orifice (as in
+[Poiseuille's law](https://en.wikipedia.org/wiki/Poiseuille_law)). The
+key idea is that the relationship between filament, pressure, and flow
+rate can be modeled using a linear coefficient:
+```
+stepper_position = requested_e_position + pressure_advance_coefficient * nominal_extruder_velocity
+```
+
+See the [pressure advance](Pressure_Advance.md) document for
+information on how to find this pressure advance coefficient.
+
+Once configured, Klipper will push in an additional amount of filament
+during acceleration. The higher the desired filament flow rate, the
+more filament must be pushed in during acceleration to account for
+pressure. During head deceleration the extra filament is retracted
+(the extruder will have a negative velocity).
+
+![pressure-advance](img/pressure-advance.svg.png)
+
+One may notice that the pressure advance algorithm can cause the
+extruder motor to make sudden velocity changes. This is tolerated
+based on the idea that the majority of the inertia in the system is in
+changing the extruder pressure. As long as the extruder pressure does
+not change rapidly the sudden changes in extruder motor velocity are
+tolerated.
+
+One area where sudden velocity changes become problematic is during
+small changes in head speed due to cornering.
+
+![pressure-cornering](img/pressure-cornering.svg.png)
+
+To prevent this, the Klipper pressure advance code utilizes the move
+look-ahead queue to detect intermittent speed changes. During a
+deceleration event the code finds the maximum upcoming head speed
+within a configurable time window. The pressure is then only adjusted
+to this found maximum. This can greatly reduce (or even completely
+eliminate) pressure changes during cornering.

docs/MCU_Commands.md

@@ -0,0 +1,306 @@
+This document provides information on the low-level micro-controller
+commands that are sent from the Klipper "host" software and processed
+by the Klipper micro-controller software. This document is not an
+authoritative reference for these commands, nor is it an exclusive
+list of all available commands.
+
+This document may be useful for developers interested in understanding
+the low-level micro-controller commands.
+
+See the [protocol](Protocol.md) document for more information on the
+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".
+
+Startup Commands
+================
+
+It may be necessary to take certain one-time actions to configure the
+micro-controller and its peripherals. This section lists common
+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
+  configures the given pin as a digital out GPIO and it sets it to
+  either a low level (value=0) or a high level (value=1). This command
+  may be useful for configuring the initial value of LEDs and for
+  configuring the initial value of stepper driver micro-stepping pins.
+
+* `set_pwm_out pin=%u cycle_ticks=%u value=%hu` : This command will
+  immediately configure the given pin to use hardware based
+  pulse-width-modulation (PWM) with the given number of
+  cycle_ticks. The "cycle_ticks" is the number of MCU clock ticks each
+  power on and power off cycle should last. A cycle_ticks value of 1
+  can be used to request the fastest possible cycle time. The "value"
+  parameter is between 0 and 255 with 0 indicating a full off state
+  and 255 indicating a full on state. This command may be useful for
+  enabling CPU and nozzle cooling fans.
+
+Low-level micro-controller configuration
+========================================
+
+Most commands in the micro-controller require an initial setup before
+they can be successfully invoked. This section provides an overview of
+the configuration process. This section and the following sections are
+likely only of interest to developers interested in the internal
+details of Klipper.
+
+When the host first connects to the micro-controller it always starts
+by obtaining a data dictionary (see [protocol](Protocol.md) for more
+information). After the data dictionary is obtained the host will
+check if the micro-controller is in a "configured" state and configure
+it if not. Configuration involves the following phases:
+
+* `get_config` : The host starts by checking if the micro-controller
+  is already configured. The micro-controller responds to this command
+  with a "config" response message. The micro-controller software
+  always starts in an unconfigured state at power-on. It remains in
+  this state until the host completes the configuration processes (by
+  issuing a finalize_config command). If the micro-controller is
+  already configured from a previous session (and is configured with
+  the desired settings) then no further action is needed by the host
+  and the configuration process ends successfully.
+
+* `allocate_oids count=%c` : This command is issued to inform the
+  micro-controller of the maximum number of object-ids (oid) that the
+  host requires. It is only valid to issue this command once. An oid
+  is an integer identifier allocated to each stepper, each endstop,
+  and each schedulable gpio pin. The host determines in advance the
+  number of oids it will require to operate the hardware and passes
+  this to the micro-controller so that it may allocate sufficient
+  memory to store a mapping from oid to internal object.
+
+* `config_XXX oid=%c ...` : By convention any command starting with
+  the "config_" prefix creates a new micro-controller object and
+  assigns the given oid to it. For example, the config_digital_out
+  command will configure the specified pin as a digital output GPIO
+  and create an internal object that the host can use to schedule
+  changes to the given GPIO. The oid parameter passed into the config
+  command is selected by the host and must be between zero and the
+  maximum count supplied in the allocate_oids command. The config
+  commands may only be run when the micro-controller is not in a
+  configured state (ie, prior to the host sending finalize_config) and
+  after the allocate_oids command has been sent.
+
+* `finalize_config crc=%u` : The finalize_config command transitions
+  the micro-controller from an unconfigured state to a configured
+  state. The crc parameter passed to the micro-controller is stored
+  and provided back to the host in "config" response messages. By
+  convention, the host takes a 32bit CRC of the configuration it will
+  request and at the start of subsequent communication sessions it
+  checks that the CRC stored in the micro-controller exactly matches
+  its desired CRC. If the CRC does not match then the host knows the
+  micro-controller has not been configured in the state desired by the
+  host.
+
+Common micro-controller objects
+-------------------------------
+
+This section lists some commonly used config commands.
+
+* `config_digital_out oid=%c pin=%u value=%c default_value=%c
+  max_duration=%u` : This command creates an internal micro-controller
+  object for the given GPIO 'pin'. The pin will be configured in
+  digital output mode and set to an initial value as specified by
+  'value' (0 for low, 1 for high). Creating a digital_out object
+  allows the host to schedule GPIO updates for the given pin at
+  specified times (see the schedule_digital_out command described
+  below). Should the micro-controller software go into shutdown mode
+  then all configured digital_out objects will be set to
+  'default_value'. The 'max_duration' parameter is used to implement a
+  safety check - if it is non-zero then it is the maximum number of
+  clock ticks that the host may set the given GPIO to a non-default
+  value without further updates. For example, if the default_value is
+  zero and the max_duration is 16000 then if the host sets the gpio to
+  a value of one then it must schedule another update to the gpio pin
+  (to either zero or one) within 16000 clock ticks. This safety
+  feature can be used with heater pins to ensure the host does not
+  enable the heater and then go off-line.
+
+* `config_pwm_out oid=%c pin=%u cycle_ticks=%u value=%hu
+  default_value=%hu max_duration=%u` : This command creates an
+  internal object for hardware based PWM pins that the host may
+  schedule updates for. Its usage is analogous to config_digital_out -
+  see the description of the 'set_pwm_out' and 'config_digital_out'
+  commands for parameter description.
+
+* `config_soft_pwm_out oid=%c pin=%u cycle_ticks=%u value=%c
+  default_value=%c max_duration=%u` : This command creates an internal
+  micro-controller object for software implemented PWM. Unlike
+  hardware pwm pins, a software pwm object does not require any
+  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
+  greater. See the description of the 'set_pwm_out' and
+  'config_digital_out' 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
+  sampled at regular interval using the query_analog_in command (see
+  below).
+
+* `config_stepper oid=%c step_pin=%c dir_pin=%c min_stop_interval=%u
+  invert_step=%c` : This command creates an internal stepper
+  object. The 'step_pin' and 'dir_pin' parameters specify the step and
+  direction pins respectively; this command will configure them in
+  digital output mode. The 'invert_step' parameter specifies whether a
+  step occurs on a rising edge (invert_step=0) or falling edge
+  (invert_step=1). The 'min_stop_interval' implements a safety
+  feature - it is checked when the micro-controller finishes all moves
+  for a stepper - if it is non-zero it specifies the minimum number of
+  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
+  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
+  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).
+
+* `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
+===============
+
+This section lists some commonly used run-time commands. It is likely
+only of interest to developers looking to gain insight into Klipper.
+
+* `schedule_digital_out oid=%c clock=%u value=%c` : This command will
+  schedule a change to a digital output GPIO pin at the given clock
+  time. To use this command a 'config_digital_out' command with the
+  same 'oid' parameter must have been issued during micro-controller
+  configuration.
+
+* `schedule_pwm_out oid=%c clock=%u value=%hu` : Schedules a change to
+  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
+  change to a software PWM output pin. See the 'schedule_digital_out'
+  and 'config_soft_pwm_out' commands for more info.
+
+* `query_analog_in oid=%c clock=%u sample_ticks=%u sample_count=%c
+  rest_ticks=%u min_value=%hu max_value=%hu` : This command sets up a
+  recurring schedule of analog input samples. To use this command a
+  'config_analog_in' command with the same 'oid' parameter must have
+  been issued during micro-controller configuration. The samples will
+  start as of 'clock' time, it will report on the obtained value every
+  'rest_ticks' clock ticks, it will over-sample 'sample_count' number
+  of times, and it will pause 'sample_ticks' number of clock ticks
+  between over-sample samples. The 'min_value' and 'max_value'
+  parameters implement a safety feature - the micro-controller
+  software will verify the sampled value (after any oversampling) is
+  always between the supplied range. This is intended for use with
+  pins attached to thermistors controlling heaters - it can be used to
+  check that a heater is within a temperature range.
+
+* `get_clock` : This command causes the micro-controller to generate a
+  "clock" response message. The host sends this command once a second
+  to obtain the value of the micro-controller clock and to estimate
+  the drift between host and micro-controller clocks. It enables the
+  host to accurately estimate the micro-controller clock.
+
+Stepper commands
+----------------
+
+* `queue_step oid=%c interval=%u count=%hu add=%hi` : This command
+  schedules 'count' number of steps for the given stepper, with
+  'interval' number of clock ticks between each step. The first step
+  will be 'interval' number of clock ticks since the last scheduled
+  step for the given stepper. If 'add' is non-zero then the interval
+  will be adjusted by 'add' amount after each step. This command
+  appends the given interval/count/add sequence to a per-stepper
+  queue. There may be hundreds of these sequences queued during normal
+  operation. New sequence are appended to the end of the queue and as
+  each sequence completes its 'count' number of steps it is popped
+  from the front of the queue. This system allows the micro-controller
+  to queue potentially hundreds of thousands of steps - all with
+  reliable and predictable schedule times.
+
+* `set_next_step_dir oid=%c dir=%c` : This command specifies the value
+  of the dir_pin that the next queue_step command will use.
+
+* `reset_step_clock oid=%c clock=%u` : Normally, step timing is
+  relative to the last step for a given stepper. This command resets
+  the clock so that the next step is relative to the supplied 'clock'
+  time. The host usually only sends this command at the start of a
+  print.
+
+* `stepper_get_position oid=%c` : This command causes the
+  micro-controller to generate a "stepper_position" response message
+  with the stepper's current position. The position is the total
+  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
+  rest_ticks=%u pin_value=%c` : This command is used during stepper
+  "homing" operations. To use this command a 'config_end_stop' 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'
+  clock ticks and check if it has a value equal to 'pin_value'. If the
+  value matches (and it continues to match for 'sample_count'
+  additional samples spread 'sample_ticks' apart) then the movement
+  queue for the associated stepper will be cleared and the stepper
+  will come to an immediate halt. The host uses this command to
+  implement homing - the host instructs the endstop to sample for the
+  endstop trigger and then it issues a series of queue_step commands
+  to move a stepper towards the endstop. Once the stepper hits the
+  endstop, the trigger will be detected, the movement halted, and the
+  host notified.
+
+### Move queue
+
+Each queue_step command utilizes an entry in the micro-controller
+"move queue". This queue is allocated when it receives the
+"finalize_config" command, and it reports the number of available
+queue entries in "config" response messages.
+
+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/Overview.md

@@ -1,20 +1,48 @@
-See [installation](Installation.md) for information on compiling,
-installing, and running Klipper. Read [features](Features.md) for a
-high-level description of useful capabilities. The history of releases
-is available at [releases](Releases.md).
+Welcome to the Klipper documentation. There are two parts to Klipper -
+code that runs on a micro-controller and code that runs on a "host"
+machine. The host code is intended to run on a low-cost
+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
+machine. The [config/example.cfg](../config/example.cfg) file serves
+as a reference for the config file. See the [Slicers](Slicers.md)
+document for information on configuring a slicer with Klipper. See the
+[Endstop Phase](Endstop_Phase.md) document for information on
+Klipper's "stepper phase adjusted endstop" system. See the
+[Delta Calibrate](Delta_Calibrate.md) document for information on
+calibrating delta printers. The
+[Pressure Advance](Pressure_Advance.md) document contains information
+on tuning the pressure advance config.
+
+The [kinematics](Kinematics.md) document provides some technical
+details on how Klipper implements motion. The [FAQ](FAQ.md) answers
+some common questions. The [G-Codes](G-Codes.md) document lists
+currently supported run-time commands.
+
+The history of Klipper releases is available at
+[releases](Releases.md). See [contact](Contact.md) for information on
+bug reporting and general communication with the developers.
+
+Developer Documentation
+=======================
 
 There are also several documents available for developers interested
-in understanding how Klipper works:
+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 [code overview](Code_Overview.md) for information on the structure
-and layout of the Klipper code.
-
-See [protocol](Protocol.md) for information on the messaging protocol
-between host and firmware. See also
-[firmware commands](Firmware_Commands.md) for a high-level description
-of common commands implemented in the firmware.
+See [protocol](Protocol.md) for information on the low-level messaging
+protocol between host and micro-controller. See also
+[MCU commands](MCU_Commands.md) for a description of low-level
+commands implemented in the micro-controller software.
 
 See [debugging](Debugging.md) for information on how to test and debug
-Klipper.
-
-See [todo](Todo.md) for information on possible future code features.
+Klipper. See [stm32f1](stm32f1.md) for information on the STM32F1
+micro-controller port. See [bootloaders](Bootloaders.md) for developer
+information on micro-controller flashing.

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

@@ -0,0 +1,143 @@
+This document provides information on tuning the "pressure advance"
+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.
+
+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 tuning.
+
+In order to calibrate pressure advance the printer must be configured
+and operational. The tuning test involves printing objects and
+inspecting the differences between objects. It is a good idea to read
+this document in full prior to running the test.
+
+Use a slicer to generate g-code for the large hollow square found in
+[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
+lack of filament on the side immediately after that corner:
+
+![corner-blob](img/corner-blob.jpg)
+
+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 increase pressure advance (start with
+`SET_PRESSURE_ADVANCE ADVANCE=0.050`) and reprint the test object.
+With pressure advance, the extruder will retract when the head slows
+down, thus countering the pressure buildup and ideally eliminate the
+blobbing.
+
+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
+up after cornering):
+
+![corner-dimple](img/corner-dimple.jpg)
+
+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.050 and 1.000 (the high
+end usually only with bowden extruders). If there is no significant
+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.
+
+Although this tuning exercise directly improves the quality of
+corners, it's worth remembering that a good pressure advance
+configuration also reduces ooze throughout the print.
+
+At the completion of this test, update the extruder's pressure_advance
+setting in the configuration file and issue a RESTART command. The
+RESTART command will also return the acceleration, cornering speeds,
+and look-ahead times to their normal values.
+
+Important Notes
+===============
+
+* 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/Protocol.md

@@ -1,8 +1,9 @@
-The Klipper transmission protocol can be thought of, at a high level,
-as a series of command and response strings that are compressed,
-transmitted over a serial line, and then processed at the receiving
-side. An example series of commands in uncompressed human-readable
-format might look like:
+The Klipper messaging protocol is used for low-level communication
+between the Klipper host software and the Klipper micro-controller
+software. At a high level the protocol can be thought of as a series
+of command and response strings that are compressed, transmitted, and
+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
@@ -12,34 +13,35 @@ queue_step oid=7 interval=7458 count=10 add=331
 queue_step oid=7 interval=11717 count=4 add=1281
 ```
 
-See the [firmware commands](Firmware_Commands.md) document for
-information on available commands. See the [debugging](Debugging.md)
-document for information on how to translate a G-Code file into its
-corresponding human-readable firmware commands.
+See the [mcu commands](MCU_Commands.md) document for information on
+available commands. See the [debugging](Debugging.md) document for
+information on how to translate a G-Code file into its corresponding
+human-readable micro-controller commands.
 
-This page provides a high-level description of the Klipper
-transmission protocol itself. It describes how messages are declared,
-encoded in binary format (the "compression" scheme), and transmitted.
+This page provides a high-level description of the Klipper messaging
+protocol itself. It describes how messages are declared, encoded in
+binary format (the "compression" scheme), and transmitted.
 
 The goal of the protocol is to enable an error-free communication
-channel between the host and firmware that is low-latency,
-low-bandwidth, and low-complexity for the firmware.
+channel between the host and micro-controller that is low-latency,
+low-bandwidth, and low-complexity for the micro-controller.
 
-Firmware Interface
-==================
+Micro-controller Interface
+==========================
 
 The Klipper transmission protocol can be thought of as a
 [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) mechanism
-between firmware and host. The firmware declares the commands that the
-host may invoke along with the response messages that it can
-generate. The host uses that information to command the firmware to
-perform actions and to interpret the results.
+between micro-controller and host. The micro-controller software
+declares the commands that the host may invoke along with the response
+messages that it can generate. The host uses that information to
+command the micro-controller to perform actions and to interpret the
+results.
 
 Declaring commands
 ------------------
 
-The firmware declares a "command" by using the DECL_COMMAND() macro in
-the C code. For example:
+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");
@@ -48,11 +50,11 @@ DECL_COMMAND(command_set_digital_out, "set_digital_out pin=%u value=%c");
 The above declares a command named "set_digital_out". This allows the
 host to "invoke" this command which would cause the
 command_set_digital_out() C function to be executed in the
-firmware. The above also indicates that the command takes two integer
-parameters. When the command_set_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
-'value'.
+micro-controller. The above also indicates that the command takes two
+integer parameters. When the command_set_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 'value'.
 
 In general, the parameters are described with printf() style syntax
 (eg, "%u"). The formatting directly corresponds to the human-readable
@@ -63,64 +65,61 @@ documentation. In this example, the "%c" is also used as documentation
 to indicate the expected integer is 1 byte in size (the declared
 integer size does not impact the parsing or encoding).
 
-At firmware compile time, the build will collect all commands declared
-with DECL_COMMAND(), determine their parameters, and arrange for them
-to be callable.
+The micro-controller build will collect all commands declared with
+DECL_COMMAND(), determine their parameters, and arrange for them to be
+callable.
 
 Declaring responses
 -------------------
 
-To send information from the firmware to the host a "response" is
-generated. These are both declared and transmitted using the sendf() C
-macro. For example:
+To send information from the micro-controller to the host a "response"
+is generated. These are both declared and transmitted using the
+sendf() C macro. For example:
 
 ```
 sendf("status clock=%u status=%c", sched_read_time(), sched_is_shutdown());
 ```
 
 The above transmits a "status" response message that contains two
-integer parameters ("clock" and "status"). At firmware compile time
-the build automatically finds all sendf() calls and generates encoders
-for them. The first parameter of the sendf() function describes the
+integer parameters ("clock" and "status"). The micro-controller build
+automatically finds all sendf() calls and generates encoders for
+them. The first parameter of the sendf() function describes the
 response and it is in the same format as command declarations.
 
 The host can arrange to register a callback function for each
 response. So, in effect, commands allow the host to invoke C functions
-in the firmware and responses allow the firmware to invoke code in the
-host.
+in the micro-controller and responses allow the micro-controller
+software to invoke code in the host.
 
-The firmware should only invoke sendf() from command or task handlers,
-and it should not be invoked from interrupts or timers. The firmware
-does not need to issue a sendf() in response to a received command, it
-is not limited in the number of times sendf() may be invoked, and it
-may invoke sendf() at any time from a task handler.
+The sendf() macro should only be invoked from command or task
+handlers, and it should not be invoked from interrupts or timers. The
+code does not need to issue a sendf() in response to a received
+command, it is not limited in the number of times sendf() may be
+invoked, and it may invoke sendf() at any time from a task handler.
 
 ### Output responses
 
-To simplify debugging, the firmware also has an output() C
-function. For example:
+To simplify debugging, there is also has an output() C function. For
+example:
 
 ```
 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. It is
-a wrapper around sendf() and as with sendf() it should not be called
-from interrupts or timers.
+to generate and format arbitrary messages for human consumption.
 
 Declaring constants
 -------------------
 
-The firmware can also define constants to be exported.  For example,
-the following:
+Constants can also be exported. For example, the following:
 
 ```
 DECL_CONSTANT(SERIAL_BAUD, 250000);
 ```
 
 would export a constant named "SERIAL_BAUD" with a value of 250000
-from the firmware to the host.
+from the micro-controller to the host.
 
 Low-level message encoding
 ==========================
@@ -132,9 +131,9 @@ the transmission system.
 Message Blocks
 --------------
 
-All data sent from host to firmware and vice-versa are contained in
-"message blocks". A message block has a two byte header and a three
-byte trailer.  The format of a message block is:
+All data sent from host to micro-controller and vice-versa are
+contained in "message blocks". A message block has a two byte header
+and a three byte trailer. The format of a message block is:
 
 ```
 <1 byte length><1 byte sequence><n-byte content><2 byte crc><1 byte sync>
@@ -162,10 +161,11 @@ present in the message block content.
 Message Block Contents
 ----------------------
 
-Each message block sent from host to firmware contains a series of
-zero or more message commands in its contents. Each command starts
-with a Variable Length Quantity (VLQ) encoded integer command-id
-followed by zero or more VLQ parameters for the given command.
+Each message block sent from host to micro-controller contains a
+series of zero or more message commands in its contents. Each command
+starts with a [Variable Length Quantity](#variable-length-quantities)
+(VLQ) encoded integer command-id followed by zero or more VLQ
+parameters for the given command.
 
 As an example, the following four commands might be placed in a single
 message block:
@@ -174,31 +174,32 @@ message block:
 set_digital_out pin=86 value=1
 set_digital_out pin=85 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_set_digital_out><86><1><id_set_digital_out><85><0><id_get_config><id_get_clock>
 ```
 
 In order to encode and parse the message contents, both the host and
-firmware must agree on the command ids and the number of parameters
-each command has. So, in the above example, both the host and firmware
-would know that "id_set_digital_out" is always followed by two
-parameters, and "id_get_config" and "id_get_status" have zero
-parameters. The host and firmware share a "data dictionary" that maps
-the command descriptions (eg, "set_digital_out pin=%u value=%c") to
-their integer command-ids. When processing the data, the parser will
-know to expect a specific number of VLQ encoded parameters following a
-given command id.
+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
+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
+pin=%u value=%c") to their integer command-ids. When processing the
+data, the parser will know to expect a specific number of VLQ encoded
+parameters following a given command id.
 
-The message contents for blocks sent from firmware to host follow the
-same format. The identifiers in these messages are "response ids", but
-they serve the same purpose and follow the same encoding rules. In
-practice, message blocks sent from the firmware to the host never
-contain more than one response in the message block contents.
+The message contents for blocks sent from micro-controller to host
+follow the same format. The identifiers in these messages are
+"response ids", but they serve the same purpose and follow the same
+encoding rules. In practice, message blocks sent from the
+micro-controller to the host never contain more than one response in
+the message block contents.
 
 ### Variable Length Quantities
 
@@ -230,60 +231,62 @@ the length as a VLQ encoded integer followed by the contents itself:
 ```
 
 The command descriptions found in the data dictionary allow both the
-host and firmware to know which command parameters use simple VLQ
-encoding and which parameters use string encoding.
+host and micro-controller to know which command parameters use simple
+VLQ encoding and which parameters use string encoding.
 
 Data Dictionary
 ===============
 
 In order for meaningful communications to be established between
-firmware and host, both sides must agree on a "data dictionary". This
-data dictionary contains the integer identifiers for commands and
-responses along with their descriptions.
+micro-controller and host, both sides must agree on a "data
+dictionary". This data dictionary contains the integer identifiers for
+commands and responses along with their descriptions.
 
-At compile time the firmware build uses the contents of DECL_COMMAND()
-and sendf() macros to generate the data dictionary. The build
+The micro-controller build uses the contents of DECL_COMMAND() and
+sendf() macros to generate the data dictionary. The build
 automatically assigns unique identifiers to each command and
-response. This system allows both the host and firmware code to
-seamlessly use descriptive human-readable names while still using
+response. This system allows both the host and micro-controller code
+to seamlessly use descriptive human-readable names while still using
 minimal bandwidth.
 
 The host queries the data dictionary when it first connects to the
-firmware. Once the host downloads the data dictionary from the
-firmware, it uses that data dictionary to encode all commands and to
-parse all responses from the firmware. The host must therefore handle
-a dynamic data dictionary. However, to keep the firmware simple, the
-firmware always uses its static (compiled in) data dictionary.
+micro-controller. Once the host downloads the data dictionary from the
+micro-controller, it uses that data dictionary to encode all commands
+and to parse all responses from the micro-controller. The host must
+therefore handle a dynamic data dictionary. However, to keep the
+micro-controller software simple, the micro-controller always uses its
+static (compiled in) data dictionary.
 
 The data dictionary is queried by sending "identify" commands to the
-firmware. The firmware will respond to each identify command with an
-"identify_response" message. Since these two commands are needed prior
-to obtaining the data dictionary, their integer ids and parameter
-types are hard-coded in both the firmware and the host. The
-"identify_response" response id is 0, the "identify" command id
-is 1. Other than having hard-coded ids the identify command and its
-response are declared and transmitted the same way as other commands
-and responses. No other command or response is hard-coded.
+micro-controller. The micro-controller will respond to each identify
+command with an "identify_response" message. Since these two commands
+are needed prior to obtaining the data dictionary, their integer ids
+and parameter types are hard-coded in both the micro-controller and
+the host. The "identify_response" response id is 0, the "identify"
+command id is 1. Other than having hard-coded ids the identify command
+and its response are declared and transmitted the same way as other
+commands and responses. No other command or response is hard-coded.
 
 The format of the transmitted data dictionary itself is a zlib
-compressed JSON string. The firmware compile process generates the
-string, compresses it, and stores it in the text section of the
-firmware. The data dictionary can be much larger than the maximum
-message block size - the host downloads it by sending multiple
-identify commands requesting progressive chunks of the data
+compressed JSON string. The micro-controller build process generates
+the string, compresses it, and stores it in the text section of the
+micro-controller flash. The data dictionary can be much larger than
+the maximum message block size - the host downloads it by sending
+multiple identify commands requesting progressive chunks of the data
 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 firmware version, constants (as defined by
-DECL_CONSTANT), and static strings.
+dictionary also contains the software version, constants (as defined
+by DECL_CONSTANT), and static strings.
 
 Static Strings
 --------------
 
 To reduce bandwidth the data dictionary also contains a set of static
-strings known to the firmware. This is useful when sending messages
-from firmware to host. For example, if the firmware were to run:
+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");
@@ -296,22 +299,22 @@ to their associated human-readable strings.
 Message flow
 ============
 
-Message commands sent from host to firmware are intended to be
-error-free. The firmware will check the CRC and sequence numbers in
-each message block to ensure the commands are accurate and
-in-order. The firmware always processes message blocks in-order -
-should it receive a block out-of-order it will discard it and any
-other out-of-order blocks until it receives blocks with the correct
-sequencing.
+Message commands sent from host to micro-controller are intended to be
+error-free. The micro-controller will check the CRC and sequence
+numbers in each message block to ensure the commands are accurate and
+in-order. The micro-controller always processes message blocks
+in-order - should it receive a block out-of-order it will discard it
+and any other out-of-order blocks until it receives blocks with the
+correct sequencing.
 
 The low-level host code implements an automatic retransmission system
-for lost and corrupt message blocks sent to the firmware. To
-facilitate this, the firmware transmits an "ack message block" after
-each successfully received message block. The host schedules a timeout
-after sending each block and it will retransmit should the timeout
-expire without receiving a corresponding "ack". In addition, if the
-firmware detects a corrupt or out-of-order block it may transmit a
-"nak message block" to facilitate fast retransmission.
+for lost and corrupt message blocks sent to the micro-controller. To
+facilitate this, the micro-controller transmits an "ack message block"
+after each successfully received message block. The host schedules a
+timeout after sending each block and it will retransmit should the
+timeout expire without receiving a corresponding "ack". In addition,
+if the micro-controller detects a corrupt or out-of-order block it may
+transmit a "nak message block" to facilitate fast retransmission.
 
 An "ack" is a message block with empty content (ie, a 5 byte message
 block) and a sequence number greater than the last received host
@@ -326,15 +329,15 @@ in the event of transmission latency. The timeout, retransmit,
 windowing, and ack mechanism are inspired by similar mechanisms in
 [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol).
 
-In the other direction, message blocks sent from firmware to host are
-designed to be error-free, but they do not have assured
+In the other direction, message blocks sent from micro-controller to
+host are designed to be error-free, but they do not have assured
 transmission. (Responses should not be corrupt, but they may go
-missing.) This is done to keep the implementation in the firmware
-simple. There is no automatic retransmission system for responses -
-the high-level code is expected to be capable of handling an
-occasional missing response (usually by re-requesting the content or
-setting up a recurring schedule of response transmission). The
-sequence number field in message blocks sent to the host is always one
-greater than the last received sequence number of message blocks
-received from the host. It is not used to track sequences of response
-message blocks.
+missing.) This is done to keep the implementation in the
+micro-controller simple. There is no automatic retransmission system
+for responses - the high-level code is expected to be capable of
+handling an occasional missing response (usually by re-requesting the
+content or setting up a recurring schedule of response
+transmission). The sequence number field in message blocks sent to the
+host is always one greater than the last received sequence number of
+message blocks received from the host. It is not used to track
+sequences of response message blocks.

docs/README.md

@@ -0,0 +1,2 @@
+Welcome to the Klipper documentation. The
+[overview document](Overview.md) is a good starting point.

docs/Releases.md

@@ -1,6 +1,111 @@
 History of Klipper releases. Please see
 [installation](Installation.md) for information on installing Klipper.
 
+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
+=============
+
+Available on 20180331. Major changes in this release:
+* Enhanced heater and thermistor hardware failure checks
+* Support for Z probes
+* Initial support for automatic parameter calibration on deltas (via a
+  new delta_calibrate command)
+* Initial support for bed tilt compensation (via bed_tilt_calibrate
+  command)
+* Initial support for "safe homing" and homing overrides
+* Initial support for displaying status on RepRapDiscount style 2004
+  and 12864 displays
+* New multi-extruder improvements:
+  * Support for shared heaters
+  * Initial support for dual carriages
+* Support for configuring multiple steppers per axis (eg, dual Z)
+* Support for custom digital and pwm output pins (with a new SET_PIN command)
+* Initial support for a "virtual sdcard" that allows printing directly
+  from Klipper (helps on machines too slow to run OctoPrint well)
+* Support for setting different arm lengths on each tower of a delta
+* Support for G-Code M220/M221 commands (speed factor override /
+  extrude factor override)
+* Several documentation updates:
+  * Many new example config files for common off-the-shelf printers
+  * New multiple MCU config example
+  * New bltouch sensor config example
+  * New FAQ, config check, and G-Code documents
+* Initial support for continuous integration testing on all github commits
+* Several bug fixes and code cleanups
+
+Klipper 0.5.0
+=============
+
+Available on 20171025. Major changes in this release:
+
+* Support for printers with multiple extruders.
+* Initial support for running on the Beaglebone PRU. Initial support
+  for the Replicape board.
+* Initial support for running the micro-controller code in a real-time
+  Linux process.
+* Support for multiple micro-controllers. (For example, one could
+  control an extruder with one micro-controller and the rest of the
+  printer with another.) Software clock synchronization is implemented
+  to coordinate actions between micro-controllers.
+* Stepper performance improvements (20Mhz AVRs up to 189K steps per
+  second).
+* Support for controlling servos and support for defining nozzle
+  cooling fans.
+* Several bug fixes and code cleanups
+
+Klipper 0.4.0
+=============
+
+Available on 20170503. Major changes in this release:
+
+* Improved installation on Raspberry Pi machines. Most of the install
+  is now scripted.
+* Support for corexy kinematics
+* Documentation updates: New Kinematics document, new Pressure Advance
+  tuning guide, new example config files, and more
+* Stepper performance improvements (20Mhz AVRs over 175K steps per
+  second, Arduino Due over 460K)
+* Support for automatic micro-controller resets. Support for resets
+  via toggling USB power on Raspberry Pi.
+* The pressure advance algorithm now works with look-ahead to reduce
+  pressure changes during cornering.
+* Support for limiting the top speed of short zigzag moves
+* Support for AD595 sensors
+* Several bug fixes and code cleanups
+
 Klipper 0.3.0
 =============
 

docs/Slicers.md

@@ -0,0 +1,71 @@
+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](../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 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/Todo.md

@@ -1,129 +0,0 @@
-Klipper is currently in an experimental state. There are several
-features still to be implemented.  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 startup:
-
- * Provide startup scripts so that Klippy can startup at system
-   bootup.
-
- * Allow loading of a new config without having to restart the mcu.
-
-* 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:
-
- * Automatically roll Klippy log files. The default log file should
-   have the current date in the log file name.
-
- * Report the Klippy git version in log file. Log the contents of the
-   config file at startup.
-
- * 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 firmware after
-  homing. This would provide a sanity check in the firmware that would
-  reduce the risk of the host commanding a stepper motor past its
-  valid step range. To maintain high efficiency in the firmware, the
-  firmware 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.)
-
-* Support validating that heaters are heating at expected rates. This
-  can be useful to detect a sensor failure (eg, thermistor short) that
-  could otherwise cause the PID to command excessive heating.
-
-* Possibly implement host based checking on the ratio between extrude
-  amount and head movement.
- * Enforce acceleration and speed limits on extruder stepper motor.
-
-Testing features
-================
-
-* Complete the host based simulator. It's possible to compile the
-  firmware 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
-=============
-
-* Document and test running the host software on a Beagle Bone Black.
-
-* Add documentation describing how to perform bed-leveling accurately
-  in Klipper. Improve description of stepper phase based bed leveling.
-
-* Document the kinematic formulas in Klippy. Document how acceleration
-  and jerk limits are enforced.
-
-* Document how one can tune the pressure advance setting.
-
-Hardware features
-=================
-
-* Port firmware to more architectures:
- * Beagle Bone Black PRU
- * Smoothieboard / NXP LPC1769 (ARM cortex-M3)
- * Unix based scheduling; Unix based real-time scheduling
-
-* Support for additional kinematics: scara, corexy, etc.
-
-* Support shared motor enable GPIO lines.
-
-* Support for multiple extruders.
-
-* Support for bed-level probes.
-
-* 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.)
-
-* The raspberry pi has the ability to cut power to its USB ports. This
-  feature is useful for resetting micro-controllers that are powered
-  over USB. It would be useful to have a high-level command interface
-  in Klippy to request a micro-controller reset via this mechanism.
-
-* Possibly support printers using multiple micro-controllers.
-
-Misc features
-=============
-
-* Possibly use cubic functions instead of quadratic functions in step
-  compression code.
-
-* 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/beaglebone.md

@@ -0,0 +1,103 @@
+This document describes the process of running Klipper on a Beaglebone
+PRU.
+
+Building an OS image
+====================
+
+Start by installing the
+[latest Jessie IoT](https://beagleboard.org/latest-images) image
+(2017-03-19 or later). One may run the image from either a micro-SD
+card or from builtin eMMC. If using the eMMC, install it to eMMC now
+by following the instructions from the above link.
+
+Then ssh into the beaglebone machine (ssh debian@beaglebone --
+password is "temppwd") and install Klipper by running the following
+commands:
+```
+git clone https://github.com/KevinOConnor/klipper
+./klipper/scripts/install-beaglebone.sh
+```
+
+Install Octoprint
+=================
+
+One may then install Octoprint:
+```
+git clone https://github.com/foosel/OctoPrint.git
+cd OctoPrint/
+virtualenv venv
+./venv/bin/python setup.py install
+```
+
+And setup OctoPrint to start at bootup:
+```
+sudo cp ~/OctoPrint/scripts/octoprint.init /etc/init.d/octoprint
+sudo chmod +x /etc/init.d/octoprint
+sudo cp ~/OctoPrint/scripts/octoprint.default /etc/default/octoprint
+sudo update-rc.d octoprint defaults
+```
+
+It is necessary to modify OctoPrint's **/etc/default/octoprint**
+configuration file. One must change the OCTOPRINT_USER user to
+"debian", change NICELEVEL to 0, uncomment the BASEDIR, CONFIGFILE,
+and DAEMON settings and change the references from "/home/pi/" to
+"/home/debian/":
+```
+sudo nano /etc/default/octoprint
+```
+
+Then start the Octoprint service:
+```
+sudo systemctl start octoprint
+```
+
+Make sure the octoprint web server is accessible - it should be at:
+[http://beaglebone:5000/](http://beaglebone:5000/)
+
+Building the micro-controller code
+==================================
+
+To compile the Klipper micro-controller code, start by configuring it
+for the "Beaglebone PRU":
+```
+cd ~/klipper/
+make menuconfig
+```
+
+To build and install the new micro-controller code, run:
+```
+sudo service klipper stop
+make flash
+sudo service klipper start
+```
+
+It is also necessary to compile and install the micro-controller code
+for a Linux host process. Run "make menuconfig" a second time and
+configure it for a "Linux process":
+```
+make menuconfig
+```
+
+Then install this micro-controller code as well:
+```
+sudo service klipper stop
+make flash
+sudo service klipper start
+```
+
+Remaining configuration
+=======================
+
+Complete the installation by configuring Klipper and Octoprint
+following the instructions in
+[the main installation document](Installation.md#configuring-klipper).
+
+Printing on the Beaglebone
+==========================
+
+Unfortunately, the Beaglebone processor can sometimes struggle to run
+OctoPrint well. Print stalls have been known to occur on complex
+prints (the printer may move faster than OctoPrint can send movement
+commands). If this occurs, consider using the "virtual_sdcard" feature
+(see [config/example-extras.cfg](../config/example-extras.cfg) for
+details) to print directly from Klipper.

docs/developer-certificate-of-origin

@@ -0,0 +1,37 @@
+Developer Certificate of Origin
+Version 1.1
+
+Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
+1 Letterman Drive
+Suite D4700
+San Francisco, CA, 94129
+
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
+
+
+Developer's Certificate of Origin 1.1
+
+By making a contribution to this project, I certify that:
+
+(a) The contribution was created in whole or in part by me and I
+    have the right to submit it under the open source license
+    indicated in the file; or
+
+(b) The contribution is based upon previous work that, to the best
+    of my knowledge, is covered under an appropriate open source
+    license and I have the right under that license to submit that
+    work with modifications, whether created in whole or in part
+    by me, under the same open source license (unless I am
+    permitted to submit under a different license), as indicated
+    in the file; or
+
+(c) The contribution was provided directly to me by some other
+    person who certified (a), (b) or (c) and I have not modified
+    it.
+
+(d) I understand and agree that this project and the contribution
+    are public and that a record of the contribution (including all
+    personal information I submit with it, including my sign-off) is
+    maintained indefinitely and may be redistributed consistent with
+    this project or the open source license(s) involved.

docs/img/corner.svg

@@ -0,0 +1,184 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="54.904114mm"
+   height="6.0860338mm"
+   viewBox="0 0 194.54213 21.564687"
+   id="svg3506"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="corner.svg">
+  <defs
+     id="defs3508">
+    <marker
+       inkscape:stockid="DiamondL"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="DiamondL"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4399"
+         d="M 0,-7.0710768 -7.0710894,0 0,7.0710589 7.0710462,0 0,-7.0710768 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="scale(0.8,0.8)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow2Lend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow2Lend"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4341"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:0.625;stroke-linejoin:round;stroke-opacity:1"
+         d="M 8.7185878,4.0337352 -2.2072895,0.01601326 8.7185884,-4.0017078 c -1.7454984,2.3720609 -1.7354408,5.6174519 -6e-7,8.035443 z"
+         transform="matrix(-1.1,0,0,-1.1,-1.1,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="marker4596"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4598"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4329"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend-1"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4329-1"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="2.49"
+     inkscape:cx="95.030833"
+     inkscape:cy="-0.17370789"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="true"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:window-width="1068"
+     inkscape:window-height="478"
+     inkscape:window-x="378"
+     inkscape:window-y="113"
+     inkscape:window-maximized="0">
+    <inkscape:grid
+       type="xygrid"
+       id="grid6021"
+       spacingx="9.9999997"
+       spacingy="10.000001"
+       originx="0.89299989"
+       originy="-30.954583" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata3511">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-253.40821,-436.43703)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend)"
+       d="m 345.38554,440.31401 96.88541,12.96764"
+       id="path3514"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend-1)"
+       d="m 253.63788,454.62572 89.78715,-13.91164"
+       id="path3514-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="189.09824"
+       y="482.48389"
+       id="text12656-9"
+       sodipodi:linespacing="125%"
+       transform="matrix(0.98759291,-0.15703579,0.15703579,0.98759291,0,0)"
+       inkscape:transform-center-x="1.3563414"
+       inkscape:transform-center-y="-5.7099754"><tspan
+         sodipodi:role="line"
+         id="tspan5552"
+         x="189.09824"
+         y="482.48389">move 1</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="427.95532"
+       y="379.5321"
+       id="text12656-9-8"
+       sodipodi:linespacing="125%"
+       transform="matrix(0.98949457,0.14457001,-0.14457001,0.98949457,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan5554"
+         x="427.95532"
+         y="379.5321">move 2</tspan></text>
+  </g>
+</svg>

docs/img/lookahead-slow.svg

@@ -0,0 +1,208 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="97.22496mm"
+   height="32.550285mm"
+   viewBox="0 0 344.49789 115.33566"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="lookahead-slow.svg"
+   inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/lookahead-slow.svg.png"
+   inkscape:export-xdpi="90"
+   inkscape:export-ydpi="90">
+  <defs
+     id="defs4">
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend-1"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         inkscape:connector-curvature="0"
+         id="path4329-1"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)" />
+    </marker>
+    <marker
+       inkscape:stockid="Arrow1Mend"
+       orient="auto"
+       refY="0"
+       refX="0"
+       id="Arrow1Mend"
+       style="overflow:visible"
+       inkscape:isstock="true">
+      <path
+         id="path4329"
+         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
+         style="fill:#000000;fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1pt;stroke-opacity:1"
+         transform="matrix(-0.4,0,0,-0.4,-4,0)"
+         inkscape:connector-curvature="0" />
+    </marker>
+  </defs>
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.15"
+     inkscape:cx="3.4198125"
+     inkscape:cy="101.26451"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1091"
+     inkscape:window-height="588"
+     inkscape:window-x="149"
+     inkscape:window-y="422"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-135.22429,-249.96955)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="434.04257"
+       y="365.1282"
+       id="text3349"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351"
+         x="434.04257"
+         y="365.1282">time</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-313.86618"
+       y="140.27856"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan3355"
+         x="-313.86618"
+         y="140.27856">velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.62366331px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 179.63013,351.45141 16.05677,-60.94328 43.25999,0 16.53759,47.11348"
+       id="path3361"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.7558428px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 254.72406,337.27551 22.65101,-77.77178 43.89917,0 24.69858,91.73948"
+       id="path3361-7"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="195.45749"
+       y="286.52051"
+       id="text12656-9"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan7078"
+         x="195.45749"
+         y="286.52051">move A</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="280.5639"
+       y="254.60564"
+       id="text12656-9-3"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan7080"
+         x="280.5639"
+         y="254.60564">move B</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend)"
+       d="m 74.333855,283.02668 -147.83244,52.19984"
+       id="path3514"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:3;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#Arrow1Mend-1)"
+       d="m -79.633985,251.6122 154.13499,31.81455"
+       id="path3514-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="36.7374"
+       y="252.31848"
+       id="text12656-9-1"
+       sodipodi:linespacing="125%"
+       transform="matrix(0.96753827,0.25272454,-0.25272454,0.96753827,0,0)"
+       inkscape:transform-center-x="-0.91382951"
+       inkscape:transform-center-y="-4.9145266"><tspan
+         sodipodi:role="line"
+         id="tspan7074"
+         x="36.7374"
+         y="252.31848">move A</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-126.26086"
+       y="304.35226"
+       id="text12656-9-8"
+       sodipodi:linespacing="125%"
+       transform="matrix(0.93839918,-0.34555314,0.34555314,0.93839918,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan7076"
+         x="-126.26086"
+         y="304.35226">move B</tspan></text>
+  </g>
+</svg>

docs/img/lookahead.svg

@@ -0,0 +1,136 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="97.22496mm"
+   height="32.550285mm"
+   viewBox="0 0 344.49789 115.33566"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="lookahead.svg">
+  <defs
+     id="defs4" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.94"
+     inkscape:cx="116.54041"
+     inkscape:cy="45.708959"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1091"
+     inkscape:window-height="588"
+     inkscape:window-x="149"
+     inkscape:window-y="422"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-135.22429,-249.96955)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="434.04257"
+       y="365.1282"
+       id="text3349"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351"
+         x="434.04257"
+         y="365.1282">time</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-313.86618"
+       y="140.27856"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan3355"
+         x="-313.86618"
+         y="140.27856">velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.62366331px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 179.63013,351.45141 16.05677,-60.94328 61.3451,0 4.83546,8.81561"
+       id="path3361"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.7558428px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 261.70791,300.17937 13.5395,-40.67564 59.85662,0 24.69858,91.73948"
+       id="path3361-7"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="200.77664"
+       y="286.52051"
+       id="text12656-9"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5532"
+         x="200.77664"
+         y="286.52051">move 1</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="280.5639"
+       y="255.66946"
+       id="text12656-9-3"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan5534"
+         x="280.5639"
+         y="255.66946">move 2</tspan></text>
+  </g>
+</svg>

docs/img/ooze.svg

@@ -0,0 +1,207 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="98.140816mm"
+   height="63.537022mm"
+   viewBox="0 0 347.74305 225.13119"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="ooze.svg"
+   inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/ooze.svg.png"
+   inkscape:export-xdpi="90"
+   inkscape:export-ydpi="90">
+  <defs
+     id="defs4" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.94"
+     inkscape:cx="199.68782"
+     inkscape:cy="58.510649"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1091"
+     inkscape:window-height="588"
+     inkscape:window-x="266"
+     inkscape:window-y="106"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436"
+       originx="-1.5695746e-05"
+       originy="109.79552" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-135.22431,-249.96955)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-346.84067"
+       y="139.75046"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12733"
+         x="-346.84067"
+         y="139.75046">head velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 179.63013,351.45141 16.05677,-60.94328 120.91957,-1.06383 16.53759,62.00711"
+       id="path3361"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.78742969px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 332.99641,351.24986 16.72764,-63.00287 133.24331,0"
+       id="path3361-7"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="200.11789"
+       y="284.45413"
+       id="text12656"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12658"
+         x="200.11789"
+         y="284.45413">extrude move</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="356.50089"
+       y="283.39032"
+       id="text12660"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12662"
+         x="356.50089"
+         y="283.39032">non-extrude move</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 152.72419,471.73218 1.06383,102.12766 327.12768,-0.53192 -7.97872,5.85107"
+       id="path3347-0"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="436.76678"
+       y="586.62585"
+       id="text3349-3"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351-4"
+         x="436.76678"
+         y="586.62585">time</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-551.11292"
+       y="125.37186"
+       id="text3353-0"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan4197"
+         x="-551.11292"
+         y="125.37186">actual</tspan><tspan
+         sodipodi:role="line"
+         id="tspan4199"
+         x="-551.11292"
+         y="140.99686">filament</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 152.72419,471.73218 -5.31915,8.51063"
+       id="path3359-9"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 182.35432,572.94905 c 17.46262,-43.80215 52.67413,-56.54375 92.65253,-60.94329 l 48.57915,-1.06383 c 24.916,55.4715 110.00504,59.23318 151.64398,62.00712"
+       id="path3361-1"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150.87843,360.66993 1.06383,102.12766 327.12768,-0.53192 -7.97872,5.85107"
+       id="path3347-8"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-444.27307"
+       y="124.17301"
+       id="text3353-6"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan4193"
+         x="-444.27307"
+         y="124.17301">desired</tspan><tspan
+         sodipodi:role="line"
+         id="tspan4195"
+         x="-444.27307"
+         y="139.79802">filament</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150.87843,360.66993 -5.31915,8.51063"
+       id="path3359-8"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 180.50856,461.8868 16.05678,-60.94329 120.91958,-1.06383 16.53759,62.00712"
+       id="path3361-4"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+  </g>
+</svg>

docs/img/pressure-advance.svg

@@ -0,0 +1,207 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="102.61139mm"
+   height="99.266594mm"
+   viewBox="0 0 363.58366 351.73204"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="pressure-advance.svg"
+   inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/pressure-advance.svg.png"
+   inkscape:export-xdpi="90"
+   inkscape:export-ydpi="90">
+  <defs
+     id="defs4" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.97968464"
+     inkscape:cx="147.06528"
+     inkscape:cy="169.55487"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1091"
+     inkscape:window-height="588"
+     inkscape:window-x="419"
+     inkscape:window-y="273"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436"
+       originx="17.089787"
+       originy="126.61899" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-118.13451,-140.19216)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150.47693,249.82417 0.58688,123.9666 m 0,-21.42857 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-334.86746"
+       y="122.91875"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12816"
+         x="-334.86746"
+         y="122.91875">extruder</tspan><tspan
+         sodipodi:role="line"
+         id="tspan12818"
+         x="-334.86746"
+         y="138.54375">velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 316.60647,311.78473 16.53759,62.00711 m -154.57776,-52.12767 16.05677,-60.94328 1.06383,29.78724 m 0,0 120.91957,-1.06383 0,22.34043"
+       id="path3361"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 148.75077,140.45716 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
+       id="path3347-6"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-237.05733"
+       y="140.25932"
+       id="text3353-2"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12733-6"
+         x="-237.05733"
+         y="140.25932">head velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 148.75077,140.45716 -5.31915,8.51063"
+       id="path3359-7"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 178.3809,241.67403 16.05679,-60.94329 120.91958,-1.06383 16.53759,62.00712"
+       id="path3361-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:0.78742969px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 331.74721,241.47248 16.72764,-63.00288 133.24332,0"
+       id="path3361-7-6"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="198.86868"
+       y="174.67674"
+       id="text12656-9"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12658-8"
+         x="198.86868"
+         y="174.67674">extrude move</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="355.25165"
+       y="173.61293"
+       id="text12660-7"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12662-2"
+         x="355.25165"
+         y="173.61293">non-extrude move</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 151.94226,384.0742 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
+       id="path3347-2"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-467.65732"
+       y="122.73453"
+       id="text3353-1"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12868"
+         x="-467.65732"
+         y="122.73453">extruder</tspan><tspan
+         sodipodi:role="line"
+         id="tspan12870"
+         x="-467.65732"
+         y="138.35953">pressure</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 151.94226,384.0742 -5.31915,8.51063"
+       id="path3359-5"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 181.57239,485.29107 16.05679,-60.94329 120.91958,-1.06383 16.53759,62.00712"
+       id="path3361-9"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="438.03586"
+       y="499.53384"
+       id="text3349"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351"
+         x="438.03586"
+         y="499.53384">time</tspan></text>
+  </g>
+</svg>

docs/img/pressure-cornering.svg

@@ -0,0 +1,180 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="102.04809mm"
+   height="61.494076mm"
+   viewBox="0 0 361.58771 217.8924"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="pressure-cornering.svg"
+   inkscape:export-filename="/home/kevin/src/reprap/firmware/klipper/docs/img/pressure-cornering.svg.png"
+   inkscape:export-xdpi="90"
+   inkscape:export-ydpi="90">
+  <defs
+     id="defs4" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="0.98"
+     inkscape:cx="110.74341"
+     inkscape:cy="35.715236"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="1091"
+     inkscape:window-height="588"
+     inkscape:window-x="656"
+     inkscape:window-y="0"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436"
+       originx="17.089805"
+       originy="-7.2206491" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title />
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-118.13449,-140.19216)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-334.86746"
+       y="122.91875"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12816"
+         x="-334.86746"
+         y="122.91875">extruder</tspan><tspan
+         sodipodi:role="line"
+         id="tspan12818"
+         x="-334.86746"
+         y="138.54375">velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 178.5663,321.66417 16.05677,-60.94328 1.06383,29.78724 m 0,0 117.21969,-0.77616 5.99519,7.3871 5.9952,-6.89861 131.50541,-0.77616"
+       id="path3361"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccccccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 148.75077,140.45716 1.06383,102.12766 327.12769,-0.53192 -7.97872,5.85107"
+       id="path3347-6"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.50000095px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-237.05733"
+       y="140.25932"
+       id="text3353-2"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan12733-6"
+         x="-237.05733"
+         y="140.25932">head velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 148.75077,140.45716 -5.31915,8.51063"
+       id="path3359-7"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2.00000024;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 178.3809,241.67403 16.05679,-60.94329 120.91958,-1.06383 4.29269,10.98671"
+       id="path3361-5"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
+       d="m 319.50231,193.5133 4.48274,-15.0437 133.24332,0"
+       id="path3361-7-6"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="198.86868"
+       y="174.67674"
+       id="text12656-9"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12891"
+         x="198.86868"
+         y="174.67674">first extrude</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:11.25px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="355.25165"
+       y="173.61293"
+       id="text12660-7"
+       sodipodi:linespacing="125%"><tspan
+         sodipodi:role="line"
+         id="tspan12893"
+         x="355.25165"
+         y="173.61293">second extrude</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:2;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:4, 2, 1, 2;stroke-dashoffset:0;stroke-opacity:1"
+       d="m 314.05288,288.86296 0,17.34694 5.10204,17.34694 -1.02041,-48.97959 7.14286,-17.34694 0,31.63265"
+       id="path12895"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="435.80841"
+       y="366.8262"
+       id="text3349"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351"
+         x="435.80841"
+         y="366.8262">time</tspan></text>
+  </g>
+</svg>

docs/img/smoothed.svg

@@ -0,0 +1,132 @@
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!-- Created with Inkscape (http://www.inkscape.org/) -->
+
+<svg
+   xmlns:dc="http://purl.org/dc/elements/1.1/"
+   xmlns:cc="http://creativecommons.org/ns#"
+   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
+   xmlns:svg="http://www.w3.org/2000/svg"
+   xmlns="http://www.w3.org/2000/svg"
+   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
+   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
+   width="97.22496mm"
+   height="32.550285mm"
+   viewBox="0 0 344.49789 115.33566"
+   id="svg2"
+   version="1.1"
+   inkscape:version="0.91 r13725"
+   sodipodi:docname="smoothed.svg">
+  <defs
+     id="defs4" />
+  <sodipodi:namedview
+     id="base"
+     pagecolor="#ffffff"
+     bordercolor="#666666"
+     borderopacity="1.0"
+     inkscape:pageopacity="0.0"
+     inkscape:pageshadow="2"
+     inkscape:zoom="1.75"
+     inkscape:cx="167.32577"
+     inkscape:cy="45.708959"
+     inkscape:document-units="px"
+     inkscape:current-layer="layer1"
+     showgrid="false"
+     inkscape:window-width="840"
+     inkscape:window-height="628"
+     inkscape:window-x="162"
+     inkscape:window-y="50"
+     inkscape:window-maximized="0"
+     fit-margin-top="0"
+     fit-margin-left="0"
+     fit-margin-right="0"
+     fit-margin-bottom="0"
+     showborder="false"
+     inkscape:snap-global="false"
+     showguides="false">
+    <inkscape:grid
+       type="xygrid"
+       id="grid3436" />
+  </sodipodi:namedview>
+  <metadata
+     id="metadata7">
+    <rdf:RDF>
+      <cc:Work
+         rdf:about="">
+        <dc:format>image/svg+xml</dc:format>
+        <dc:type
+           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
+        <dc:title></dc:title>
+      </cc:Work>
+    </rdf:RDF>
+  </metadata>
+  <g
+     inkscape:label="Layer 1"
+     inkscape:groupmode="layer"
+     id="layer1"
+     transform="translate(-135.22429,-249.96955)">
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 1.06383,102.12765 327.12765,-0.53192 -7.97871,5.85107"
+       id="path3347"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:100%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="434.04257"
+       y="365.1282"
+       id="text3349"
+       sodipodi:linespacing="100%"><tspan
+         sodipodi:role="line"
+         id="tspan3351"
+         x="434.04257"
+         y="365.1282">time</tspan></text>
+    <text
+       xml:space="preserve"
+       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:12.5px;line-height:125%;font-family:'DejaVu Sans';-inkscape-font-specification:'DejaVu Sans, Normal';text-align:start;letter-spacing:0px;word-spacing:0px;writing-mode:lr-tb;text-anchor:start;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       x="-313.86618"
+       y="140.27856"
+       id="text3353"
+       sodipodi:linespacing="125%"
+       transform="matrix(-0.01601372,-0.99987177,0.99987177,-0.01601372,0,0)"><tspan
+         sodipodi:role="line"
+         id="tspan3355"
+         x="-313.86618"
+         y="140.27856">velocity</tspan></text>
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 150,250.23455 -5.31915,8.51063"
+       id="path3359"
+       inkscape:connector-curvature="0" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 165.50998,351.59092 15.42857,-35.42857 35.71428,0 11.71429,36.57143"
+       id="path3362"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.07142997px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 227.83578,352.85633 15.76217,-47.37239 22.00135,0 5.58242,17.6933"
+       id="path3362-3"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.21482575px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 271.35434,323.73296 11.15454,-30.54076 19.27119,-0.11152 8.73883,29.51288"
+       id="path3362-6"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#000000;stroke-width:1.01949775px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
+       d="m 311.26144,322.49329 11.63197,-21.06975 15.33656,0 13.51652,50.22357"
+       id="path3362-7"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="cccc" />
+    <path
+       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:2.00000012, 1.00000006, 0.50000003, 1.00000006;stroke-dashoffset:0;stroke-opacity:1"
+       d="m 165.50999,351.59092 33.14285,-34.28571 29.14286,34.28571"
+       id="path3426"
+       inkscape:connector-curvature="0"
+       sodipodi:nodetypes="ccc" />
+  </g>
+</svg>