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) $(CFLAGS_klipper.o) -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

@@ -46,7 +46,7 @@ nozzle_diameter: 0.500
 filament_diameter: 3.500
 heater_pin: ar4
 sensor_type: EPCOS 100K B57560G104F
-sensor_pin: analog1
+sensor_pin: analog7
 control: pid
 pid_Kp: 22.2
 pid_Ki: 1.08

config/example-corexy.cfg

@@ -8,38 +8,35 @@
 # 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 controlling the X+Y movement.
 [stepper_x]
 step_pin: ar54
 dir_pin: ar55
 enable_pin: !ar38
 step_distance: .01
-endstop_pin: ^ar2
-homing_speed: 50.0
-position_min: 0
+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 controlling the X-Y movement.
 [stepper_y]
 step_pin: ar60
 dir_pin: ar61
 enable_pin: !ar56
 step_distance: .01
-endstop_pin: ^ar15
-homing_speed: 50.0
-position_min: 0
+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: .01
-endstop_pin: ^ar19
-position_min: 0.1
+step_distance: .0025
+endstop_pin: ^ar18
 position_endstop: 0.5
 position_max: 200
 

config/example-delta.cfg

@@ -16,28 +16,40 @@ dir_pin: ar55
 enable_pin: !ar38
 step_distance: .01
 endstop_pin: ^ar2
-homing_speed: 50.0
+homing_speed: 50
 position_endstop: 297.05
+#   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
@@ -64,7 +76,7 @@ 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
 
@@ -77,27 +89,43 @@ kinematics: delta
 #   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 limits the velocity of the toolhead relative to the
-#   print - at the extreme end of the print envelope the delta axis
-#   steppers themselves may briefly exceed this speed by up to 3
-#   times. This parameter must be specified.
+#   print. This parameter must be specified.
 max_accel: 3000
 #   Maximum acceleration (in mm/s^2) of the toolhead relative to the
-#   print. This limits the acceleration of the toolhead relative to
-#   the print - at the extreme end of the print envelope the delta
-#   axis steppers may briefly exceed this acceleration by up to 3
-#   times. This parameter must be specified.
-max_z_velocity: 200
+#   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). The default is to use
 #   max_velocity for max_z_velocity.
-delta_arm_length: 333.0
-#   Length (in mm) of the diagonal rods that connect the linear axes
-#   to the print head. This parameter must be provided.
+#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

@@ -2,7 +2,8 @@
 # copy and edit this file to configure a new cartesian style
 # printer. For delta style printers, see the "example-delta.cfg"
 # file. For corexy/h-bot style printers, see the "example-corexy.cfg"
-# file.
+# 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.
@@ -18,53 +19,24 @@
 
 
 # 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_pin: ar54
 #   Step GPIO pin (triggered high). This parameter must be provided.
-dir_pin: !ar28
+dir_pin: ar55
 #   Direction GPIO pin (high indicates positive direction). This
 #   parameter must be provided.
-enable_pin: !ar25
+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. This
 #   parameter must be provided.
-endstop_pin: ^ar0
+endstop_pin: ^ar3
 #   Endstop switch detection pin. 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. The default is 5mm.
-#homing_positive_dir: False
-#   If true, homes in a positive direction (away from zero). The
-#   default is False.
-#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
+#position_min: 0
 #   Minimum valid distance (in mm) the user may command the stepper to
 #   move to.  The default is 0mm.
 position_endstop: 0
@@ -74,30 +46,43 @@ position_max: 200
 #   Maximum valid distance (in mm) the user may command the stepper 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
 
@@ -105,38 +90,38 @@ 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
 nozzle_diameter: 0.500
 #   Diameter of the nozzle orifice (in mm). This parameter must be
 #   provided.
 filament_diameter: 3.500
-#   Diameter of the raw filament (in mm) as it enters the
+#   The nominal diameter of the raw filament (in mm) as it enters the
 #   extruder. This parameter must be provided.
 #max_extrude_cross_section:
-#   Maximum area of the cross section of an extrusion line (in
-#   mm^2). 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 *
+#   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 an extrude only move
-#   may be. If an extrude only move requests a distance greater than
-#   this value it will cause an error to be returned. The default is
-#   50mm.
+#   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:
-#   Maximum velocity (in mm/s) of the extruder motor for extrude only
-#   moves. If this is not specified then it is calculated to match the
-#   limit an XY printing move with a max_extrude_cross_section
-#   extrusion would have.
 #max_extrude_only_accel:
-#   Maximum acceleration (in mm/s^2) of the extruder motor for extrude
-#   only moves. If this is not specified then it is calculated to
-#   match the limit an XY printing move with a
-#   max_extrude_cross_section extrusion would have.
+#   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
@@ -151,8 +136,8 @@ filament_diameter: 3.500
 #   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: ar4
+# 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
@@ -164,8 +149,13 @@ heater_pin: ar4
 #   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", or "AD595". This parameter must be provided.
-sensor_pin: analog1
+#   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
@@ -174,7 +164,11 @@ sensor_pin: analog1
 #   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. The default is 5 volts.
+#   sensor is an AD595 or "PT100 INA826". The default is 5 volts.
+#smooth_time: 2.0
+#   A time value (in seconds) over which temperature measurements will
+#   be smoothed to reduce the impact of measurement noise. The default
+#   is 2 seconds.
 control: pid
 #   Control algorithm (either pid or watermark). This parameter must
 #   be provided.
@@ -187,29 +181,34 @@ pid_Ki: 1.08
 pid_Kd: 114
 #   Kd is the "derivative" constant for the pid. This parameter must
 #   be provided for PID heaters.
-#pid_deriv_time: 2.0
-#   A time value (in seconds) over which the derivative in the pid
-#   will be smoothed to reduce the impact of measurement noise. The
-#   default is 2 seconds.
 #pid_integral_max:
 #   The maximum "windup" the integral term may accumulate. The default
 #   is to use the same value as max_power.
+#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. The default is 170 Celsius.
 min_temp: 0
-#   Minimum temperature in Celsius (mcu will shutdown if not
-#   met). This parameter must be provided.
 max_temp: 210
-#   Maximum temperature (mcu will shutdown if temperature is above
-#   this value). This parameter must be provided.
+#   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
+heater_pin: ar8
 sensor_type: EPCOS 100K B57560G104F
-sensor_pin: analog0
+sensor_pin: analog14
 control: watermark
 #max_delta: 2.0
 #   On 'watermark' controlled heaters this is the number of degrees in
@@ -219,48 +218,60 @@ control: watermark
 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
+pin: ar9
 #   PWM output pin controlling the fan. This parameter must be
 #   provided.
-#hard_pwm: 0
-#   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 to force hardware PWM with the given cycle time in clock
-#   ticks. The default is 0 which enables software PWM with a cycle
-#   time of 10ms.
+#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). The default is 0.100 seconds.
 
-# Micro-controller information
+# Micro-controller information.
 [mcu]
 serial: /dev/ttyACM0
-#   The serial port to connect to the MCU. The default is /dev/ttyS0
+#   The serial port to connect to the MCU. If unsure (or if it
+#   changes) see the "Where's my serial port?" section of the FAQ. The
+#   default is /dev/ttyS0
 #baud: 250000
 #   The baud rate to use. The default is 250000.
 pin_map: arduino
 #   This option may be used to enable Arduino pin name aliases. The
 #   default is to not enable the aliases.
-#restart_method: arduino
+#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; set baud to 1200) 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'.
-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.
+#   '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.
@@ -286,11 +297,16 @@ max_z_accel: 30
 #   mm/s^2) of movement along the z axis. It limits the acceleration
 #   of the z stepper motor on cartesian printers. The default is to
 #   use max_accel for max_z_accel.
-#motor_off_time: 600
-#   Time (in seconds) of idle time before the printer will try to
-#   disable active motors. The default is 600 seconds.
-#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. The
-#   default is 0.02mm.
+#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

@@ -9,9 +9,10 @@ dir_pin: PL1
 enable_pin: !PA7
 step_distance: .0125
 endstop_pin: ^PB6
-homing_speed: 50
+#endstop_pin: ^PA2
 position_endstop: 0
 position_max: 200
+homing_speed: 50
 
 [stepper_y]
 step_pin: PC1
@@ -19,18 +20,19 @@ dir_pin: !PL0
 enable_pin: !PA6
 step_distance: .0125
 endstop_pin: ^PB5
-homing_speed: 50
+#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: 0.00025
+step_distance: .0025
 endstop_pin: ^PB4
-homing_speed: 5
-position_endstop: 0
+#endstop_pin: ^PC7
+position_endstop: 0.5
 position_max: 200
 
 [extruder]
@@ -50,6 +52,14 @@ 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
@@ -61,26 +71,11 @@ max_temp: 130
 [fan]
 pin: PH5
 
+#[heater_fan nozzle_cooling_fan]
+#pin: PH3
+
 [mcu]
 serial: /dev/ttyACM0
-custom:
-  # 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
@@ -88,3 +83,44 @@ 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

@@ -10,9 +10,10 @@ dir_pin: ar55
 enable_pin: !ar38
 step_distance: .0125
 endstop_pin: ^ar3
-homing_speed: 50
+#endstop_pin: ^ar2
 position_endstop: 0
 position_max: 200
+homing_speed: 50
 
 [stepper_y]
 step_pin: ar60
@@ -20,18 +21,19 @@ dir_pin: !ar61
 enable_pin: !ar56
 step_distance: .0125
 endstop_pin: ^ar14
-homing_speed: 50
+#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: 0.00025
+step_distance: .0025
 endstop_pin: ^ar18
-homing_speed: 5
-position_endstop: 0
+#endstop_pin: ^ar19
+position_endstop: 0.5
 position_max: 200
 
 [extruder]
@@ -51,6 +53,14 @@ 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
@@ -72,3 +82,24 @@ 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/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

@@ -9,12 +9,13 @@ 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
+homing_speed: 50
+
+[endstop_phase stepper_x]
+phases: 32
+endstop_accuracy: .200
 
 [stepper_y]
 step_pin: PC1
@@ -22,12 +23,13 @@ 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
+homing_speed: 50
+
+[endstop_phase stepper_y]
+phases: 32
+endstop_accuracy: .200
 
 [stepper_z]
 step_pin: PC2
@@ -35,13 +37,14 @@ 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
+homing_retract_dist: 2.0
+
+[endstop_phase stepper_z]
+phases: 32
+endstop_accuracy: .070
 
 [extruder]
 step_pin: PC3
@@ -72,28 +75,14 @@ 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
-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
@@ -101,3 +90,25 @@ 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 software.
+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
@@ -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
@@ -100,9 +108,9 @@ DECL_COMMAND macro in the micro-controller code).
 
 There are four threads in the Klippy host code. The main thread
 handles incoming gcode commands. A second thread (which resides
-entirely in the **klippy/serialqueue.c** C code) handles low-level IO
-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.
@@ -142,70 +150,305 @@ provides further information on the mechanics of moves.
   zero duration.
   * When Move.move() is called, everything about the move is known -
   its start location, its end location, its acceleration, its
-  start/crusing/end velocity, and distance traveled during
+  start/cruising/end velocity, and distance traveled during
   acceleration/cruising/deceleration. All the information is stored in
   the Move() class and is in cartesian space in units of millimeters
-  and seconds. Times are stored relative to the start of the print.
+  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 in cartesian.py, corexy.py, delta.py, and extruder.py. 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. The
-  kinematic classes translate the three parts of each move
-  (acceleration, constant "cruising" velocity, and deceleration) to
-  the associated movement on each stepper. 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.
+  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.
 
-* For efficiency reasons, the stepper pulse times are generated in C
-  code. The code flow is: `kin.move() -> MCU_Stepper.step_const() ->
-  stepcompress_push_const()`, or for delta kinematics:
-  `DeltaKinematics.move() -> MCU_Stepper.step_delta() ->
-  stepcompress_push_delta()`. The MCU_Stepper code just performs unit
-  and axis transformation (seconds to clock ticks and millimeters to
-  step distances), and calls the C code. The C code calculates the
-  stepper step times for each movement and fills an array (struct
-  stepcompress.queue) with the corresponding micro-controller clock
-  counter times (in 64bit integers) 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.
+* 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 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).
+  -> 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 command.c which parses the command and calls
-  `command_queue_step()`. The command_queue_step() code (in 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;`
+  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

@@ -75,10 +75,10 @@ cd /patch/to/klipper
 make menuconfig
 ```
 
-and compile the micro-controller software 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
@@ -115,17 +115,20 @@ 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
 ======================
 
@@ -148,3 +151,264 @@ Then graphs can be produced with:
 ```
 
 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

@@ -15,17 +15,26 @@ Klipper has several compelling features:
 * 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 over 175K steps per second. On
-  more recent ARM micro-controllers, rates over 450K 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.
+  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
@@ -33,29 +42,22 @@ Klipper has several compelling features:
 
 * Simpler code. Klipper uses a very high level language (Python) for
   most code. The kinematics algorithms, the G-code parsing, the
-  heating and thermistor algorithms, etc. are all written in
-  Python. This makes it easier to develop new functionality.
+  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.
-  * 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.
+* 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.
@@ -64,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.
 
-* "Look-ahead" support. The incoming stream of G-Code movement
-  commands are queued and analyzed - the acceleration between
+* Support for cartesian, delta, and corexy 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.
 
-* Support for cartesian, delta, and corexy style printers.
+* Klipper implements a "stepper phase endstop" algorithm that can
+  improve the accuracy of typical endstop switches. When properly
+  tuned it can improve a print's first layer bed adhesion.
+
+* Support for limiting the top speed of short "zigzag" moves to reduce
+  printer vibration and noise. See the [kinematics](Kinematics.md)
+  document for more information.
+
+* Sample configuration files are available for many common printers.
+  Check the [config directory](../config/) for a list.
+
+To get started with Klipper, read the [installation](Installation.md)
+guide.
 
 Step Benchmarks
 ===============
@@ -81,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         | 177K             | 117K              |
-| 16Mhz AVR         | 140K             | 93K               |
-| Arduino Due (ARM) | 462K             | 406K              |
+| 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/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,29 +1,32 @@
 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.
+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 should be possible to run the Klipper host software on any computer
-running a recent Linux distribution, but doing so will require Linux
-admin knowledge to translate these installation instructions to the
-particulars of that machine.
-
-Klipper currently supports Atmel ATmega based micro-controllers and
-Arduino Due (Atmel SAM3x8e ARM micro-controller) printers.
+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.2 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:
+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
@@ -38,15 +41,18 @@ minutes to complete.
 Building and flashing the micro-controller
 ==========================================
 
-To compile the micro-controller code, start by configuring it:
+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
@@ -60,25 +66,11 @@ make flash FLASH_DEVICE=/dev/ttyACM0
 sudo service klipper start
 ```
 
-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. The next step is to copy and
-edit one of these config files - 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.
+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.
 
 Configuring OctoPrint to use Klipper
 ====================================
@@ -92,8 +84,9 @@ Under "Serial Connection" in "Additional serial ports" add
 "/tmp/printer". Then click "Save".
 
 Enter the Settings tab again and under "Serial Connection" change the
-"Serial Port" setting to "/tmp/printer". Unselect the "Not only cancel
-ongoing prints but also disconnect..." checkbox. Click "Save".
+"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".
 
 From the main page, under the "Connection" section (at the top left of
 the page) make sure the "Serial Port" is set to "/tmp/printer" and
@@ -103,13 +96,47 @@ 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". The
 terminal window will likely report there is an error opening the
-config file - issue a "restart" command in the OctoPrint 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.
+config file - that means OctoPrint is successfully communicating with
+Klipper. Proceed to the next section.
+
+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
@@ -119,3 +146,14 @@ 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

@@ -18,12 +18,12 @@ 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 enforce a maximum acceleration of the stepper
-motors to ensure they do not skip or put excessive stress on the
-machine. Klipper limits the acceleration of each stepper by virtue of
-limiting the acceleration of the print head. Enforcing acceleration at
-the print head naturally also enforces acceleration at the steppers
-that control that print head (the inverse is not always true).
+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:
@@ -87,10 +87,14 @@ small junction speed is permitted.
 The junction speeds are determined using "approximated centripetal
 acceleration". Best
 [described by the author](https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/).
+However, in Klipper, junction speeds are configured by specifying the
+desired speed that a 90° corner should have (the "square corner
+velocity"), and the junction speeds for other angles are derived from
+that.
 
-Klipper implements look-ahead between moves contained in the XY plane
-that have similar extruder flow rates. Other moves are relatively rare
-and implementing look-ahead between them is unnecessary.
+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:
 ```
@@ -139,15 +143,32 @@ tracked in millimeters, seconds, and in cartesian coordinate space.
 It's the task of the kinematic classes to convert from this generic
 coordinate system to the hardware specifics of the particular printer.
 
-In general, the code determines each step time by first calculating
-where along the line of movement the head would be if a step is
-taken. It then calculates what time the head should be at that
-position. Determining the time along the line of movement can be done
-using the formulas for constant acceleration and constant velocity:
+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:
 ```
-time = sqrt(2*distance/accel + (start_velocity/accel)^2) - start_velocity/accel
-time = distance/cruise_velocity
+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
@@ -157,67 +178,53 @@ Generating steps for cartesian printers is the simplest case. The
 movement on each axis is directly related to the movement in cartesian
 space.
 
+Key formulas:
+```
+stepper_x_position = cartesian_x_position
+stepper_y_position = cartesian_y_position
+stepper_z_position = cartesian_z_position
+```
+
+CoreXY Robots
+----------------
+
+Generating steps on a CoreXY machine is only a little more complex
+than basic cartesian robots. The key formulas are:
+```
+stepper_a_position = cartesian_x_position + cartesian_y_position
+stepper_b_position = cartesian_x_position - cartesian_y_position
+stepper_z_position = cartesian_z_position
+```
+
 Delta Robots
 ------------
 
-To generate step times on Delta printers it is necessary to correlate
-the movement in cartesian space with the movement on each stepper
-tower.
-
-To simplify the math, for each stepper tower, the code calculates the
-location of a "virtual tower" that is along the line of movement.
-This virtual tower is chosen at the point where the line of movement
-(extended infinitely in both directions) would be closest to the
-actual tower.
-
-![delta-tower](img/delta-tower.svg.png)
-
-It is then possible to calculate where the head will be along the line
-of movement after each step is taken on the virtual tower.
-
-![virtual-tower](img/virtual-tower.svg.png)
-
-The key formula is Pythagoras's theorem:
+Step generation on a delta robot is based on Pythagoras's theorem:
 ```
-distance_to_tower^2 = arm_length^2 - tower_height^2
+stepper_position = (sqrt(arm_length^2
+                         - (cartesian_x_position - tower_x_position)^2
+                         - (cartesian_y_position - tower_y_position)^2)
+                    + cartesian_z_position)
 ```
 
-One complexity is that if the print head passes the virtual tower
-location then the stepper direction must be reversed. In this case
-forward steps will be taken at the start of the move and reverse steps
-will be taken at the end of the move.
-
-### Delta movements beyond simple XY plane ###
-
-Movement calculation is more complicated if a single move contains
-both XY movement and Z movement. These moves are rare, but they must
-still be handled correctly. A virtual tower along the line of movement
-is still calculated, but in this case the tower is not at a 90 degree
-angle relative to the line of movement:
-
-![xy+z-tower](img/xy+z-tower.svg.png)
-
-The code continues to calculate step times using the same general
-scheme as delta moves within an XY plane, but the slope of the tower
-must also be used in the calculations.
-
-Should the move contain only Z movement (ie, no XY movement at all)
-then the same math is used - just in this case the tower is parallel
-to the line of movement.
-
 ### Stepper motor acceleration limits ###
 
 With delta kinematics it is possible for a move that is accelerating
 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
-is near that stepper's tower.
+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.
 
-Klipper does enforce a maximum ceiling on stepper acceleration that is
-three times the maximum acceleration of a move in cartesian
-space. (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
+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.
 
@@ -231,8 +238,10 @@ independently from the step time calculations of the print head
 movement.
 
 Basic extruder movement is simple to calculate. The step time
-generation uses the same constant acceleration and constant velocity
-formulas that cartesian robots use.
+generation uses the same formulas that cartesian robots use:
+```
+stepper_position = requested_e_position
+```
 
 ### Pressure advance ###
 
@@ -259,7 +268,7 @@ through the nozzle orifice (as in
 key idea is that the relationship between filament, pressure, and flow
 rate can be modeled using a linear coefficient:
 ```
-extra_filament = pressure_advance_coefficient * extruder_velocity
+stepper_position = requested_e_position + pressure_advance_coefficient * nominal_extruder_velocity
 ```
 
 See the [pressure advance](Pressure_Advance.md) document for

docs/MCU_Commands.md

@@ -4,10 +4,8 @@ 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 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 low-level 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
@@ -25,22 +23,13 @@ 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.
 
-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 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. Similarly, several commands take time parameters specified in
-clock ticks. One can specify a value for these parameters in seconds
-using the "TICKS()" macro - for example "cycle_ticks=TICKS(0.001)"
-would result in "cycle_ticks=16000" on a micro-controller with a 16Mhz
-clock.
+host.
 
 Common startup commands:
 
@@ -50,7 +39,7 @@ Common startup commands:
   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
+* `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
@@ -60,13 +49,6 @@ Common startup commands:
   and 255 indicating a full on state. This command may be useful for
   enabling CPU and nozzle cooling fans.
 
-* `send_spi_message pin=%u msg=%*s` : This command can be used to
-  transmit messages to a serial-peripheral-interface (SPI) component
-  connected to the micro-controller. It has been used to configure the
-  startup settings of AD5206 digipots. The 'pin' parameter specifies
-  the chip select line to use during the transmission. The 'msg'
-  indicates the binary message to transmit to the given chip.
-
 Low-level micro-controller configuration
 ========================================
 
@@ -129,16 +111,16 @@ Common micro-controller objects
 
 This section lists some commonly used config commands.
 
-* `config_digital_out oid=%c pin=%u default_value=%c
+* `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
-  '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
+  '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 back to their
-  default values. The 'max_duration' parameter is used to implement a
+  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
@@ -148,23 +130,23 @@ This section lists some commonly used config commands.
   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 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_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 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_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
@@ -193,6 +175,22 @@ This section lists some commonly used config commands.
   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
 ===============
 
@@ -205,11 +203,11 @@ only of interest to developers looking to gain insight into Klipper.
   same 'oid' parameter must have been issued during micro-controller
   configuration.
 
-* `schedule_pwm_out oid=%c clock=%u value=%c` : Schedules a change to
+* `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=%c` : Schedules a
+* `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.
 
@@ -228,11 +226,11 @@ only of interest to developers looking to gain insight into Klipper.
   pins attached to thermistors controlling heaters - it can be used to
   check that a heater is within a temperature range.
 
-* `get_status` : This command causes the micro-controller to generate
-  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.
+* `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
 ----------------
@@ -266,13 +264,15 @@ Stepper commands
   number of steps generated with dir=1 minus the total number of steps
   generated with dir=0.
 
-* `end_stop_home oid=%c clock=%u 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 then the movement
+* `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
@@ -292,3 +292,15 @@ It is the responsibility of the host to ensure that there is available
 space in the queue before sending a queue_step command. The host does
 this by calculating when each queue_step command completes and
 scheduling new queue_step commands accordingly.
+
+SPI Commands
+------------
+
+* `spi_transfer oid=%c data=%*s` : This command causes the
+  micro-controller to send 'data' to the spi device specified by 'oid'
+  and it generates a "spi_transfer_response" response message with the
+  data returned during the transmission.
+
+* `spi_send oid=%c data=%*s` : This command is similar to
+  "spi_transfer", but it does not generate a "spi_transfer_response"
+  message.

docs/Overview.md

@@ -4,19 +4,29 @@ 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.
+[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. The
+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.
+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).
+[releases](Releases.md). See [contact](Contact.md) for information on
+bug reporting and general communication with the developers.
 
 Developer Documentation
 =======================
@@ -24,7 +34,8 @@ Developer Documentation
 There are also several documents available for developers interested
 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.
+on the structure and layout of the Klipper code. See the
+[contributing](CONTRIBUTING.md) document to submit improvements to Klipper.
 
 See [protocol](Protocol.md) for information on the low-level messaging
 protocol between host and micro-controller. See also
@@ -32,6 +43,6 @@ protocol between host and micro-controller. See also
 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

@@ -1,5 +1,5 @@
 This document provides information on tuning the "pressure advance"
-configuration variables for a particular nozzle and filament. The
+configuration variable for a particular nozzle and filament. The
 pressure advance feature can be helpful in reducing ooze. For more
 information on how pressure advance is implemented see the
 [kinematics](Kinematics.md) document.
@@ -10,15 +10,27 @@ Tuning pressure advance
 Pressure advance does two useful things - it reduces ooze during
 non-extrude moves and it reduces blobbing during cornering. This guide
 uses the second feature (reducing blobbing during cornering) as a
-mechanism for measuring and tuning the pressure advance configuration.
+mechanism for tuning.
 
-Start by changing the extruder section of the config file so that
-pressure_advance is set to 0.0. (Make sure to issue a RESTART command
-after each update to the config file so that the new configuration
-takes effect.) Then print at least 10 layers of a large hollow square
-at high speed (eg, 100mm/s). See
-[docs/prints/square.stl](prints/square.stl) file for an STL file that
-one may use. While the object is printing, make a note of which
+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
@@ -29,46 +41,103 @@ lack of filament on the side immediately after that corner:
 This blobbing is the result of pressure in the extruder being released
 as a blob when the head slows down to corner.
 
-The next step is to set pressure_advance_lookahead_time to 0.0, slowly
-increase pressure_advance (eg, start with 0.05), and reprint the test
-object. (Be sure to issue RESTART between each config change.) The
-goal is to attempt to eliminate the blobbing during cornering. (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):
+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
+The goal is to find the smallest pressure advance value that results
 in good quality corners:
 
 ![corner-good](img/corner-good.jpg)
 
-Typical pressure_advance values are between 0.05 and 0.20 (the high
-end usually only with bowden extruders).
-
-Once a good pressure_advance value is found, return
-pressure_advance_lookahead_time to its default (0.010). This parameter
-controls how far in advance to check if a head slow-down is
-immediately followed by a speed-up - it reduces pointless pressure
-changes in the head. It's possible to tune this - higher values will
-decrease the number of pressure changes in the nozzle at the expense
-of permitting more blobbing during cornering. (Tuning this value is
-unlikely to impact ooze.) The default of 10ms should work well on most
-printers.
+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 can reduce ooze throughout the print.
+configuration also reduces ooze throughout the print.
 
-Finally, once pressure_advance is tuned in Klipper, it may still be
-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.
+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

@@ -174,20 +174,20 @@ 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
 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_status"
+followed by two parameters, and "id_get_config" and "id_get_clock"
 have zero parameters. The host and micro-controller share a "data
 dictionary" that maps the command descriptions (eg, "set_digital_out
 pin=%u value=%c") to their integer command-ids. When processing the

docs/Releases.md

@@ -1,6 +1,91 @@
 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
 =============
 

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,103 +0,0 @@
-There are several features still to be implemented in Klipper. In no
-particular order:
-
-Host user interaction
-=====================
-
-* See if there is a better way to report errors. Octoprint sometimes
-  doesn't highlight an error (one has to look in the terminal tab to
-  find the error) and errors written to the log can be non-obvious to
-  a user.
-
-* Improve gcode interface:
-
- * Provide a better way to handle print nozzle z offsets. The M206
-   command is cryptic to use and it is too easy to set the value
-   incorrectly or to forget to set it.
-
- * Provide a way to temporarily disable endstop checks so that a user
-   can issue commands that potentially move the head past
-   position_min/position_max.
-
-* Improve logging:
-
- * Possibly collate and report the statistics messages in the log in a
-   more friendly way.
-
-* Possibly support a mechanism for the host to limit maximum velocity
-  so that the mcu is never requested to step at a higher rate than it
-  can support.
-
-Safety features
-===============
-
-* Support loading a valid step range into the micro-controller
-  software after homing. This would provide a sanity check in the
-  micro-controller that would reduce the risk of the host commanding a
-  stepper motor past its valid step range. To maintain high
-  efficiency, the micro-controller would only need to check
-  periodically (eg, every 100ms) that the stepper is in range.
-
- * Possibly support periodically querying the endstop switches and use
-   multiple step ranges depending on the switch state. This would
-   enable runtime endstop detection. (However, it's unclear if runtime
-   endstop detection is a good idea because of spurious signals caused
-   by electrical noise.)
-
-* 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.
-
-Testing features
-================
-
-* Complete the host based simulator. It's possible to compile the
-  micro-controller for a "host simulator", but that simulator doesn't
-  do anything currently. It would be useful to expand the code to
-  support more error checks, kinematic simulations, and improved
-  logging.
-
-Documentation
-=============
-
-* 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.
-
-Hardware features
-=================
-
-* Port to additional micro-controller architectures:
- * Beagle Bone Black PRU
- * Smoothieboard / NXP LPC1769 (ARM cortex-M3)
- * Unix based scheduling; Unix based real-time scheduling
-
-* Support for additional kinematics: scara, 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.)
-
-* 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/delta-tower.svg

@@ -1,273 +0,0 @@
-<?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="delta-tower.svg">
-  <defs
-     id="defs4">
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6618"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend">
-      <path
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6620"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mend"
-       orient="auto"
-       refY="0.0"
-       refX="0.0"
-       id="marker6500"
-       style="overflow:visible;"
-       inkscape:isstock="true">
-      <path
-         id="path6502"
-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
-         style="fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1;fill:#4b4b4b;fill-opacity:1"
-         transform="scale(0.4) rotate(180) translate(10,0)" />
-    </marker>
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible;"
-       id="marker6082"
-       refX="0.0"
-       refY="0.0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend"
-       inkscape:collect="always">
-      <path
-         transform="scale(0.4) rotate(180) translate(10,0)"
-         style="fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1;fill:#4b4b4b;fill-opacity:1"
-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
-         id="path6084" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mend"
-       orient="auto"
-       refY="0.0"
-       refX="0.0"
-       id="Arrow1Mend"
-       style="overflow:visible;"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <path
-         id="path5747"
-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
-         style="fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1;fill:#4b4b4b;fill-opacity:1"
-         transform="scale(0.4) rotate(180) translate(10,0)" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mstart"
-       orient="auto"
-       refY="0.0"
-       refX="0.0"
-       id="Arrow1Mstart"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5744"
-         d="M 0.0,0.0 L 5.0,-5.0 L -12.5,0.0 L 5.0,5.0 L 0.0,0.0 z "
-         style="fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1;fill:#4b4b4b;fill-opacity:1"
-         transform="scale(0.4) translate(10,0)" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Mend-1"
-       style="overflow:visible"
-       inkscape:isstock="true"
-       inkscape:collect="always">
-      <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:isstock="true"
-       style="overflow:visible"
-       id="marker6082-9"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend"
-       inkscape:collect="always">
-      <path
-         inkscape:connector-curvature="0"
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6084-2" />
-    </marker>
-  </defs>
-  <sodipodi:namedview
-     id="base"
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1.0"
-     inkscape:pageopacity="0.0"
-     inkscape:pageshadow="2"
-     inkscape:zoom="1.75"
-     inkscape:cx="172.24895"
-     inkscape:cy="45.708959"
-     inkscape:document-units="px"
-     inkscape:current-layer="layer1"
-     showgrid="false"
-     inkscape:window-width="928"
-     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 />
-      </cc:Work>
-    </rdf:RDF>
-  </metadata>
-  <g
-     inkscape:label="Layer 1"
-     inkscape:groupmode="layer"
-     id="layer1"
-     transform="translate(-135.22429,-249.96955)">
-    <ellipse
-       style="fill:#4d4d4d;stroke:#4b4b4b;stroke-width:1;stroke-miterlimit:4;stroke-dasharray:2, 1, 0.5, 1;stroke-dashoffset:0;stroke-opacity:1"
-       id="path4255"
-       cx="353.79568"
-       cy="327.87662"
-       rx="4.2857141"
-       ry="4.8571429" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000006;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none;marker-start:url(#Arrow1Mstart);marker-end:url(#Arrow1Mend)"
-       d="M 181.50998,381.87664 359.22427,275.01949"
-       id="path5510"
-       inkscape:connector-curvature="0" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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="371.22427"
-       y="354.44806"
-       id="text6058"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6060"
-         x="371.22427"
-         y="354.44806">stepper</tspan><tspan
-         sodipodi:role="line"
-         x="371.22427"
-         y="366.94806"
-         id="tspan9337">tower</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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="166.65283"
-       y="304.16235"
-       id="text6062"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6064"
-         x="166.65283"
-         y="304.16235">line of movement</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-weight:normal;font-size:10.0000006px;line-height:125%;font-family:'DejaVu Sans';letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;-inkscape-font-specification:'DejaVu Sans, Normal';font-stretch:normal;font-variant:normal;text-anchor:start;text-align:start;writing-mode:lr;"
-       x="252.93855"
-       y="384.16235"
-       id="text6066"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6068"
-         x="252.93855"
-         y="384.16235">move</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000006;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none;marker-end:url(#marker6618)"
-       d="m 382.65284,344.73378 c -0.19273,-13.52091 -9.87887,-14.83602 -20.57143,-14.85715"
-       id="path6070"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#marker6500)"
-       d="m 254.65284,374.44806 c 3.39239,-12.86009 -2.06023,-20.09154 -15.42857,-22.28571"
-       id="path6072"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6082)"
-       d="m 257.50997,296.16234 c 31.05376,-3.13332 32.38959,-1.23784 42.28572,10.28572"
-       id="path6074"
-       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 219.61431,358.80126 57.78715,-34.48307"
-       id="path3514-5"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:0.50000003;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;stroke-miterlimit:4;stroke-dasharray:none"
-       d="m 351.22427,323.59092 -20.57143,-32"
-       id="path3358"
-       inkscape:connector-curvature="0" />
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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="244.36713"
-       y="257.30521"
-       id="text4460"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan4462"
-         x="244.36713"
-         y="257.30521">virtual tower</tspan><tspan
-         sodipodi:role="line"
-         x="244.36713"
-         y="269.80521"
-         id="tspan5867">location</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6082-9)"
-       d="m 310.90661,257.14111 c 21.29088,8.40268 18.35244,16.28958 20.57143,29.7143"
-       id="path6074-6"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-  </g>
-</svg>

docs/img/virtual-tower.svg

@@ -1,241 +0,0 @@
-<?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="64.619751mm"
-   height="27.45583mm"
-   viewBox="0 0 228.96762 97.284438"
-   id="svg2"
-   version="1.1"
-   inkscape:version="0.91 r13725"
-   sodipodi:docname="virtual-tower.svg">
-  <defs
-     id="defs4">
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6618"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend">
-      <path
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6620"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6500"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path6502"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;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"
-       inkscape:collect="always">
-      <path
-         id="path5747"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mstart"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Mstart"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5744"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;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"
-       inkscape:collect="always">
-      <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:isstock="true"
-       style="overflow:visible"
-       id="marker6082"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend"
-       inkscape:collect="always">
-      <path
-         inkscape:connector-curvature="0"
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6084" />
-    </marker>
-  </defs>
-  <sodipodi:namedview
-     id="base"
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1.0"
-     inkscape:pageopacity="0.0"
-     inkscape:pageshadow="2"
-     inkscape:zoom="1.75"
-     inkscape:cx="169.7719"
-     inkscape:cy="-4.0565054"
-     inkscape:document-units="px"
-     inkscape:current-layer="layer1"
-     showgrid="false"
-     inkscape:window-width="922"
-     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"
-       originx="-14.085234"
-       originy="-95.286988" />
-  </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(-149.30952,-172.73378)">
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Mstart);marker-end:url(#Arrow1Mend)"
-       d="m 176.36712,256.16235 200.00001,-0.57143"
-       id="path5510"
-       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:10.00000095px;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="-254.01012"
-       y="369.20834"
-       id="text6058"
-       sodipodi:linespacing="125%"
-       transform="matrix(-0.01833576,-0.99983189,0.99983189,-0.01833576,0,0)"
-       inkscape:transform-center-x="-8.0000002"
-       inkscape:transform-center-y="12.571429"><tspan
-         sodipodi:role="line"
-         id="tspan10365"
-         x="-254.01012"
-         y="369.20834">virtual tower</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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="148.36713"
-       y="269.87662"
-       id="text6062"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6064"
-         x="148.36713"
-         y="269.87662">line of movement</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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.50998"
-       y="251.01949"
-       id="text6066"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6068"
-         x="237.50998"
-         y="251.01949">move</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:7.00000048;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
-       d="m 358.08141,255.01949 0,-82.28571"
-       id="path10351"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
-       d="M 220.36713,255.01949 357.50998,173.30521"
-       id="path10373"
-       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:10.00000095px;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.36713"
-       y="187.59093"
-       id="text10375"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan10377"
-         x="200.36713"
-         y="187.59093">virtual arm</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6082)"
-       d="m 261.76375,182.85539 c 22.73118,-0.70136 26.45506,3.7437 40.00001,18.28573"
-       id="path6074"
-       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 219.61431,255.37268 70.93001,0.37408"
-       id="path3514-5"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-  </g>
-</svg>

docs/img/xy+z-tower.svg

@@ -1,241 +0,0 @@
-<?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="64.619751mm"
-   height="27.45583mm"
-   viewBox="0 0 228.96762 97.284438"
-   id="svg2"
-   version="1.1"
-   inkscape:version="0.91 r13725"
-   sodipodi:docname="xy+z-tower.svg">
-  <defs
-     id="defs4">
-    <marker
-       inkscape:isstock="true"
-       style="overflow:visible"
-       id="marker6618"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend">
-      <path
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6620"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mend"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="marker6500"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path6502"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;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"
-       inkscape:collect="always">
-      <path
-         id="path5747"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         inkscape:connector-curvature="0" />
-    </marker>
-    <marker
-       inkscape:stockid="Arrow1Mstart"
-       orient="auto"
-       refY="0"
-       refX="0"
-       id="Arrow1Mstart"
-       style="overflow:visible"
-       inkscape:isstock="true">
-      <path
-         id="path5744"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;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"
-       inkscape:collect="always">
-      <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:isstock="true"
-       style="overflow:visible"
-       id="marker6082"
-       refX="0"
-       refY="0"
-       orient="auto"
-       inkscape:stockid="Arrow1Mend"
-       inkscape:collect="always">
-      <path
-         inkscape:connector-curvature="0"
-         transform="matrix(-0.4,0,0,-0.4,-4,0)"
-         style="fill:#4b4b4b;fill-opacity:1;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1pt;stroke-opacity:1"
-         d="M 0,0 5,-5 -12.5,0 5,5 0,0 Z"
-         id="path6084" />
-    </marker>
-  </defs>
-  <sodipodi:namedview
-     id="base"
-     pagecolor="#ffffff"
-     bordercolor="#666666"
-     borderopacity="1.0"
-     inkscape:pageopacity="0.0"
-     inkscape:pageshadow="2"
-     inkscape:zoom="1.75"
-     inkscape:cx="169.7719"
-     inkscape:cy="-4.0565054"
-     inkscape:document-units="px"
-     inkscape:current-layer="layer1"
-     showgrid="false"
-     inkscape:window-width="922"
-     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"
-       originx="-14.085234"
-       originy="-95.286988" />
-  </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(-149.30952,-172.73378)">
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-start:url(#Arrow1Mstart);marker-end:url(#Arrow1Mend)"
-       d="m 176.36712,256.16235 200.00001,-0.57143"
-       id="path5510"
-       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:10.00000095px;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="-119.27526"
-       y="434.37329"
-       id="text6058"
-       sodipodi:linespacing="125%"
-       transform="matrix(0.32454206,-0.94587127,0.94587127,0.32454206,0,0)"
-       inkscape:transform-center-x="-3.9400734"
-       inkscape:transform-center-y="14.789029"><tspan
-         sodipodi:role="line"
-         id="tspan10365"
-         x="-119.27526"
-         y="434.37329">virtual tower</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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="148.36713"
-       y="269.87662"
-       id="text6062"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6064"
-         x="148.36713"
-         y="269.87662">line of movement</tspan></text>
-    <text
-       xml:space="preserve"
-       style="font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-size:10.00000095px;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.50998"
-       y="251.01949"
-       id="text6066"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan6068"
-         x="237.50998"
-         y="251.01949">move</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:7.00000048;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
-       d="m 354.70239,255.76769 28.12779,-77.32895"
-       id="path10351"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
-       d="M 220.36713,255.01949 380.93855,178.44807"
-       id="path10373"
-       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:10.00000095px;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.36713"
-       y="187.59093"
-       id="text10375"
-       sodipodi:linespacing="125%"><tspan
-         sodipodi:role="line"
-         id="tspan10377"
-         x="200.36713"
-         y="187.59093">virtual arm</tspan></text>
-    <path
-       style="fill:none;fill-rule:evenodd;stroke:#4b4b4b;stroke-width:1.00000012;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1;marker-end:url(#marker6082)"
-       d="m 261.76375,182.85539 c 22.73118,-0.70136 26.45506,3.7437 40.00001,18.28573"
-       id="path6074"
-       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 219.61431,255.37268 70.93001,0.37408"
-       id="path3514-5"
-       inkscape:connector-curvature="0"
-       sodipodi:nodetypes="cc" />
-  </g>
-</svg>

docs/issue_template.md

@@ -0,0 +1,2 @@
+<!-- Klipper do something undesirable? YOU MUST ATTACH THE KLIPPER LOG FILE.
+See: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md -->

docs/prints/calibrate_size.scad

@@ -0,0 +1,77 @@
+// Calibration object for delta sizing
+//
+// Generate STL using OpenSCAD:
+//   openscad calibrate_size.scad -o calibrate_size.stl
+
+base_radius = 70;
+base_height = 1.5;
+base_width = 8;
+cylinder_height = 5;
+cylinder_radius = 5;
+cylinder_outer_dist = 65;
+ridge_cut_radius = .5;
+text_height = 1;
+text_size = 5;
+spoke_angles = [0, 60, 120, 180, 240, 300];
+CUT=0.01;
+
+// Circular ring around entire object (to help reduce warping)
+module base_ring() {
+    difference() {
+        cylinder(h=base_height, r=base_radius);
+        translate([0, 0, -CUT])
+            cylinder(h=base_height + 2*CUT, r=base_radius-base_width);
+    }
+}
+
+// The base ring plus the base spokes
+module base() {
+    base_ring();
+    // Spokes
+    for (angle=spoke_angles)
+        rotate([0, 0, angle])
+            translate([-base_width/2, -CUT, 0])
+                cube([base_width, base_radius-base_width+2*CUT, base_height]);
+}
+
+// Cylinder that measurement ridges are cut out of
+module measuring_cylinder() {
+    cut_width = cylinder_radius;
+    difference() {
+        cylinder(h=cylinder_height+CUT, r=cylinder_radius, $fn=60);
+        for (angle=spoke_angles)
+            rotate([0, 0, angle])
+                translate([-cut_width, cylinder_radius - ridge_cut_radius, -CUT])
+                    cube([2*cut_width, cut_width, cylinder_height+3*CUT]);
+    }
+}
+
+// All the measuring cylinders around the ring
+module measuring_cylinders() {
+    measuring_cylinder();
+    for (angle=spoke_angles)
+        rotate([0, 0, angle])
+            translate([0, cylinder_outer_dist, 0])
+                measuring_cylinder();
+}
+
+// Text writing
+module write_text(angle, dist, msg) {
+    text_offset = dist + 1 - text_size/2;
+    rotate([0, 0, angle])
+        translate([0, text_offset, base_height - CUT])
+            linear_extrude(height=text_height + CUT)
+                text(msg, size=text_size, halign="center");
+}
+
+// Final object with text descriptions
+module calibration_object() {
+    base();
+    translate([0, 0, base_height-CUT])
+        measuring_cylinders();
+    write_text(120, cylinder_outer_dist - 20, "A");
+    write_text(240, cylinder_outer_dist - 20, "B");
+    write_text(0, cylinder_outer_dist - 20, "C");
+}
+
+calibration_object();

docs/prints/square.scad

@@ -7,8 +7,39 @@ square_width = 5;
 square_size = 60;
 square_height = 5;
 
-difference() {
-  cube([square_size, square_size, square_height]);
-  translate([square_width, square_width, -1])
-    cube([square_size-2*square_width, square_size-2*square_width, square_height+2]);
+module hollow_square() {
+    difference() {
+        cube([square_size, square_size, square_height]);
+        translate([square_width, square_width, -1])
+            cube([square_size-2*square_width, square_size-2*square_width,
+                  square_height+2]);
+    }
 }
+
+module notch() {
+    CUT = 0.01;
+    depth = .5;
+    width = 1;
+    translate([-depth, -width, -CUT])
+        cube([2*depth, 2*width, square_height + 2*CUT]);
+}
+
+module square_with_notches() {
+    difference() {
+        // Start with initial square
+        hollow_square();
+        // Remove four notches on inside perimeter
+        translate([square_width, square_size/2 - 4, 0])
+            notch();
+        translate([square_size/2, square_size - square_width, 0])
+            rotate([0, 0, 90])
+                notch();
+        translate([square_size - square_width, square_size/2, 0])
+            notch();
+        translate([square_size/2, square_width, 0])
+            rotate([0, 0, 90])
+                notch();
+    }
+}
+
+square_with_notches();

docs/prints/square.stl

@@ -13,60 +13,172 @@ solid OpenSCAD_Model
       vertex 0 0 5
     endloop
   endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 5 25 5
+      vertex 4.5 25 5
+      vertex 5 5 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 29 5 5
+      vertex 5 5 5
+      vertex 29 4.5 5
+    endloop
+  endfacet
   facet normal 0 0 1
     outer loop
       vertex 60 60 5
-      vertex 55 55 5
+      vertex 55.5 31 5
       vertex 60 0 5
     endloop
   endfacet
   facet normal 0 0 1
     outer loop
       vertex 60 60 5
-      vertex 5 55 5
       vertex 55 55 5
+      vertex 55.5 31 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 60 60 5
+      vertex 31 55.5 5
+      vertex 55 55 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 60 60 5
+      vertex 29 55.5 5
+      vertex 31 55.5 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 29 55.5 5
+      vertex 5 55 5
+      vertex 29 55 5
+    endloop
+  endfacet
+  facet normal -0 0 1
+    outer loop
+      vertex 0 60 5
+      vertex 29 55.5 5
+      vertex 60 60 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 5 55 5
+      vertex 4.5 27 5
+      vertex 5 27 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 0 0 5
+      vertex 4.5 27 5
+      vertex 0 60 5
     endloop
   endfacet
   facet normal 0 0 1
     outer loop
       vertex 5 55 5
       vertex 0 60 5
-      vertex 5 5 5
-    endloop
-  endfacet
-  facet normal -0 0 1
-    outer loop
-      vertex 0 60 5
-      vertex 5 55 5
-      vertex 60 60 5
-    endloop
-  endfacet
-  facet normal -0 0 1
-    outer loop
-      vertex 55 5 5
-      vertex 60 0 5
-      vertex 55 55 5
-    endloop
-  endfacet
-  facet normal -0 0 1
-    outer loop
-      vertex 5 5 5
-      vertex 60 0 5
-      vertex 55 5 5
+      vertex 4.5 27 5
     endloop
   endfacet
   facet normal 0 0 1
     outer loop
+      vertex 29 55.5 5
+      vertex 0 60 5
+      vertex 5 55 5
+    endloop
+  endfacet
+  facet normal -0 0 1
+    outer loop
+      vertex 55.5 29 5
+      vertex 60 0 5
+      vertex 55.5 31 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 55 5 5
+      vertex 55.5 29 5
+      vertex 55 29 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 55.5 29 5
+      vertex 55 5 5
+      vertex 60 0 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 31 4.5 5
+      vertex 55 5 5
+      vertex 31 5 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 55 5 5
+      vertex 31 4.5 5
+      vertex 60 0 5
+    endloop
+  endfacet
+  facet normal -0 0 1
+    outer loop
+      vertex 29 4.5 5
+      vertex 60 0 5
+      vertex 31 4.5 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 0 0 5
+      vertex 29 4.5 5
       vertex 5 5 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 4.5 27 5
+      vertex 0 0 5
+      vertex 4.5 25 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 29 4.5 5
       vertex 0 0 5
       vertex 60 0 5
     endloop
   endfacet
   facet normal 0 0 1
     outer loop
+      vertex 4.5 25 5
       vertex 0 0 5
       vertex 5 5 5
-      vertex 0 60 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 55.5 31 5
+      vertex 55 55 5
+      vertex 55 31 5
+    endloop
+  endfacet
+  facet normal 0 0 1
+    outer loop
+      vertex 55 55 5
+      vertex 31 55.5 5
+      vertex 31 55 5
     endloop
   endfacet
   facet normal 1 -0 0
@@ -97,62 +209,174 @@ solid OpenSCAD_Model
       vertex 0 60 0
     endloop
   endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 5 27 0
+      vertex 4.5 27 0
+      vertex 5 55 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 29 55 0
+      vertex 5 55 0
+      vertex 29 55.5 0
+    endloop
+  endfacet
   facet normal 0 0 -1
     outer loop
       vertex 60 0 0
-      vertex 55 5 0
+      vertex 55.5 29 0
       vertex 60 60 0
     endloop
   endfacet
   facet normal 0 0 -1
     outer loop
       vertex 60 0 0
-      vertex 5 5 0
       vertex 55 5 0
+      vertex 55.5 29 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 60 0 0
+      vertex 31 4.5 0
+      vertex 55 5 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 60 0 0
+      vertex 29 4.5 0
+      vertex 31 4.5 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 29 4.5 0
+      vertex 5 5 0
+      vertex 29 5 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 0 0 0
+      vertex 29 4.5 0
+      vertex 60 0 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 5 5 0
+      vertex 4.5 25 0
+      vertex 5 25 0
+    endloop
+  endfacet
+  facet normal -0 0 -1
+    outer loop
+      vertex 4.5 25 0
+      vertex 0 0 0
+      vertex 4.5 27 0
     endloop
   endfacet
   facet normal -0 0 -1
     outer loop
       vertex 5 5 0
       vertex 0 0 0
-      vertex 5 55 0
+      vertex 4.5 25 0
     endloop
   endfacet
-  facet normal 0 0 -1
+  facet normal -0 0 -1
     outer loop
+      vertex 29 4.5 0
       vertex 0 0 0
       vertex 5 5 0
-      vertex 60 0 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 55.5 31 0
+      vertex 60 60 0
+      vertex 55.5 29 0
     endloop
   endfacet
   facet normal 0 0 -1
     outer loop
       vertex 55 55 0
-      vertex 60 60 0
-      vertex 55 5 0
+      vertex 55.5 31 0
+      vertex 55 31 0
     endloop
   endfacet
   facet normal 0 0 -1
     outer loop
-      vertex 5 55 0
-      vertex 60 60 0
+      vertex 55.5 31 0
       vertex 55 55 0
-    endloop
-  endfacet
-  facet normal 0 0 -1
-    outer loop
-      vertex 5 55 0
-      vertex 0 60 0
       vertex 60 60 0
     endloop
   endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 31 55.5 0
+      vertex 55 55 0
+      vertex 31 55 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 55 55 0
+      vertex 31 55.5 0
+      vertex 60 60 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 29 55.5 0
+      vertex 60 60 0
+      vertex 31 55.5 0
+    endloop
+  endfacet
   facet normal 0 0 -1
     outer loop
       vertex 0 60 0
+      vertex 29 55.5 0
       vertex 5 55 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 0 60 0
+      vertex 4.5 27 0
       vertex 0 0 0
     endloop
   endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 29 55.5 0
+      vertex 0 60 0
+      vertex 60 60 0
+    endloop
+  endfacet
+  facet normal 0 0 -1
+    outer loop
+      vertex 4.5 27 0
+      vertex 0 60 0
+      vertex 5 55 0
+    endloop
+  endfacet
+  facet normal -0 0 -1
+    outer loop
+      vertex 55.5 29 0
+      vertex 55 5 0
+      vertex 55 29 0
+    endloop
+  endfacet
+  facet normal -0 0 -1
+    outer loop
+      vertex 55 5 0
+      vertex 31 4.5 0
+      vertex 31 5 0
+    endloop
+  endfacet
   facet normal 0 -1 0
     outer loop
       vertex 0 0 0
@@ -170,6 +394,20 @@ solid OpenSCAD_Model
   facet normal 1 -0 0
     outer loop
       vertex 5 5 5
+      vertex 5 25 0
+      vertex 5 25 5
+    endloop
+  endfacet
+  facet normal 1 0 0
+    outer loop
+      vertex 5 25 0
+      vertex 5 5 5
+      vertex 5 5 0
+    endloop
+  endfacet
+  facet normal 1 -0 0
+    outer loop
+      vertex 5 27 5
       vertex 5 55 0
       vertex 5 55 5
     endloop
@@ -177,13 +415,27 @@ solid OpenSCAD_Model
   facet normal 1 0 0
     outer loop
       vertex 5 55 0
-      vertex 5 5 5
-      vertex 5 5 0
+      vertex 5 27 5
+      vertex 5 27 0
     endloop
   endfacet
   facet normal -1 0 0
     outer loop
       vertex 55 5 0
+      vertex 55 29 5
+      vertex 55 29 0
+    endloop
+  endfacet
+  facet normal -1 -0 0
+    outer loop
+      vertex 55 29 5
+      vertex 55 5 0
+      vertex 55 5 5
+    endloop
+  endfacet
+  facet normal -1 0 0
+    outer loop
+      vertex 55 31 0
       vertex 55 55 5
       vertex 55 55 0
     endloop
@@ -191,36 +443,232 @@ solid OpenSCAD_Model
   facet normal -1 -0 0
     outer loop
       vertex 55 55 5
-      vertex 55 5 0
-      vertex 55 5 5
+      vertex 55 31 0
+      vertex 55 31 5
     endloop
   endfacet
   facet normal 0 1 -0
     outer loop
-      vertex 55 5 0
+      vertex 29 5 0
       vertex 5 5 5
-      vertex 55 5 5
+      vertex 29 5 5
     endloop
   endfacet
   facet normal 0 1 0
     outer loop
       vertex 5 5 5
-      vertex 55 5 0
+      vertex 29 5 0
       vertex 5 5 0
     endloop
   endfacet
+  facet normal 0 1 -0
+    outer loop
+      vertex 55 5 0
+      vertex 31 5 5
+      vertex 55 5 5
+    endloop
+  endfacet
+  facet normal 0 1 0
+    outer loop
+      vertex 31 5 5
+      vertex 55 5 0
+      vertex 31 5 0
+    endloop
+  endfacet
   facet normal 0 -1 0
     outer loop
       vertex 5 55 0
-      vertex 55 55 5
+      vertex 29 55 5
       vertex 5 55 5
     endloop
   endfacet
   facet normal 0 -1 -0
     outer loop
-      vertex 55 55 5
+      vertex 29 55 5
       vertex 5 55 0
+      vertex 29 55 0
+    endloop
+  endfacet
+  facet normal 0 -1 0
+    outer loop
+      vertex 31 55 0
+      vertex 55 55 5
+      vertex 31 55 5
+    endloop
+  endfacet
+  facet normal 0 -1 -0
+    outer loop
+      vertex 55 55 5
+      vertex 31 55 0
       vertex 55 55 0
     endloop
   endfacet
+  facet normal 1 -0 0
+    outer loop
+      vertex 4.5 25 5
+      vertex 4.5 27 0
+      vertex 4.5 27 5
+    endloop
+  endfacet
+  facet normal 1 0 0
+    outer loop
+      vertex 4.5 27 0
+      vertex 4.5 25 5
+      vertex 4.5 25 0
+    endloop
+  endfacet
+  facet normal 0 -1 0
+    outer loop
+      vertex 4.5 27 0
+      vertex 5 27 5
+      vertex 4.5 27 5
+    endloop
+  endfacet
+  facet normal 0 -1 -0
+    outer loop
+      vertex 5 27 5
+      vertex 4.5 27 0
+      vertex 5 27 0
+    endloop
+  endfacet
+  facet normal 0 1 -0
+    outer loop
+      vertex 5 25 0
+      vertex 4.5 25 5
+      vertex 5 25 5
+    endloop
+  endfacet
+  facet normal 0 1 0
+    outer loop
+      vertex 4.5 25 5
+      vertex 5 25 0
+      vertex 4.5 25 0
+    endloop
+  endfacet
+  facet normal 0 -1 0
+    outer loop
+      vertex 29 55.5 0
+      vertex 31 55.5 5
+      vertex 29 55.5 5
+    endloop
+  endfacet
+  facet normal 0 -1 -0
+    outer loop
+      vertex 31 55.5 5
+      vertex 29 55.5 0
+      vertex 31 55.5 0
+    endloop
+  endfacet
+  facet normal 1 -0 0
+    outer loop
+      vertex 29 55 5
+      vertex 29 55.5 0
+      vertex 29 55.5 5
+    endloop
+  endfacet
+  facet normal 1 0 0
+    outer loop
+      vertex 29 55.5 0
+      vertex 29 55 5
+      vertex 29 55 0
+    endloop
+  endfacet
+  facet normal -1 0 0
+    outer loop
+      vertex 31 55 0
+      vertex 31 55.5 5
+      vertex 31 55.5 0
+    endloop
+  endfacet
+  facet normal -1 -0 0
+    outer loop
+      vertex 31 55.5 5
+      vertex 31 55 0
+      vertex 31 55 5
+    endloop
+  endfacet
+  facet normal -1 0 0
+    outer loop
+      vertex 55.5 29 0
+      vertex 55.5 31 5
+      vertex 55.5 31 0
+    endloop
+  endfacet
+  facet normal -1 -0 0
+    outer loop
+      vertex 55.5 31 5
+      vertex 55.5 29 0
+      vertex 55.5 29 5
+    endloop
+  endfacet
+  facet normal 0 -1 0
+    outer loop
+      vertex 55 31 0
+      vertex 55.5 31 5
+      vertex 55 31 5
+    endloop
+  endfacet
+  facet normal 0 -1 -0
+    outer loop
+      vertex 55.5 31 5
+      vertex 55 31 0
+      vertex 55.5 31 0
+    endloop
+  endfacet
+  facet normal 0 1 -0
+    outer loop
+      vertex 55.5 29 0
+      vertex 55 29 5
+      vertex 55.5 29 5
+    endloop
+  endfacet
+  facet normal 0 1 0
+    outer loop
+      vertex 55 29 5
+      vertex 55.5 29 0
+      vertex 55 29 0
+    endloop
+  endfacet
+  facet normal 0 1 -0
+    outer loop
+      vertex 31 4.5 0
+      vertex 29 4.5 5
+      vertex 31 4.5 5
+    endloop
+  endfacet
+  facet normal 0 1 0
+    outer loop
+      vertex 29 4.5 5
+      vertex 31 4.5 0
+      vertex 29 4.5 0
+    endloop
+  endfacet
+  facet normal -1 0 0
+    outer loop
+      vertex 31 4.5 0
+      vertex 31 5 5
+      vertex 31 5 0
+    endloop
+  endfacet
+  facet normal -1 -0 0
+    outer loop
+      vertex 31 5 5
+      vertex 31 4.5 0
+      vertex 31 4.5 5
+    endloop
+  endfacet
+  facet normal 1 -0 0
+    outer loop
+      vertex 29 4.5 5
+      vertex 29 5 0
+      vertex 29 5 5
+    endloop
+  endfacet
+  facet normal 1 0 0
+    outer loop
+      vertex 29 5 0
+      vertex 29 4.5 5
+      vertex 29 4.5 0
+    endloop
+  endfacet
 endsolid OpenSCAD_Model

docs/stm32f1.md

@@ -0,0 +1,52 @@
+This document describes how the STM32F1 port operates and how it can be used on
+STM32-based boards, such as the "Blue Pill". STM32 MCUs are not used on any
+Arduino boards, so their restrictions aren't as widely known and less straight
+forward compared to common Arduino compatible boards. There aren't any standard
+pin mappings either.
+
+General considerations
+======================
+
+The STM32 port currently requires an 8 MHz crystal for correct
+operation. The port is currently designed for and tested with
+STM32F103xB series MCUs, but it should work with any STM32F103 series
+MCUs with minimal changes.
+
+Unlike Arduino-based boards, typically there is no automatic reset on serial
+connection with STM32 boards. Please use `restart_method: command` with the
+STM32F1 port.
+
+Fixed pins
+==========
+
+When using serial, the UART used for communication with the host is
+fixed to pins PA9 (TX) and PA10 (RX). When using USB, the PA11 (D-)
+and PA12 (D+) pins are reserved. The USB code assumes that PA12 (D+)
+has a fixed pullup resistor attached to it.
+
+SWD pins (PA13/PA14) are enabled for debugging and cannot be used for
+any I/O. SPI uses pins PB13/PB14/PB15, but the pins can be used as
+general I/O if SPI is not used.
+
+Digital I/O
+===========
+
+All pins that aren't part of the fixed set can be used for digital I/O. Pins are
+referred to by their primary name, e.g. `PA1`. Do not try to use Arduino pin
+aliases in your configuration. See ST's datasheets for more details. The
+[STM32Duino](http://wiki.stm32duino.com/index.php?title=Blue_Pill) wiki has more
+info on the popular "Blue Pill" board.
+
+Analog inputs
+=============
+
+All ADC-capable pins can be used as analog inputs with the same naming as
+digital I/O pins. Small packages MCUs (e.g. LFQP48) have 10 channels (PA0-PA7,
+PB0-PB1), while larger package devices have 16 channels (PA0-PA7, PB0-PB1,
+PC0-PC5).
+
+SPI
+===
+
+SPI uses pin PB13 (SCK), PB14 (MISO) and PB15 (MOSI). The clock speed range is
+0.15..18 MHz. Chip select pins do not have any restrictions.

klippy/cartesian.py

@@ -1,132 +0,0 @@
-# Code for handling the kinematics of cartesian robots
-#
-# Copyright (C) 2016  Kevin O'Connor <kevin@koconnor.net>
-#
-# This file may be distributed under the terms of the GNU GPLv3 license.
-import logging
-import stepper, homing
-
-StepList = (0, 1, 2)
-
-class CartKinematics:
-    def __init__(self, printer, config):
-        self.steppers = [stepper.PrinterStepper(
-            printer, config.getsection('stepper_' + n), n)
-                         for n in ['x', 'y', 'z']]
-        self.max_z_velocity = config.getfloat(
-            'max_z_velocity', 9999999.9, above=0.)
-        self.max_z_accel = config.getfloat(
-            'max_z_accel', 9999999.9, above=0.)
-        self.need_motor_enable = True
-        self.limits = [(1.0, -1.0)] * 3
-    def set_max_jerk(self, max_xy_halt_velocity, max_velocity, max_accel):
-        self.steppers[0].set_max_jerk(max_xy_halt_velocity, max_accel)
-        self.steppers[1].set_max_jerk(max_xy_halt_velocity, max_accel)
-        self.steppers[2].set_max_jerk(0., self.max_z_accel)
-    def set_position(self, newpos):
-        for i in StepList:
-            self.steppers[i].mcu_stepper.set_position(newpos[i])
-    def home(self, homing_state):
-        # Each axis is homed independently and in order
-        for axis in homing_state.get_axes():
-            s = self.steppers[axis]
-            self.limits[axis] = (s.position_min, s.position_max)
-            # Determine moves
-            if s.homing_positive_dir:
-                pos = s.position_endstop - 1.5*(
-                    s.position_endstop - s.position_min)
-                rpos = s.position_endstop - s.homing_retract_dist
-                r2pos = rpos - s.homing_retract_dist
-            else:
-                pos = s.position_endstop + 1.5*(
-                    s.position_max - s.position_endstop)
-                rpos = s.position_endstop + s.homing_retract_dist
-                r2pos = rpos + s.homing_retract_dist
-            # Initial homing
-            homepos = [None, None, None, None]
-            homepos[axis] = s.position_endstop
-            coord = [None, None, None, None]
-            coord[axis] = pos
-            homing_state.home(list(coord), homepos, [s], s.homing_speed)
-            # Retract
-            coord[axis] = rpos
-            homing_state.retract(list(coord), s.homing_speed)
-            # Home again
-            coord[axis] = r2pos
-            homing_state.home(
-                list(coord), homepos, [s], s.homing_speed/2.0, second_home=True)
-            # Set final homed position
-            coord[axis] = s.position_endstop + s.get_homed_offset()
-            homing_state.set_homed_position(coord)
-    def motor_off(self, move_time):
-        self.limits = [(1.0, -1.0)] * 3
-        for stepper in self.steppers:
-            stepper.motor_enable(move_time, 0)
-        self.need_motor_enable = True
-    def _check_motor_enable(self, move_time, move):
-        need_motor_enable = False
-        for i in StepList:
-            if move.axes_d[i]:
-                self.steppers[i].motor_enable(move_time, 1)
-            need_motor_enable |= self.steppers[i].need_motor_enable
-        self.need_motor_enable = need_motor_enable
-    def query_endstops(self, print_time):
-        endstops = [(s, s.query_endstop(print_time)) for s in self.steppers]
-        return [(s.name, es.query_endstop_wait()) for s, es in endstops]
-    def _check_endstops(self, move):
-        end_pos = move.end_pos
-        for i in StepList:
-            if (move.axes_d[i]
-                and (end_pos[i] < self.limits[i][0]
-                     or end_pos[i] > self.limits[i][1])):
-                if self.limits[i][0] > self.limits[i][1]:
-                    raise homing.EndstopMoveError(
-                        end_pos, "Must home axis first")
-                raise homing.EndstopMoveError(end_pos)
-    def check_move(self, move):
-        limits = self.limits
-        xpos, ypos = move.end_pos[:2]
-        if (xpos < limits[0][0] or xpos > limits[0][1]
-            or ypos < limits[1][0] or ypos > limits[1][1]):
-            self._check_endstops(move)
-        if not move.axes_d[2]:
-            # Normal XY move - use defaults
-            return
-        # Move with Z - update velocity and accel for slower Z axis
-        self._check_endstops(move)
-        z_ratio = move.move_d / abs(move.axes_d[2])
-        move.limit_speed(
-            self.max_z_velocity * z_ratio, self.max_z_accel * z_ratio)
-    def move(self, move_time, move):
-        if self.need_motor_enable:
-            self._check_motor_enable(move_time, move)
-        for i in StepList:
-            axis_d = move.axes_d[i]
-            if not axis_d:
-                continue
-            mcu_stepper = self.steppers[i].mcu_stepper
-            mcu_time = mcu_stepper.print_to_mcu_time(move_time)
-            start_pos = move.start_pos[i]
-            axis_r = abs(axis_d) / move.move_d
-            accel = move.accel * axis_r
-            cruise_v = move.cruise_v * axis_r
-
-            # Acceleration steps
-            if move.accel_r:
-                accel_d = move.accel_r * axis_d
-                mcu_stepper.step_const(
-                    mcu_time, start_pos, accel_d, move.start_v * axis_r, accel)
-                start_pos += accel_d
-                mcu_time += move.accel_t
-            # Cruising steps
-            if move.cruise_r:
-                cruise_d = move.cruise_r * axis_d
-                mcu_stepper.step_const(
-                    mcu_time, start_pos, cruise_d, cruise_v, 0.)
-                start_pos += cruise_d
-                mcu_time += move.cruise_t
-            # Deceleration steps
-            if move.decel_r:
-                decel_d = move.decel_r * axis_d
-                mcu_stepper.step_const(
-                    mcu_time, start_pos, decel_d, cruise_v, -accel)

klippy/chelper/__init__.py

@@ -1,6 +1,6 @@
 # Wrapper around C helper code
 #
-# Copyright (C) 2016,2017  Kevin O'Connor <kevin@koconnor.net>
+# Copyright (C) 2016-2018  Kevin O'Connor <kevin@koconnor.net>
 #
 # This file may be distributed under the terms of the GNU GPLv3 license.
 import os, logging
@@ -11,34 +11,73 @@ import cffi
 # c_helper.so compiling
 ######################################################################
 
-COMPILE_CMD = "gcc -Wall -g -O2 -shared -fPIC -o %s %s"
-SOURCE_FILES = ['stepcompress.c', 'serialqueue.c', 'pyhelper.c']
+COMPILE_CMD = ("gcc -Wall -g -O2 -shared -fPIC"
+               " -flto -fwhole-program -fno-use-linker-plugin"
+               " -o %s %s")
+SOURCE_FILES = [
+    'pyhelper.c', 'serialqueue.c', 'stepcompress.c', 'itersolve.c',
+    'kin_cartesian.c', 'kin_corexy.c', 'kin_delta.c', 'kin_extruder.c'
+]
 DEST_LIB = "c_helper.so"
-OTHER_FILES = ['list.h', 'serialqueue.h', 'pyhelper.h']
+OTHER_FILES = [
+    'list.h', 'serialqueue.h', 'stepcompress.h', 'itersolve.h', 'pyhelper.h'
+]
 
 defs_stepcompress = """
-    struct stepcompress *stepcompress_alloc(uint32_t max_error
-        , uint32_t queue_step_msgid, uint32_t set_next_step_dir_msgid
-        , uint32_t invert_sdir, uint32_t oid);
+    struct stepcompress *stepcompress_alloc(uint32_t oid);
+    void stepcompress_fill(struct stepcompress *sc, uint32_t max_error
+        , uint32_t invert_sdir, uint32_t queue_step_msgid
+        , uint32_t set_next_step_dir_msgid);
     void stepcompress_free(struct stepcompress *sc);
     int stepcompress_reset(struct stepcompress *sc, uint64_t last_step_clock);
     int stepcompress_set_homing(struct stepcompress *sc, uint64_t homing_clock);
     int stepcompress_queue_msg(struct stepcompress *sc, uint32_t *data, int len);
 
-    int stepcompress_push(struct stepcompress *sc, double step_clock
-        , int32_t sdir);
-    int32_t stepcompress_push_const(struct stepcompress *sc, double clock_offset
-        , double step_offset, double steps, double start_sv, double accel);
-    int32_t stepcompress_push_delta(struct stepcompress *sc
-        , double clock_offset, double move_sd, double start_sv, double accel
-        , double height, double startxy_sd, double arm_d, double movez_r);
-
     struct steppersync *steppersync_alloc(struct serialqueue *sq
         , struct stepcompress **sc_list, int sc_num, int move_num);
     void steppersync_free(struct steppersync *ss);
+    void steppersync_set_time(struct steppersync *ss
+        , double time_offset, double mcu_freq);
     int steppersync_flush(struct steppersync *ss, uint64_t move_clock);
 """
 
+defs_itersolve = """
+    struct move *move_alloc(void);
+    void move_fill(struct move *m, double print_time
+        , double accel_t, double cruise_t, double decel_t
+        , double start_pos_x, double start_pos_y, double start_pos_z
+        , double axes_d_x, double axes_d_y, double axes_d_z
+        , double start_v, double cruise_v, double accel);
+    int32_t itersolve_gen_steps(struct stepper_kinematics *sk, struct move *m);
+    void itersolve_set_stepcompress(struct stepper_kinematics *sk
+        , struct stepcompress *sc, double step_dist);
+    double itersolve_calc_position_from_coord(struct stepper_kinematics *sk
+        , double x, double y, double z);
+    void itersolve_set_commanded_pos(struct stepper_kinematics *sk, double pos);
+    double itersolve_get_commanded_pos(struct stepper_kinematics *sk);
+"""
+
+defs_kin_cartesian = """
+    struct stepper_kinematics *cartesian_stepper_alloc(char axis);
+"""
+
+defs_kin_corexy = """
+    struct stepper_kinematics *corexy_stepper_alloc(char type);
+"""
+
+defs_kin_delta = """
+    struct stepper_kinematics *delta_stepper_alloc(double arm2
+        , double tower_x, double tower_y);
+"""
+
+defs_kin_extruder = """
+    struct stepper_kinematics *extruder_stepper_alloc(void);
+    void extruder_move_fill(struct move *m, double print_time
+        , double accel_t, double cruise_t, double decel_t, double start_pos
+        , double start_v, double cruise_v, double accel
+        , double extra_accel_v, double extra_decel_v);
+"""
+
 defs_serialqueue = """
     #define MESSAGE_MAX 64
     struct pull_queue_message {
@@ -54,13 +93,13 @@ defs_serialqueue = """
     void serialqueue_free_commandqueue(struct command_queue *cq);
     void serialqueue_send(struct serialqueue *sq, struct command_queue *cq
         , uint8_t *msg, int len, uint64_t min_clock, uint64_t req_clock);
-    void serialqueue_encode_and_send(struct serialqueue *sq
-        , struct command_queue *cq, uint32_t *data, int len
-        , uint64_t min_clock, uint64_t req_clock);
-    void serialqueue_pull(struct serialqueue *sq, struct pull_queue_message *pqm);
+    void serialqueue_pull(struct serialqueue *sq
+        , struct pull_queue_message *pqm);
     void serialqueue_set_baud_adjust(struct serialqueue *sq, double baud_adjust);
-    void serialqueue_set_clock_est(struct serialqueue *sq, double est_clock
-        , double last_ack_time, uint64_t last_ack_clock);
+    void serialqueue_set_receive_window(struct serialqueue *sq
+        , int receive_window);
+    void serialqueue_set_clock_est(struct serialqueue *sq, double est_freq
+        , double last_clock_time, uint64_t last_clock);
     void serialqueue_get_stats(struct serialqueue *sq, char *buf, int len);
     int serialqueue_extract_old(struct serialqueue *sq, int sentq
         , struct pull_queue_message *q, int max);
@@ -71,6 +110,15 @@ defs_pyhelper = """
     double get_monotonic(void);
 """
 
+defs_std = """
+    void free(void*);
+"""
+
+defs_all = [
+    defs_pyhelper, defs_serialqueue, defs_std, defs_stepcompress, defs_itersolve,
+    defs_kin_cartesian, defs_kin_corexy, defs_kin_delta, defs_kin_extruder
+]
+
 # Return the list of file modification times
 def get_mtimes(srcdir, filelist):
     out = []
@@ -88,7 +136,7 @@ def check_build_code(srcdir, target, sources, cmd, other_files=[]):
     src_times = get_mtimes(srcdir, sources + other_files)
     obj_times = get_mtimes(srcdir, [target])
     if not obj_times or max(src_times) > min(obj_times):
-        logging.info("Building C code module %s" % (target,))
+        logging.info("Building C code module %s", target)
         srcfiles = [os.path.join(srcdir, fname) for fname in sources]
         destlib = os.path.join(srcdir, target)
         os.system(cmd % (destlib, ' '.join(srcfiles)))
@@ -105,9 +153,8 @@ def get_ffi():
         check_build_code(srcdir, DEST_LIB, SOURCE_FILES, COMPILE_CMD
                          , OTHER_FILES)
         FFI_main = cffi.FFI()
-        FFI_main.cdef(defs_stepcompress)
-        FFI_main.cdef(defs_serialqueue)
-        FFI_main.cdef(defs_pyhelper)
+        for d in defs_all:
+            FFI_main.cdef(d)
         FFI_lib = FFI_main.dlopen(os.path.join(srcdir, DEST_LIB))
         # Setup error logging
         def logging_callback(msg):
@@ -124,7 +171,7 @@ def get_ffi():
 
 HC_COMPILE_CMD = "gcc -Wall -g -O2 -o %s %s -lusb"
 HC_SOURCE_FILES = ['hub-ctrl.c']
-HC_SOURCE_DIR = '../lib/hub-ctrl'
+HC_SOURCE_DIR = '../../lib/hub-ctrl'
 HC_TARGET = "hub-ctrl"
 HC_CMD = "sudo %s/hub-ctrl -h 0 -P 2 -p %d"
 
@@ -133,3 +180,7 @@ def run_hub_ctrl(enable_power):
     hubdir = os.path.join(srcdir, HC_SOURCE_DIR)
     check_build_code(hubdir, HC_TARGET, HC_SOURCE_FILES, HC_COMPILE_CMD)
     os.system(HC_CMD % (hubdir, enable_power))
+
+
+if __name__ == '__main__':
+    get_ffi()

klippy/chelper/compiler.h

@@ -0,0 +1,46 @@
+#ifndef __COMPILER_H
+#define __COMPILER_H
+// Low level definitions for C languange and gcc compiler.
+
+#define barrier() __asm__ __volatile__("": : :"memory")
+
+#define likely(x)       __builtin_expect(!!(x), 1)
+#define unlikely(x)     __builtin_expect(!!(x), 0)
+
+#define noinline __attribute__((noinline))
+#ifndef __always_inline
+#define __always_inline inline __attribute__((always_inline))
+#endif
+#define __visible __attribute__((externally_visible))
+#define __noreturn __attribute__((noreturn))
+
+#define PACKED __attribute__((packed))
+#ifndef __aligned
+#define __aligned(x) __attribute__((aligned(x)))
+#endif
+#ifndef __section
+#define __section(S) __attribute__((section(S)))
+#endif
+
+#define ARRAY_SIZE(a) (sizeof(a) / sizeof(a[0]))
+#define ALIGN(x,a)              __ALIGN_MASK(x,(typeof(x))(a)-1)
+#define __ALIGN_MASK(x,mask)    (((x)+(mask))&~(mask))
+#define ALIGN_DOWN(x,a)         ((x) & ~((typeof(x))(a)-1))
+
+#define container_of(ptr, type, member) ({                      \
+        const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
+        (type *)( (char *)__mptr - offsetof(type,member) );})
+
+#define __stringify_1(x)        #x
+#define __stringify(x)          __stringify_1(x)
+
+#define ___PASTE(a,b) a##b
+#define __PASTE(a,b) ___PASTE(a,b)
+
+#define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
+#define DIV_ROUND_CLOSEST(x, divisor)({                 \
+            typeof(divisor) __divisor = divisor;        \
+            (((x) + ((__divisor) / 2)) / (__divisor));  \
+        })
+
+#endif // compiler.h

klippy/chelper/itersolve.c

@@ -0,0 +1,238 @@
+// Iterative solver for kinematic moves
+//
+// Copyright (C) 2018  Kevin O'Connor <kevin@koconnor.net>
+//
+// This file may be distributed under the terms of the GNU GPLv3 license.
+
+#include <math.h> // sqrt
+#include <stdlib.h> // malloc
+#include <string.h> // memset
+#include "compiler.h" // __visible
+#include "itersolve.h" // struct coord
+#include "pyhelper.h" // errorf
+#include "stepcompress.h" // queue_append_start
+
+
+/****************************************************************
+ * Kinematic moves
+ ****************************************************************/
+
+struct move * __visible
+move_alloc(void)
+{
+    struct move *m = malloc(sizeof(*m));
+    memset(m, 0, sizeof(*m));
+    return m;
+}
+
+// Populate a 'struct move' with a velocity trapezoid
+void __visible
+move_fill(struct move *m, double print_time
+          , double accel_t, double cruise_t, double decel_t
+          , double start_pos_x, double start_pos_y, double start_pos_z
+          , double axes_d_x, double axes_d_y, double axes_d_z
+          , double start_v, double cruise_v, double accel)
+{
+    // Setup velocity trapezoid
+    m->print_time = print_time;
+    m->move_t = accel_t + cruise_t + decel_t;
+    m->accel_t = accel_t;
+    m->cruise_t = cruise_t;
+    m->cruise_start_d = accel_t * .5 * (cruise_v + start_v);
+    m->decel_start_d = m->cruise_start_d + cruise_t * cruise_v;
+
+    // Setup for accel/cruise/decel phases
+    m->cruise_v = cruise_v;
+    m->accel.c1 = start_v;
+    m->accel.c2 = .5 * accel;
+    m->decel.c1 = cruise_v;
+    m->decel.c2 = -m->accel.c2;
+
+    // Setup for move_get_coord()
+    m->start_pos.x = start_pos_x;
+    m->start_pos.y = start_pos_y;
+    m->start_pos.z = start_pos_z;
+    double inv_move_d = 1. / sqrt(axes_d_x*axes_d_x + axes_d_y*axes_d_y
+                                  + axes_d_z*axes_d_z);
+    m->axes_r.x = axes_d_x * inv_move_d;
+    m->axes_r.y = axes_d_y * inv_move_d;
+    m->axes_r.z = axes_d_z * inv_move_d;
+}
+
+// Find the distance travel during acceleration/deceleration
+static inline double
+move_eval_accel(struct move_accel *ma, double move_time)
+{
+    return (ma->c1 + ma->c2 * move_time) * move_time;
+}
+
+// Return the distance moved given a time in a move
+inline double
+move_get_distance(struct move *m, double move_time)
+{
+    if (unlikely(move_time < m->accel_t))
+        // Acceleration phase of move
+        return move_eval_accel(&m->accel, move_time);
+    move_time -= m->accel_t;
+    if (likely(move_time <= m->cruise_t))
+        // Cruising phase
+        return m->cruise_start_d + m->cruise_v * move_time;
+    // Deceleration phase
+    move_time -= m->cruise_t;
+    return m->decel_start_d + move_eval_accel(&m->decel, move_time);
+}
+
+// Return the XYZ coordinates given a time in a move
+inline struct coord
+move_get_coord(struct move *m, double move_time)
+{
+    double move_dist = move_get_distance(m, move_time);
+    return (struct coord) {
+        .x = m->start_pos.x + m->axes_r.x * move_dist,
+        .y = m->start_pos.y + m->axes_r.y * move_dist,
+        .z = m->start_pos.z + m->axes_r.z * move_dist };
+}
+
+
+/****************************************************************
+ * Iterative solver
+ ****************************************************************/
+
+struct timepos {
+    double time, position;
+};
+
+// Find step using "false position" method
+static struct timepos
+itersolve_find_step(struct stepper_kinematics *sk, struct move *m
+                    , struct timepos low, struct timepos high
+                    , double target)
+{
+    sk_callback calc_position = sk->calc_position;
+    struct timepos best_guess = high;
+    low.position -= target;
+    high.position -= target;
+    if (!high.position)
+        // The high range was a perfect guess for the next step
+        return best_guess;
+    int high_sign = signbit(high.position);
+    if (high_sign == signbit(low.position))
+        // The target is not in the low/high range - return low range
+        return (struct timepos){ low.time, target };
+    for (;;) {
+        double guess_time = ((low.time*high.position - high.time*low.position)
+                             / (high.position - low.position));
+        if (fabs(guess_time - best_guess.time) <= .000000001)
+            break;
+        best_guess.time = guess_time;
+        best_guess.position = calc_position(sk, m, guess_time);
+        double guess_position = best_guess.position - target;
+        int guess_sign = signbit(guess_position);
+        if (guess_sign == high_sign) {
+            high.time = guess_time;
+            high.position = guess_position;
+        } else {
+            low.time = guess_time;
+            low.position = guess_position;
+        }
+    }
+    return best_guess;
+}
+
+// Generate step times for a stepper during a move
+int32_t __visible
+itersolve_gen_steps(struct stepper_kinematics *sk, struct move *m)
+{
+    struct stepcompress *sc = sk->sc;
+    sk_callback calc_position = sk->calc_position;
+    double half_step = .5 * sk->step_dist;
+    double mcu_freq = stepcompress_get_mcu_freq(sc);
+    struct timepos last = { 0., sk->commanded_pos }, low = last, high = last;
+    double seek_time_delta = 0.000100;
+    int sdir = stepcompress_get_step_dir(sc);
+    struct queue_append qa = queue_append_start(sc, m->print_time, .5);
+    for (;;) {
+        // Determine if next step is in forward or reverse direction
+        double dist = high.position - last.position;
+        if (fabs(dist) < half_step) {
+        seek_new_high_range:
+            if (high.time >= m->move_t)
+                // At end of move
+                break;
+            // Need to increase next step search range
+            low = high;
+            high.time = last.time + seek_time_delta;
+            seek_time_delta += seek_time_delta;
+            if (high.time > m->move_t)
+                high.time = m->move_t;
+            high.position = calc_position(sk, m, high.time);
+            continue;
+        }
+        int next_sdir = dist > 0.;
+        if (unlikely(next_sdir != sdir)) {
+            // Direction change
+            if (fabs(dist) < half_step + .000000001)
+                // Only change direction if going past midway point
+                goto seek_new_high_range;
+            if (last.time >= low.time && high.time > last.time) {
+                // Must seek new low range to avoid re-finding previous time
+                high.time = (last.time + high.time) * .5;
+                high.position = calc_position(sk, m, high.time);
+                continue;
+            }
+            int ret = queue_append_set_next_step_dir(&qa, next_sdir);
+            if (ret)
+                return ret;
+            sdir = next_sdir;
+        }
+        // Find step
+        double target = last.position + (sdir ? half_step : -half_step);
+        struct timepos next = itersolve_find_step(sk, m, low, high, target);
+        // Add step at given time
+        int ret = queue_append(&qa, next.time * mcu_freq);
+        if (ret)
+            return ret;
+        seek_time_delta = next.time - last.time;
+        if (seek_time_delta < .000000001)
+            seek_time_delta = .000000001;
+        last.position = target + (sdir ? half_step : -half_step);
+        last.time = next.time;
+        low = next;
+        if (last.time >= high.time)
+            // The high range is no longer valid - recalculate it
+            goto seek_new_high_range;
+    }
+    queue_append_finish(qa);
+    sk->commanded_pos = last.position;
+    return 0;
+}
+
+void __visible
+itersolve_set_stepcompress(struct stepper_kinematics *sk
+                           , struct stepcompress *sc, double step_dist)
+{
+    sk->sc = sc;
+    sk->step_dist = step_dist;
+}
+
+double __visible
+itersolve_calc_position_from_coord(struct stepper_kinematics *sk
+                                   , double x, double y, double z)
+{
+    struct move m;
+    memset(&m, 0, sizeof(m));
+    move_fill(&m, 0., 0., 1., 0., x, y, z, 0., 1., 0., 0., 1., 0.);
+    return sk->calc_position(sk, &m, 0.);
+}
+
+void __visible
+itersolve_set_commanded_pos(struct stepper_kinematics *sk, double pos)
+{
+    sk->commanded_pos = pos;
+}
+
+double __visible
+itersolve_get_commanded_pos(struct stepper_kinematics *sk)
+{
+    return sk->commanded_pos;
+}

klippy/chelper/itersolve.h

@@ -0,0 +1,49 @@
+#ifndef ITERSOLVE_H
+#define ITERSOLVE_H
+
+#include <stdint.h> // uint32_t
+
+struct coord {
+    double x, y, z;
+};
+
+struct move_accel {
+    double c1, c2;
+};
+
+struct move {
+    double print_time, move_t;
+    double accel_t, cruise_t;
+    double cruise_start_d, decel_start_d;
+    double cruise_v;
+    struct move_accel accel, decel;
+    struct coord start_pos, axes_r;
+};
+
+struct move *move_alloc(void);
+void move_fill(struct move *m, double print_time
+               , double accel_t, double cruise_t, double decel_t
+               , double start_pos_x, double start_pos_y, double start_pos_z
+               , double axes_d_x, double axes_d_y, double axes_d_z
+               , double start_v, double cruise_v, double accel);
+double move_get_distance(struct move *m, double move_time);
+struct coord move_get_coord(struct move *m, double move_time);
+
+struct stepper_kinematics;
+typedef double (*sk_callback)(struct stepper_kinematics *sk, struct move *m
+                              , double move_time);
+struct stepper_kinematics {
+    double step_dist, commanded_pos;
+    struct stepcompress *sc;
+    sk_callback calc_position;
+};
+
+int32_t itersolve_gen_steps(struct stepper_kinematics *sk, struct move *m);
+void itersolve_set_stepcompress(struct stepper_kinematics *sk
+                                , struct stepcompress *sc, double step_dist);
+double itersolve_calc_position_from_coord(struct stepper_kinematics *sk
+                                          , double x, double y, double z);
+void itersolve_set_commanded_pos(struct stepper_kinematics *sk, double pos);
+double itersolve_get_commanded_pos(struct stepper_kinematics *sk);
+
+#endif // itersolve.h

klippy/chelper/kin_cartesian.c

@@ -0,0 +1,46 @@
+// Cartesian kinematics stepper pulse time generation
+//
+// Copyright (C) 2018  Kevin O'Connor <kevin@koconnor.net>
+//
+// This file may be distributed under the terms of the GNU GPLv3 license.
+
+#include <stdlib.h> // malloc
+#include <string.h> // memset
+#include "compiler.h" // __visible
+#include "itersolve.h" // move_get_coord
+#include "pyhelper.h" // errorf
+
+static double
+cart_stepper_x_calc_position(struct stepper_kinematics *sk, struct move *m
+                             , double move_time)
+{
+    return move_get_coord(m, move_time).x;
+}
+
+static double
+cart_stepper_y_calc_position(struct stepper_kinematics *sk, struct move *m
+                             , double move_time)
+{
+    return move_get_coord(m, move_time).y;
+}
+
+static double
+cart_stepper_z_calc_position(struct stepper_kinematics *sk, struct move *m
+                             , double move_time)
+{
+    return move_get_coord(m, move_time).z;
+}
+
+struct stepper_kinematics * __visible
+cartesian_stepper_alloc(char axis)
+{
+    struct stepper_kinematics *sk = malloc(sizeof(*sk));
+    memset(sk, 0, sizeof(*sk));
+    if (axis == 'x')
+        sk->calc_position = cart_stepper_x_calc_position;
+    else if (axis == 'y')
+        sk->calc_position = cart_stepper_y_calc_position;
+    else if (axis == 'z')
+        sk->calc_position = cart_stepper_z_calc_position;
+    return sk;
+}

klippy/chelper/kin_corexy.c

@@ -0,0 +1,38 @@
+// CoreXY kinematics stepper pulse time generation
+//
+// Copyright (C) 2018  Kevin O'Connor <kevin@koconnor.net>
+//
+// This file may be distributed under the terms of the GNU GPLv3 license.
+
+#include <stdlib.h> // malloc
+#include <string.h> // memset
+#include "compiler.h" // __visible
+#include "itersolve.h" // struct stepper_kinematics
+
+static double
+corexy_stepper_plus_calc_position(struct stepper_kinematics *sk, struct move *m
+                                  , double move_time)
+{
+    struct coord c = move_get_coord(m, move_time);
+    return c.x + c.y;
+}
+
+static double
+corexy_stepper_minus_calc_position(struct stepper_kinematics *sk, struct move *m
+                                   , double move_time)
+{
+    struct coord c = move_get_coord(m, move_time);
+    return c.x - c.y;
+}
+
+struct stepper_kinematics * __visible
+corexy_stepper_alloc(char type)
+{
+    struct stepper_kinematics *sk = malloc(sizeof(*sk));
+    memset(sk, 0, sizeof(*sk));
+    if (type == '+')
+        sk->calc_position = corexy_stepper_plus_calc_position;
+    else if (type == '-')
+        sk->calc_position = corexy_stepper_minus_calc_position;
+    return sk;
+}