mcu: Disable waiting in send_wait_ack() if in debugging mode

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

.github/workflows/build-test.yaml

@@ -4,7 +4,7 @@ on: [push, pull_request]
 
 jobs:
   build:
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-22.04
     steps:
     - uses: actions/checkout@v3
 
@@ -21,7 +21,7 @@ jobs:
       run: ./scripts/ci-build.sh 2>&1
 
     - name: Upload micro-controller data dictionaries
-      uses: actions/upload-artifact@v3
+      uses: actions/upload-artifact@v4
       with:
         name: data-dict
         path: ci_build/dict

.github/workflows/stale-issue-bot.yaml

@@ -62,54 +62,54 @@ jobs:
                 state: 'closed'
               });
             }
-  # Close tickets marked with "reviewer needed" label for 2+ weeks
-  close_reviewer_needed:
-    if: github.repository == 'Klipper3d/klipper'
-    runs-on: ubuntu-latest
-    steps:
-      - uses: actions/github-script@v6
-        with:
-          script: |
-            const issues = await github.rest.issues.listForRepo({
-              owner: context.repo.owner,
-              repo: context.repo.repo,
-              state: 'open',
-              labels: 'reviewer needed',
-              assignee: 'none',
-              per_page: 100,
-              page: 1
-            });
-            msg = "Unfortunately a reviewer has not assigned themselves to"
-                + " this GitHub Pull Request and it is therefore being"
-                + " closed. It is a good idea to move"
-                + " further discussion to the [Klipper Discourse]"
-                + "(https://www.klipper3d.org/Contact.html#discourse-forum)"
-                + " server. Reviewers can reach out on that forum to let you"
-                + " know if they are interested and when they are available."
-                + "\n\n"
-                + "Best regards,\n"
-                + "~ Your friendly GitIssueBot"
-                + "\n\n"
-                + "PS: I'm just an automated script, not a human being.";
-            const expireMillis = 1000 * 60 * 60 * 24 * 14;
-            const curtime = new Date().getTime();
-            for (const issue of issues.data.values()) {
-              const updatetime = new Date(issue.updated_at).getTime();
-              if (curtime < updatetime + expireMillis)
-                continue;
-              await github.rest.issues.createComment({
-                owner: context.repo.owner,
-                repo: context.repo.repo,
-                issue_number: issue.number,
-                body: msg
-              });
-              await github.rest.issues.update({
-                owner: context.repo.owner,
-                repo: context.repo.repo,
-                issue_number: issue.number,
-                state: 'closed'
-              });
-            }
+#  # Close tickets marked with "reviewer needed" label for 2+ weeks
+#  close_reviewer_needed:
+#    if: github.repository == 'Klipper3d/klipper'
+#    runs-on: ubuntu-latest
+#    steps:
+#      - uses: actions/github-script@v6
+#        with:
+#          script: |
+#            const issues = await github.rest.issues.listForRepo({
+#              owner: context.repo.owner,
+#              repo: context.repo.repo,
+#              state: 'open',
+#              labels: 'reviewer needed',
+#              assignee: 'none',
+#              per_page: 100,
+#              page: 1
+#            });
+#            msg = "Unfortunately a reviewer has not assigned themselves to"
+#                + " this GitHub Pull Request and it is therefore being"
+#                + " closed. It is a good idea to move"
+#                + " further discussion to the [Klipper Discourse]"
+#                + "(https://www.klipper3d.org/Contact.html#discourse-forum)"
+#                + " server. Reviewers can reach out on that forum to let you"
+#                + " know if they are interested and when they are available."
+#                + "\n\n"
+#                + "Best regards,\n"
+#                + "~ Your friendly GitIssueBot"
+#                + "\n\n"
+#                + "PS: I'm just an automated script, not a human being.";
+#            const expireMillis = 1000 * 60 * 60 * 24 * 14;
+#            const curtime = new Date().getTime();
+#            for (const issue of issues.data.values()) {
+#              const updatetime = new Date(issue.updated_at).getTime();
+#              if (curtime < updatetime + expireMillis)
+#                continue;
+#              await github.rest.issues.createComment({
+#                owner: context.repo.owner,
+#                repo: context.repo.repo,
+#                issue_number: issue.number,
+#                body: msg
+#              });
+#              await github.rest.issues.update({
+#                owner: context.repo.owner,
+#                repo: context.repo.repo,
+#                issue_number: issue.number,
+#                state: 'closed'
+#              });
+#            }
   # Mark unassigned PRs that are idle for 2 weeks
   mark_reviewer_needed:
     if: github.repository == 'Klipper3d/klipper'

Makefile

@@ -29,10 +29,11 @@ dirs-y = src
 cc-option=$(shell if test -z "`$(1) $(2) -S -o /dev/null -xc /dev/null 2>&1`" \
     ; then echo "$(2)"; else echo "$(3)"; fi ;)
 
-CFLAGS := -I$(OUT) -Isrc -I$(OUT)board-generic/ -std=gnu11 -O2 -MD \
-    -Wall -Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \
+CFLAGS := -iquote $(OUT) -iquote src -iquote $(OUT)board-generic/ \
+		-std=gnu11 -O2 -MD -Wall \
+		-Wold-style-definition $(call cc-option,$(CC),-Wtype-limits,) \
     -ffunction-sections -fdata-sections -fno-delete-null-pointer-checks
-CFLAGS += -flto -fwhole-program -fno-use-linker-plugin -ggdb3
+CFLAGS += -flto=auto -fwhole-program -fno-use-linker-plugin -ggdb3
 
 OBJS_klipper.elf = $(patsubst %.c, $(OUT)src/%.o,$(src-y))
 OBJS_klipper.elf += $(OUT)compile_time_request.o

README.md

@@ -4,15 +4,14 @@ Welcome to the Klipper project!
 
 https://www.klipper3d.org/
 
-Klipper is a 3d-Printer firmware. It combines the power of a general
-purpose computer with one or more micro-controllers. See the
+The Klipper firmware controls 3d-Printers. It combines the power of a
+general purpose computer with one or more micro-controllers. See the
 [features document](https://www.klipper3d.org/Features.html) for more
-information on why you should use Klipper.
+information on why you should use the Klipper software.
 
-To begin using Klipper start by
-[installing](https://www.klipper3d.org/Installation.html) it.
+Start by [installing Klipper software](https://www.klipper3d.org/Installation.html).
 
-Klipper is Free Software. See the [license](COPYING) or read the
-[documentation](https://www.klipper3d.org/Overview.html). We depend on
-the generous support from our
+Klipper software is Free Software. See the [license](COPYING) or read
+the [documentation](https://www.klipper3d.org/Overview.html). We
+depend on the generous support from our
 [sponsors](https://www.klipper3d.org/Sponsors.html).

config/example-generic-caretesian.cfg

@@ -0,0 +1,138 @@
+# This file is an example config file for cartesian style printers.
+# One may copy and edit this file to configure a new printer with
+# a generic cartesian kinematics.
+
+# DO NOT COPY THIS FILE WITHOUT CAREFULLY READING AND UPDATING IT
+# FIRST. Incorrectly configured parameters may cause damage.
+
+# See docs/Config_Reference.md for a description of parameters.
+
+[carriage x]
+position_endstop: 0
+position_max: 300
+homing_speed: 50
+endstop_pin: ^PE5
+
+[carriage y]
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+endstop_pin: ^PJ1
+
+[extra_carriage y1]
+primary_carriage: y
+endstop_pin: ^PB6
+
+[carriage z]
+position_endstop: 0.5
+position_max: 100
+endstop_pin: ^PD3
+
+[dual_carriage u]
+primary_carriage: x
+position_endstop: 300
+position_max: 300
+homing_speed: 50
+endstop_pin: ^PE4
+
+[stepper my_stepper_x]
+carriages: x+y
+step_pin: PF0
+dir_pin: PF1
+enable_pin: !PD7
+microsteps: 16
+rotation_distance: 40
+
+[stepper my_stepper_u]
+carriages: u-y1
+step_pin: PH1
+dir_pin: PH0
+enable_pin: !PA1
+microsteps: 16
+rotation_distance: 40
+
+[stepper my_stepper_y0]
+carriages: y
+step_pin: PF6
+dir_pin: !PF7
+enable_pin: !PF2
+microsteps: 16
+rotation_distance: 40
+
+[stepper my_stepper_y1]
+carriages: y1
+step_pin: PE3
+dir_pin: !PH6
+enable_pin: !PG5
+microsteps: 16
+rotation_distance: 40
+
+[stepper my_stepper_z0]
+carriages: z
+step_pin: PL3
+dir_pin: PL1
+enable_pin: !PK0
+microsteps: 16
+rotation_distance: 8
+
+[stepper my_stepper_z1]
+carriages: z
+step_pin: PG1
+dir_pin: PG0
+enable_pin: !PH3
+microsteps: 16
+rotation_distance: 8
+
+[extruder]
+step_pin: PA4
+dir_pin: PA6
+enable_pin: !PA2
+microsteps: 16
+rotation_distance: 33.5
+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
+
+[extruder1]
+step_pin: PC1
+dir_pin: PC3
+enable_pin: !PC7
+microsteps: 16
+rotation_distance: 33.5
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK7
+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: watermark
+min_temp: 0
+max_temp: 110
+
+[mcu]
+serial: /dev/ttyACM0
+
+[printer]
+kinematics: generic_cartesian
+max_velocity: 500
+max_accel: 3000
+max_z_velocity: 20
+max_z_accel: 100

config/generic-I3DBEEZ9.cfg

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

config/generic-bigtreetech-manta-m8p-v1.0.cfg

@@ -39,7 +39,7 @@ position_max: 270
 # Motor4
 # The M8P only has 4 heater outputs which leaves an extra stepper
 # This can be used for a second Z stepper, dual_carriage, extruder co-stepper,
-# or other accesory such as an MMU
+# or other accessory such as an MMU
 #[stepper_]
 #step_pin: PD3
 #dir_pin: PD2

config/generic-bigtreetech-manta-m8p-v1.1.cfg

@@ -40,7 +40,7 @@ position_max: 270
 # Motor4
 # The M8P only has 4 heater outputs which leaves an extra stepper
 # This can be used for a second Z stepper, dual_carriage, extruder co-stepper,
-# or other accesory such as an MMU
+# or other accessory such as an MMU
 #[stepper_]
 #step_pin: PD3
 #dir_pin: PD2

config/generic-bigtreetech-octopus-max-ez.cfg

@@ -43,7 +43,7 @@ position_max: 200
 # Motor-4
 # The Octopus only has 4 heater outputs which leaves an extra stepper
 # This can be used for a second Z stepper, dual_carriage, extruder co-stepper,
-# or other accesory such as an MMU
+# or other accessory such as an MMU
 #[stepper_]
 #step_pin: PB8
 #dir_pin: PB9

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

@@ -52,7 +52,7 @@ position_max: 200
 # Driver3
 # The Octopus only has 4 heater outputs which leaves an extra stepper
 # This can be used for a second Z stepper, dual_carriage, extruder co-stepper,
-# or other accesory such as an MMU
+# or other accessory such as an MMU
 #[stepper_]
 #step_pin: PG4
 #dir_pin: PC1

config/generic-bigtreetech-skr-2.cfg

@@ -153,3 +153,48 @@ aliases:
 #uart_pin: PD12
 #run_current: 0.600
 #diag_pin:
+
+########################################
+# TMC2130 configuration
+########################################
+
+#[tmc2130 stepper_x]
+#cs_pin: PE0
+#spi_software_miso_pin: PA14
+#spi_software_mosi_pin: PE14
+#spi_software_sclk_pin: PE15
+#run_current: 0.800
+#diag1_pin: PC1
+
+#[tmc2130 stepper_y]
+#cs_pin: PD3
+#spi_software_miso_pin: PA14
+#spi_software_mosi_pin: PE14
+#spi_software_sclk_pin: PE15
+#run_current: 0.800
+#diag1_pin: PC3
+
+#[tmc2130 stepper_z]
+#cs_pin: PD0
+#spi_software_miso_pin: PA14
+#spi_software_mosi_pin: PE14
+#spi_software_sclk_pin: PE15
+#run_current: 0.800
+#diag1_pin: PC0
+
+#[tmc2130 extruder]
+#cs_pin: PC6
+#spi_software_miso_pin: PA14
+#spi_software_mosi_pin: PE14
+#spi_software_sclk_pin: PE15
+#run_current: 0.600
+#diag1_pin: PC2
+
+#[tmc2130 extruder1]
+#cs_pin: PD12
+#spi_software_miso_pin: PA14
+#spi_software_mosi_pin: PE14
+#spi_software_sclk_pin: PE15
+#run_current: 0.600
+#stealthchop_threshold: 999999
+#diag1_pin: PA0

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

@@ -85,11 +85,10 @@ uart_pin: PC11
 tx_pin: PC10
 uart_address: 3
 run_current: 0.650
-stealthchop_threshold: 999999
 
 [heater_bed]
 heater_pin: PC9
-sensor_type: ATC Semitec 104GT-2
+sensor_type: EPCOS 100K B57560G104F
 sensor_pin: PC4
 control: pid
 pid_Kp: 54.027

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

@@ -122,6 +122,12 @@ max_z_accel: 100
 [static_digital_output usb_pullup_enable]
 pins: !PA14
 
+#[neopixel my_neopixel]
+#pin: PA8
+
+[output_pin red_led]
+pin: PA13
+
 [board_pins]
 aliases:
     # EXP1 header

config/generic-creality-v4.2.7.cfg

@@ -95,4 +95,4 @@ max_z_accel: 100
 aliases:
   EXP1_1=PC6,EXP1_3=PB10,EXP1_5=PB14,EXP1_7=PB12,EXP1_9=<GND>,
   EXP1_2=PB2,EXP1_4=PB11,EXP1_6=PB13,EXP1_8=PB15,EXP1_10=<5V>,
-  PROBE_IN=PB0,PROBE_OUT=PB1,FIL_RUNOUT=PC6
+  PROBE_IN=PB0,PROBE_OUT=PB1,FIL_RUNOUT=PA4

config/generic-ldo-leviathan-v1.2.cfg

@@ -0,0 +1,241 @@
+# This file contains common pin mappings for the LDO Leviathan v1.2.
+
+# To use this config, during "make menuconfig", select "Enable
+# low-level configuration options", select the STM32F446 micro-controller,
+# select a "32KiB bootloader", and select a "12Mhz crystal".
+
+# See docs/Config_Reference.md for a description of parameters.
+
+# HV-STEPPER-0
+[stepper_x]
+step_pin: PB10
+dir_pin: PB11
+enable_pin: !PG0
+microsteps: 32
+rotation_distance: 40
+endstop_pin: PC1 # X-ENDSTOP
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc5160 stepper_x]
+spi_bus: spi4
+cs_pin: PE15
+#diag0_pin: PG1
+interpolate: False
+sense_resistor: 0.075
+run_current: 0.8
+stealthchop_threshold: 0
+
+# HV-STEPPER-1
+[stepper_y]
+step_pin: PF15
+dir_pin: PF14
+enable_pin: !PE9
+microsteps: 32
+rotation_distance: 40
+endstop_pin: PC2 # Y-ENDSTOP
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+
+[tmc5160 stepper_y]
+spi_bus: spi4
+cs_pin: PE11
+#diag0_pin: PE10
+interpolate: False
+sense_resistor: 0.075
+run_current: 0.8
+stealthchop_threshold: 0
+
+# STEPPER-0
+[stepper_z]
+step_pin: PD4
+dir_pin: PD3
+enable_pin: !PD7
+microsteps: 32
+rotation_distance: 8
+endstop_pin: PC3 # Z-ENDSTOP
+position_endstop: 0
+position_max: 200
+
+[tmc2209 stepper_z]
+uart_pin: PD5
+#diag_pin: PD6
+interpolate: False
+run_current: 0.6
+stealthchop_threshold: 999999
+
+# The Leviathan was developed for Voron printers. It therefore has several
+# steppers for the z-axes, but only one heater for one extruder.
+
+# STEPPER-1
+#[stepper_z1]
+#step_pin: PC12
+#dir_pin: PC11
+#enable_pin: !PD2
+#microsteps: 32
+#rotation_distance: 8
+#
+#[tmc2209 stepper_z1]
+#uart_pin: PD5
+##diag_pin: PD6
+#interpolate: False
+#run_current: 0.6
+#stealthchop_threshold: 999999
+
+# STEPPER-2
+#[stepper_z2]
+#step_pin: PC9
+#dir_pin: PC8
+#enable_pin: !PC10
+#microsteps: 32
+#rotation_distance: 8
+#
+#[tmc2209 stepper_z2]
+#uart_pin: PA8
+##diag_pin: PA15
+#interpolate: False
+#run_current: 0.6
+#stealthchop_threshold: 999999
+
+# STEPPER-3
+#[stepper_z3]
+#step_pin: PG7
+#dir_pin: PG6
+#enable_pin: !PC7
+#microsteps: 32
+#rotation_distance: 8
+#
+#[tmc2209 stepper_z2]
+#uart_pin: PG8
+##diag_pin: PC6
+#interpolate: False
+#run_current: 0.6
+#stealthchop_threshold: 999999
+
+# STEPPER-4
+[extruder]
+step_pin: PD10
+dir_pin: PD9
+enable_pin: !PD13
+microsteps: 32
+rotation_distance: 22.67
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PG10 # HEATER
+sensor_pin:  PA2 # TH1
+sensor_type: ATC Semitec 104NT-4-R025H42G
+pullup_resistor: 2200
+control: pid
+pid_Kp: 36.787
+pid_Ki: 4.716
+pid_Kd: 71.735
+min_temp: 0
+max_temp: 250
+
+[tmc2209 stepper_z]
+uart_pin: PD11
+#diag_pin: PD12
+interpolate: False
+run_current: 0.5
+stealthchop_threshold: 0
+
+#[filament_switch_sensor material_0]
+#switch_pin: PC0 # FILAMENT-SENSOR
+
+[heater_bed]
+heater_pin: PG11 # HEATBED
+sensor_pin: PA1 # TH0
+sensor_type: ATC Semitec 104GT-2
+pullup_resistor: 2200
+control: pid
+pid_kp: 56.723
+pid_ki: 5.561
+pid_kd: 144.642
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PB7 # FAN0
+#tachometer_pin: PB0
+
+#[heater_fan fan1]
+#pin: PB3
+#tachometer_pin: PB4
+
+#[heater_fan fan2]
+#pin: PF7
+#tachometer_pin: PF6
+
+#[controller_fan fan3]
+#pin: PF9
+#tachometer_pin: PF8
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_Klipper_firmware_12345-if00
+# CAN bus is also available on this board
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+[board_pins]
+aliases:
+    # EXP1 header
+    EXP1_1=PG9, EXP1_2=PG12,
+    EXP1_3=PG13, EXP1_4=PG14,
+    EXP1_5=PC13, EXP1_6=PC14,
+    EXP1_7=PC15, EXP1_8=PF0,
+    EXP1_9=<GND>, EXP1_10=<5V>,
+
+    # EXP2 header
+    EXP2_1=PA6, EXP2_2=PA5,
+    EXP2_3=PE2, EXP2_4=PE4,
+    EXP2_5=PE3, EXP2_6=PA7,
+    EXP2_7=PE5, EXP2_8=<RST>,
+    EXP2_9=<GND>, EXP2_10=PE4,
+
+    # See the sample-lcd.cfg file for definitions of common LCD displays.
+
+    # EXTENSION PORT
+    EXP3_1=<5V>, EXP3_2=<5V>,       # max. 0.5A
+    EXP3_3=<GND>, EXP3_4=<GND>,
+    EXP3_5=<3.3V>, EXP3_6=<3.3V>,   # max. 0.5A
+    EXP3_7=PF5, EXP3_8=PF4,
+    EXP3_9=PF3, EXP3_10=PF2,
+    EXP3_11=PC4, EXP3_12=PC5,       # EXP3_11 and EXP3_12 are ADC inputs
+    EXP3_13=PB0, EXP3_14=PB1,       # EXP3_13 and EXP3_14 are ADC inputs
+    EXP3_15=PE8, EXP3_16=PE7,       # EXP3_15 is UART5_TX, EXP3_16 is UART5_RX
+    EXP3_17=PG5, EXP3_18=PG4,
+    EXP3_19=PG3, EXP3_20=PG2,
+    EXP3_21=PD15, EXP3_22=PD14,
+    EXP3_23=PB15, EXP3_24=PB14,     # EXP3_23 is SPI2_MOSI
+                                    # EXP3_24 is SPI2_MISO
+    EXP3_25=PB13, EXP3_26=PB12,     # EXP3_25 is SPI2_SCK + CAN2_TX
+                                    # EXP3_26 is SPI2_CS + CAN2_RX
+    EXP3_27=<GND>, EXP3_28=<GND>,
+    EXP3_29=<24V>, EXP3_30=<24V>,   # max. 0.5A
+
+#[probe]
+#sensor_pin: PF1 # Z-PROBE
+#z_offset: 0
+
+#[led my_led]
+#white_pin: PE6 # LED-Strip
+
+#[neopixel my_neopixel]
+#pin: PF10 # NEOPIXEL
+
+#[temperature_sensor TH2]
+#sensor_type: ATC Semitec 104GT-2
+#sensor_pin: PA0 # TH2
+#pullup_resistor: 2200
+
+#[temperature_sensor TH3]
+#sensor_type: ATC Semitec 104GT-2
+#sensor_pin: PA3 # TH3
+#pullup_resistor: 2200

config/generic-mellow-fly-e3-v2.cfg

@@ -0,0 +1,232 @@
+# This file contains common pin mappings for the Mellow Fly-E3-v2.
+# To use this config, the firmware should be compiled for the
+# STM32F407 with a "32KiB bootloader".
+
+# The "make flash" command does not work on the Fly-E3-v2. Instead,
+# after running "make", copy the generated "out/klipper.bin" file to a
+# file named "firmware.bin" or "klipper.bin" on an SD card and then restart the Fly-E3-v2
+# with that SD card.
+
+# See docs/Config_Reference.md for a description of parameters.
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_stm32f407xx_27004A001851323333353137-if00
+
+[stepper_x]
+step_pin: PE5
+dir_pin: PC0
+enable_pin: !PC1
+microsteps: 16
+rotation_distance: 30
+full_steps_per_rotation: 200
+endstop_pin: PE7 #X-STOP
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+second_homing_speed: 10
+homing_retract_dist: 5.0
+homing_positive_dir: false
+step_pulse_duration: 0.000004
+
+[stepper_y]
+step_pin: PE4
+dir_pin: !PC13
+enable_pin: !PC14
+microsteps: 16
+rotation_distance: 30
+full_steps_per_rotation: 200
+endstop_pin: PE8 #Y-STOP
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+second_homing_speed: 10
+homing_retract_dist: 5.0
+homing_positive_dir: false
+step_pulse_duration: 0.000004
+
+[stepper_z]
+step_pin: PE1
+dir_pin: !PB7
+enable_pin: !PE3
+microsteps: 16
+rotation_distance: 30
+full_steps_per_rotation: 200
+endstop_pin: PE9 #Z-STOP
+position_min: 0
+position_endstop: 0
+position_max: 200
+homing_speed: 5
+second_homing_speed: 3
+homing_retract_dist: 5.0
+homing_positive_dir: false
+step_pulse_duration: 0.000004
+
+[extruder]
+step_pin: PE2
+dir_pin: PD5
+enable_pin: !PD6
+microsteps: 16
+rotation_distance: 33.500
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC6 #E0
+
+########################################
+# Extruder 100K thermistor configuration
+########################################
+sensor_type: ATC Semitec 104GT-2
+sensor_pin: PC4 #T0 TEMP
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 275
+########################################
+# Extruder MAX31865 PT100 2 wire config
+########################################
+# sensor_type: MAX31865
+# sensor_pin: PD15 #PT-100
+# spi_speed: 4000000
+# spi_software_sclk_pin: PD12
+# spi_software_mosi_pin: PD11
+# spi_software_miso_pin: PD13
+# rtd_nominal_r: 100
+# rtd_reference_r: 430
+# rtd_num_of_wires: 2
+# rtd_use_50Hz_filter: True
+min_temp: 0
+max_temp: 300
+
+#[extruder1]
+#step_pin: PE0
+#dir_pin: PD1
+#enable_pin: !PD3
+#microsteps: 16
+#heater_pin: PC7 #E1
+#sensor_pin: PC5 #T1 TEMP
+
+########################################
+# TMC2209 configuration
+########################################
+
+[tmc2209 stepper_x]
+uart_pin: PC15
+interpolate: False
+run_current: 0.3
+sense_resistor: 0.110
+stealthchop_threshold: 999999
+
+[tmc2209 stepper_y]
+uart_pin: PB6
+interpolate: False
+run_current: 0.3
+sense_resistor: 0.110
+stealthchop_threshold: 999999
+
+[tmc2209 stepper_z]
+uart_pin: PD7
+interpolate: False
+run_current: 0.4
+sense_resistor: 0.110
+stealthchop_threshold: 999999
+
+[tmc2209 extruder]
+uart_pin: PD4
+interpolate: False
+run_current: 0.27
+sense_resistor: 0.075
+stealthchop_threshold: 999999
+
+#[tmc2209 extruder1]
+#uart_pin: PD0
+#interpolate: False
+#run_current: 0.27
+#sense_resistor: 0.075
+#stealthchop_threshold: 999999
+
+
+#######################################
+# Heated Bed
+#######################################
+
+[heater_bed]
+heater_pin: PB0 #BED
+sensor_type: Generic 3950
+sensor_pin: PB1 #B-TEMP
+max_power: 1.0
+min_temp: 0
+max_temp: 120
+control: pid
+pid_kp: 58.437
+pid_ki: 2.347
+pid_kd: 363.769
+
+#######################################
+# LIGHTING
+#######################################
+
+#[led Toolhead]
+#white_pin: PA2 #FAN2
+#cycle_time: 0.010
+#initial_white: 0
+
+#######################################
+# COOLING
+#######################################
+
+[heater_fan hotend_fan]
+pin: PA1 #FAN1
+max_power: 1.0
+kick_start_time: 0.5
+heater: extruder
+heater_temp: 50
+fan_speed: 1.0
+
+[controller_fan controller_fan]
+pin: PA0 #FAN0
+max_power: 1.0
+kick_start_time: 0.5
+heater: extruder
+stepper: stepper_x, stepper_y, stepper_z
+fan_speed: 1.0
+idle_timeout: 60
+
+[fan]
+pin: PA3 #FAN3
+max_power: 1.0
+off_below: 0.2
+
+[temperature_sensor Mellow_Fly_E3_V2]
+sensor_type: temperature_mcu
+min_temp: 5
+max_temp: 80
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 50
+max_z_accel: 100
+
+########################################
+# EXP1 / EXP2 (display) pins
+########################################
+[board_pins]
+aliases:
+    EXP1_1=PD10, EXP1_3=PA8,   EXP1_5=PE15,   EXP1_7=PA14,  EXP1_9=<GND>,
+    EXP1_2=PA9,  EXP1_4=PA10,  EXP1_6=PE14,   EXP1_8=PA13,  EXP1_10=<5V>,
+    # EXP2 header
+    EXP2_1=PA6, EXP2_3=PB11,  EXP2_5=PB10,  EXP2_7=PE13,   EXP2_9=<GND>,
+    EXP2_2=PA5, EXP2_4=PA4,   EXP2_6=PA7,   EXP2_8=<RST>, EXP2_10=<NC>,
+
+# See the sample-lcd.cfg file for definitions of common LCD displays.
+
+#######################################
+# BL-Touch
+#######################################
+
+#[bltouch]
+#sensor_pin: PC2
+#control_pin: PE6
+#z_offset: 0

config/generic-mightyboard.cfg

@@ -89,32 +89,32 @@ max_z_velocity: 5
 max_z_accel: 100
 
 [mcp4018 x_axis_pot]
-scl_pin: PJ5
-sda_pin: PF3
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PF3
 wiper: 0.50
 scale: 0.773
 
 [mcp4018 y_axis_pot]
-scl_pin: PJ5
-sda_pin: PF7
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PF7
 wiper: 0.50
 scale: 0.773
 
 [mcp4018 z_axis_pot]
-scl_pin: PJ5
-sda_pin: PK3
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PK3
 wiper: 0.50
 scale: 0.773
 
 [mcp4018 a_axis_pot]
-scl_pin: PJ5
-sda_pin: PA5
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PA5
 wiper: 0.50
 scale: 0.773
 
 [mcp4018 b_axis_pot]
-scl_pin: PJ5
-sda_pin: PJ6
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PJ6
 wiper: 0.50
 scale: 0.773
 

config/generic-mini-rambo.cfg

@@ -84,7 +84,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.3
+value: 1.3
 
 [output_pin stepper_z_current]
 pin: PL4
@@ -92,7 +92,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.3
+value: 1.3
 
 [output_pin stepper_e_current]
 pin: PL5
@@ -100,7 +100,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.25
+value: 1.25
 
 [static_digital_output stepper_config]
 pins:

config/generic-ultimaker-ultimainboard-v2.cfg

@@ -97,7 +97,7 @@ max_z_accel: 30
 
 [output_pin case_light]
 pin: PH5
-static_value: 1.0
+value: 1.0
 
 # Motor current settings.
 [output_pin stepper_xy_current]
@@ -107,7 +107,7 @@ scale: 2.000
 # Max power setting.
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.200
+value: 1.200
 # Power adjustment setting.
 
 [output_pin stepper_z_current]
@@ -116,7 +116,7 @@ pwm: True
 scale: 2.000
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.200
+value: 1.200
 
 [output_pin stepper_e_current]
 pin: PL3
@@ -124,4 +124,4 @@ pwm: True
 scale: 2.000
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.250
+value: 1.250

config/kit-voron2-250mm.cfg

@@ -19,7 +19,7 @@
 # FSR switch (z endstop) location       [homing_override] section
 # FSR switch (z endstop) offset for Z0  [stepper_z] section
 # Probe points                          [quad_gantry_level] section
-# Min & Max gantry corner postions      [quad_gantry_level] section
+# Min & Max gantry corner positions     [quad_gantry_level] section
 # PID tune                              [extruder] and [heater_bed] sections
 # Fine tune E steps                     [extruder] section
 

config/kit-zav3d-2019.cfg

@@ -20,7 +20,7 @@
 # FSR switch (z endstop) location       [homing_override] section
 # FSR switch (z endstop) offset for Z0  [stepper_z] section
 # Probe points                          [quad_gantry_level] section
-# Min & Max gantry corner postions      [quad_gantry_level] section
+# Min & Max gantry corner positions     [quad_gantry_level] section
 # PID tune                              [extruder] and [heater_bed] sections
 # Fine tune E steps                     [extruder] section
 

config/printer-adimlab-2018.cfg

@@ -89,7 +89,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.3
+value: 1.3
 
 [output_pin stepper_z_current]
 pin: PL4
@@ -97,7 +97,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.3
+value: 1.3
 
 [output_pin stepper_e_current]
 pin: PL3
@@ -105,7 +105,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.25
+value: 1.25
 
 [display]
 lcd_type: st7920

config/printer-anycubic-4maxpro-2.0-2021.cfg

@@ -126,7 +126,6 @@ restart_method: arduino
 kinematics: cartesian
 max_velocity: 150
 max_accel: 3000
-max_accel_to_decel: 1500
 max_z_velocity: 7
 max_z_accel: 50
 square_corner_velocity: 5

config/printer-anycubic-kobra-go-2022.cfg

@@ -118,7 +118,7 @@ cycle_time: 0.00005 #20kHz
 
 [output_pin enable_pin]
 pin: PB6
-static_value: 1
+value: 1
     #This pin enables the bed, hotend, extruder fan, part fan.
 
 [mcu]

config/printer-anycubic-kobra-plus-2022.cfg

@@ -14,6 +14,7 @@
 # To build the firmware, use the following configuration:
 #   - Micro-controller: Huada Semiconductor HC32F460
 #   - Communication interface: Serial (PA3 & PA2) - Anycube
+#   - Clock Speed: 200 MHz
 #
 # Installation:
 #  1. Rename the klipper bin to `firmware.bin` and copy it to an SD Card.
@@ -144,10 +145,9 @@ max_temp: 120
 pause_on_runout: True
 switch_pin: !PC13
 
-[heater_fan controller_fan]
+[controller_fan controller_fan]
 pin: PA14
 heater: heater_bed
-heater_temp: 45.0
 
 [heater_fan hotend_fan]
 pin: PA13

config/printer-anycubic-kossel-2016.cfg

@@ -17,7 +17,7 @@ endstop_pin: ^PE4
 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.
+# and measure the distance from nozzle to bed.
 # This value then needs to be added.
 position_endstop: 273.0
 arm_length: 229.4

config/printer-artillery-genius-pro-2022.cfg

@@ -0,0 +1,126 @@
+# This file contains pin mappings for the Artillery Genius Pro (2022)
+# with a Artillery_Ruby-v1.2 board. To use this config, during "make menuconfig"
+# select the STM32F401 with "No bootloader" and USB (on PA11/PA12)
+# communication.
+
+# To flash this firmware, set the physical bridge between +3.3V and Boot0 PIN
+# on Artillery_Ruby mainboard. Then run the command:
+#   make flash FLASH_DEVICE=/dev/serial/by-id/usb-Klipper_stm32f401xc_*-if00
+
+# See docs/Config_Reference.md for a description of parameters.
+
+[extruder]
+max_extrude_only_distance: 700.0
+step_pin: PA7
+dir_pin: PA6
+enable_pin: !PC4
+microsteps: 16
+rotation_distance: 7.1910
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PC9
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC0
+min_temp: 0
+max_temp: 250
+control: pid
+pid_Kp: 23.223
+pid_Ki: 1.518
+pid_Kd: 88.826
+
+[stepper_x]
+step_pin: !PB14
+dir_pin: PB13
+enable_pin: !PB15
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PA2
+position_endstop: 0
+position_max: 220
+homing_speed: 60
+
+[stepper_y]
+step_pin: PB10
+dir_pin: PB2
+enable_pin: !PB12
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PA1
+position_endstop: 0
+position_max: 220
+homing_speed: 60
+
+[stepper_z]
+step_pin: PB0
+dir_pin: !PC5
+enable_pin: !PB1
+microsteps: 16
+rotation_distance: 8
+endstop_pin: probe:z_virtual_endstop
+position_max: 250
+position_min: -5
+
+[heater_bed]
+heater_pin: PA8
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC1
+min_temp: 0
+max_temp: 130
+control: pid
+pid_Kp: 23.223
+pid_Ki: 1.518
+pid_Kd: 88.826
+
+[bed_screws]
+screw1: 38,45
+screw2: 180,45
+screw3: 180,180
+screw4: 38,180
+
+[fan]
+pin: PC8
+off_below: 0.1
+
+[heater_fan hotend_fan]
+pin: PC7
+heater: extruder
+heater_temp: 50.0
+
+[controller_fan stepper_fan]
+pin: PC6
+idle_timeout: 300
+
+[mcu]
+serial: /dev/serial/by-id/usb-Klipper_stm32f401xc_
+
+[printer]
+kinematics: cartesian
+max_velocity: 500
+max_accel: 4000
+max_z_velocity: 50
+square_corner_velocity: 5.0
+max_z_accel: 100
+
+[bltouch]
+sensor_pin: PC2
+control_pin: PC3
+x_offset:27.25
+y_offset:-12.8
+z_offset: 0.25
+speed:10
+samples:1
+samples_result:average
+
+[bed_mesh]
+speed: 800
+mesh_min: 30, 20
+mesh_max: 210, 200
+probe_count: 5,5
+algorithm: bicubic
+move_check_distance: 3.0
+
+[safe_z_home]
+home_xy_position: 110,110
+speed: 100
+z_hop: 10
+z_hop_speed: 5

config/printer-artillery-sidewinder-x3-plus-2024.cfg

@@ -0,0 +1,188 @@
+# For the Artillery Sidewinder X3 Pro/Plus that came factory installed with V1.29 firmware, follow these steps.
+#   - Compile with the processor model STM32F401.
+#   - Select the 48KiB bootloader,
+#   - Select USB PA11/PA12 for USB communication interface.
+#   - Select USART2 PA3/PA2 for UART communication via the Wi-Fi Tx/Rx pins
+# To set 48KiB bootloader, you need to make a change to make menuconfig Kconfig file
+# Here is a link to a how-to video: https://youtu.be/dpc76zN7Dh0
+# Rename klipper.bin to yuntu.bin
+# Copy the file out/yuntu.bin to an SD card and then restart the printer with that SD card
+#
+# For models that did not come with V1.29 installed
+#   - Compile with the processor model STM32F401.
+#   - Select the NO BOOTLOADER
+#   - Select USB PA11/PA12 for USB communication interface.
+#   - Select USART2 PA3/PA2 for UART communication via the Wi-Fi Tx/Rx pins
+#   - quit, save, make
+#   - Connect your printer to a computer running Pronterface, Octoprint, Repetier, BedLeveler5000 (anything with Console capability)
+#   - Power on the machine and send M997 through console into Marlin, this will put the board into "DFU" mode
+#   - DO NOT TURN OFF THE PRINTER
+#   - Connect your Linux/Klipper device to the USB port
+#   - Run lsusb and verify that the STM32 DFU device is visible (Bus 001 Device 006: ID 0483:df11 STMicroelectronics STM Device in DFU Mode)
+#   - Run sudo make flash 0483:df11
+#   - Run lsusb again and there should be two devices:
+#        Bus 001 Device 007: ID 1d50:614e OpenMoko, Inc. stm32f401xc
+#        Bus 001 Device 003: ID 0cf3:e010 Qualcomm Atheros Communications stm32f401xc
+# See docs/Config_Reference.md for a description of parameters.
+
+[mcu]
+serial: /dev/ttyACM0
+restart_method: command
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 15
+max_z_accel: 100
+square_corner_velocity: 5
+
+[led LED_Light]
+white_pin: PC2
+initial_white: 1.0
+
+[neopixel hotend_neopixel]
+pin: PD2
+color_order: GRB
+initial_RED: 1.0
+initial_GREEN: 1.0
+initial_BLUE: 1.0
+
+[stepper_x]
+step_pin: PA8
+dir_pin: PC9
+enable_pin: !PA15
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PB9
+position_min: 0
+position_endstop: 0
+position_max: 315
+homing_speed: 50
+
+[stepper_y]
+step_pin: PC7
+dir_pin: !PC6
+enable_pin: !PC8
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PB8
+position_endstop: 0
+position_max: 315
+homing_speed: 50
+
+[stepper_z]
+step_pin: PB10
+dir_pin: !PA4
+enable_pin: !PC4
+rotation_distance: 8
+microsteps: 16
+position_min: -1
+position_max: 400
+endstop_pin: probe:z_virtual_endstop # Use Z- as endstop
+#homing_speed: 10.0
+
+[extruder]
+max_extrude_only_distance: 100.0
+step_pin: PC11
+dir_pin: !PC10
+enable_pin: !PC12
+microsteps: 64
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PA6
+sensor_type: EPCOS 100K B57560G104F #Generic 3950
+sensor_pin: PC5
+min_extrude_temp: 170
+min_temp: 0
+max_temp: 300
+# Calibrate E-Steps https://www.klipper3d.org/Rotation_Distance.html#calibrating-rotation_distance-on-extruders
+rotation_distance: 17.75
+# Calibrate PID: https://www.klipper3d.org/Config_checks.html#calibrate-pid-settings
+#  - Example: PID_CALIBRATE HEATER=extruder TARGET=200
+control: pid
+pid_kp: 30.356
+pid_ki: 1.857
+pid_kd: 124.081
+# Calibrate PA: https://www.klipper3d.org/Pressure_Advance.html
+
+[heater_bed]
+heater_pin: PA7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC0
+max_temp: 100
+min_temp: 0
+# Calibrate PID: https://www.klipper3d.org/Config_checks.html#calibrate-pid-settings
+#  - Example: PID_CALIBRATE HEATER=heater_bed TARGET=60
+control: pid
+pid_kp: 64.230
+pid_ki: 0.723
+pid_kd: 1425.905
+
+[heater_fan hotend_fan]
+pin: PB1
+heater: extruder
+heater_temp: 50.0
+
+[fan]
+pin: PB0
+
+[temperature_fan Artillery_MCU]
+sensor_type: temperature_mcu
+pin: PA5
+max_temp: 60.0
+target_temp: 40.0
+min_temp: 0
+shutdown_speed: 0.0
+kick_start_time: 0.5
+off_below: 0.19
+max_speed: 1.0
+min_speed: 0.0
+control: watermark
+
+[filament_switch_sensor filament_sensor]
+pause_on_runout: true
+switch_pin: PC1
+
+[probe]
+pin: PC14
+x_offset:45.2
+y_offset:11.6
+speed:5
+lift_speed:15
+z_offset: 2.350
+
+[safe_z_home]
+home_xy_position: 110, 145 #   X, Y coordinate (e.g. 100, 100) where the Z homing should be
+speed: 300.0
+z_hop: 10
+z_hop_speed: 15.0
+
+[bed_mesh]
+speed: 300
+horizontal_move_z: 6
+mesh_min: 46,15
+mesh_max: 300,300
+probe_count: 10, 10
+fade_start: 1.0
+fade_end: 0.0
+algorithm: bicubic
+
+[screws_tilt_adjust]
+screw1: 120, 153
+screw1_name: center reference
+screw2: 7, 45
+screw2_name: front left
+screw3: 210, 45
+screw3_name: front right
+screw4: 227, 145
+screw4_name: right center
+screw5: 210, 245
+screw5_name: rear right
+screw6: 7, 245
+screw6_name: rear left
+screw7: 7, 145
+screw7_name: left center
+horizontal_move_z: 8
+speed: 300
+screw_thread: CW-M4

config/printer-creality-cr10-v3-2020.cfg

@@ -43,7 +43,7 @@ position_max: 400
 #Uncomment if you have a BL-Touch:
 #position_min: -4
 #endstop_pin: probe:z_virtual_endstop
-#and comment the follwing lines:
+#and comment the following lines:
 position_endstop: 0.0
 endstop_pin: ^PD3 #ar18
 

config/printer-creality-cr30-2021.cfg

@@ -98,7 +98,6 @@ max_temp: 100
 
 [output_pin led]
 pin: PC14
-static_value: 0
 
 # Neopixel LED support
 # [neopixel led_neopixel]

config/printer-creality-cr6se-2020.cfg

@@ -1,4 +1,5 @@
-# This file contains pin mappings for the stock 2020 Creality CR6-SE.
+# This file contains pin mappings for the stock 2020 Creality CR6-SE
+# with the early 4.5.2 board only.
 # To use this config, during "make menuconfig" select the STM32F103
 # with a "28KiB bootloader" and serial (on USART1 PA10/PA9)
 # communication.
@@ -98,6 +99,10 @@ z_offset: 0.0
 speed: 2.0
 samples: 5
 
+[safe_z_home]
+home_xy_position: 117, 117
+z_hop: 10
+
 [filament_switch_sensor filament_sensor]
 pause_on_runout: true
 switch_pin: ^!PA7

config/printer-creality-cr6se-2021.cfg

@@ -1,4 +1,6 @@
-# This file contains pin mappings for the Creality CR6-SE with Rev. 4.5.3 Motherboard (Late 2020/2021) as the heater pins changed.
+# This file contains pin mappings for the Creality CR6-SE
+# with Rev. 4.5.3 Motherboard (Late 2020/2021) as the heater pins changed.
+# This config also works for the CR-ERA_V1.1.0.3
 # To use this config, during "make menuconfig" select the STM32F103
 # with a "28KiB bootloader" and serial (on USART1 PA10/PA9)
 # communication.
@@ -98,6 +100,10 @@ z_offset: 0.0
 speed: 2.0
 samples: 5
 
+[safe_z_home]
+home_xy_position: 117, 117
+z_hop: 10
+
 [filament_switch_sensor filament_sensor]
 pause_on_runout: true
 switch_pin: ^!PA7

config/printer-creality-ender5-s1-2023.cfg

@@ -0,0 +1,170 @@
+# Creality Ender 5 S1 (HW version: CR4NS200141C13)
+#
+# printer_size: 220x220x280
+# To use this config, during "make menuconfig" select the STM32F401
+# with a "64KiB bootloader" and serial (on USART1 PA10/PA9)
+# communication.
+#
+# Flash this firmware by creating a directory named "STM32F4_UPDATE"
+# on an SD card, copying the "out/klipper.bin" to it and then turn
+# on the printer with the card inserted. The firmware filename must
+# end in ".bin" and must not match the last filename that was flashed.
+#
+# See docs/Config_Reference.md for a description of parameters.
+
+[stepper_x]
+step_pin: PC2
+dir_pin: !PB9
+enable_pin: !PC3
+rotation_distance: 40
+microsteps: 16
+endstop_pin: !PA5
+position_endstop: 220
+position_max: 222
+homing_speed: 80
+
+[stepper_y]
+step_pin: PB8
+dir_pin: !PB7
+enable_pin: !PC3
+rotation_distance: 40
+microsteps: 16
+endstop_pin: !PA6
+position_endstop: 220
+position_max: 220
+homing_speed: 80
+
+[stepper_z]
+step_pin: PB6
+dir_pin: PB5
+enable_pin: !PC3
+rotation_distance: 8
+microsteps: 16
+endstop_pin: probe:z_virtual_endstop
+position_max: 280
+homing_speed: 20
+second_homing_speed: 1
+homing_retract_dist: 2.0
+
+[extruder]
+step_pin: PB4
+dir_pin: PB3
+enable_pin: !PC3
+rotation_distance: 7.5
+microsteps: 16
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PA1
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid  # tuned for stock hardware with 210 degree Celsius target
+pid_kp: 20.749
+pid_ki: 1.064
+pid_kd: 101.153
+min_temp: 0
+max_temp: 305
+
+[heater_bed]
+heater_pin: PA7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid  # tuned for stock hardware with 60 degree Celsius target
+pid_kp: 66.566
+pid_ki: 0.958
+pid_kd: 1155.761
+min_temp: 0
+max_temp: 110
+
+# Part cooling fan
+[fan]
+pin: PA0
+kick_start_time: 0.5
+
+# Hotend fan
+# set fan running when extruder temperature is over 60
+[heater_fan heatbreak_fan]
+pin: PC0
+heater:extruder
+heater_temp: 60
+fan_speed: 0.8
+
+[filament_switch_sensor filament_sensor]
+pause_on_runout: true
+switch_pin: ^!PC15
+
+# Stock CR Touch bed sensor
+[bltouch]
+sensor_pin: ^PC14
+control_pin: PC13
+x_offset: -13
+y_offset: 27
+z_offset: 2.0
+speed: 10
+stow_on_each_sample: true    # Occasional bed crashes when false
+samples: 4
+sample_retract_dist: 2
+samples_result: average
+probe_with_touch_mode: true
+
+[bed_mesh]
+speed: 150
+mesh_min: 3,28         # need to handle head distance with bl_touch
+mesh_max: 205,218
+mesh_pps: 3
+probe_count: 4,4
+fade_start: 1
+fade_end: 10
+fade_target: 0
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
+restart_method: command
+
+[safe_z_home]
+home_xy_position: 123,83
+speed: 200
+z_hop: 10
+z_hop_speed: 10
+
+# Many Ender 5 S1 printers appear to suffer from a slight twist
+# in the X axis.  This twist can be measured, and compensated for
+# using the AXIS_TWIST_COMPENSATION_CALIBRATE G-Code command.  See
+# https://www.klipper3d.org/Axis_Twist_Compensation.html for more
+# information.  This section provides the setup for this optional
+# calibration step.
+[axis_twist_compensation]
+calibrate_start_x: 3
+calibrate_end_x: 207
+calibrate_y: 110
+
+# Probe locations for assisted bed screw adjustment.
+[screws_tilt_adjust]
+screw1: 38,6
+screw1_name: Front Left Screw
+screw2: 215,6
+screw2_name: Front Right Screw
+screw3: 215,175
+screw3_name: Rear Right Screw
+screw4: 38,175
+screw4_name: Rear Left Screw
+horizontal_move_z: 5
+speed: 100
+screw_thread: CW-M4
+
+[bed_screws]
+screw1: 25,25
+screw1_name: Front Left Screw
+screw2: 195,25
+screw2_name: Front Right Screw
+screw3: 195,195
+screw3_name: Rear Right Screw
+screw4: 25,195
+screw4_name: Rear Left Screw
+
+[printer]
+kinematics: cartesian
+max_velocity: 300
+max_accel: 5000
+max_z_velocity: 5
+max_z_accel: 100
+square_corner_velocity: 5.0

config/printer-flashforge-creator-pro-2018.cfg

@@ -127,32 +127,32 @@ max_z_velocity: 5
 max_z_accel: 100
 
 [mcp4018 x_axis_pot]
-scl_pin: PJ5
-sda_pin: PF3
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PF3
 wiper: 118
 scale: 127
 
 [mcp4018 y_axis_pot]
-scl_pin: PJ5
-sda_pin: PF7
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PF7
 wiper: 118
 scale: 127
 
 [mcp4018 z_axis_pot]
-scl_pin: PJ5
-sda_pin: PK3
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PK3
 wiper: 40
 scale: 127
 
 [mcp4018 a_axis_pot]
-scl_pin: PJ5
-sda_pin: PA5
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PA5
 wiper: 118
 scale: 127
 
 [mcp4018 b_axis_pot]
-scl_pin: PJ5
-sda_pin: PJ6
+i2c_software_scl_pin: PJ5
+i2c_software_sda_pin: PJ6
 wiper: 118
 scale: 127
 

config/printer-geeetech-301-2019.cfg

@@ -71,25 +71,21 @@ pid_Kp: 39
 pid_Ki: 2
 pid_Kd: 210
 
-[extruder1]
+[extruder_stepper e1]
+extruder:
 step_pin: PA0
 dir_pin: !PB6
 enable_pin: !PA1
 microsteps: 16
 rotation_distance: 32
-nozzle_diameter: 0.4
-filament_diameter: 1.75
-shared_heater: extruder
 
-[extruder2]
+[extruder_stepper e2]
+extruder:
 step_pin: PB2
 dir_pin: !PB11
 enable_pin: !PC4
 microsteps: 16
 rotation_distance: 32
-nozzle_diameter: 0.4
-filament_diameter: 1.75
-shared_heater: extruder
 
 [heater_bed]
 heater_pin: PB1

config/printer-geeetech-A10T-A20T-2021.cfg

@@ -0,0 +1,256 @@
+# This file contains common pin mappings for the Geeetech GT2560 v4.0 and v4.1b
+# boards. These boards use a firmware compiled for the AVR atmega2560.
+# For default Geeetech A10/A20  (1 extruder),
+#                      A10M/A20M (mixing 2 in 1 out),
+#                      A10T/A20T (mixing 3 in 1 out) printers
+# Installation: https://www.klipper3d.org/Installation.html
+# Always read for first start: https://www.klipper3d.org/Config_checks.html
+
+[mcu]
+# Might need to be changed: https://www.klipper3d.org/Installation.html
+serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
+
+[printer]
+kinematics: cartesian
+max_velocity: 200
+max_accel: 1500
+max_z_velocity: 20
+max_z_accel: 500
+
+# # uncomment for BLTouch/3DTouch
+# [bltouch]
+# sensor_pin: PC7 # there is an external pull up so no need in ^
+# control_pin: PB5
+# speed: 3.0
+# samples: 2
+# x_offset: -42.0
+# y_offset: -1.0
+#                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      z_offset: 1.0 # during calibration this line is commented out and new record added at the end of file
+
+[safe_z_home]
+home_xy_position: 100, 100  # Change coordinates to the center of your print bed
+speed: 50
+z_hop: 10  # Move up 10mm
+z_hop_speed: 5
+
+[stepper_x]
+enable_pin: !PC2
+dir_pin: !PG2
+step_pin: PC0
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PA2 # there are external pull ups
+position_endstop: 0
+position_max: 220 # for A10/M/T / change to 250 for A20/M/T
+homing_speed: 40
+
+[stepper_y]
+enable_pin: !PA7
+dir_pin: !PC4
+step_pin: PC6
+microsteps: 16
+rotation_distance: 40
+endstop_pin: !PA6 # there are external pull ups
+position_endstop: 0
+position_max: 220 # for A10/M/T / change to 250 for A20/M/T
+homing_speed: 40
+
+[stepper_z]
+enable_pin: !PA5
+dir_pin: PA1
+step_pin: PA3
+microsteps: 16
+rotation_distance: 8
+#endstop_pin: probe:z_virtual_endstop # uncomment for BLTouch/3DTouch
+endstop_pin: !PC7 # comment for BLTouch/3DTouch
+position_endstop: 0 # comment for BLTouch/3DTouch
+position_max: 230 # for A10/M/T / change to 250 for A20/M/T
+position_min: -5
+homing_speed: 20
+
+[extruder]
+enable_pin: !PB6
+dir_pin: PL5
+step_pin: PL3
+microsteps: 16
+rotation_distance: 8 # Needs to be optimized: https://www.klipper3d.org/Rotation_Distance.html#calibrating-rotation_distance-on-extruders
+nozzle_diameter: 0.4
+filament_diameter: 1.750
+heater_pin: PB4
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK3
+min_temp: 0
+max_temp: 250
+max_extrude_only_distance: 200.0
+# Parameters for stock hotend on A10M
+# Please recalibrate according to https://www.klipper3d.org/Config_checks.html#calibrate-pid-settings
+control: pid
+pid_kp: 54.722
+pid_ki: 4.800
+pid_kd: 155.958
+
+[extruder_stepper extruder_1]
+extruder:
+enable_pin: !PL1
+dir_pin: PL2
+step_pin: PL0
+microsteps: 16
+rotation_distance: 8 # Needs to be optimized: https://www.klipper3d.org/Rotation_Distance.html#calibrating-rotation_distance-on-extruders
+
+[extruder_stepper extruder_2]
+extruder:
+enable_pin: !PG0
+dir_pin: PL4
+step_pin: PL6
+microsteps: 16
+rotation_distance: 8 # Needs to be optimized: https://www.klipper3d.org/Rotation_Distance.html#calibrating-rotation_distance-on-extruders
+
+[heater_bed]
+heater_pin: PG5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK2
+min_temp: 0
+max_temp: 120
+# Parameters for `SuperPlate` on A10M
+# Please recalibrate according to https://www.klipper3d.org/Config_checks.html#calibrate-pid-settings
+control: pid
+pid_kp: 70.936
+pid_ki: 1.785
+pid_kd: 704.924
+
+[fan]
+pin: PH6
+cycle_time: 0.150
+kick_start_time: 0.300
+
+# # for GT2560V4.0 with 20pin flat cable toward the display
+# [display]
+# lcd_type: hd44780
+# hd44780_protocol_init: True
+# rs_pin: PD1
+# e_pin: PH0
+# d4_pin: PH1
+# d5_pin: PD0
+# d6_pin: PE3
+# d7_pin: PC1
+# encoder_pins: ^PG1, ^PL7
+# click_pin: ^!PD2
+
+
+# for GT2560V4.1B with 12pin flat cable toward the display YHCB2004-06 ver3.0
+# the aip31068_spi driver was added to Klipper on 2024-12-02, commit aecb29d2
+[display]
+lcd_type: aip31068_spi
+latch_pin: PE3
+spi_software_sclk_pin: PD0
+spi_software_mosi_pin: PC1
+spi_software_miso_pin: PH7 # any unused pin
+encoder_pins: ^PH0, ^PH1
+click_pin: ^!PD2
+
+
+[filament_switch_sensor sensor_e0]
+switch_pin: !PK4
+
+[filament_switch_sensor sensor_e1]
+switch_pin: !PK5
+
+[filament_switch_sensor sensor_e2]
+# switch_pin: !PE2 # for GT2560V4.0
+switch_pin: !PF0 # for GT2560V4.1B
+
+# to enable M118 echo command
+[respond]
+
+# Specific macros for mixing colors.
+# Add in slicer new filament color and in filament start G-Code add desired mixing factor:
+#     M163 S0 P50 ; set extruder 0 to 50%
+#     M163 S1 P40 ; set extruder 1 to 40%
+#     M163 S2 P10 ; set extruder 2 to 10%
+#     M164 ; commit the mix factors
+[gcode_macro M163]
+description:  M163 [P<factor>] [S<index>] Set a single mix factor (in proportion to the sum total of all mix factors). The mix must be committed to a virtual tool by M164 before it takes effect.
+gcode:
+    {% if 'P' in params %}
+            {% set s = params.S|default(0)| int %}
+            {% if s == 0 %}
+                SET_GCODE_VARIABLE MACRO=M164 VARIABLE=e0_parts VALUE={params.P|default(0)|float}
+                M118 Set Mixing factor for extruder 0 to {params.P|default(0)|float}
+            {% elif s == 1 %}
+                SET_GCODE_VARIABLE MACRO=M164 VARIABLE=e1_parts VALUE={params.P|default(0)|float}
+                M118 Set Mixing factor for extruder 1 to {params.P|default(0)|float}
+            {% elif s == 2 %}
+                SET_GCODE_VARIABLE MACRO=M164 VARIABLE=e2_parts VALUE={params.P|default(0)|float}
+                M118 Set Mixing factor for extruder 2 to {params.P|default(0)|float}
+            {% endif %}
+    {% else %}
+        M118 No Mixing factor set, missing value for P
+    {% endif %}
+    M118 {e0_parts} {e1_parts} {e2_parts}
+
+
+[gcode_macro M164]
+description: Applies the set mixing factors to the extruders
+# default values:
+variable_e0_parts : 100
+variable_e1_parts : 0
+variable_e2_parts : 0
+gcode:
+    # normalize the parts to sum of 1
+    {% set e0 = e0_parts / (e0_parts + e1_parts + e2_parts) | float %}
+    {% set e1 = e1_parts / (e0_parts + e1_parts + e2_parts) | float %}
+    {% set e2 = e2_parts / (e0_parts + e1_parts + e2_parts) | float %}
+    M118 scaled rot-dist_e0 { printer.configfile.settings.extruder.rotation_distance / (e0 + 0.000001) | float }
+    M118 scaled rot-dist_e1 { printer.configfile.settings['extruder_stepper extruder_1'].rotation_distance / (e1 + 0.000001) | float }
+    M118 scaled rot-dist_e2 { printer.configfile.settings['extruder_stepper extruder_2'].rotation_distance / (e2 + 0.000001) |float }
+    # activate stepper percentages
+    SYNC_EXTRUDER_MOTION EXTRUDER=extruder MOTION_QUEUE=extruder
+    SYNC_EXTRUDER_MOTION EXTRUDER=extruder_1 MOTION_QUEUE=extruder
+    SYNC_EXTRUDER_MOTION EXTRUDER=extruder_2 MOTION_QUEUE=extruder
+    SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder DISTANCE={ printer.configfile.settings.extruder.rotation_distance / (e0+0.000001)|float }
+    SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder_1 DISTANCE={ printer.configfile.settings['extruder_stepper extruder_1'].rotation_distance / (e1+0.000001)|float }
+    SET_EXTRUDER_ROTATION_DISTANCE EXTRUDER=extruder_2 DISTANCE={ printer.configfile.settings['extruder_stepper extruder_2'].rotation_distance / (e2+0.000001)|float }
+    M118 Mixing factors {e0} {e1} {e2} are activated
+
+# In PrusaSlicer:
+#    - you can add as many extruders as mixing ratios you want
+#    - in Printer Settings -> Custom G-code -> Tool change G-code add:
+#        TOOL_CHANGE EXTRUDER={next_extruder}
+#    - in this config file add:
+#           [gcode_macro TOOL_CHANGE]
+#           description: Tool change macro with mix ratio setup for 11 extruders
+#           variable_extruder: 0
+#           gcode:
+#               {% set extruder = params.EXTRUDER|default(0)| int %}
+#               {% if extruder == 0 %}
+#                   M163 S0 P100
+#                   M163 S1 P0
+#                   M163 S2 P0
+#                   M164
+#                   M118 Switching to Extruder 0
+#               {% elif extruder == 1 %}
+#                   M163 S0 P90
+#                   M163 S1 P10
+#                   M163 S2P0
+#                   M164
+#                   M118 Switching to Extruder 1
+#               {% elif extruder == 2 %}
+#                   # and so on ...
+#               {% else %}
+#                   M118 Unknown extruder number: {extruder}
+#               {% endif %}
+
+# In OrcaSlicer:
+# you can add as many filaments as mixing ratios you want
+# in Material settings -> Advanced -> Filament start G-code add desired mixing ratio:
+#    ; filament start gcode
+#    M163 S0 P100 ; set extruder 0
+#    M163 S1 P0 ; set extruder 1
+#    M163 S2 P0 ; set extruder 2
+#    M164 ; commit the mix factors
+
+# For gradient over Z axis:
+# In `Printer -> Custom G-code -> After layer change G-code` add:
+#     M163 S0 P{ layer_num * 100 / total_layer_count } ; Gradient 0-100
+#     M163 S1 P{(total_layer_count-layer_num) * 100 / total_layer_count} ; Gradient 100-0
+#     M164 ; commit the mix factors

config/printer-lulzbot-mini1-2016.cfg

@@ -125,7 +125,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.300
+value: 1.300
 
 [output_pin stepper_z_current]
 pin: PL4
@@ -133,7 +133,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.630
+value: 1.630
 
 [output_pin stepper_e_current]
 pin: PL5
@@ -141,7 +141,7 @@ pwm: True
 scale: 2.0
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.250
+value: 1.250
 
 [static_digital_output stepper_config]
 # Microstepping pins
@@ -195,7 +195,7 @@ samples_tolerance: 0.200
 samples_tolerance_retries: 2
 
 [bed_tilt]
-# Enable bed tilt measurments using the probe we defined above
+# Enable bed tilt measurements using the probe we defined above
 # Probe points using X0 Y0 offsets @ 0.01mm/step
 points: -2, -6
         156, -6

config/printer-lulzbot-taz6-dual-v3-2017.cfg

@@ -183,7 +183,7 @@ samples: 2
 samples_tolerance: 0.100
 
 [bed_tilt]
-#Enable bed tilt measurments using the probe we defined above
+#Enable bed tilt measurements using the probe we defined above
 #Probe points using X0 Y0 offsets @ 0.01mm/step
 points: -3, -6
         282, -6

config/printer-modix-big60-2020.cfg

@@ -199,7 +199,6 @@ algorithm: bicubic
 bicubic_tension: 0.15
 fade_start: 0.5
 fade_end: 2.5
-relative_reference_index: 60
 
 [bed_screws]
 screw1: 0,0

config/printer-robo3d-r2-2017.cfg

@@ -37,7 +37,7 @@ microsteps: 16
 rotation_distance: 4
 # Required if not using probe for the virtual endstop
 # endstop_pin: ^PD3
-# position_endstop: 250 # Will need ajustment
+# position_endstop: 250 # Will need adjustment
 endstop_pin: probe:z_virtual_endstop
 homing_speed: 10.0
 position_max: 250

config/printer-seemecnc-rostock-max-v2-2015.cfg

@@ -1,4 +1,4 @@
-# This file constains the pin mappings for the SeeMeCNC Rostock Max
+# This file contains 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.
 

config/printer-sovol-sv05-2022.cfg

@@ -19,7 +19,7 @@ restart_method: command
 kinematics: cartesian
 max_velocity: 300
 max_accel: 1000
-max_accel_to_decel: 1000
+minimum_cruise_ratio: 0.0
 max_z_velocity: 5
 max_z_accel: 100
 

config/printer-sovol-sv06-2022.cfg

@@ -28,7 +28,7 @@ microsteps: 16
 rotation_distance: 40
 endstop_pin: tmc2209_stepper_x:virtual_endstop
 position_endstop: 0
-position_max: 225
+position_max: 220
 homing_speed: 40
 homing_retract_dist: 0
 
@@ -50,7 +50,7 @@ microsteps: 16
 rotation_distance: 40
 endstop_pin: tmc2209_stepper_y:virtual_endstop
 position_endstop: 0
-position_max: 225
+position_max: 220
 homing_speed: 40
 homing_retract_dist: 0
 
@@ -72,7 +72,7 @@ microsteps: 16
 rotation_distance: 4
 endstop_pin: probe:z_virtual_endstop
 position_min: -4
-position_max: 261
+position_max: 250
 homing_speed: 4
 
 [tmc2209 stepper_z]
@@ -127,7 +127,7 @@ pin: PA0
 
 [probe]
 pin: PB1
-x_offset: 28
+x_offset: 27
 y_offset: -20
 z_offset: 0
 samples: 2

config/printer-sovol-sv06-plus-2023.cfg

@@ -0,0 +1,147 @@
+# This file contains pin mappings for the stock Sovol SV06 Plus
+# To use this config, during "make menuconfig" select the
+# STM32F103 with a "28KiB bootloader" and serial (on USART1 PA10/PA9) communication.
+# Also, since it is using the GD32F103, please select Disable SWD at startup
+#
+# Flash this firmware by copying "out/klipper.bin" to a SD card and
+# turning on the printer with the card inserted. The firmware
+# filename must end in ".bin" and must not match the last filename
+# that was flashed.
+#
+# Note: The stock LCD display does not currently work with Klipper
+#
+# See docs/Config_Reference.md for a description of parameters.
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
+restart_method: command
+
+[printer]
+kinematics: cartesian
+max_velocity: 500
+max_accel: 2000
+max_z_velocity: 10
+max_z_accel: 100
+
+[stepper_x]
+step_pin: PC2
+dir_pin: !PB9
+enable_pin: !PC3
+microsteps: 16
+rotation_distance: 40
+endstop_pin: tmc2209_stepper_x:virtual_endstop
+position_endstop: 0
+position_max: 305
+homing_speed: 40
+homing_retract_dist: 0
+
+[tmc2209 stepper_x]
+uart_pin: PC1
+run_current: 0.860
+sense_resistor: 0.150
+uart_address: 3
+driver_SGTHRS: 86
+diag_pin: PA5
+
+[stepper_y]
+step_pin: PB8
+dir_pin: PB7
+enable_pin: !PC3
+microsteps: 16
+rotation_distance: 40
+endstop_pin: tmc2209_stepper_y:virtual_endstop
+position_endstop: 0
+position_max: 305
+homing_speed: 40
+homing_retract_dist: 0
+
+[tmc2209 stepper_y]
+uart_pin: PC0
+run_current: 0.900
+sense_resistor: 0.150
+uart_address: 3
+driver_SGTHRS: 110
+diag_pin: PA6
+
+[stepper_z]
+step_pin: PB6
+dir_pin: !PB5
+enable_pin: !PC3
+microsteps: 16
+rotation_distance: 4
+endstop_pin: probe:z_virtual_endstop
+position_min: -4
+position_max: 350
+homing_speed: 4
+
+[tmc2209 stepper_z]
+uart_pin: PA15
+run_current: 1.000
+interpolate: False
+sense_resistor: 0.150
+uart_address: 3
+diag_pin: PA7
+
+[extruder]
+max_extrude_only_distance: 100.0
+step_pin: PB4
+dir_pin: !PB3
+enable_pin: !PC3
+microsteps: 16
+rotation_distance: 4.56
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PA1
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC5
+control: pid
+pid_kd: 41.96
+pid_kp: 15.66
+pid_ki: 1.49
+min_temp: 0
+max_temp: 300
+
+[tmc2209 extruder]
+uart_pin: PC14
+run_current: 0.550
+stealthchop_threshold: 0
+interpolate: False
+sense_resistor: 0.150
+uart_address: 3
+
+[heater_bed]
+heater_pin: PA2
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC4
+control: pid
+pid_kp: 186.38
+pid_ki: 36.12
+pid_kd: 637.30
+min_temp: 0
+max_temp: 130
+
+[fan]
+pin: PA0
+
+[probe]
+pin: PB1
+x_offset: 28
+y_offset: -20
+z_offset: 0
+
+[safe_z_home]
+home_xy_position: 123,170
+z_hop: 10
+z_hop_speed: 5
+
+[bed_mesh]
+speed: 120
+mesh_min: 28, 20
+mesh_max: 270, 270
+probe_count: 5
+algorithm: bicubic
+fade_end: 10
+fade_target: 0
+
+[filament_switch_sensor filament_runout_sensor]
+switch_pin: PA4
+pause_on_runout: True

config/printer-tronxy-crux1-2022.cfg

@@ -0,0 +1,138 @@
+# Klipper configuration for the TronXY Crux1 printer
+# CXY-V10.1-220921 mainboard, GD32F4XX or STM32F446 MCU
+#
+# =======================
+# BUILD AND FLASH OPTIONS
+# =======================
+#
+# MCU-architecture:  STMicroelectronics
+# Processor model:   STM32F446
+# Bootloader offset: 64KiB
+# Comms interface:   Serial on USART1 PA10/PA9
+#
+# Build the firmware with these options
+# Rename the resulting klipper.bin into fmw_tronxy.bin
+# Put the file into a directory called "update" on a FAT32 formatted SD card.
+# Turn off the printer, plug in the SD card and turn the printer back on
+# Flashing will start automatically and progress will be indicated on the LCD
+# Once the flashing is completed the display will get stuck on the white Tronxy logo bootscreen
+# The LCD display will NOT work anymore after flashing Klipper onto this printer
+
+[mcu]
+serial: /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
+restart_method: command
+
+[printer]
+kinematics: cartesian
+max_velocity: 250
+max_accel: 1500
+square_corner_velocity: 5
+max_z_velocity: 15
+max_z_accel: 100
+
+[controller_fan drivers_fan]
+pin: PD7
+
+[pwm_cycle_time BEEPER_pin]
+pin: PA8
+value: 0
+shutdown_value: 0
+cycle_time: 0.001
+
+[safe_z_home]
+home_xy_position: 0, 0
+speed: 100
+z_hop: 10
+z_hop_speed: 5
+
+[stepper_x]
+step_pin: PE5
+dir_pin: PF1
+enable_pin: !PF0
+microsteps: 16
+rotation_distance: 20
+endstop_pin: ^!PC15
+position_endstop: -1
+position_min: -1
+position_max: 180
+homing_speed: 100
+homing_retract_dist: 10
+second_homing_speed: 25
+
+[stepper_y]
+step_pin: PF9
+dir_pin: !PF3
+enable_pin: !PF5
+microsteps: 16
+rotation_distance: 20
+endstop_pin: ^!PC14
+position_endstop: -3
+position_min: -3
+position_max: 180
+homing_retract_dist: 10
+homing_speed: 100
+second_homing_speed: 25
+
+[stepper_z]
+step_pin: PA6
+dir_pin: !PF15
+enable_pin: !PA5
+microsteps: 16
+rotation_distance: 4
+endstop_pin: ^!PC13
+position_endstop: 0
+position_max: 180
+position_min: 0
+
+[extruder]
+step_pin: PB1
+dir_pin: PF13
+enable_pin: !PF14
+microsteps: 16
+rotation_distance: 16.75
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PG7
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC3
+control: pid
+pid_kp: 22.2
+pid_ki: 1.08
+pid_kd: 114.00
+min_temp: 0
+max_temp: 250
+min_extrude_temp: 170
+max_extrude_only_distance: 450
+
+[heater_fan hotend_fan]
+heater: extruder
+heater_temp: 50.0
+pin: PG9
+
+[fan]
+pin: PG0
+
+[filament_switch_sensor filament_sensor]
+pause_on_runout: True
+switch_pin: ^!PE6
+
+[heater_bed]
+heater_pin: PE2
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PC2
+min_temp: 0
+max_temp: 130
+control: pid
+pid_kp: 10.00
+pid_ki: 0.023
+pid_kd: 305.4
+
+[bed_screws]
+screw1: 17.5, 11
+screw1_name: front_left
+screw2: 162.5, 11
+screw2_name: front_right
+screw3: 162.5, 162.5
+screw3_name: back_right
+screw4: 17.5, 162.5
+screw4_name: back_left

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

@@ -86,7 +86,7 @@ pwm: True
 scale: 2.782
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.2
+value: 1.2
 
 [output_pin stepper_z_current]
 pin: PL4
@@ -94,7 +94,7 @@ pwm: True
 scale: 2.782
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.2
+value: 1.2
 
 [output_pin stepper_e_current]
 pin: PL3
@@ -102,7 +102,7 @@ pwm: True
 scale: 2.782
 cycle_time: .000030
 hardware_pwm: True
-static_value: 1.0
+value: 1.0
 
 [display]
 lcd_type: ssd1306

config/sample-corexyuv.cfg

@@ -0,0 +1,177 @@
+# This file contains a configuration snippet for a CoreXYUV
+# printer with an independent dual extruder moving over X and Y axes.
+
+# See docs/Config_Reference.md for a description of parameters.
+
+[carriage x]
+position_endstop: 0
+position_max: 300
+homing_speed: 50
+endstop_pin: ^PE5
+
+[carriage y]
+position_endstop: 0
+position_max: 200
+homing_speed: 50
+endstop_pin: ^PJ1
+
+[dual_carriage u]
+primary_carriage: x
+safe_distance: 70
+position_endstop: 300
+position_max: 300
+homing_speed: 50
+endstop_pin: ^PE4
+
+[dual_carriage v]
+primary_carriage: y
+safe_distance: 50
+position_endstop: 200
+position_max: 200
+homing_speed: 50
+endstop_pin: ^PD4
+
+[stepper a]
+carriages: x+y
+step_pin: PF0
+dir_pin: PF1
+enable_pin: !PD7
+microsteps: 16
+rotation_distance: 40
+
+[stepper b]
+carriages: u-v
+step_pin: PH1
+dir_pin: PH0
+enable_pin: !PA1
+microsteps: 16
+rotation_distance: 40
+
+[stepper c]
+carriages: x-y
+step_pin: PF6
+dir_pin: !PF7
+enable_pin: !PF2
+microsteps: 16
+rotation_distance: 40
+
+[stepper d]
+carriages: u+v
+step_pin: PE3
+dir_pin: !PH6
+enable_pin: !PG5
+microsteps: 16
+rotation_distance: 40
+
+[extruder]
+step_pin: PA4
+dir_pin: PA6
+enable_pin: !PA2
+microsteps: 16
+rotation_distance: 33.5
+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
+
+[gcode_macro PARK_extruder]
+gcode:
+    SET_DUAL_CARRIAGE CARRIAGE=x
+    SET_DUAL_CARRIAGE CARRIAGE=y
+    G90
+    G1 X0 Y0
+
+[gcode_macro T0]
+gcode:
+    PARK_{printer.toolhead.extruder}
+    ACTIVATE_EXTRUDER EXTRUDER=extruder
+    SET_DUAL_CARRIAGE CARRIAGE=x
+    SET_DUAL_CARRIAGE CARRIAGE=y
+
+[extruder1]
+step_pin: PC1
+dir_pin: PC3
+enable_pin: !PC7
+microsteps: 16
+rotation_distance: 33.5
+nozzle_diameter: 0.400
+filament_diameter: 1.750
+heater_pin: PB5
+sensor_type: EPCOS 100K B57560G104F
+sensor_pin: PK7
+control: pid
+pid_Kp: 22.2
+pid_Ki: 1.08
+pid_Kd: 114
+min_temp: 0
+max_temp: 250
+
+[gcode_macro PARK_extruder1]
+gcode:
+    SET_DUAL_CARRIAGE CARRIAGE=u
+    SET_DUAL_CARRIAGE CARRIAGE=v
+    G90
+    G1 X300 Y200
+
+[gcode_macro T1]
+gcode:
+    PARK_{printer.toolhead.extruder}
+    ACTIVATE_EXTRUDER EXTRUDER=extruder1
+    SET_DUAL_CARRIAGE CARRIAGE=u
+    SET_DUAL_CARRIAGE CARRIAGE=v
+
+# A helper script to activate copy mode
+[gcode_macro ACTIVATE_COPY_MODE]
+gcode:
+    SET_DUAL_CARRIAGE CARRIAGE=x MODE=PRIMARY
+    SET_DUAL_CARRIAGE CARRIAGE=y MODE=PRIMARY
+    G1 X0 Y0
+    ACTIVATE_EXTRUDER EXTRUDER=extruder
+    SET_DUAL_CARRIAGE CARRIAGE=u MODE=PRIMARY
+    SET_DUAL_CARRIAGE CARRIAGE=v MODE=PRIMARY
+    G1 X150 Y100
+    SET_DUAL_CARRIAGE CARRIAGE=u MODE=COPY
+    SET_DUAL_CARRIAGE CARRIAGE=v MODE=COPY
+    SYNC_EXTRUDER_MOTION EXTRUDER=extruder1 MOTION_QUEUE=extruder
+
+# A helper script to activate mirror mode
+[gcode_macro ACTIVATE_MIRROR_MODE]
+gcode:
+    SET_DUAL_CARRIAGE CARRIAGE=x MODE=PRIMARY
+    SET_DUAL_CARRIAGE CARRIAGE=y MODE=PRIMARY
+    G1 X0 Y0
+    ACTIVATE_EXTRUDER EXTRUDER=extruder
+    SET_DUAL_CARRIAGE CARRIAGE=u MODE=PRIMARY
+    SET_DUAL_CARRIAGE CARRIAGE=v MODE=PRIMARY
+    G1 X300 Y100
+    SET_DUAL_CARRIAGE CARRIAGE=u MODE=MIRROR
+    SET_DUAL_CARRIAGE CARRIAGE=v MODE=COPY
+    SYNC_EXTRUDER_MOTION EXTRUDER=extruder1 MOTION_QUEUE=extruder
+
+[printer]
+kinematics: generic_cartesian
+max_velocity: 300
+max_accel: 3000
+max_z_velocity: 5
+max_z_accel: 100
+
+## An optional input shaper support
+#[input_shaper]
+## The section is intentionally empty
+#
+#[delayed_gcode init_shaper]
+#initial_duration: 0.1
+#gcode:
+#    SET_DUAL_CARRIAGE CARRIAGE=u
+#    SET_DUAL_CARRIAGE CARRIAGE=v
+#    SET_INPUT_SHAPER SHAPER_TYPE_X=<dual_carriage_x_shaper> SHAPER_FREQ_X=<dual_carriage_x_freq> SHAPER_TYPE_Y=<dual_carriage_y_shaper> SHAPER_FREQ_Y=<dual_carriage_y_freq>
+#    SET_DUAL_CARRIAGE CARRIAGE=x MODE=PRIMARY
+#    SET_DUAL_CARRIAGE CARRIAGE=y MODE=PRIMARY
+#    SET_INPUT_SHAPER SHAPER_TYPE_X=<primary_carriage_x_shaper> SHAPER_FREQ_X=<primary_carriage_x_freq> SHAPER_TYPE_Y=<primary_carriage_y_shaper> SHAPER_FREQ_Y=<primary_carriage_y_freq>

config/sample-duet3-1lc.cfg

@@ -6,7 +6,7 @@
 # Communication interface of "CAN bus (on PA25/PA24)"
 
 # To flash the board use a debugger, or use a raspberry pi and follow
-# the instructions at docs/Bootloaders.md fot the SAMC21. You may
+# the instructions at docs/Bootloaders.md for the SAMC21. You may
 # supply power to the 1LC by connecting the 3.3v rail on the Pi to the
 # 5v input of the SWD header on the 1LC.
 
@@ -77,5 +77,14 @@ heater_temp: 50.0
 pin: toolboard:PA9
 z_offset: 20
 
+[samd_sercom sercom_i2c]
+sercom: sercom1
+tx_pin: toolboard:PA16
+clk_pin: toolboard:PA17
+
+[lis3dh]
+i2c_mcu: toolboard
+i2c_bus: sercom1
+
 [mcu toolboard]
 canbus_uuid: 4b194673554e

config/sample-macros.cfg

@@ -61,12 +61,10 @@ gcode:
 #   P is the tone duration, S the tone frequency.
 # The frequency won't be pitch perfect.
 
-[output_pin BEEPER_pin]
+[pwm_cycle_time 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

config/sample-mmu2s-diy.cfg

@@ -96,7 +96,7 @@ switch_pin: !P1.28 # P1.28 for X-max
 # variable_pause_z               : z lift when MMU2S need intervention and the printer is paused
 # variable_min_temp_extruder     : minimal required heater temperature to load/unload filament from the extruder gear to the nozzle
 # variable_extruder_eject_temp   : heater temperature used to eject filament during home if the filament is already loaded
-# variable_enable_5in1           : pass from MMU2S standart (0) to MMU2S-5in1 mode with splitter
+# variable_enable_5in1           : pass from MMU2S standard (0) to MMU2S-5in1 mode with splitter
 #
 ################################
 [gcode_macro VAR_MMU2S]
@@ -394,7 +394,7 @@ gcode:
     {% endif %}
     {% endif %}
 
-# Retry unload, try correct misalignement of bondtech gear
+# Retry unload, try correct misalignment of bondtech gear
 [gcode_macro RETRY_UNLOAD_FILAMENT_IN_EXTRUDER]
 gcode:
     {% if printer["filament_switch_sensor ir_sensor"].filament_detected == True %}
@@ -444,7 +444,7 @@ gcode:
     {% endif %}
     {% endif %}
 
-# Ramming process for standart PLA, code extracted from slic3r gcode
+# Ramming process for standard PLA, code extracted from slic3r gcode
 [gcode_macro RAMMING_SLICER]
 gcode:
     G91

config/sample-pwm-tool.cfg

@@ -2,9 +2,8 @@
 # such as a laser or spindle.
 # See docs/Using_PWM_Tools.md for a more detailed description.
 
-[output_pin TOOL]
+[pwm_tool TOOL]
 pin: !ar9       # use your fan's pin number
-pwm: True
 hardware_pwm: True
 cycle_time: 0.001
 shutdown_value: 0
@@ -36,9 +35,9 @@ gcode:
 
 [menu __main __control __toolonoff]
 type: input
-enable: {'output_pin TOOL' in printer}
+enable: {'pwm_tool TOOL' in printer}
 name: Fan: {'ON ' if menu.input else 'OFF'}
-input: {printer['output_pin TOOL'].value}
+input: {printer['pwm_tool TOOL'].value}
 input_min: 0
 input_max: 1
 input_step: 1
@@ -47,9 +46,9 @@ gcode:
 
 [menu __main __control __toolspeed]
 type: input
-enable: {'output_pin TOOL' in printer}
+enable: {'pwm_tool TOOL' in printer}
 name: Tool speed: {'%3d' % (menu.input*100)}%
-input: {printer['output_pin TOOL'].value}
+input: {printer['pwm_tool TOOL'].value}
 input_min: 0
 input_max: 1
 input_step: 0.01

docs/API_Server.md

@@ -364,6 +364,43 @@ and might later produce asynchronous messages such as:
 The "header" field in the initial query response is used to describe
 the fields found in later "data" responses.
 
+### load_cell/dump_force
+
+This endpoint is used to subscribe to force data produced by a load_cell.
+Using this endpoint may increase Klipper's system load.
+
+A request may look like:
+`{"id": 123, "method":"load_cell/dump_force",
+"params": {"sensor": "load_cell", "response_template": {}}}`
+and might return:
+`{"id": 123,"result":{"header":["time", "force (g)", "counts", "tare_counts"]}}`
+and might later produce asynchronous messages such as:
+`{"params":{"data":[[3292.432935, 40.65, 562534, -234467]]}}`
+
+The "header" field in the initial query response is used to describe
+the fields found in later "data" responses.
+
+### load_cell_probe/dump_taps
+
+This endpoint is used to subscribe to details of probing "tap" events.
+Using this endpoint may increase Klipper's system load.
+
+A request may look like:
+`{"id": 123, "method":"load_cell/dump_force",
+"params": {"sensor": "load_cell", "response_template": {}}}`
+and might return:
+`{"id": 123,"result":{"header":["probe_tap_event"]}}`
+and might later produce asynchronous messages such as:
+```
+{"params":{"tap":'{
+   "time": [118032.28039, 118032.2834, ...],
+   "force": [-459.4213119680034, -458.1640702543264, ...],
+}}}
+```
+
+This data can be used to render:
+* The time/force graph
+
 ### pause_resume/cancel
 
 This endpoint is similar to running the "PRINT_CANCEL" G-Code command.
@@ -401,3 +438,130 @@ might return:
 
 As with the "gcode/script" endpoint, this endpoint only completes
 after any pending G-Code commands complete.
+
+### bed_mesh/dump_mesh
+
+Dumps the configuration and state for the current mesh and all
+saved profiles.
+
+For example:
+`{"id": 123, "method": "bed_mesh/dump_mesh"}`
+
+might return:
+
+```
+{
+    "current_mesh": {
+        "name": "eddy-scan-test",
+        "probed_matrix": [...],
+        "mesh_matrix": [...],
+        "mesh_params": {
+            "x_count": 9,
+            "y_count": 9,
+            "mesh_x_pps": 2,
+            "mesh_y_pps": 2,
+            "algo": "bicubic",
+            "tension": 0.5,
+            "min_x": 20,
+            "max_x": 330,
+            "min_y": 30,
+            "max_y": 320
+        }
+    },
+    "profiles": {
+        "default": {
+            "points": [...],
+            "mesh_params": {
+                "min_x": 20,
+                "max_x": 330,
+                "min_y": 30,
+                "max_y": 320,
+                "x_count": 9,
+                "y_count": 9,
+                "mesh_x_pps": 2,
+                "mesh_y_pps": 2,
+                "algo": "bicubic",
+                "tension": 0.5
+            }
+        },
+        "eddy-scan-test": {
+            "points": [...],
+            "mesh_params": {
+                "x_count": 9,
+                "y_count": 9,
+                "mesh_x_pps": 2,
+                "mesh_y_pps": 2,
+                "algo": "bicubic",
+                "tension": 0.5,
+                "min_x": 20,
+                "max_x": 330,
+                "min_y": 30,
+                "max_y": 320
+            }
+        },
+        "eddy-rapid-test": {
+            "points": [...],
+            "mesh_params": {
+                "x_count": 9,
+                "y_count": 9,
+                "mesh_x_pps": 2,
+                "mesh_y_pps": 2,
+                "algo": "bicubic",
+                "tension": 0.5,
+                "min_x": 20,
+                "max_x": 330,
+                "min_y": 30,
+                "max_y": 320
+            }
+        }
+    },
+    "calibration": {
+        "points": [...],
+        "config": {
+            "x_count": 9,
+            "y_count": 9,
+            "mesh_x_pps": 2,
+            "mesh_y_pps": 2,
+            "algo": "bicubic",
+            "tension": 0.5,
+            "mesh_min": [
+                20,
+                30
+            ],
+            "mesh_max": [
+                330,
+                320
+            ],
+            "origin": null,
+            "radius": null
+        },
+        "probe_path": [...],
+        "rapid_path": [...]
+    },
+    "probe_offsets": [
+        0,
+        25,
+        0.5
+    ],
+    "axis_minimum": [
+        0,
+        0,
+        -5,
+        0
+    ],
+    "axis_maximum": [
+        351,
+        358,
+        330,
+        0
+    ]
+}
+```
+
+The `dump_mesh` endpoint takes one optional parameter, `mesh_args`.
+This parameter must be an object, where the keys and values are
+parameters available to [BED_MESH_CALIBRATE](#bed_mesh_calibrate).
+This will update the mesh configuration and probe points using the
+supplied parameters prior to returning the result.   It is recommended
+to omit mesh parameters unless it is desired to visualize the probe points
+and/or travel path before performing `BED_MESH_CALIBRATE`.

docs/Axis_Twist_Compensation.md

@@ -1,6 +1,6 @@
 # Axis Twist Compensation
 
-This document describes the [axis_twist_compensation] module.
+This document describes the `[axis_twist_compensation]` module.
 
 Some printers may have a small twist in their X rail which can skew the results
 of a probe attached to the X carriage.
@@ -24,27 +24,50 @@ try to probe the bed without attaching the probe if you use it.
 > **Tip:** Make sure the [probe X and Y offsets](Config_Reference.md#probe) are
 > correctly set as they greatly influence calibration.
 
-1. After setting up the [axis_twist_compensation] module,
-perform `AXIS_TWIST_COMPENSATION_CALIBRATE`
-* The calibration wizard will prompt you to measure the probe Z offset at a few
-points along the bed
-* The calibration defaults to 3 points but you can use the option
-`SAMPLE_COUNT=` to use a different number.
-2. [Adjust your Z offset](Probe_Calibrate.md#calibrating-probe-z-offset)
-3. Perform automatic/probe-based bed tramming operations, such as
-[Screws Tilt Adjust](G-Codes.md#screws_tilt_adjust),
-[Z Tilt Adjust](G-Codes.md#z_tilt_adjust) etc
-4. Home all axis, then perform a [Bed Mesh](Bed_Mesh.md) if required
-5. Perform a test print, followed by any
-[fine-tuning](Axis_Twist_Compensation.md#fine-tuning) as desired
+### Basic Usage: X-Axis Calibration
+1. After setting up the `[axis_twist_compensation]` module, run:
+```
+AXIS_TWIST_COMPENSATION_CALIBRATE
+```
+This command will calibrate the X-axis by default.
+  - The calibration wizard will prompt you to measure the probe Z offset at
+    several points along the bed.
+  - By default, the calibration uses 3 points, but you can specify a different
+    number with the option:
+``
+SAMPLE_COUNT=<value>
+``
+
+2. **Adjust Your Z Offset:**
+After completing the calibration, be sure to
+[adjust your Z offset](Probe_Calibrate.md#calibrating-probe-z-offset).
+
+3. **Perform Bed Leveling Operations:**
+Use probe-based operations as needed, such as:
+  - [Screws Tilt Adjust](G-Codes.md#screws_tilt_adjust)
+  - [Z Tilt Adjust](G-Codes.md#z_tilt_adjust)
+
+4. **Finalize the Setup:**
+  - Home all axes, and perform a [Bed Mesh](Bed_Mesh.md) if necessary.
+  - Run a test print, followed by any
+    [fine-tuning](Axis_Twist_Compensation.md#fine-tuning)
+    if needed.
+
+### For Y-Axis Calibration
+The calibration process for the Y-axis is similar to the X-axis. To calibrate
+the Y-axis, use:
+```
+AXIS_TWIST_COMPENSATION_CALIBRATE AXIS=Y
+```
+This will guide you through the same measuring process as for the X-axis.
 
 > **Tip:** Bed temperature and nozzle temperature and size do not seem to have
 > an influence to the calibration process.
 
 ## [axis_twist_compensation] setup and commands
 
-Configuration options for [axis_twist_compensation] can be found in the
+Configuration options for `[axis_twist_compensation]` can be found in the
 [Configuration Reference](Config_Reference.md#axis_twist_compensation).
 
-Commands for [axis_twist_compensation] can be found in the
+Commands for `[axis_twist_compensation]` can be found in the
 [G-Codes Reference](G-Codes.md#axis_twist_compensation)

docs/Beaglebone.md

@@ -6,23 +6,64 @@ PRU.
 ## Building an OS image
 
 Start by installing the
-[Debian 9.9 2019-08-03 4GB SD IoT](https://beagleboard.org/latest-images)
+[Debian 11.7 2023-09-02 4GB microSD IoT](https://beagleboard.org/latest-images)
 image. 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
+password is `temppwd`).
+
+Before start installing Klipper you need to free-up additional space.
+there are 3 options to do that:
+1. remove some BeagleBone "Demo" resources
+2. if you did boot from SD-Card, and it's bigger than 4Gb - you can expand
+current filesystem to take whole card space
+3. do option #1 and #2 together.
+
+To remove some BeagleBone "Demo" resources execute these commands
+```
+sudo apt remove bb-node-red-installer
+sudo apt remove bb-code-server
+```
+
+To expand filesystem to full size of your SD-Card execute this command, reboot is not required.
+```
+sudo growpart /dev/mmcblk0 1
+sudo resize2fs /dev/mmcblk0p1
+```
+
+
+Install Klipper by running the following
 commands:
 
 ```
-git clone https://github.com/Klipper3d/klipper
+git clone https://github.com/Klipper3d/klipper.git
 ./klipper/scripts/install-beaglebone.sh
 ```
 
-## Install Octoprint
+After installing Klipper you need to decide what kind of deployment do you need,
+but take a note that BeagleBone is 3.3v based hardware and in most cases you can't
+directly connect pins to 5v or 12v based hardware without conversion boards.
 
-One may then install Octoprint:
+As Klipper have multimodule architecture on BeagleBone you can achieve many different use cases,
+but general ones are following:
+
+Use case 1: Use BeagleBone only as a host system to run Klipper and additional software
+like OctoPrint/Fluidd + Moonraker/...  and this configuration will be driving
+external micro-controllers via serial/usb/canbus connections.
+
+Use case 2: Use BeagleBone with extension board (cape) like CRAMPS board.
+in this configuration BeagleBone will host Klipper + additional software, and
+it will drive extension board with BeagleBone PRU cores (2 additional cores 200Mh, 32Bit).
+
+Use case 3: It's same as "Use case 1" but additionally you want to drive
+BeagleBone GPIOs with high speed by utilizing PRU cores to offload main CPU.
+
+
+## Installing Octoprint
+
+One may then install Octoprint or fully skip this section if desired other software:
 ```
 git clone https://github.com/foosel/OctoPrint.git
 cd OctoPrint/
@@ -51,25 +92,89 @@ Then start the Octoprint service:
 ```
 sudo systemctl start octoprint
 ```
-
-Make sure the OctoPrint web server is accessible - it should be at:
+Wait 1-2 minutes and 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":
+## Building the BeagleBone PRU micro-controller code (PRU firmware)
+This section is required for "Use case 2" and "Use case 3" mentioned above,
+you should skip it for "Use case 1".
+
+Check that required devices are present
+
+```
+sudo beagle-version
+```
+You should check that output contains successful "remoteproc" drivers loading and presence of PRU cores,
+in Kernel 5.10 they should be "remoteproc1" and "remoteproc2" (4a334000.pru, 4a338000.pru)
+Also check that many GPIOs are loaded they will look like "Allocated GPIO id=0 name='P8_03'"
+Usually everything is fine and no hardware configuration is required.
+If something is missing - try to play with "uboot overlays" options or with cape-overlays
+Just for reference some output of working BeagleBone Black configuration with CRAMPS board:
+```
+model:[TI_AM335x_BeagleBone_Black]
+UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
+UBOOT: Loaded Overlay:[BB-ADC-00A0.bb.org-overlays]
+UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0.bb.org-overlays]
+kernel:[5.10.168-ti-r71]
+/boot/uEnv.txt Settings:
+uboot_overlay_options:[enable_uboot_overlays=1]
+uboot_overlay_options:[disable_uboot_overlay_video=0]
+uboot_overlay_options:[disable_uboot_overlay_audio=1]
+uboot_overlay_options:[disable_uboot_overlay_wireless=1]
+uboot_overlay_options:[enable_uboot_cape_universal=1]
+pkg:[bb-cape-overlays]:[4.14.20210821.0-0~bullseye+20210821]
+pkg:[bb-customizations]:[1.20230720.1-0~bullseye+20230720]
+pkg:[bb-usb-gadgets]:[1.20230414.0-0~bullseye+20230414]
+pkg:[bb-wl18xx-firmware]:[1.20230414.0-0~bullseye+20230414]
+.............
+.............
+
+```
+
+To compile the Klipper micro-controller code, start by configuring it for the "Beaglebone PRU",
+for "BeagleBone Black" additionally disable options "Support GPIO Bit-banging devices" and disable "Support LCD devices"
+inside the "Optional features" because they will not fit in 8Kb PRU firmware memory,
+then exit and save config:
 ```
 cd ~/klipper/
 make menuconfig
 ```
 
-To build and install the new micro-controller code, run:
+To build and install the new PRU micro-controller code, run:
 ```
 sudo service klipper stop
 make flash
 sudo service klipper start
 ```
+After previous commands was executed your PRU firmware should be ready and started
+to check if everything was fine you can execute following command
+```
+dmesg
+```
+and compare last messages with sample one which indicate that everything started properly:
+```
+[   71.105499] remoteproc remoteproc1: 4a334000.pru is available
+[   71.157155] remoteproc remoteproc2: 4a338000.pru is available
+[   73.256287] remoteproc remoteproc1: powering up 4a334000.pru
+[   73.279246] remoteproc remoteproc1: Booting fw image am335x-pru0-fw, size 97112
+[   73.285807]  remoteproc1#vdev0buffer: registered virtio0 (type 7)
+[   73.285836] remoteproc remoteproc1: remote processor 4a334000.pru is now up
+[   73.286322] remoteproc remoteproc2: powering up 4a338000.pru
+[   73.313717] remoteproc remoteproc2: Booting fw image am335x-pru1-fw, size 188560
+[   73.313753] remoteproc remoteproc2: header-less resource table
+[   73.329964] remoteproc remoteproc2: header-less resource table
+[   73.348321] remoteproc remoteproc2: remote processor 4a338000.pru is now up
+[   73.443355] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 0x1e
+[   73.443727] virtio_rpmsg_bus virtio0: msg received with no recipient
+[   73.444352] virtio_rpmsg_bus virtio0: rpmsg host is online
+[   73.540993] rpmsg_pru virtio0.rpmsg-pru.-1.30: new rpmsg_pru device: /dev/rpmsg_pru30
+```
+take a note about "/dev/rpmsg_pru30" - it's your future serial device for main mcu configuration
+this device is required to be present, if it's absent - your PRU cores did not start properly.
+
+## Building and installing Linux host micro-controller code
+This section is required for "Use case 2" and optional for "Use case 3" mentioned above
 
 It is also necessary to compile and install the micro-controller code
 for a Linux host process. Configure it a second time for a "Linux process":
@@ -83,12 +188,24 @@ sudo service klipper stop
 make flash
 sudo service klipper start
 ```
+take a note about "/tmp/klipper_host_mcu" - it will be your future serial device for "mcu host"
+if that file don't exist - refer to "scripts/klipper-mcu.service" file, it was installed by
+previous commands, and it's responsible for it.
+
+
+Take a note for "Use case 2" about following: when you will define printer configuration you should always
+use temperature sensors from "mcu host" because ADCs not present in default "mcu" (PRU cores).
+Sample configuration of "sensor_pin" for extruder and heated bed are available in "generic-cramps.cfg"
+You can use any other GPIO directly from "mcu host" by referencing them this way "host:gpiochip1/gpio17"
+but that should be avoided because it will be creating additional load on main CPU and most probably
+you can't use them for stepper control.
+
 
 ## Remaining configuration
 
-Complete the installation by configuring Klipper and Octoprint
+Complete the installation by configuring Klipper
 following the instructions in
-the main [Installation](Installation.md#configuring-klipper) document.
+the main [Installation](Installation.md#configuring-octoprint-to-use-klipper) document.
 
 ## Printing on the Beaglebone
 
@@ -97,4 +214,111 @@ 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 Reference](Config_Reference.md#virtual_sdcard) for
-details) to print directly from Klipper.
+details) to print directly from Klipper
+and disable any DEBUG or VERBOSE logging options if you did enable them.
+
+
+## AVR micro-controller code build
+This environment have everything to build necessary micro-controller code except AVR,
+AVR packages was removed because of conflict with PRU packages.
+if you still want to build AVR micro-controller code in this environment you need to remove
+PRU packages and install AVR packages by executing following commands
+
+```
+sudo apt-get remove gcc-pru
+sudo apt-get install avrdude gcc-avr binutils-avr avr-libc
+```
+if you need to restore PRU packages - then remove ARV packages before that
+```
+sudo apt-get remove avrdude gcc-avr binutils-avr avr-libc
+sudo apt-get install gcc-pru
+```
+
+
+## Hardware Pin designation
+BeagleBone is very flexible in terms of pin designation, same pin can be configured for different function
+but always single function for single pin, same function can be present on different pins.
+So you can't have multiple functions on single pin or have same function on multiple pins.
+Example:
+P9_20 - i2c2_sda/can0_tx/spi1_cs0/gpio0_12/uart1_ctsn
+P9_19 - i2c2_scl/can0_rx/spi1_cs1/gpio0_13/uart1_rtsn
+P9_24 - i2c1_scl/can1_rx/gpio0_15/uart1_tx
+P9_26 - i2c1_sda/can1_tx/gpio0_14/uart1_rx
+
+Pin designation is defined by using special "overlays" which will be loaded during linux boot
+they are configured by editing file /boot/uEnv.txt with elevated permissions
+```
+sudo editor /boot/uEnv.txt
+```
+and defining which functionality to load, for example to enable CAN1 you need to define overlay for it
+```
+uboot_overlay_addr4=/lib/firmware/BB-CAN1-00A0.dtbo
+```
+This overlay BB-CAN1-00A0.dtbo will reconfigure all required pins for CAN1 and create CAN device in Linux.
+Any change in overlays will require system reboot to be applied.
+If you need to understand which pins are involved in some overlay - you can analyze source files in
+this location: /opt/sources/bb.org-overlays/src/arm/
+or search info in BeagleBone forums.
+
+
+## Enabling hardware SPI
+BeagleBone usually have multiple hardware SPI buses, for example BeagleBone Black can have 2 of them,
+they can work up to 48Mhz, but usually they are limited to 16Mhz by Kernel Device-tree.
+By default, in BeagleBone Black some of SPI1 pins are configured for HDMI-Audio output,
+to fully enable 4-wire SPI1 you need to disable HDMI Audio and enable SPI1
+To do that edit file /boot/uEnv.txt with elevated permissions
+```
+sudo editor /boot/uEnv.txt
+```
+uncomment variable
+```
+disable_uboot_overlay_audio=1
+```
+
+next uncomment variable and define it this way
+```
+uboot_overlay_addr4=/lib/firmware/BB-SPIDEV1-00A0.dtbo
+```
+Save changes in /boot/uEnv.txt and reboot the board.
+Now you have SPI1 Enabled, to verify its presence execute command
+```
+ls /dev/spidev1.*
+```
+Take a note that BeagleBone usually is 3.3v based hardware and to use 5V SPI devices
+you need to add Level-Shifting chip, for example SN74CBTD3861, SN74LVC1G34 or similar.
+If you are using CRAMPS board - it already contains Level-Shifting chip and SPI1 pins
+will become available on P503 port, and they can accept 5v hardware,
+check CRAMPS board Schematics for pin references.
+
+## Enabling hardware I2C
+BeagleBone usually have multiple hardware I2C buses, for example BeagleBone Black can have 3 of them,
+they support speed up-to 400Kbit Fast mode.
+By default, in BeagleBone Black there are two of them (i2c-1 and i2c-2) usually both are already configured and
+present on P9, third ic2-0 usually reserved for internal use.
+If you are using CRAMPS board then i2c-2 is present on P303 port with 3.3v level,
+If you want to obtain I2c-1 in CRAMPS board - you can get them on Extruder1.Step, Extruder1.Dir pins,
+they also are 3.3v based, check CRAMPS board Schematics for pin references.
+Related overlays, for [Hardware Pin designation](#hardware-pin-designation):
+I2C1(100Kbit): BB-I2C1-00A0.dtbo
+I2C1(400Kbit): BB-I2C1-FAST-00A0.dtbo
+I2C2(100Kbit): BB-I2C2-00A0.dtbo
+I2C2(400Kbit): BB-I2C2-FAST-00A0.dtbo
+
+## Enabling hardware UART(Serial)/CAN
+BeagleBone have up to 6 hardware UART(Serial) buses (up to 3Mbit)
+and up to 2 hardware CAN(1Mbit) buses.
+UART1(RX,TX) and CAN1(TX,RX) and I2C2(SDA,SCL) are using same pins - so you need to chose what to use
+UART1(CTSN,RTSN) and CAN0(TX,RX) and I2C1(SDA,SCL) are using same pins - so you need to chose what to use
+All UART/CAN related pins are 3.3v based, so you will need to use Transceiver chips/boards like SN74LVC2G241DCUR (for UART),
+SN65HVD230 (for CAN), TTL-RS485 (for RS-485) or something similar which can convert 3.3v signals to appropriate levels.
+
+Related overlays, for [Hardware Pin designation](#hardware-pin-designation)
+CAN0: BB-CAN0-00A0.dtbo
+CAN1: BB-CAN1-00A0.dtbo
+UART0: - used for Console
+UART1(RX,TX):  BB-UART1-00A0.dtbo
+UART1(RTS,CTS): BB-UART1-RTSCTS-00A0.dtbo
+UART2(RX,TX): BB-UART2-00A0.dtbo
+UART3(RX,TX): BB-UART3-00A0.dtbo
+UART4(RS-485): BB-UART4-RS485-00A0.dtbo
+UART5(RX,TX): BB-UART5-00A0.dtbo

docs/Bed_Mesh.md

@@ -44,10 +44,9 @@ probe_count: 5, 3
 
 - `mesh_max: 240, 198`\
   _Required_\
-  The probed coordinate farthest farthest from the origin.  This is not
-  necessarily the last point probed, as the probing process occurs in a
-  zig-zag fashion.  As with `mesh_min`, this coordinate is relative to
-  the probe's location.
+  The probed coordinate farthest from the origin.  This is not necessarily
+  the last point probed, as the probing process occurs in a zig-zag fashion.
+  As with `mesh_min`, this coordinate is relative to the probe's location.
 
 - `probe_count: 5, 3`\
   _Default Value: 3, 3_\
@@ -142,7 +141,7 @@ bicubic_tension: 0.2
   integer pair, and also may be specified a single integer that is applied
   to both axes.  In this example there are 4 segments along the X axis
   and 2 segments along the Y axis.  This evaluates to 8 interpolated
-  points along X, 6 interpolated points along Y, which results in a 13x8
+  points along X, 6 interpolated points along Y, which results in a 13x9
   mesh.  Note that if mesh_pps is set to 0 then mesh interpolation is
   disabled and the probed matrix will be sampled directly.
 
@@ -268,9 +267,9 @@ by heat or interference.  This can make calculating the probe's z-offset
 challenging, particularly at different bed temperatures.  As such, some
 printers use an endstop for homing the Z axis and a probe for calibrating the
 mesh. In this configuration it is possible offset the mesh so that the (X, Y)
-`reference position` applies zero adjustment.  The `reference postion` should
+`reference position` applies zero adjustment.  The `reference position` should
 be the location on the bed where a
-[Z_ENDSTOP_CALIBRATE](./Manual_Level#calibrating-a-z-endstop)
+[Z_ENDSTOP_CALIBRATE](./Manual_Level.md#calibrating-a-z-endstop)
 paper test is performed.  The bed_mesh module provides the
 `zero_reference_position` option for specifying this coordinate:
 
@@ -293,33 +292,6 @@ probe_count: 5, 3
   z-offset.  Note that this coordinate must NOT be in a location specified as
   a `faulty_region` if a probe is necessary.
 
-#### The deprecated relative_reference_index
-
-Existing configurations using the `relative_reference_index` option must be
-updated to use the `zero_reference_position`.  The response to the
-[BED_MESH_OUTPUT PGP=1](#output) gcode command will include the (X, Y)
-coordinate associated with the index;  this position may be used as the value for
-the `zero_reference_position`. The output will look similar to the following:
-
-```
-// bed_mesh: generated points
-// Index | Tool Adjusted | Probe
-// 0 | (1.0, 1.0) | (24.0, 6.0)
-// 1 | (36.7, 1.0) | (59.7, 6.0)
-// 2 | (72.3, 1.0) | (95.3, 6.0)
-// 3 | (108.0, 1.0) | (131.0, 6.0)
-... (additional generated points)
-// bed_mesh: relative_reference_index 24 is (131.5, 108.0)
-```
-
-_Note:  The above output is also printed in `klippy.log` during initialization._
-
-Using the example above we see that the `relative_reference_index` is
-printed along with its coordinate.  Thus the `zero_reference_position`
-is `131.5, 108`.
-
-
-
 ### Faulty Regions
 
 It is possible for some areas of a bed to report inaccurate results when
@@ -370,21 +342,147 @@ are identified in green.
 
 ![bedmesh_interpolated](img/bedmesh_faulty_regions.svg)
 
+### Adaptive Meshes
+
+Adaptive bed meshing is a way to speed up the bed mesh generation by only probing
+the area of the bed used by the objects being printed. When used, the method will
+automatically adjust the mesh parameters based on the area occupied by the defined
+print objects.
+
+The adapted mesh area will be computed from the area defined by the boundaries of all
+the defined print objects so it covers every object, including any margins defined in
+the configuration. After the area is computed, the number of probe points will be
+scaled down based on the ratio of the default mesh area and the adapted mesh area. To
+illustrate this consider the following example:
+
+For a 150mmx150mm bed with `mesh_min` set to `25,25` and `mesh_max` set to `125,125`,
+the default mesh area is a 100mmx100mm square. An adapted mesh area of `50,50`
+means a ratio of `0.5x0.5` between the adapted area and default mesh area.
+
+If the `bed_mesh` configuration specified `probe_count` as `7x7`, the adapted bed
+mesh will use 4x4 probe points (7 * 0.5 rounded up).
+
+![adaptive_bedmesh](img/adaptive_bed_mesh.svg)
+
+```
+[bed_mesh]
+speed: 120
+horizontal_move_z: 5
+mesh_min: 35, 6
+mesh_max: 240, 198
+probe_count: 5, 3
+adaptive_margin: 5
+```
+
+- `adaptive_margin` \
+  _Default Value: 0_ \
+  Margin (in mm) to add around the area of the bed used by the defined objects. The diagram
+  below shows the adapted bed mesh area with an `adaptive_margin` of 5mm. The adapted mesh
+  area (area in green) is computed as the used bed area (area in blue) plus the defined margin.
+
+  ![adaptive_bedmesh_margin](img/adaptive_bed_mesh_margin.svg)
+
+By nature, adaptive bed meshes use the objects defined by the Gcode file being printed.
+Therefore, it is expected that each Gcode file will generate a mesh that probes a different
+area of the print bed. Therefore, adapted bed meshes should not be re-used. The expectation
+is that a new mesh will be generated for each print if adaptive meshing is used.
+
+It is also important to consider that adaptive bed meshing is best used on machines that can
+normally probe the entire bed and achieve a maximum variance less than or equal to 1 layer
+height. Machines with mechanical issues that a full bed mesh normally compensates for may
+have undesirable results when attempting print moves **outside** of the probed area. If a
+full bed mesh has a variance greater than 1 layer height, caution must be taken when using
+adaptive bed meshes and attempting print moves outside of the meshed area.
+
+## Surface Scans
+
+Some probes, such as the [Eddy Current Probe](./Eddy_Probe.md), are capable of
+"scanning" the surface of the bed.  That is, these probes can sample a mesh
+without lifting the tool between samples.  To activate scanning mode, the
+`METHOD=scan` or `METHOD=rapid_scan` probe parameter should be passed in the
+`BED_MESH_CALIBRATE` gcode command.
+
+### Scan Height
+
+The scan height is set by the `horizontal_move_z` option in `[bed_mesh]`.  In
+addition it can be supplied with the `BED_MESH_CALIBRATE` gcode command via the
+`HORIZONTAL_MOVE_Z` parameter.
+
+The scan height must be sufficiently low to avoid scanning errors.  Typically
+a height of 2mm (ie: `HORIZONTAL_MOVE_Z=2`) should work well, presuming that the
+probe is mounted correctly.
+
+It should be noted that if the probe is more than 4mm above the surface then the
+results will be invalid.  Thus, scanning is not possible on beds with severe
+surface deviation or beds with extreme tilt that hasn't been corrected.
+
+### Rapid (Continuous) Scanning
+
+When performing a `rapid_scan` one should keep in mind that the results will
+have some amount of error.  This error should be low enough to be useful on
+large print areas with reasonably thick layer heights.  Some probes may be
+more prone to error than others.
+
+It is not recommended that rapid mode be used to scan a "dense" mesh.  Some of
+the error introduced during a rapid scan may be gaussian noise from the sensor,
+and a dense mesh will reflect this noise (ie: there will be peaks and valleys).
+
+Bed Mesh will attempt to optimize the travel path to provide the best possible
+result based on the configuration.  This includes avoiding faulty regions
+when collecting samples and "overshooting" the mesh when changing direction.
+This overshoot improves sampling at the edges of a mesh, however it requires
+that the mesh be configured in a way that allows the tool to travel outside
+of the mesh.
+
+```
+[bed_mesh]
+speed: 120
+horizontal_move_z: 5
+mesh_min: 35, 6
+mesh_max: 240, 198
+probe_count: 5
+scan_overshoot: 8
+```
+
+- `scan_overshoot`
+  _Default Value: 0 (disabled)_\
+  The maximum amount of travel (in mm) available outside of the mesh.
+  For rectangular beds this applies to travel on the X axis, and for round beds
+  it applies to the entire radius.  The tool must be able to travel the amount
+  specified outside of the mesh.  This value is used to optimize the travel
+  path when performing a "rapid scan".  The minimum value that may be specified
+  is 1.  The default is no overshoot.
+
+If no scan overshoot is configured then travel path optimization will not
+be applied to changes in direction.
+
 ## Bed Mesh Gcodes
 
 ### Calibration
 
-`BED_MESH_CALIBRATE PROFILE=<name> METHOD=[manual | automatic] [<probe_parameter>=<value>]
- [<mesh_parameter>=<value>]`\
+`BED_MESH_CALIBRATE PROFILE=<name> METHOD=[manual | automatic | scan | rapid_scan] \
+[<probe_parameter>=<value>] [<mesh_parameter>=<value>] [ADAPTIVE=[0|1] \
+[ADAPTIVE_MARGIN=<value>]`\
 _Default Profile:  default_\
-_Default Method:  automatic if a probe is detected, otherwise manual_
+_Default Method:  automatic if a probe is detected, otherwise manual_ \
+_Default Adaptive: 0_ \
+_Default Adaptive Margin: 0_
 
 Initiates the probing procedure for Bed Mesh Calibration.
 
-The mesh will be saved into a profile specified by the `PROFILE` parameter,
-or `default` if unspecified. If `METHOD=manual` is selected then manual probing
-will occur.  When switching between automatic and manual probing the generated
-mesh points will automatically be adjusted.
+The mesh will be immediately ready to use when the command completes and saved
+into a profile specified by the `PROFILE` parameter,
+or `default` if unspecified. The `METHOD` parameter takes one of the following
+values:
+
+- `METHOD=manual`: enables manual probing using the nozzle and the paper test
+- `METHOD=automatic`:  Automatic (standard) probing.  This is the default.
+- `METHOD=scan`: Enables surface scanning.  The tool will pause over each position
+                 to collect a sample.
+- `METHOD=rapid_scan`: Enables continuous surface scanning.
+
+XY positions are automatically adjusted to include the X and/or Y offsets
+when a probing method other than `manual` is selected.
 
 It is possible to specify mesh parameters to modify the probed area.  The
 following parameters are available:
@@ -398,7 +496,10 @@ following parameters are available:
   - `MESH_ORIGIN`
   - `ROUND_PROBE_COUNT`
 - All beds:
+  - `MESH_PPS`
   - `ALGORITHM`
+  - `ADAPTIVE`
+  - `ADAPTIVE_MARGIN`
 
 See the configuration documentation above for details on how each parameter
 applies to the mesh.
@@ -434,6 +535,10 @@ load the `default` profile it is recommended to add
 `BED_MESH_PROFILE LOAD=default` to either their `START_PRINT` macro or their
 slicer's "Start G-Code" configuration, whichever is applicable.
 
+Note that this is not required if a new mesh is generated with
+`BED_MESH_CALIBRATE` in the `START_PRINT` macro or the slicer's "Start G-Code"
+and may produce unexpected results, especially with adaptive meshing.
+
 Alternatively the old behavior of loading a profile at startup can be
 restored with a `[delayed_gcode]`:
 
@@ -486,11 +591,207 @@ This gcode may be used to clear the internal mesh state.
 
 ### Apply X/Y offsets
 
-`BED_MESH_OFFSET [X=<value>] [Y=<value>]`
+`BED_MESH_OFFSET [X=<value>] [Y=<value>] [ZFADE=<value>]`
 
 This is useful for printers with multiple independent extruders, as an offset
 is necessary to produce correct Z adjustment after a tool change.  Offsets
 should be specified relative to the primary extruder.  That is, a positive
 X offset should be specified if the secondary extruder is mounted to the
-right of the primary extruder, and a positive Y offset should be specified
-if the secondary extruder is mounted "behind" the primary extruder.
+right of the primary extruder, a positive Y offset should be specified
+if the secondary extruder is mounted "behind" the primary extruder, and
+a positive ZFADE offset should be specified if the secondary extruder's
+nozzle is above the primary extruder's.
+
+Note that a ZFADE offset does *NOT* directly apply additional adjustment.  It
+is intended to compensate for a `gcode offset` when [mesh fade](#mesh-fade)
+is enabled.  For example, if a secondary extruder is higher than the primary
+and needs a negative gcode offset, ie: `SET_GCODE_OFFSET Z=-.2`, it can be
+accounted for in `bed_mesh` with `BED_MESH_OFFSET ZFADE=.2`.
+
+## Bed Mesh Webhooks APIs
+
+### Dumping mesh data
+
+`{"id": 123, "method": "bed_mesh/dump_mesh"}`
+
+Dumps the configuration and state for the current mesh and all
+saved profiles.
+
+The `dump_mesh` endpoint takes one optional parameter, `mesh_args`.
+This parameter must be an object, where the keys and values are
+parameters available to [BED_MESH_CALIBRATE](#bed_mesh_calibrate).
+This will update the mesh configuration and probe points using the
+supplied parameters prior to returning the result.   It is recommended
+to omit mesh parameters unless it is desired to visualize the probe points
+and/or travel path before performing `BED_MESH_CALIBRATE`.
+
+## Visualization and analysis
+
+Most users will likely find that the visualizers included with
+applications such as Mainsail, Fluidd, and Octoprint are sufficient
+for basic analysis.  However, Klipper's `scripts` folder contains the
+`graph_mesh.py` script that may be used to perform additional
+visualizations and more detailed analysis, particularly useful
+for debugging hardware or the results produced by `bed_mesh`:
+
+```
+usage: graph_mesh.py [-h] {list,plot,analyze,dump} ...
+
+Graph Bed Mesh Data
+
+positional arguments:
+  {list,plot,analyze,dump}
+    list                List available plot types
+    plot                Plot a specified type
+    analyze             Perform analysis on mesh data
+    dump                Dump API response to json file
+
+options:
+  -h, --help            show this help message and exit
+```
+
+### Pre-requisites
+
+Like most graphing tools provided by Klipper, `graph_mesh.py` requires
+the `matplotlib` and `numpy` python dependencies. In addition, connecting
+to Klipper via Moonraker's websocket requires the `websockets` python
+dependency.  While all visualizations can be output to an `svg` file, most of
+the visualizations offered by `graph_mesh.py` are better viewed in live
+preview mode on a desktop class PC. For example, the 3D visualizations may be
+rotated and zoomed in preview mode, and the path visualizations can optionally
+be animated in preview mode.
+
+### Plotting Mesh data
+
+The `graph_mesh.py` tool can plot several types of visualizations.
+Available types can be shown by running `graph_mesh.py list`:
+
+```
+graph_mesh.py list
+points    Plot original generated points
+path      Plot probe travel path
+rapid     Plot rapid scan travel path
+probedz   Plot probed Z values
+meshz     Plot mesh Z values
+overlay   Plots the current probed mesh overlaid with a profile
+delta     Plots the delta between current probed mesh and a profile
+```
+
+Several options are available when plotting visualizations:
+
+```
+usage: graph_mesh.py plot [-h] [-a] [-s] [-p PROFILE_NAME] [-o OUTPUT] <plot type> <input>
+
+positional arguments:
+  <plot type>           Type of data to graph
+  <input>               Path/url to Klipper Socket or path to json file
+
+options:
+  -h, --help            show this help message and exit
+  -a, --animate         Animate paths in live preview
+  -s, --scale-plot      Use axis limits reported by Klipper to scale plot X/Y
+  -p PROFILE_NAME, --profile-name PROFILE_NAME
+                        Optional name of a profile to plot for 'probedz'
+  -o OUTPUT, --output OUTPUT
+                        Output file path
+```
+
+Below is a description of each argument:
+
+- `plot type`: A required positional argument designating the type of
+  visualization to generate.  Must be one of the types output by the
+  `graph_mesh.py list` command.
+- `input`: A required positional argument containing a path or url
+  to the input source.  This must be one of the following:
+  - A path to Klipper's Unix Domain Socket
+  - A url to an instance of Moonraker
+  - A path to a json file produced by `graph_mesh.py dump <input>`
+- `-a`:  Optional animation for the `path` and `rapid` visualization types.
+  Animations only apply to a live preview.
+- `-s`:  Optionally scales a plot using the `axis_minimum` and `axis_maximum`
+  values reported by Klipper's `toolhead` object when the dump file was
+  generated.
+- `-p`: A profile name that may be specified when generating the
+  `probedz` 3D mesh visualization.  When generating an `overlay` or
+  `delta` visualization this argument must be provided.
+- `-o`: An optional file path indicating that the script should save the
+  visualization to this location rather than run in preview mode.  Images
+  are saved in `svg` format.
+
+For example, to plot an animated rapid path, connecting via Klipper's unix
+socket:
+
+```
+graph_mesh.py plot -a rapid ~/printer_data/comms/klippy.sock
+```
+
+Or to plot a 3d visualization of the mesh, connecting via Moonraker:
+
+```
+graph_mesh.py plot meshz http://my-printer.local
+```
+
+### Bed Mesh Analysis
+
+The `graph_mesh.py` tool may also be used to perform an analysis on the
+data provided by the [bed_mesh/dump_mesh](#dumping-mesh-data) API:
+
+```
+graph_mesh.py analyze <input>
+```
+
+As with the `plot` command, the `<input>` must be a path to Klipper's
+unix socket, a URL to an instance of Moonraker, or a path to a json file
+generated by the dump command.
+
+To begin, the analysis will perform various checks on the points and
+probe paths generated by `bed_mesh` at the time of the dump.  This
+includes the following:
+
+- The number of probe points generated, without any additions
+- The number of probe points generated including any points generated
+  as the result faulty regions and/or a configured zero reference position.
+- The number of probe points generated when performing a rapid scan.
+- The total number of moves generated for a rapid scan.
+- A validation that the probe points generated for a rapid scan are
+  identical to the probe points generated for a standard probing procedure.
+- A "backtracking" check for both the standard probe path and a rapid scan
+  path.  Backtracking can be defined as moving to the same position more than
+  once during the probing procedure.  Backtracking should never occur during a
+  standard probe.  Faulty regions *can* result in backtracking during a rapid
+  scan in an attempt to avoid entering a faulty region when approaching or
+  leaving a probe location, however should never occur otherwise.
+
+Next each probed mesh present in the dump will by analyzed, beginning with
+the mesh loaded at the time of the dump (if present) and followed by any
+saved profiles.  The following data is extracted:
+
+- Mesh shape (Min X,Y, Max X,Y Probe Count)
+- Mesh Z range, (Minimum Z, Maximum Z)
+- Mean Z value in the mesh
+- Standard Deviation of the Z values in the Mesh
+
+In addition to the above, a delta analysis is performed between meshes
+with the same shape, reporting the following:
+- The range of the delta between to meshes (Minimum and Maximum)
+- The mean delta
+- Standard Deviation of the delta
+- The absolute maximum difference
+- The absolute mean
+
+### Save mesh data to a file
+
+The `dump` command may be used to save the response to a file which
+can be shared for analysis when troubleshooting:
+
+```
+graph_mesh.py dump -o <output file name> <input>
+```
+
+The `<input>` should be a path to Klipper's unix socket or
+a URL to an instance of Moonraker.  The `-o` option may be used to
+specify the path to the output file.  If omitted, the file will be
+saved in the working directory, with a file name in the following
+format:
+
+`klipper-bedmesh-{year}{month}{day}{hour}{minute}{second}.json`

docs/Benchmarks.md

@@ -250,23 +250,22 @@ results were obtained by running an STM32F407 binary on an STM32F446
 
 ### STM32H7 step rate benchmark
 
-The following configuration sequence is used on a STM32H743VIT6:
+The following configuration sequence is used on STM32H723:
 ```
 allocate_oids count=3
-config_stepper oid=0 step_pin=PD4 dir_pin=PD3 invert_step=-1 step_pulse_ticks=0
-config_stepper oid=1 step_pin=PA15 dir_pin=PA8 invert_step=-1 step_pulse_ticks=0
-config_stepper oid=2 step_pin=PE2 dir_pin=PE3 invert_step=-1 step_pulse_ticks=0
+config_stepper oid=0 step_pin=PA13 dir_pin=PB5 invert_step=-1 step_pulse_ticks=52
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=52
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=52
 finalize_config crc=0
 ```
 
-The test was last run on commit `00191b5c` with gcc version
-`arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release)
-[gcc-8-branch revision 273027]`.
+The test was last run on commit `554ae78d` with gcc version
+`arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0`.
 
-| stm32h7              | ticks |
+| stm32h723            | ticks |
 | -------------------- | ----- |
-| 1 stepper            | 44    |
-| 3 stepper            | 198   |
+| 1 stepper            | 70    |
+| 3 stepper            | 181   |
 
 ### STM32G0B1 step rate benchmark
 
@@ -287,6 +286,25 @@ The test was last run on commit `247cd753` with gcc version
 | 1 stepper        | 58    |
 | 3 stepper        | 243   |
 
+### STM32G4 step rate benchmark
+
+The following configuration sequence is used on the STM32G431:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PA0 dir_pin=PB5 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=1 step_pin=PB2 dir_pin=PB6 invert_step=-1 step_pulse_ticks=17
+config_stepper oid=2 step_pin=PB3 dir_pin=PB7 invert_step=-1 step_pulse_ticks=17
+finalize_config crc=0
+```
+
+The test was last run on commit `cfa48fe3` with gcc version
+`arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0`.
+
+| stm32g431        | ticks |
+| ---------------- | ----- |
+| 1 stepper        | 47    |
+| 3 stepper        | 208   |
+
 ### LPC176x step rate benchmark
 
 The following configuration sequence is used on the LPC176x:
@@ -354,6 +372,26 @@ micro-controller.
 | 1 stepper (200Mhz)   | 39    |
 | 3 stepper (200Mhz)   | 181   |
 
+### SAME70 step rate benchmark
+
+The following configuration sequence is used on the SAME70:
+```
+allocate_oids count=3
+config_stepper oid=0 step_pin=PC18 dir_pin=PB5 invert_step=-1 step_pulse_ticks=0
+config_stepper oid=1 step_pin=PC16 dir_pin=PD10 invert_step=-1 step_pulse_ticks=0
+config_stepper oid=2 step_pin=PC28 dir_pin=PA4 invert_step=-1 step_pulse_ticks=0
+finalize_config crc=0
+```
+
+The test was last run on commit `34e9ea55` with gcc version
+`arm-none-eabi-gcc (NixOS 10.3-2021.10) 10.3.1` on a SAME70Q20B
+micro-controller.
+
+| same70               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 45    |
+| 3 stepper            | 190   |
+
 ### AR100 step rate benchmark ###
 
 The following configuration sequence is used on AR100 CPU (Allwinner A64):
@@ -366,7 +404,7 @@ finalize_config crc=0
 
 ```
 
-The test was last run on commit `08d037c6` with gcc version
+The test was last run on commit `b7978d37` with gcc version
 `or1k-linux-musl-gcc (GCC) 9.2.0` on an Allwinner A64-H
 micro-controller.
 
@@ -375,9 +413,9 @@ micro-controller.
 | 1 stepper            | 85    |
 | 3 stepper            | 359   |
 
-### RP2040 step rate benchmark
+### RPxxxx step rate benchmark
 
-The following configuration sequence is used on the RP2040:
+The following configuration sequence is used on the RP2040 and RP2350:
 
 ```
 allocate_oids count=3
@@ -387,14 +425,25 @@ config_stepper oid=2 step_pin=gpio27 dir_pin=gpio5 invert_step=-1 step_pulse_tic
 finalize_config crc=0
 ```
 
-The test was last run on commit `59314d99` with gcc version
-`arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0` on a Raspberry Pi
-Pico board.
+The test was last run on commit `14c105b8` with gcc version
+`arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0` on Raspberry Pi
+Pico and Pico 2 boards.
 
-| rp2040               | ticks |
+| rp2040 (*)           | ticks |
 | -------------------- | ----- |
-| 1 stepper            | 5     |
-| 3 stepper            | 22    |
+| 1 stepper            | 3     |
+| 3 stepper            | 14    |
+
+| rp2350               | ticks |
+| -------------------- | ----- |
+| 1 stepper            | 36    |
+| 3 stepper            | 169   |
+
+(*) Note that the reported rp2040 ticks are relative to a 12Mhz
+scheduling timer and do not correspond to its 200Mhz internal ARM
+processing rate. It is expected that 3 scheduling ticks corresponds to
+~42 ARM core cycles and 14 scheduling ticks corresponds to ~225 ARM
+core cycles.
 
 ### Linux MCU step rate benchmark
 
@@ -433,18 +482,23 @@ When the test completes, determine the difference between the clocks
 reported in the two "uptime" response messages. The total number of
 commands per second is then `100000 * mcu_frequency / clock_diff`.
 
-Note that this test may saturate the USB/CPU capacity of a Raspberry
-Pi. If running on a Raspberry Pi, Beaglebone, or similar host computer
-then increase the delay (eg, `DELAY {clock + 20*freq} get_uptime`).
-Where applicable, the benchmarks below are with console.py running on
-a desktop class machine with the device connected via a high-speed
-hub.
+The USB tests may exceed the CPU capacity of a Raspberry Pi. If
+running on a Raspberry Pi, Beaglebone, or similar host computer then
+increase the delay (eg, `DELAY {clock + 20*freq} get_uptime`). Where
+applicable, the benchmarks below are with console.py running on a
+desktop class machine with the device connected via a super-speed hub.
+
+The CAN bus tests may saturate the USB host controller of a Raspberry
+Pi (when testing via a standard gs_usb USB to CAN bus adapter). Where
+applicable, the CAN bus benchmarks below are with console.py running
+on a desktop class machine with a USB to CAN bus adapter connected via
+a super-speed USB hub.
 
 | MCU                 | Rate | Build    | Build compiler      |
 | ------------------- | ---- | -------- | ------------------- |
-| stm32f042 (CAN)     |  18K | c105adc8 | arm-none-eabi-gcc (GNU Tools 7-2018-q3-update) 7.3.1 |
 | atmega2560 (serial) |  23K | b161a69e | avr-gcc (GCC) 4.8.1 |
 | sam3x8e (serial)    |  23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
+| rp2350 (CAN)        |  59K | 17b8ce4c | arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0 |
 | at90usb1286 (USB)   |  75K | 01d2183f | avr-gcc (GCC) 5.4.0 |
 | ar100 (serial)      | 138K | 08d037c6 | or1k-linux-musl-gcc 9.3.0 |
 | samd21 (USB)        | 223K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
@@ -456,7 +510,8 @@ hub.
 | sam4s8c (USB)       | 650K | 8d4a5c16 | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
 | samd51 (USB)        | 864K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
 | stm32f446 (USB)     | 870K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
-| rp2040 (USB)        | 873K | c5667193 | arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 |
+| rp2040 (USB)        | 885K | f6718291 | arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0 |
+| rp2350 (USB)        | 885K | f6718291 | arm-none-eabi-gcc (Fedora 14.1.0-1.fc40) 14.1.0 |
 
 ## Host Benchmarks
 

docs/Bootloaders.md

@@ -194,7 +194,7 @@ Alternatively, one can use a
 
 When using OpenOCD with the SAMC21, extra steps must be taken to first
 put the chip into Cold Plugging mode if the board makes use of the
-SWD pins for other purposes. If using OpenOCD on a Rasberry Pi, this
+SWD pins for other purposes. If using OpenOCD on a Raspberry Pi, this
 can be done by running the following commands before invoking OpenOCD.
 ```
 SWCLK=25

docs/CANBUS.md

@@ -31,7 +31,7 @@ adapter. This is typically done by creating a new file named
 allow-hotplug can0
 iface can0 can static
     bitrate 1000000
-    up ifconfig $IFACE txqueuelen 128
+    up ip link set $IFACE txqueuelen 128
 ```
 
 ## Terminating Resistors
@@ -113,7 +113,7 @@ Some important notes when using this mode:
 allow-hotplug can0
 iface can0 can static
     bitrate 1000000
-    up ifconfig $IFACE txqueuelen 128
+    up ip link set $IFACE txqueuelen 128
 ```
 
 * The "bridge mcu" is not actually on the CAN bus. Messages to and
@@ -125,10 +125,14 @@ iface can0 can static
   frequency. As a result, it is recommended to use a CAN bus frequency
   of 1000000 when using "USB to CAN bus bridge mode".
 
-  Even at a CAN bus frequency of 1000000, there may not be sufficient
-  bandwidth to run a `SHAPER_CALIBRATE` test if both the XY steppers
-  and the accelerometer all communicate via a single "USB to CAN bus"
-  interface.
+* It is only valid to use USB to CAN bridge mode if there is a
+  functioning CAN bus with at least one other node available (in
+  addition to the bridge node itself). Use a standard USB
+  configuration if the goal is to communicate only with the single USB
+  device. Using USB to CAN bridge mode without a fully functioning CAN
+  bus (including terminating resistors and an additional node) may
+  result in sporadic errors even when communicating with the bridge
+  node.
 
 * A USB to CAN bridge board will not appear as a USB serial device, it
   will not show up when running `ls /dev/serial/by-id`, and it can not

docs/CANBUS_Troubleshooting.md

@@ -37,20 +37,103 @@ hours or more frequently) then it is an indication of a severe
 problem.
 
 Incrementing `bytes_invalid` on a CAN bus connection is a symptom of
-reordered messages on the CAN bus. There are two known causes of
-reordered messages:
-1. Old versions of the popular candlight_firmware for USB CAN adapters
-   had a bug that could cause reordered messages. If using a USB CAN
-   adapter running this firmware then make sure to update to the
-   latest firmware if incrementing `bytes_invalid` is observed.
-2. Some Linux kernel builds for embedded devices have been known to
-   reorder CAN bus messages. It may be necessary to use an alternative
-   Linux kernel or to use alternative hardware that supports
-   mainstream Linux kernels that do not exhibit this problem.
+reordered messages on the CAN bus. If seen, make sure to:
+* Use a Linux kernel version 6.6.0 or later.
+* If using a USB-to-CANBUS adapter running candlelight firmware, use
+  v2.0 or later of candleLight_fw.
+* If using Klipper's USB-to-CANBUS bridge mode, make sure the bridge
+  node is flashed with Klipper v0.12.0 or later.
 
 Reordered messages is a severe problem that must be fixed. It will
 result in unstable behavior and can lead to confusing errors at any
-part of a print.
+part of a print. An incrementing `bytes_invalid` is not caused by
+wiring or similar hardware issues and can only be fixed by identifying
+and updating the faulty software.
+
+Older versions of the Linux kernel had a bug in the gs_usb canbus
+driver code that could cause reordered canbus packets.  The issue is
+thought to be fixed in
+[Linux commit 24bc41b4](https://github.com/torvalds/linux/commit/24bc41b4558347672a3db61009c339b1f5692169)
+which was released in v6.6.0. In some cases, older Linux versions may
+not show the problem (due to how hardware interrupts are configured),
+however if problems are seen the recommended solution is to upgrade to
+a newer kernel.
+
+Older versions of candlelight firmware could reorder canbus packets,
+and the issue is thought to be fixed in
+[candlelight_fw commit 8b3a7b45](https://github.com/candle-usb/candleLight_fw/commit/8b3a7b4565a3c9521b762b154c94c72c5acb2bcf).
+
+Older versions of Klipper's USB-to-CANBUS bridge code could
+incorrectly drop canbus messages. This is not as severe as reordering
+messages, but it should still be fixed. It is thought to be fixed with
+[Klipper PR #6175](https://github.com/Klipper3d/klipper/pull/6175).
+
+## Use an appropriate txqueuelen setting
+
+The Klipper code uses the Linux kernel to manage CAN bus traffic. By
+default, the kernel will only queue 10 CAN transmit packets. It is
+recommended to [configure the can0 device](CANBUS.md#host-hardware)
+with a `txqueuelen 128` to increase that size.
+
+If Klipper transmits a packet and Linux has filled all of its transmit
+queue space then Linux will drop that packet and messages like the
+following will appear in the Klipper log:
+```
+Got error -1 in can write: (105)No buffer space available
+```
+Klipper will automatically retransmit the lost messages as part of its
+normal application level message retransmit system. Thus, this log
+message is a warning and it does not indicate an unrecoverable error.
+
+If a complete CAN bus failure occurs (such as a CAN wire break) then
+Linux will not be able to transmit any messages on the CAN bus and it
+is common to find the above message in the Klipper log. In this case,
+the log message is a symptom of a larger problem (the inability to
+transmit any messages) and is not directly related to Linux
+`txqueuelen`.
+
+One may check the current queue size by running the Linux command `ip
+link show can0`. It should report a bunch of text including the
+snippet `qlen 128`. If one sees something like `qlen 10` then it
+indicates the CAN device has not been properly configured.
+
+It is not recommended to use a `txqueuelen` significantly larger
+than 128. A CAN bus running at a frequency of 1000000 will typically
+take around 120us to transmit a CAN packet. Thus a queue of 128
+packets is likely to take around 15-20ms to drain. A substantially
+larger queue could cause excessive spikes in message round-trip-time
+which could lead to unrecoverable errors. Said another way, Klipper's
+application retransmit system is more robust if it does not have to
+wait for Linux to drain an excessively large queue of possibly stale
+data. This is analogous to the problem of
+[bufferbloat](https://en.wikipedia.org/wiki/Bufferbloat) on internet
+routers.
+
+Under normal circumstances Klipper may utilize ~25 queue slots per
+MCU - typically only utilizing more slots during retransmits.
+(Specifically, the Klipper host may transmit up to 192 bytes to each
+Klipper MCU before receiving an acknowledgment from that MCU.) If a
+single CAN bus has 5 or more Klipper MCUs on it, then it might be
+necessary to increase the `txqueuelen` above the recommended value
+of 128. However, as above, care should be taken when selecting a new
+value to avoid excessive round-trip-time latency.
+
+## Use `canbus_query.py` only to identify nodes never previously seen
+
+It is only valid to use the
+[`canbus_query.py` tool](CANBUS.md#finding-the-canbus_uuid-for-new-micro-controllers)
+to identify micro-controllers that have never been previously
+identified. Once all nodes on a bus are identified, record the
+resulting uuids in the printer.cfg, and avoid running the tool
+unnecessarily.
+
+The tool is implemented using a low-level mechanism that can cause
+nodes to internally observe bus errors. These internal errors may
+result in communication interruptions and may result is some nodes
+disconnecting from the bus.
+
+It is not valid to use the tool to "ping" if a node is connected. Do
+not run the tool during an active print.
 
 ## Obtaining candump logs
 

docs/CONTRIBUTING.md

@@ -323,7 +323,7 @@ a month without updates.
 
 Once the requirements are met, you need to:
 
-1. update klipper-tranlations repository
+1. update klipper-translations repository
 [active_translations](https://github.com/Klipper3d/klipper-translations/blob/translations/active_translations)
 2. Optional: add a manual-index.md file in klipper-translations repository's
 `docs\locals\<lang>` folder to replace the language specific index.md (generated

docs/Code_Overview.md

@@ -136,8 +136,9 @@ provides further information on the mechanics of moves.
 
 * The ToolHead class (in toolhead.py) handles "look-ahead" and tracks
   the timing of printing actions. The main codepath for a move is:
-  `ToolHead.move() -> MoveQueue.add_move() -> MoveQueue.flush() ->
-  Move.set_junction() -> ToolHead._process_moves()`.
+  `ToolHead.move() -> LookAheadQueue.add_move() ->
+  LookAheadQueue.flush() -> Move.set_junction() ->
+  ToolHead._process_moves()`.
   * ToolHead.move() creates a Move() object with the parameters of the
   move (in cartesian space and in units of seconds and millimeters).
   * The kinematics class is given the opportunity to audit each move
@@ -146,10 +147,10 @@ provides further information on the mechanics of moves.
   may raise an error if the move is not valid. If check_move()
   completes successfully then the underlying kinematics must be able
   to handle the move.
-  * MoveQueue.add_move() places the move object on the "look-ahead"
-  queue.
-  * MoveQueue.flush() determines the start and end velocities of each
-  move.
+  * LookAheadQueue.add_move() places the move object on the
+  "look-ahead" queue.
+  * LookAheadQueue.flush() determines the start and end velocities of
+  each move.
   * Move.set_junction() implements the "trapezoid generator" on a
   move. The "trapezoid generator" breaks every move into three parts:
   a constant acceleration phase, followed by a constant velocity
@@ -170,17 +171,18 @@ provides further information on the mechanics of moves.
   placed on a "trapezoid motion queue": `ToolHead._process_moves() ->
   trapq_append()` (in klippy/chelper/trapq.c). The step times are then
   generated: `ToolHead._process_moves() ->
-  ToolHead._update_move_time() -> MCU_Stepper.generate_steps() ->
-  itersolve_generate_steps() -> itersolve_gen_steps_range()` (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).
+  ToolHead._advance_move_time() -> ToolHead._advance_flush_time() ->
+  MCU_Stepper.generate_steps() -> itersolve_generate_steps() ->
+  itersolve_gen_steps_range()` (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).
 
 * Note that the extruder is handled in its own kinematic class:
   `ToolHead._process_moves() -> PrinterExtruder.move()`. Since
@@ -284,6 +286,11 @@ The following may also be useful:
   during the `load_config()` or "connect event" phases. Use either
   `raise config.error("my error")` or `raise printer.config_error("my
   error")` to report the error.
+* Do not store a reference to the `config` object in a class member
+  variable (nor in any similar location that may persist past initial
+  module loading). The `config` object is a reference to a "config
+  loading phase" class and it is not valid to invoke its methods after
+  the "config loading phase" has completed.
 * 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",
@@ -357,10 +364,10 @@ Useful steps:
    be efficient as it is typically only called during homing and
    probing operations.
 5. Other methods. Implement the `check_move()`, `get_status()`,
-   `get_steppers()`, `home()`, and `set_position()` methods. These
-   functions are typically used to provide kinematic specific checks.
-   However, at the start of development one can use boiler-plate code
-   here.
+   `get_steppers()`, `home()`, `clear_homing_state()`, and `set_position()`
+   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

docs/Config_Changes.md

@@ -8,6 +8,119 @@ All dates in this document are approximate.
 
 ## Changes
 
+20250811: Support for the `max_accel_to_decel` parameter in the
+`[printer]` config section has been removed and support for the
+`ACCEL_TO_DECEL` parameter in the `SET_VELOCITY_LIMIT` command has
+been removed. These capabilities were deprecated on 20240313.
+
+20250721: The `[pca9632]` and `[mcp4018]` modules no longer accept the
+`scl_pin` and `sda_pin` options. Use `i2c_software_scl_pin` and
+`i2c_software_sda_pin` instead.
+
+20250428: The maximum `cycle_time` for pwm `[output_pin]`,
+`[pwm_cycle_time]`, `[pwm_tool]`, and similar config sections is now 3
+seconds (reduced from 5 seconds). The `maximum_mcu_duration` in
+`[pwm_tool]` is now also 3 seconds.
+
+20250418: The manual_stepper `STOP_ON_ENDSTOP` feature may now take
+less time to complete. Previously, the command would wait the entire
+time the move could possibly take even if the endstop triggered
+earlier. Now, the command finishes shortly after the endstop trigger.
+
+20250417: SPI devices using "software SPI" are now rate limited.
+Previously, the `spi_speed` in the config was ignored and the
+transmission speed was only limited by the processing speed of the
+micro-controller. Now, speeds are limited by the `spi_speed` config
+parameter (actual hardware speeds are likely to be lower than the
+configured value due to software overhead).
+
+20250411: Klipper v0.13.0 released.
+
+20250308: The `AUTO` parameter of the
+`AXIS_TWIST_COMPENSATION_CALIBRATE` command has been removed.
+
+20250131: Option `VARIABLE=<name>` in `SAVE_VARIABLE` requires lowercase
+value. For example, `extruder` instead of mixedcase `Extruder` or
+uppercase `EXTRUDER`. Using any uppercase letter will raise an error.
+
+20241203: The resonance test has been changed to include slow sweeping
+moves. This change requires that testing point(s) have some clearance
+in X/Y plane (+/- 30 mm from the test point should suffice when using
+the default settings). The new test should generally produce more
+accurate and reliable test results. However, if required, the previous
+test behavior can be restored by adding options `sweeping_period: 0` and
+`accel_per_hz: 75` to the `[resonance_tester]` config section.
+
+20241201: In some cases Klipper may have ignored leading characters or
+spaces in a traditional G-Code command. For example, "99M123" may have
+been interpreted as "M123" and "M 321" may have been interpreted as
+"M321". Klipper will now report these cases with an "Unknown command"
+warning.
+
+20241112: Option `CHIPS=<chip_name>` in `TEST_RESONANCES` and
+`SHAPER_CALIBRATE` requires specifying the full name(s) of the accel
+chip(s). For example, `adxl345 rpi` instead of short name - `rpi`.
+
+20240912: `SET_PIN`, `SET_SERVO`, `SET_FAN_SPEED`, `M106`, and `M107`
+commands are now collated. Previously, if many updates to the same
+object were issued faster than the minimum scheduling time (typically
+100ms) then actual updates could be queued far into the future. Now if
+many updates are issued in rapid succession then it is possible that
+only the latest request will be applied. If the previous behavior is
+required then consider adding explicit `G4` delay commands between
+updates.
+
+20240912: Support for `maximum_mcu_duration` and `static_value`
+parameters in `[output_pin]` config sections have been removed. These
+options have been deprecated since 20240123.
+
+20240415: The `on_error_gcode` parameter in the `[virtual_sdcard]`
+config section now has a default. If this parameter is not specified
+it now defaults to `TURN_OFF_HEATERS`. If the previous behavior is
+desired (take no default action on an error during a virtual_sdcard
+print) then define `on_error_gcode` with an empty value.
+
+20240313: The `max_accel_to_decel` parameter in the `[printer]` config
+section has been deprecated. The `ACCEL_TO_DECEL` parameter of the
+`SET_VELOCITY_LIMIT` command has been deprecated. The
+`printer.toolhead.max_accel_to_decel` status has been removed. Use the
+[minimum_cruise_ratio parameter](./Config_Reference.md#printer)
+instead. The deprecated features will be removed in the near future,
+and using them in the interim may result in subtly different behavior.
+
+20240215: Several deprecated features have been removed. Using "NTC
+100K beta 3950" as a thermistor name has been removed (deprecated on
+20211110). The `SYNC_STEPPER_TO_EXTRUDER` and
+`SET_EXTRUDER_STEP_DISTANCE` commands have been removed, and the
+extruder `shared_heater` config option has been removed (deprecated on
+20220210). The bed_mesh `relative_reference_index` option has been
+removed (deprecated on 20230619).
+
+20240123: The output_pin SET_PIN CYCLE_TIME parameter has been
+removed. Use the new
+[pwm_cycle_time](Config_Reference.md#pwm_cycle_time) module if it is
+necessary to dynamically change a pwm pin's cycle time.
+
+20240123: The output_pin `maximum_mcu_duration` parameter is
+deprecated. Use a [pwm_tool config section](Config_Reference.md#pwm_tool)
+instead. The option will be removed in the near future.
+
+20240123: The output_pin `static_value` parameter is deprecated.
+Replace with `value` and `shutdown_value` parameters.  The option will
+be removed in the near future.
+
+20231216: The `[hall_filament_width_sensor]` is changed to trigger filament runout
+when the thickness of the filament exceeds `max_diameter`. The maximum diameter
+defaults to `default_nominal_filament_diameter + max_difference`. See
+[[hall_filament_width_sensor] configuration
+reference](./Config_Reference.md#hall_filament_width_sensor) for more details.
+
+20231207: Several undocumented config parameters in the `[printer]`
+config section have been removed (the buffer_time_low,
+buffer_time_high, buffer_time_start, and move_flush_time parameters).
+
+20231110: Klipper v0.12.0 released.
+
 20230826: If `safe_distance` is set or calculated to be 0 in `[dual_carriage]`,
 the carriages proximity checks will be disabled as per documentation. A user
 may wish to configure `safe_distance` explicitly to prevent accidental crashes
@@ -27,7 +140,7 @@ carriage are exported as `printer.dual_carriage.carriage_0` and
 `printer.dual_carriage.carriage_1`.
 
 20230619: The `relative_reference_index` option has been deprecated
-and superceded by the `zero_reference_position` option.  Refer to the
+and superseded by the `zero_reference_position` option.  Refer to the
 [Bed Mesh Documentation](./Bed_Mesh.md#the-deprecated-relative_reference_index)
 for details on how to update the configuration.  With this deprecation
 the `RELATIVE_REFERENCE_INDEX` is no longer available as a parameter
@@ -261,7 +374,7 @@ endstop phases by running the ENDSTOP_PHASE_CALIBRATE command.
 `gear_ratio` for their rotary steppers, and they may no longer specify
 a `step_distance` parameter.  See the
 [config reference](Config_Reference.md#stepper) for the format of the
-new gear_ratio paramter.
+new gear_ratio parameter.
 
 20201213: It is not valid to specify a Z "position_endstop" when using
 "probe:z_virtual_endstop".  An error will now be raised if a Z

docs/Contact.md

@@ -132,3 +132,10 @@ There are several
 you have questions on the code then you can also ask in the
 [Klipper Discourse Forum](#discourse-forum) or on the
 [Klipper Discord Chat](#discord-chat).
+
+## Professional Services
+
+![](img/klipper-logo-small.png)
+
+Custom software development, software support, and solutions:
+[https://ko-fi.com/koconnor](https://ko-fi.com/koconnor)

docs/Eddy_Probe.md

@@ -0,0 +1,146 @@
+# Eddy Current Inductive probe
+
+This document describes how to use an
+[eddy current](https://en.wikipedia.org/wiki/Eddy_current) inductive
+probe in Klipper.
+
+Currently, an eddy current probe can not be used for Z homing. The
+sensor can only be used for Z probing.
+
+Start by declaring a
+[probe_eddy_current config section](Config_Reference.md#probe_eddy_current)
+in the printer.cfg file. It is recommended to set the `z_offset` to
+0.5mm. It is typical for the sensor to require an `x_offset` and
+`y_offset`. If these values are not known, one should estimate the
+values during initial calibration.
+
+The first step in calibration is to determine the appropriate
+DRIVE_CURRENT for the sensor. Home the printer and navigate the
+toolhead so that the sensor is near the center of the bed and is about
+20mm above the bed. Then issue an `LDC_CALIBRATE_DRIVE_CURRENT
+CHIP=<config_name>` command. For example, if the config section was
+named `[probe_eddy_current my_eddy_probe]` then one would run
+`LDC_CALIBRATE_DRIVE_CURRENT CHIP=my_eddy_probe`. This command should
+complete in a few seconds.  After it completes, issue a `SAVE_CONFIG`
+command to save the results to the printer.cfg and restart.
+
+The second step in calibration is to correlate the sensor readings to
+the corresponding Z heights. Home the printer and navigate the
+toolhead so that the nozzle is near the center of the bed. Then run an
+`PROBE_EDDY_CURRENT_CALIBRATE CHIP=my_eddy_probe` command. Once the
+tool starts, follow the steps described at
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
+actual distance between the nozzle and bed at the given location. Once
+those steps are complete one can `ACCEPT` the position. The tool will
+then move the the toolhead so that the sensor is above the point where
+the nozzle used to be and run a series of movements to correlate the
+sensor to Z positions. This will take a couple of minutes. After the
+tool completes, issue a `SAVE_CONFIG` command to save the results to
+the printer.cfg and restart.
+
+After initial calibration it is a good idea to verify that the
+`x_offset` and `y_offset` are accurate. Follow the steps to
+[calibrate probe x and y offsets](Probe_Calibrate.md#calibrating-probe-x-and-y-offsets).
+If either the `x_offset` or `y_offset` is modified then be sure to run
+the `PROBE_EDDY_CURRENT_CALIBRATE` command (as described above) after
+making the change.
+
+Once calibration is complete, one may use all the standard Klipper
+tools that use a Z probe.
+
+Note that eddy current sensors (and inductive probes in general) are
+susceptible to "thermal drift". That is, changes in temperature can
+result in changes in reported Z height. Changes in either the bed
+surface temperature or sensor hardware temperature can skew the
+results. It is important that calibration and probing is only done
+when the printer is at a stable temperature.
+
+## Thermal Drift Calibration
+
+As with all inductive probes, eddy current probes are subject to
+significant thermal drift.  If the eddy probe has a temperature
+sensor on the coil it is possible to configure a `[temperature_probe]`
+to report coil temperature and enable software drift compensation. To
+link a temperature probe to an eddy current probe the
+`[temperature_probe]` section must share a name with the
+`[probe_eddy_current]` section.  For example:
+
+```
+[probe_eddy_current my_probe]
+# eddy probe configuration...
+
+[temperature_probe my_probe]
+# temperature probe configuration...
+```
+
+See the [configuration reference](Config_Reference.md#temperature_probe)
+for further details on how to configure a `temperature_probe`.  It is
+advised to configure the `calibration_position`,
+`calibration_extruder_temp`, `extruder_heating_z`, and
+`calibration_bed_temp` options, as doing so will automate some of the
+steps outlined below.  If the printer to be calibrated is enclosed, it
+is strongly recommended to set the `max_validation_temp` option to a value
+between 100 and 120.
+
+Eddy probe manufacturers may offer a stock drift calibration that can be
+manually added to `drift_calibration` option of the `[probe_eddy_current]`
+section. If they do not, or if the stock calibration does not perform well on
+your system, the `temperature_probe` module offers a manual calibration
+procedure via the `TEMPERATURE_PROBE_CALIBRATE` gcode command.
+
+Prior to performing calibration the user should have an idea of what the
+maximum attainable temperature probe coil temperature is.  This temperature
+should be used to set the `TARGET` parameter of the
+`TEMPERATURE_PROBE_CALIBRATE` command.  The goal is to calibrate across the
+widest temperature range possible, thus its desirable to start with the printer
+cold and finish with the coil at the maximum temperature it can reach.
+
+Once a `[temperature_probe]` is configured, the following steps may be taken
+to perform thermal drift calibration:
+
+- The probe must be calibrated using `PROBE_EDDY_CURRENT_CALIBRATE`
+  when a `[temperature_probe]` is configured and linked.  This captures
+  the temperature during calibration which is necessary to perform
+  thermal drift compensation.
+- Make sure the nozzle is free of debris and filament.
+- The bed, nozzle, and probe coil should be cold prior to calibration.
+- The following steps are required if the `calibration_position`,
+  `calibration_extruder_temp`, and `extruder_heating_z` options in
+  `[temperature_probe]` are **NOT** configured:
+  - Move the tool to the center of the bed.  Z should be 30mm+ above the bed.
+  - Heat the extruder to a temperature above the maximum safe bed temperature.
+    150-170C should be sufficient for most configurations.  The purpose of
+    heating the extruder is to avoid nozzle expansion during calibration.
+  - When the extruder temperature has settled, move the Z axis down to about 1mm
+    above the bed.
+- Start drift calibration.  If the probe's name is `my_probe` and the maximum
+  probe temperature we can achieve is 80C, the appropriate gcode command is
+  `TEMPERATURE_PROBE_CALIBRATE PROBE=my_probe TARGET=80`.  If configured, the
+  tool will move to the X,Y coordinate specified by the `calibration_position`
+  and the Z value specified by `extruder_heating_z`.  After heating the extruder
+  to the specified temperature the tool will move to the Z value specified
+  by the`calibration_position`.
+- The procedure will request a manual probe.  Perform the manual probe with
+  the paper test and `ACCEPT`.  The calibration procedure will take the first
+  set of samples with the probe then park the probe in the heating position.
+- If the `calibration_bed_temp` is **NOT** configured turn on the bed heat
+  to the maximum safe temperature.  Otherwise this step will be performed
+  automatically.
+- By default the calibration procedure will request a manual probe every
+  2C between samples until the `TARGET` is reached.  The temperature delta
+  between samples can be customized by setting the `STEP` parameter in
+  `TEMPERATURE_PROBE_CALIBRATE`.  Care should be taken when setting a custom
+  `STEP` value, a value too high may request too few samples resulting in
+  a poor calibration.
+- The following additional gcode commands are available during drift
+  calibration:
+  - `TEMPERATURE_PROBE_NEXT` may be used to force a new sample before the step
+    delta has been reached.
+  - `TEMPERATURE_PROBE_COMPLETE` may be used to complete calibration before the
+    `TARGET` has been reached.
+  - `ABORT` may be used to end calibration and discard results.
+- When calibration is finished use `SAVE_CONFIG` to store the drift
+  calibration.
+
+As one may conclude, the calibration process outlined above is more challenging
+and time consuming than most other procedures.  It may require practice and several attempts to achieve an optimal calibration.

docs/Features.md

@@ -102,11 +102,13 @@ Klipper supports many standard 3d printer features:
   printers.
 
 * Automatic bed leveling support. Klipper can be configured for basic
-  bed tilt detection or full mesh bed leveling. If the bed uses
+  bed tilt detection or full mesh bed leveling. The bed mesh can be
+  customized to the print size (adaptive bed mesh). 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 BL-Touch probes and servo activated probes. Probes may be
-  calibrated for axis twist compensation.
+  calibrated for axis twist compensation. If using an "eddy current
+  probe" then one can utilize fast bed mesh scanning,
 
 * Automatic delta calibration support. The calibration tool can
   perform basic height calibration as well as an enhanced X and Y
@@ -118,7 +120,7 @@ Klipper supports many standard 3d printer features:
 
 * Support for common temperature sensors (eg, common thermistors,
   AD595, AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856,
-  MAX31865, BME280, HTU21D, DS18B20, AHT10, and LM75). Custom
+  MAX31865, BME280, HTU21D, DS18B20, AHT10, SHT3x, and LM75). Custom
   thermistors and custom analog temperature sensors can also be
   configured. One can monitor the internal micro-controller
   temperature sensor and the internal temperature sensor of a
@@ -128,7 +130,8 @@ Klipper supports many standard 3d printer features:
 
 * Support for standard fans, nozzle fans, and temperature controlled
   fans. No need to keep fans running when the printer is idle. Fan
-  speed can be monitored on fans that have a tachometer.
+  speed can be monitored on fans that have a tachometer. One can
+  assign a "math formula" to a fan for automatic fan speed updating.
 
 * Support for run-time configuration of TMC2130, TMC2208/TMC2224,
   TMC2209, TMC2240, TMC2660, and TMC5160 stepper motor drivers. There
@@ -154,7 +157,7 @@ Klipper supports many standard 3d printer features:
   filament width sensors.
 
 * Support for measuring and recording acceleration using adxl345,
-  mpu9250, mpu6050, and lis2dw12 accelerometers.
+  mpu9250, mpu6050, lis2dw12, lis3dh, and icm20948 accelerometers.
 
 * Support for limiting the top speed of short "zigzag" moves to reduce
   printer vibration and noise. See the [kinematics](Kinematics.md)
@@ -184,13 +187,16 @@ represent total number of steps per second on the micro-controller.
 | SAM4S8C                         | 1690K             | 1385K             |
 | LPC1768                         | 1923K             | 1351K             |
 | LPC1769                         | 2353K             | 1622K             |
-| RP2040                          | 2400K             | 1636K             |
 | SAM4E8E                         | 2500K             | 1674K             |
 | SAMD51                          | 3077K             | 1885K             |
 | AR100                           | 3529K             | 2507K             |
+| STM32G431                       | 3617K             | 2452K             |
 | STM32F407                       | 3652K             | 2459K             |
 | STM32F446                       | 3913K             | 2634K             |
-| STM32H743                       | 9091K             | 6061K             |
+| RP2040                          | 4000K             | 2571K             |
+| RP2350                          | 4167K             | 2663K             |
+| SAME70                          | 6667K             | 4737K             |
+| STM32H723                       | 7429K             | 8619K             |
 
 If unsure of the micro-controller on a particular board, find the
 appropriate [config file](../config/), and look for the

docs/G-Codes.md

@@ -127,6 +127,14 @@ use this tool the Python "numpy" package must be installed (see the
 [measuring resonance document](Measuring_Resonances.md#software-installation)
 for more information).
 
+#### ANGLE_CHIP_CALIBRATE
+`ANGLE_CHIP_CALIBRATE CHIP=<chip_name>`: Perform internal sensor calibration,
+if implemented (MT6826S/MT6835).
+
+- **MT68XX**: The motor should be disconnected
+from any printer carriage before performing calibration.
+After calibration, the sensor should be reset by disconnecting the power.
+
 #### ANGLE_DEBUG_READ
 `ANGLE_DEBUG_READ CHIP=<config_name> REG=<register>`: Queries sensor
 register "register" (e.g. 44 or 0x2C). Can be useful for debugging
@@ -139,6 +147,21 @@ Writes raw "value" into register "register". Both "value" and
 and refer to sensor data sheet for the reference. This is only
 available for tle5012b chips.
 
+### [axis_twist_compensation]
+
+The following commands are available when the
+[axis_twist_compensation config
+section](Config_Reference.md#axis_twist_compensation) is enabled.
+
+#### AXIS_TWIST_COMPENSATION_CALIBRATE
+`AXIS_TWIST_COMPENSATION_CALIBRATE [AXIS=<X|Y>] [SAMPLE_COUNT=<value>]`
+
+Calibrates axis twist compensation by specifying the target axis or
+enabling automatic calibration.
+
+- **AXIS:** Define the axis (`X` or `Y`) for which the twist compensation
+will be calibrated. If not specified, the axis defaults to `'X'`.
+
 ### [bed_mesh]
 
 The following commands are available when the
@@ -146,15 +169,23 @@ The following commands are available when the
 (also see the [bed mesh guide](Bed_Mesh.md)).
 
 #### BED_MESH_CALIBRATE
-`BED_MESH_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>]
-[<probe_parameter>=<value>] [<mesh_parameter>=<value>]`: This command probes
-the bed using generated points specified by the parameters in the config. After
-probing, a mesh is generated and z-movement is adjusted according to the mesh.
+`BED_MESH_CALIBRATE [PROFILE=<name>] [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>]
+[<probe_parameter>=<value>] [<mesh_parameter>=<value>] [ADAPTIVE=1]
+[ADAPTIVE_MARGIN=<value>]`: This command probes the bed using generated points
+specified by the parameters in the config. After probing, a mesh is generated
+and z-movement is adjusted according to the mesh.
+The mesh is immediately active after successful completion of `BED_MESH_CALIBRATE`.
+The mesh will be saved into a profile specified by the `PROFILE` parameter,
+or `default` if unspecified. If ADAPTIVE=1 is specified then the profile
+name will begin with `adaptive-` and should not be saved for reuse.
 See the PROBE command for details on the optional probe parameters. If
 METHOD=manual is specified then the manual probing tool is activated - see the
 MANUAL_PROBE command above for details on the additional commands available
 while this tool is active. The optional `HORIZONTAL_MOVE_Z` value overrides the
-`horizontal_move_z` option specified in the config file.
+`horizontal_move_z` option specified in the config file. If ADAPTIVE=1 is
+specified then the objects defined by the Gcode file being printed will be used
+to define the probed area. The optional `ADAPTIVE_MARGIN` value overrides the
+`adaptive_margin` option specified in the config file.
 
 #### BED_MESH_OUTPUT
 `BED_MESH_OUTPUT PGP=[<0:1>]`: This command outputs the current probed
@@ -184,10 +215,12 @@ SAVE_CONFIG gcode must be run to make the changes to persistent memory
 permanent.
 
 #### BED_MESH_OFFSET
-`BED_MESH_OFFSET [X=<value>] [Y=<value>]`: Applies X and/or Y offsets
-to the mesh lookup. This is useful for printers with independent
-extruders, as an offset is necessary to produce correct Z adjustment
-after a tool change.
+`BED_MESH_OFFSET [X=<value>] [Y=<value>] [ZFADE=<value]`: Applies X, Y,
+and/or ZFADE offsets to the mesh lookup. This is useful for printers with
+independent extruders, as an offset is necessary to produce correct Z
+adjustment after a tool change.  Note that a ZFADE offset does not apply
+additional z-adjustment directly, it is used to correct the `fade`
+calculation when a `gcode offset` has been applied to the Z axis.
 
 ### [bed_screws]
 
@@ -310,15 +343,18 @@ The following command is available when the
 enabled.
 
 #### SET_DUAL_CARRIAGE
-`SET_DUAL_CARRIAGE CARRIAGE=[0|1] [MODE=[PRIMARY|COPY|MIRROR]]`:
+`SET_DUAL_CARRIAGE CARRIAGE=<carriage> [MODE=[PRIMARY|COPY|MIRROR]]`:
 This command will change the mode of the specified carriage.
-If no `MODE` is provided it defaults to `PRIMARY`. Setting the mode
-to `PRIMARY` deactivates the other carriage and makes the specified
-carriage execute subsequent G-Code commands as-is. `COPY` and `MIRROR`
-modes are supported only for `CARRIAGE=1`. When set to either of these
-modes, carriage 1 will then track the subsequent moves of the carriage 0
-and either copy relative movements of it (in `COPY` mode) or execute them
-in the opposite (mirror) direction (in `MIRROR` mode).
+If no `MODE` is provided it defaults to `PRIMARY`. `<carriage>` must
+reference a defined primary or dual carriage for `generic_cartesian`
+kinematics or be 0 (for primary carriage) or 1 (for dual carriage)
+for all other kinematics supporting IDEX. Setting the mode to `PRIMARY`
+deactivates the other carriage and makes the specified carriage execute
+subsequent G-Code commands as-is. `COPY` and `MIRROR` modes are supported
+only for dual carriages. When set to either of these modes, dual carriage
+will then track the subsequent moves of its primary carriage and either
+copy relative movements of it (in `COPY` mode) or execute them in the
+opposite (mirror) direction (in `MIRROR` mode).
 
 #### SAVE_DUAL_CARRIAGE_STATE
 `SAVE_DUAL_CARRIAGE_STATE [NAME=<state_name>]`: Save the current positions
@@ -336,7 +372,7 @@ restored and "MOVE_SPEED" is specified, then the toolhead moves will be
 performed with the given speed (in mm/s); otherwise the toolhead move will
 use the rail homing speed. Note that the carriages restore their positions
 only over their own axis, which may be necessary to correctly restore COPY
-and MIRROR mode of the dual carraige.
+and MIRROR mode of the dual carriage.
 
 ### [endstop_phase]
 
@@ -447,12 +483,6 @@ MOTION_QUEUE (as defined in an [extruder](Config_Reference.md#extruder)
 config section). If MOTION_QUEUE is an empty string then the stepper
 will be desynchronized from all extruder movement.
 
-#### SET_EXTRUDER_STEP_DISTANCE
-This command is deprecated and will be removed in the near future.
-
-#### SYNC_STEPPER_TO_EXTRUDER
-This command is deprecated and will be removed in the near future.
-
 ### [fan_generic]
 
 The following command is available when a
@@ -463,6 +493,20 @@ enabled.
 `SET_FAN_SPEED FAN=config_name SPEED=<speed>` This command sets the
 speed of a fan. "speed" must be between 0.0 and 1.0.
 
+`SET_FAN_SPEED PIN=config_name TEMPLATE=<template_name>
+[<param_x>=<literal>]`: If `TEMPLATE` is specified then it assigns a
+[display_template](Config_Reference.md#display_template) to the given
+fan. For example, if one defined a `[display_template
+my_fan_template]` config section then one could assign
+`TEMPLATE=my_fan_template` here. The display_template should produce a
+string containing a floating point number with the desired value. The
+template will be continuously evaluated and the fan will be
+automatically set to the resulting speed. One may set display_template
+parameters to use during template evaluation (parameters will be
+parsed as Python literals). If TEMPLATE is an empty string then this
+command will clear any previous template assigned to the pin (one can
+then use `SET_FAN_SPEED` commands to manage the values directly).
+
 ### [filament_switch_sensor]
 
 The following command is available when a
@@ -540,15 +584,51 @@ state; issue a G28 afterwards to reset the kinematics. This command is
 intended for low-level diagnostics and debugging.
 
 #### SET_KINEMATIC_POSITION
-`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.
+
+`SET_KINEMATIC_POSITION [X=<value>] [Y=<value>] [Z=<value>]
+[SET_HOMED=<[X][Y][Z]>] [CLEAR_HOMED=<[X][Y][Z]>]`: Force the
+low-level kinematic code to believe the toolhead is at the given
+cartesian position and set/clear homed status. This is a diagnostic
+and debugging command; use SET_GCODE_OFFSET and/or G92 for regular
+axis transformations. Setting an incorrect or invalid position may
+lead to internal software errors.
+
+The `X`, `Y`, and `Z` parameters are used to alter the low-level
+kinematic position tracking. If any of these parameters are not set
+then the position is not changed - for example `SET_KINEMATIC_POSITION
+Z=10` would set all axes as homed, set the internal Z position to 10,
+and leave the X and Y positions unchanged. Changing the internal
+position tracking is not dependent on the internal homing state - one
+may alter the position for both homed and not homed axes, and
+similarly one may set or clear the homing state of an axis without
+altering its internal position.
+
+The `SET_HOMED` parameter defaults to `XYZ` which instructs the
+kinematics to consider all axes as homed. A bare
+`SET_KINEMATIC_POSITION` command will result in all axes being
+considered homed (and not change its current position). If it is not
+desired to change the state of homed axes then assign `SET_HOMED` to
+an empty string - for example:
+`SET_KINEMATIC_POSITION SET_HOMED= X=10`. It is also possible to
+request an individual axis be considered homed (eg, `SET_HOMED=X`),
+but note that non-cartesian style kinematics (such as delta
+kinematics) may not support setting an individual axis as homed.
+
+The `CLEAR_HOMED` parameter instructs the kinematics to consider the
+given axes as not homed. For example, `CLEAR_HOMED=XYZ` would request
+all axes to be considered not homed (and thus require homing prior to
+movement on those axes). The default is `SET_HOMED=XYZ` even if
+`CLEAR_HOMED` is present, so the command `SET_KINEMATIC_POSITION
+CLEAR_HOMED=Z` will set X and Y as homed and clear the homing state
+for Z.  Use `SET_KINEMATIC_POSITION SET_HOMED= CLEAR_HOMED=Z` if the
+goal is to clear only the Z homing state. If an axis is specified in
+neither `SET_HOMED` nor `CLEAR_HOMED` then its homing state is not
+changed and if it is specified in both then `CLEAR_HOMED` has
+precedence. It is possible to request clearing of an individual axis,
+but on non-cartesian style kinematics (such as delta kinematics) doing
+so may result in clearing the homing state of additional axes. Note
+the `CLEAR` parameter is currently an alias for the `CLEAR_HOMED`
+parameter, but this alias will be removed in the future.
 
 ### [gcode]
 
@@ -640,6 +720,46 @@ is specified then the toolhead move will be performed with the given
 speed (in mm/s); otherwise the toolhead move will use the restored
 g-code speed.
 
+### [generic_cartesian]
+The commands in this section become automatically available when
+`kinematics: generic_cartesian` is specified as the printer kinematics.
+
+#### SET_STEPPER_CARRIAGES
+`SET_STEPPER_CARRIAGES STEPPER=<stepper_name> CARRIAGES=<carriages>
+[DISABLE_CHECKS=[0|1]]`: Set or update the stepper carriages.
+`<stepper_name>` must reference an existing stepper defined in `printer.cfg`,
+and `<carriages>` describes the carriages the stepper moves. See
+[Generic Cartesian Kinematics](Config_Reference.md#generic-cartesian-kinematics)
+for a more detailed overview of the `carriages` parameter in the
+stepper configuration section. Note that it is only possible
+to change the coefficients or signs of the carriages with this
+command, but a user cannot add or remove the carriages that the stepper
+controls.
+
+`SET_STEPPER_CARRIAGES` is an advanced tool, and the user is advised
+to exercise an extreme caution using it, since specifying incorrect
+configuration may physically damage the printer.
+
+Note that `SET_STEPPER_CARRIAGES` performs certain internal validations
+of the new printer kinematics after the change. Keep in mind that if it
+detects an issue, it may leave printer kinematics in an invalid state.
+This means that if `SET_STEPPER_CARRIAGES` reports an error, it is unsafe
+to issue other GCode commands, and the user must inspect the error message
+and either fix the problem, or manually restore the previous stepper(s)
+configuration.
+
+Since `SET_STEPPER_CARRIAGES` can update a configuration of a single
+stepper at a time, some sequences of changes can lead to invalid
+intermediate kinematic configurations, even if the final configuration
+is valid. In such cases a user can pass `DISABLE_CHECKS=1` parameters to
+all but the last command to disable intermediate checks. For example,
+if `stepper a` and `stepper b` initially have `x-y` and `x+y` carriages
+correspondingly, then the following sequence of commands will let a user
+effectively swap the carriage controls:
+`SET_STEPPER_CARRIAGES STEPPER=a CARRIAGES=x+y DISABLE_CHECKS=1`
+and `SET_STEPPER_CARRIAGES STEPPER=b CARRIAGES=x-y`, while
+still validating the final kinematics state.
+
 ### [hall_filament_width_sensor]
 
 The following commands are available when the
@@ -718,6 +838,116 @@ together with either of SHAPER_TYPE_X and SHAPER_TYPE_Y parameters.
 See [config reference](Config_Reference.md#input_shaper) for more
 details on each of these parameters.
 
+### [led]
+
+The following command is available when any of the
+[led config sections](Config_Reference.md#leds) are enabled.
+
+#### SET_LED
+`SET_LED LED=<config_name> RED=<value> GREEN=<value> BLUE=<value>
+WHITE=<value> [INDEX=<index>] [TRANSMIT=0] [SYNC=1]`: This sets the
+LED output. Each color `<value>` must be between 0.0 and 1.0. The
+WHITE option is only valid on RGBW LEDs. If the LED supports multiple
+chips in a daisy-chain then one may specify INDEX to alter the color
+of just the given chip (1 for the first chip, 2 for the second,
+etc.). If INDEX is not provided then all LEDs in the daisy-chain will
+be set to the provided color. If TRANSMIT=0 is specified then the
+color change will only be made on the next SET_LED command that does
+not specify TRANSMIT=0; this may be useful in combination with the
+INDEX parameter to batch multiple updates in a daisy-chain. By
+default, the SET_LED command will sync it's changes with other ongoing
+gcode commands.  This can lead to undesirable behavior if LEDs are
+being set while the printer is not printing as it will reset the idle
+timeout. If careful timing is not needed, the optional SYNC=0
+parameter can be specified to apply the changes without resetting the
+idle timeout.
+
+#### SET_LED_TEMPLATE
+`SET_LED_TEMPLATE LED=<led_name> TEMPLATE=<template_name>
+[<param_x>=<literal>] [INDEX=<index>]`: Assign a
+[display_template](Config_Reference.md#display_template) to a given
+[LED](Config_Reference.md#leds). For example, if one defined a
+`[display_template my_led_template]` config section then one could
+assign `TEMPLATE=my_led_template` here. The display_template should
+produce a comma separated string containing four floating point
+numbers corresponding to red, green, blue, and white color settings.
+The template will be continuously evaluated and the LED will be
+automatically set to the resulting colors. One may set
+display_template parameters to use during template evaluation
+(parameters will be parsed as Python literals). If INDEX is not
+specified then all chips in the LED's daisy-chain will be set to the
+template, otherwise only the chip with the given index will be
+updated. If TEMPLATE is an empty string then this command will clear
+any previous template assigned to the LED (one can then use `SET_LED`
+commands to manage the LED's color settings).
+
+### [load_cell]
+
+The following commands are enabled if a
+[load_cell config section](Config_Reference.md#load_cell) has been enabled.
+
+### LOAD_CELL_DIAGNOSTIC
+`LOAD_CELL_DIAGNOSTIC [LOAD_CELL=<config_name>]`: This command collects 10
+seconds of load cell data and reports statistics that can help you verify proper
+operation of the load cell. This command can be run on both calibrated and
+uncalibrated load cells.
+
+### LOAD_CELL_CALIBRATE
+`LOAD_CELL_CALIBRATE [LOAD_CELL=<config_name>]`: Start the guided calibration
+utility. Calibration is a 3 step process:
+1. First you remove all load from the load cell and run the `TARE` command
+2. Next you apply a known load to the load cell and run the
+`CALIBRATE GRAMS=nnn` command
+3. Finally use the `ACCEPT` command to save the results
+
+You can cancel the calibration process at any time with `ABORT`.
+
+### LOAD_CELL_TARE
+`LOAD_CELL_TARE [LOAD_CELL=<config_name>]`: This works just like the tare button
+on digital scale. It sets the current raw reading of the load cell to be the
+zero point reference value. The response is the percentage of the sensors range
+that was read and the raw value in counts. If the load cell is calibrated a
+force in grams is also reported.
+
+### LOAD_CELL_READ load_cell="name"
+`LOAD_CELL_READ [LOAD_CELL=<config_name>]`:
+This command takes a reading from the load cell. The response is the percentage
+of the sensors range that was read and the raw value in counts. If the load cell
+is calibrated a force in grams is also reported.
+
+### [load_cell_probe]
+
+The following commands are enabled if a
+[load_cell config section](Config_Reference.md#load_cell_probe) has been
+enabled.
+
+### LOAD_CELL_TEST_TAP
+`LOAD_CELL_TEST_TAP [TAPS=<taps>] [TIMEOUT=<timeout>]`: Run a testing routine
+that reports taps on the load cell. The toolhead will not move but the load cell
+probe will sense taps just as if it was probing. This can be used as a
+sanity check to make sure that the probe works. This tool replaces
+QUERY_ENDSTOPS and QUERY_PROBE for load cell probes.
+- `TAPS`: the number of taps the tool expects
+- `TIMEOOUT`: the time, in seconds, that the tool waits for each tab before
+  aborting.
+
+### Load Cell Command Extensions
+Commands that perform probes, such as [`PROBE`](#probe),
+[`PROBE_ACCURACY`](#probe_accuracy),
+[`BED_MESH_CALIBRATE`](#bed_mesh_calibrate) etc. will accept additional
+parameters if a `[load_cell_probe]` is defined. The parameters override the
+corresponding settings from the
+[`[load_cell_probe]`](./Config_Reference.md#load_cell_probe) configuration:
+- `FORCE_SAFETY_LIMIT=<grams>`
+- `TRIGGER_FORCE=<grams>`
+- `DRIFT_FILTER_CUTOFF_FREQUENCY=<frequency_hz>`
+- `DRIFT_FILTER_DELAY=<1|2>`
+- `BUZZ_FILTER_CUTOFF_FREQUENCY=<frequency_hz>`
+- `BUZZ_FILTER_DELAY=<1|2>`
+- `NOTCH_FILTER_FREQUENCIES=<list of frequency_hz>`
+- `NOTCH_FILTER_QUALITY=<quality>`
+- `TARE_TIME=<seconds>`
+
 ### [manual_probe]
 
 The manual_probe module is automatically loaded.
@@ -774,6 +1004,25 @@ scheduled to run after the stepper move completes, however if a manual
 stepper move uses SYNC=0 then future G-Code movement commands may run
 in parallel with the stepper movement.
 
+`MANUAL_STEPPER STEPPER=config_name GCODE_AXIS=[A-Z]
+[LIMIT_VELOCITY=<velocity>] [LIMIT_ACCEL=<accel>]
+[INSTANTANEOUS_CORNER_VELOCITY=<velocity>]`: If the `GCODE_AXIS`
+parameter is specified then it configures the stepper motor as an
+extra axis on `G1` move commands.  For example, if one were to issue a
+`MANUAL_STEPPER ... GCODE_AXIS=R` command then one could issue
+commands like `G1 X10 Y20 R30` to move the stepper motor.  The
+resulting moves will occur synchronously with the associated toolhead
+xyz movements.  If the motor is associated with a `GCODE_AXIS` then
+one may no longer issue movements using the above `MANUAL_STEPPER`
+command - one may unregister the stepper with a `MANUAL_STEPPER
+... GCODE_AXIS=` command to resume manual control of the motor. The
+`LIMIT_VELOCITY` and `LIMIT_ACCEL` parameters allow one to reduce the
+speed of `G1` moves if those moves would result in a velocity or
+acceleration above the specified limits. The
+`INSTANTANEOUS_CORNER_VELOCITY` specifies the maximum instantaneous
+velocity change (in mm/s) of the motor during the junction of two
+moves (the default is 1mm/s).
+
 ### [mcp4018]
 
 The following command is available when a
@@ -788,67 +1037,32 @@ be between 0.0 and 1.0, unless a 'scale' is defined in the config.
 When 'scale' is defined, then this value should be  between 0.0 and
 'scale'.
 
-### [led]
-
-The following command is available when any of the
-[led config sections](Config_Reference.md#leds) are enabled.
-
-#### SET_LED
-`SET_LED LED=<config_name> RED=<value> GREEN=<value> BLUE=<value>
-WHITE=<value> [INDEX=<index>] [TRANSMIT=0] [SYNC=1]`: This sets the
-LED output. Each color `<value>` must be between 0.0 and 1.0. The
-WHITE option is only valid on RGBW LEDs. If the LED supports multiple
-chips in a daisy-chain then one may specify INDEX to alter the color
-of just the given chip (1 for the first chip, 2 for the second,
-etc.). If INDEX is not provided then all LEDs in the daisy-chain will
-be set to the provided color. If TRANSMIT=0 is specified then the
-color change will only be made on the next SET_LED command that does
-not specify TRANSMIT=0; this may be useful in combination with the
-INDEX parameter to batch multiple updates in a daisy-chain. By
-default, the SET_LED command will sync it's changes with other ongoing
-gcode commands.  This can lead to undesirable behavior if LEDs are
-being set while the printer is not printing as it will reset the idle
-timeout. If careful timing is not needed, the optional SYNC=0
-parameter can be specified to apply the changes without resetting the
-idle timeout.
-
-#### SET_LED_TEMPLATE
-`SET_LED_TEMPLATE LED=<led_name> TEMPLATE=<template_name>
-[<param_x>=<literal>] [INDEX=<index>]`: Assign a
-[display_template](Config_Reference.md#display_template) to a given
-[LED](Config_Reference.md#leds). For example, if one defined a
-`[display_template my_led_template]` config section then one could
-assign `TEMPLATE=my_led_template` here. The display_template should
-produce a comma separated string containing four floating point
-numbers corresponding to red, green, blue, and white color settings.
-The template will be continuously evaluated and the LED will be
-automatically set to the resulting colors. One may set
-display_template parameters to use during template evaluation
-(parameters will be parsed as Python literals). If INDEX is not
-specified then all chips in the LED's daisy-chain will be set to the
-template, otherwise only the chip with the given index will be
-updated. If TEMPLATE is an empty string then this command will clear
-any previous template assigned to the LED (one can then use `SET_LED`
-commands to manage the LED's color settings).
-
 ### [output_pin]
 
 The following command is available when an
-[output_pin config section](Config_Reference.md#output_pin) is
+[output_pin config section](Config_Reference.md#output_pin) or
+[pwm_tool config section](Config_Reference.md#pwm_tool) is
 enabled.
 
 #### SET_PIN
-`SET_PIN PIN=config_name VALUE=<value> [CYCLE_TIME=<cycle_time>]`: Set
-the pin to the given output `VALUE`. VALUE should be 0 or 1 for
-"digital" output pins. For PWM pins, set to a value between 0.0 and
-1.0, or between 0.0 and `scale` if a scale is configured in the
-output_pin config section.
+`SET_PIN PIN=config_name VALUE=<value>`: Set the pin to the given
+output `VALUE`. VALUE should be 0 or 1 for "digital" output pins. For
+PWM pins, set to a value between 0.0 and 1.0, or between 0.0 and
+`scale` if a scale is configured in the output_pin config section.
 
-Some pins (currently only "soft PWM" pins) support setting an explicit
-cycle time using the CYCLE_TIME parameter (specified in seconds). Note
-that the CYCLE_TIME parameter is not stored between SET_PIN commands
-(any SET_PIN command without an explicit CYCLE_TIME parameter will use
-the `cycle_time` specified in the output_pin config section).
+`SET_PIN PIN=config_name TEMPLATE=<template_name> [<param_x>=<literal>]`:
+If `TEMPLATE` is specified then it assigns a
+[display_template](Config_Reference.md#display_template) to the given
+pin. For example, if one defined a `[display_template
+my_pin_template]` config section then one could assign
+`TEMPLATE=my_pin_template` here. The display_template should produce a
+string containing a floating point number with the desired value. The
+template will be continuously evaluated and the pin will be
+automatically set to the resulting value. One may set display_template
+parameters to use during template evaluation (parameters will be
+parsed as Python literals). If TEMPLATE is an empty string then this
+command will clear any previous template assigned to the pin (one can
+then use `SET_PIN` commands to manage the values directly).
 
 ### [palette2]
 
@@ -885,20 +1099,6 @@ Palette 2 once the loading has been completed. This command is the
 same as pressing **Smart Load** directly on the Palette 2 screen after
 the filament load is complete.
 
-### [pid_calibrate]
-
-The pid_calibrate module is automatically loaded if a heater is defined
-in the config file.
-
-#### PID_CALIBRATE
-`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.
-
 ### [pause_resume]
 
 The following commands are available when the
@@ -924,6 +1124,20 @@ the paused state is fresh for each print.
 #### CANCEL_PRINT
 `CANCEL_PRINT`: Cancels the current print.
 
+### [pid_calibrate]
+
+The pid_calibrate module is automatically loaded if a heater is defined
+in the config file.
+
+#### PID_CALIBRATE
+`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.
+
 ### [print_stats]
 
 The print_stats module is automatically loaded.
@@ -977,6 +1191,58 @@ babystepping), and subtract if from the probe's z_offset.  This acts
 to take a frequently used babystepping value, and "make it permanent".
 Requires a `SAVE_CONFIG` to take effect.
 
+### [probe_eddy_current]
+
+The following commands are available when a
+[probe_eddy_current config section](Config_Reference.md#probe_eddy_current)
+is enabled.
+
+#### PROBE_EDDY_CURRENT_CALIBRATE
+`PROBE_EDDY_CURRENT_CALIBRATE CHIP=<config_name>`: This starts a tool
+that calibrates the sensor resonance frequencies to corresponding Z
+heights. The tool will take a couple of minutes to complete. After
+completion, use the SAVE_CONFIG command to store the results in the
+printer.cfg file.
+
+#### LDC_CALIBRATE_DRIVE_CURRENT
+`LDC_CALIBRATE_DRIVE_CURRENT CHIP=<config_name>` This tool will
+calibrate the ldc1612 DRIVE_CURRENT0 register. Prior to using this
+tool, move the sensor so that it is near the center of the bed and
+about 20mm above the bed surface. Run this command to determine an
+appropriate DRIVE_CURRENT for the sensor. After running this command
+use the SAVE_CONFIG command to store that new setting in the
+printer.cfg config file.
+
+### [pwm_cycle_time]
+
+The following command is available when a
+[pwm_cycle_time config section](Config_Reference.md#pwm_cycle_time)
+is enabled.
+
+#### SET_PIN
+`SET_PIN PIN=config_name VALUE=<value> [CYCLE_TIME=<cycle_time>]`:
+This command works similarly to [output_pin](#output_pin) SET_PIN
+commands. The command here supports setting an explicit cycle time
+using the CYCLE_TIME parameter (specified in seconds). Note that the
+CYCLE_TIME parameter is not stored between SET_PIN commands (any
+SET_PIN command without an explicit CYCLE_TIME parameter will use the
+`cycle_time` specified in the pwm_cycle_time config section).
+
+### [quad_gantry_level]
+
+The following commands are available when the
+[quad_gantry_level config section](Config_Reference.md#quad_gantry_level)
+is enabled.
+
+#### QUAD_GANTRY_LEVEL
+`QUAD_GANTRY_LEVEL [RETRIES=<value>] [RETRY_TOLERANCE=<value>]
+[HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>]`: This command
+will probe the points specified in the config and then make
+independent adjustments to each Z stepper to compensate for tilt. See
+the PROBE command for details on the optional probe parameters. The
+optional `RETRIES`, `RETRY_TOLERANCE`, and `HORIZONTAL_MOVE_Z` values
+override those options specified in the config file.
+
 ### [query_adc]
 
 The query_adc module is automatically loaded.
@@ -1012,20 +1278,19 @@ is enabled (also see the
 all enabled accelerometer chips.
 
 #### TEST_RESONANCES
-`TEST_RESONANCES AXIS=<axis> OUTPUT=<resonances,raw_data>
+`TEST_RESONANCES AXIS=<axis> [OUTPUT=<resonances,raw_data>]
 [NAME=<name>] [FREQ_START=<min_freq>] [FREQ_END=<max_freq>]
-[HZ_PER_SEC=<hz_per_sec>] [CHIPS=<adxl345_chip_name>]
-[POINT=x,y,z] [INPUT_SHAPING=[<0:1>]]`: Runs the resonance
+[ACCEL_PER_HZ=<accel_per_hz>] [HZ_PER_SEC=<hz_per_sec>] [CHIPS=<chip_name>]
+[POINT=x,y,z] [INPUT_SHAPING=<0:1>]`: Runs the resonance
 test in all configured probe points for the requested "axis" and
 measures the acceleration using the accelerometer chips configured for
 the respective axis. "axis" can either be X or Y, or specify an
 arbitrary direction as `AXIS=dx,dy`, where dx and dy are floating
 point numbers defining a direction vector (e.g. `AXIS=X`, `AXIS=Y`, or
 `AXIS=1,-1` to define a diagonal direction). Note that `AXIS=dx,dy`
-and `AXIS=-dx,-dy` is equivalent. `adxl345_chip_name` can be one or
-more configured adxl345 chip,delimited with comma, for example
-`CHIPS="adxl345, adxl345 rpi"`. Note that `adxl345` can be omitted from
-named adxl345 chips. If POINT is specified it will override the point(s)
+and `AXIS=-dx,-dy` is equivalent. `chip_name` can be one or
+more configured accel chips, delimited with comma, for example
+`CHIPS="adxl345, adxl345 rpi"`. If POINT is specified it will override the point(s)
 configured in `[resonance_tester]`. If `INPUT_SHAPING=0` or not set(default),
 disables input shaping for the resonance testing, because
 it is not valid to run the resonance testing with the input shaper
@@ -1042,8 +1307,9 @@ frequency response is calculated (across all probe points) and written into
 
 #### SHAPER_CALIBRATE
 `SHAPER_CALIBRATE [AXIS=<axis>] [NAME=<name>] [FREQ_START=<min_freq>]
-[FREQ_END=<max_freq>] [HZ_PER_SEC=<hz_per_sec>] [CHIPS=<adxl345_chip_name>]
-[MAX_SMOOTHING=<max_smoothing>]`: Similarly to `TEST_RESONANCES`, runs
+[FREQ_END=<max_freq>] [ACCEL_PER_HZ=<accel_per_hz>][HZ_PER_SEC=<hz_per_sec>]
+[CHIPS=<chip_name>] [MAX_SMOOTHING=<max_smoothing>] [INPUT_SHAPING=<0:1>]`:
+Similarly to `TEST_RESONANCES`, runs
 the resonance test as configured, and tries to find the optimal
 parameters for the input shaper for the requested axis (or both X and
 Y axes if `AXIS` parameter is unset). If `MAX_SMOOTHING` is unset, its
@@ -1093,8 +1359,9 @@ has been enabled.
 
 #### SAVE_VARIABLE
 `SAVE_VARIABLE VARIABLE=<name> VALUE=<value>`: Saves the variable to
-disk so that it can be used across restarts. All stored variables are
-loaded into the `printer.save_variables.variables` dict at startup and
+disk so that it can be used across restarts. The VARIABLE must be lowercase.
+All stored variables are loaded into the
+`printer.save_variables.variables` dict at startup and
 can be used in gcode macros. The provided VALUE is parsed as a Python
 literal.
 
@@ -1238,6 +1505,42 @@ temperature_fan. If a target is not supplied, it is set to the
 specified temperature in the config file. If speeds are not supplied,
 no change is applied.
 
+### [temperature_probe]
+
+The following commands are available when a
+[temperature_probe config section](Config_Reference.md#temperature_probe)
+is enabled.
+
+#### TEMPERATURE_PROBE_CALIBRATE
+`TEMPERATURE_PROBE_CALIBRATE [PROBE=<probe name>] [TARGET=<value>] [STEP=<value>]`:
+Initiates probe drift calibration for eddy current based probes.  The `TARGET`
+is a target temperature for the last sample.  When the temperature recorded
+during a sample exceeds the `TARGET` calibration will complete.  The `STEP`
+parameter sets temperature delta (in C) between samples. After a sample has
+been taken, this delta is used to schedule a call to `TEMPERATURE_PROBE_NEXT`.
+The default `STEP` is 2.
+
+#### TEMPERATURE_PROBE_NEXT
+`TEMPERATURE_PROBE_NEXT`: After calibration has started this command is run to
+take the next sample.  It is automatically scheduled to run when the delta
+specified by `STEP` has been reached, however its also possible to manually run
+this command to force a new sample.  This command is only available during
+calibration.
+
+#### TEMPERATURE_PROBE_COMPLETE:
+`TEMPERATURE_PROBE_COMPLETE`:  Can be used to end calibration and save the
+current result before the `TARGET` temperature is reached.  This command
+is only available during calibration.
+
+#### ABORT
+`ABORT`:  Aborts the calibration process, discarding the current results.
+This command is only available during drift calibration.
+
+### TEMPERATURE_PROBE_ENABLE
+`TEMPERATURE_PROBE_ENABLE ENABLE=[0|1]`: Sets temperature drift
+compensation on or off. If ENABLE is set to 0, drift compensation
+will be disabled, if set to 1 it is enabled.
+
 ### [tmcXXXX]
 
 The following commands are available when any of the
@@ -1280,8 +1583,11 @@ The toolhead module is automatically loaded.
 
 #### SET_VELOCITY_LIMIT
 `SET_VELOCITY_LIMIT [VELOCITY=<value>] [ACCEL=<value>]
-[ACCEL_TO_DECEL=<value>] [SQUARE_CORNER_VELOCITY=<value>]`: Modify the
-printer's velocity limits.
+[MINIMUM_CRUISE_RATIO=<value>] [SQUARE_CORNER_VELOCITY=<value>]`: This
+command can alter the velocity limits that were specified in the
+printer config file. See the
+[printer config section](Config_Reference.md#printer) for a
+description of each parameter.
 
 ### [tuning_tower]
 
@@ -1339,17 +1645,6 @@ print.
 #### SDCARD_RESET_FILE
 `SDCARD_RESET_FILE`: Unload file and clear SD state.
 
-### [axis_twist_compensation]
-
-The following commands are available when the
-[axis_twist_compensation config
-section](Config_Reference.md#axis_twist_compensation) is enabled.
-
-#### AXIS_TWIST_COMPENSATION_CALIBRATE
-`AXIS_TWIST_COMPENSATION_CALIBRATE [SAMPLE_COUNT=<value>]`: Initiates the X
-twist calibration wizard. `SAMPLE_COUNT` specifies the number of points along
-the X axis to calibrate at and defaults to 3.
-
 ### [z_thermal_adjust]
 
 The following commands are available when the
@@ -1374,8 +1669,10 @@ The following commands are available when the
 [z_tilt config section](Config_Reference.md#z_tilt) is enabled.
 
 #### Z_TILT_ADJUST
-`Z_TILT_ADJUST [HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>]`: This
-command will probe the points specified in the config and then make independent
-adjustments to each Z stepper to compensate for tilt. See the PROBE command for
-details on the optional probe parameters. The optional `HORIZONTAL_MOVE_Z`
-value overrides the `horizontal_move_z` option specified in the config file.
+`Z_TILT_ADJUST [RETRIES=<value>] [RETRY_TOLERANCE=<value>]
+[HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>]`: This command
+will probe the points specified in the config and then make
+independent adjustments to each Z stepper to compensate for tilt. See
+the PROBE command for details on the optional probe parameters. The
+optional `RETRIES`, `RETRY_TOLERANCE`, and `HORIZONTAL_MOVE_Z` values
+override those options specified in the config file.

docs/Installation.md

@@ -1,15 +1,20 @@
 # Installation
 
-These instructions assume the software will run on a Raspberry Pi
-computer in conjunction with OctoPrint. It is recommended that a
-Raspberry Pi 2, 3, or 4 computer be used as the host machine (see the
+These instructions assume the software will run on a Linux-based host
+running a Klipper-compatible front end. It is recommended that a
+SBC(Small Board Computer) such as a Raspberry Pi or Debian-based Linux
+device 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).
+for other options).
+
+For the purposes of these instructions, host relates to the Linux device and
+mcu relates to the printer board. SBC relates to the term Small Board Computer
+such as the Raspberry Pi.
 
 ## Obtain a Klipper Configuration File
 
 Most Klipper settings are determined by a "printer configuration file"
-that will be stored on the Raspberry Pi. An appropriate configuration
+printer.cfg, that will be stored on the host. An appropriate configuration
 file can often be found by looking in the Klipper
 [config directory](../config/) for a file starting with a "printer-"
 prefix that corresponds to the target printer. The Klipper
@@ -35,38 +40,51 @@ printer configuration file, then start with the closest example
 [config file](../config/) and use the Klipper
 [config reference](Config_Reference.md) for further information.
 
-## Prepping an OS image
+## Interacting with Klipper
 
-Start by installing [OctoPi](https://github.com/guysoft/OctoPi) on the
-Raspberry Pi computer. Use OctoPi v0.17.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.4.2 or later.
+Klipper is a 3d printer firmware, so it needs some way for the user to
+interact with it.
 
-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:
+Currently the best choices are front ends that retrieve information through
+the [Moonraker web API](https://moonraker.readthedocs.io/) and there is also
+the option to use [Octoprint](https://octoprint.org/) to control Klipper.
 
-```
-git clone https://github.com/Klipper3d/klipper
-./klipper/scripts/install-octopi.sh
-```
+The choice is up to the user on what to use, but the underlying Klipper is the
+same in all cases. We encourage users to research the options available and
+make an informed decision.
 
-The above will download Klipper, install some system dependencies,
-setup Klipper to run at system startup, and start the Klipper host
-software. It will require an internet connection and it may take a few
-minutes to complete.
+## Obtaining an OS image for SBC's
+
+There are many ways to obtain an OS image for Klipper for SBC use, most depend on
+what front end you wish to use. Some manufacturers of these SBC boards also provide
+their own Klipper-centric images.
+
+The two main Moonraker-based front ends are [Fluidd](https://docs.fluidd.xyz/)
+and [Mainsail](https://docs.mainsail.xyz/), the latter of which has a premade install
+image ["MainsailOS"](https://docs-os.mainsail.xyz/), this has the option for Raspberry Pi
+and some OrangePi variants.
+
+Fluidd can be installed via KIAUH(Klipper Install And Update Helper), which
+is explained below and is a 3rd party installer for all things Klipper.
+
+OctoPrint can be installed via the popular OctoPi image or via KIAUH, this
+process is explained in [OctoPrint.md](OctoPrint.md)
+
+## Installing via KIAUH
+
+Normally you would start with a base image for your SBC, RPiOS Lite for example,
+or in the case of an x86 Linux device, Ubuntu Server. Please note that Desktop
+variants are not recommended due to certain helper programs that can stop some
+Klipper functions from working and even mask access to some printer boards.
+
+KIAUH can be used to install Klipper and its associated programs on a variety
+of Linux-based systems that run a form of Debian. More information can be found
+at https://github.com/dw-0/kiauh
 
 ## Building and flashing the micro-controller
 
 To compile the micro-controller code, start by running these commands
-on the Raspberry Pi:
+on your host device:
 
 ```
 cd ~/klipper/
@@ -88,7 +106,7 @@ make
 If the comments at the top of the
 [printer configuration file](#obtain-a-klipper-configuration-file)
 describe custom steps for "flashing" the final image to the printer
-control board then follow those steps and then proceed to
+control board, then follow those steps and then proceed to
 [configuring OctoPrint](#configuring-octoprint-to-use-klipper).
 
 Otherwise, the following steps are often used to "flash" the printer
@@ -108,10 +126,40 @@ It should report something similar to the following:
 It's common for each printer to have its own unique serial port name.
 This unique name will be used when flashing the micro-controller. It's
 possible there may be multiple lines in the above output - if so,
-choose the line corresponding to the micro-controller (see the
+choose the line corresponding to the micro-controller. If many
+items are listed and the choice is ambiguous, unplug the board and
+run the command again, the missing item will be your print board(see the
 [FAQ](FAQ.md#wheres-my-serial-port) for more information).
 
-For common micro-controllers, the code can be flashed with something
+For common micro-controllers with STM32 or clone chips, LPC chips and
+others, it is usual that these need an initial Klipper flash via SD card.
+
+When flashing with this method, it is important to make sure that the
+print board is not connected with USB to the host, due to some boards
+being able to feed power back to the board and stopping a flash from
+occurring.
+
+Please note, that most print boards that use SD cards for flash will
+implement some kind of flash loop protection for when the sd card is left
+in place. There are two common methods:
+
+Filename Change Required (usually "stock" print boards):
+
+These boards require the firmware file to have a different name each
+time you flash (for example, firmware1.bin, firmware2.bin, etc.).
+If you reuse the same filename, the board may ignore it and not update.
+
+Automatic File Renaming (usually aftermarket print boards:
+
+Other boards allow using the same filename, commonly firmware.bin,
+but after flashing, the board renames the file to firmware.cur.
+This helps indicate the firmware was successfully flashed and prevents
+it from flashing again on the next startup.
+
+Before flashing, make sure to check which behavior your board follows.
+
+For common micro-controllers using Atmega chips, for example the 2560,
+the code can be flashed with something
 similar to:
 
 ```
@@ -123,53 +171,38 @@ sudo service klipper start
 Be sure to update the FLASH_DEVICE with the printer's unique serial
 port name.
 
-When flashing for the first time, make sure that OctoPrint is not
-connected directly to the printer (from the OctoPrint web page, under
-the "Connection" section, click "Disconnect").
+For common micro-controllers using RP2040 chips, the code can be flashed
+with something similar to:
 
-## Configuring OctoPrint to use Klipper
+```
+sudo service klipper stop
+make flash FLASH_DEVICE=first
+sudo service klipper start
+```
 
-The OctoPrint web server needs to be configured to communicate with
-the Klipper host software. Using a web browser, login to the OctoPrint
-web page and then configure the following items:
+It is important to note that RP2040 chips may need to be put into Boot mode
+before this operation.
 
-Navigate to the Settings tab (the wrench icon at the top of the
-page). Under "Serial Connection" in "Additional serial ports" add
-"/tmp/printer". Then click "Save".
-
-Enter the Settings tab again and under "Serial Connection" change the
-"Serial Port" setting to "/tmp/printer".
-
-In the Settings tab, navigate to the "Behavior" sub-tab and select the
-"Cancel any ongoing prints but stay connected to the printer"
-option. Click "Save".
-
-From the main page, under the "Connection" section (at the top left of
-the page) make sure the "Serial Port" is set to "/tmp/printer" and
-click "Connect". (If "/tmp/printer" is not an available selection then
-try reloading the page.)
-
-Once connected, navigate to the "Terminal" tab and type "status"
-(without the quotes) into the command entry box and click "Send". The
-terminal window will likely report there is an error opening the
-config file - that means OctoPrint is successfully communicating with
-Klipper. Proceed to the next section.
 
 ## Configuring Klipper
 
 The next step is to copy the
 [printer configuration file](#obtain-a-klipper-configuration-file) to
-the Raspberry Pi.
+the host.
 
-Arguably the easiest way to set 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). Load the printer config file
-in the editor and then save it as a file named "printer.cfg" in the
-home directory of the pi user (ie, /home/pi/printer.cfg).
+Arguably the easiest way to set the Klipper configuration file is using the
+built-in editors in Mainsail or Fluidd. These will allow the user to open
+the configuration examples and save them to be printer.cfg.
+
+Another option 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).
+Load the printer config file in the editor and then 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. That may look something like the following (be
+host via SSH. That may look something like the following (be
 sure to update the command to use the appropriate printer config
 filename):
 
@@ -200,9 +233,9 @@ the `[mcu]` section to look something similar to:
 serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0
 ```
 
-After creating and editing the file it will be necessary to issue a
-"restart" command in the OctoPrint web terminal to load the config. A
-"status" command will report the printer is ready if the Klipper
+After creating and editing the file, it will be necessary to issue a
+"restart" command in the command console to load the config. A
+"status" command will report that the printer is ready if the Klipper
 config file is successfully read and the micro-controller is
 successfully found and configured.
 
@@ -211,10 +244,10 @@ Klipper to report a configuration error. If an error occurs, make any
 necessary corrections to the printer config file and issue "restart"
 until "status" reports the printer is ready.
 
-Klipper reports error messages via the OctoPrint terminal tab. The
-"status" command can be used to re-report error messages. The default
-Klipper startup script also places a log in **/tmp/klippy.log** which
-provides more detailed information.
+Klipper reports error messages via the command console and pop-ups in
+Fluidd and Mainsail. The "status" command can be used to re-report error
+messages. A log is available and usually located at
+`~/printer_data/logs/klippy.log`.
 
 After Klipper reports that the printer is ready, proceed to the
 [config check document](Config_checks.md) to perform some basic checks

docs/Kinematics.md

@@ -96,7 +96,7 @@ Key formula for look-ahead:
 end_velocity^2 = start_velocity^2 + 2*accel*move_distance
 ```
 
-### Smoothed look-ahead
+### Minimum cruise ratio
 
 Klipper also implements a mechanism for smoothing out the motions of
 short "zigzag" moves. Consider the following moves:
@@ -105,21 +105,27 @@ short "zigzag" moves. Consider the following moves:
 
 In the above, the frequent changes from acceleration to deceleration
 can cause the machine to vibrate which causes stress on the machine
-and increases the noise. To reduce this, Klipper tracks both regular
-move acceleration as well as a virtual "acceleration to deceleration"
-rate. Using this system, the top speed of these short "zigzag" moves
-are limited to smooth out the printer motion:
+and increases the noise. Klipper implements a mechanism to ensure
+there is always some movement at a cruising speed between acceleration
+and deceleration. This is done by reducing the top speed of some moves
+(or sequence of moves) to ensure there is a minimum distance traveled
+at cruising speed relative to the distance traveled during
+acceleration and deceleration.
+
+Klipper implements this feature by tracking both a regular move
+acceleration as well as a virtual "acceleration to deceleration" rate:
 
 ![smoothed](img/smoothed.svg.png)
 
 Specifically, the code calculates what the velocity of each move would
 be if it were limited to this virtual "acceleration to deceleration"
-rate (half the normal acceleration rate by default). In the above
-picture the dashed gray lines represent this virtual acceleration rate
-for the first move. If a move can not reach its full cruising speed
-using this virtual acceleration rate then its top speed is reduced to
-the maximum speed it could obtain at this virtual acceleration
-rate. For most moves the limit will be at or above the move's existing
+rate. In the above picture the dashed gray lines represent this
+virtual acceleration rate for the first move. If a move can not reach
+its full cruising speed using this virtual acceleration rate then its
+top speed is reduced to the maximum speed it could obtain at this
+virtual acceleration rate.
+
+For most moves the limit will be at or above the move's existing
 limits and no change in behavior is induced. For short zigzag moves,
 however, this limit reduces the top speed. Note that it does not
 change the actual acceleration within the move - the move continues to

docs/Load_Cell.md

@@ -0,0 +1,489 @@
+# Load Cells
+
+This document describes Klipper's support for load cells. Basic load cell
+functionality can be used to read force data and to weigh things like filament.
+A calibrated force sensor is an important part of a load cell based probe.
+
+## Related Documentation
+
+* [load_cell Config Reference](Config_Reference.md#load_cell)
+* [load_cell G-Code Commands](G-Codes.md#load_cell)
+* [load_cell Status Reference](Status_Reference.md#load_cell)
+
+## Using `LOAD_CELL_DIAGNOSTIC`
+
+When you first connect a load cell its good practice to check for issues by
+running `LOAD_CELL_DIAGNOSTIC`. This tool collects 10 seconds of data from the
+load cell and resport statistics:
+
+```
+$ LOAD_CELL_DIAGNOSTIC
+// Collecting load cell data for 10 seconds...
+// Samples Collected: 3211
+// Measured samples per second: 332.0
+// Good samples: 3211, Saturated samples: 0, Unique values: 900
+// Sample range: [4.01% to 4.02%]
+// Sample range / sensor capacity: 0.00524%
+```
+
+Things you can check with this data:
+
+* The configured sample rate of the sensor should be close to the 'Measured
+  samples per second' value. If it is not you may have a configuration or wiring
+  issue.
+* 'Saturated samples' should be 0. If you have saturated samples it means the
+  load sell is seeing more force than it can measure.
+* 'Unique values' should be a large percentage of the 'Samples
+  Collected' value. If 'Unique values' is 1 it is very likely a wiring issue.
+* Tap or push on the sensor while `LOAD_CELL_DIAGNOSTIC` runs. If
+  things are working correctly this should increase the 'Sample range'.
+
+## Calibrating a Load Cell
+
+Load cells are calibrated using the `LOAD_CELL_CALIBRATE` command. This is an
+interactive calibration utility that walks you though a 3 step process:
+
+1. First use the `TARE` command to establish the zero force value. This is the
+   `reference_tare_counts` config value.
+2. Next you apply a known load or force to the load cell and run the
+   `CALIBRATE GRAMS=nnn` command. From this the `counts_per_gram` value is
+   calculated. See [the next section](#applying-a-known-force-or-load) for some
+   suggestions on how to do this.
+3. Finally, use the `ACCEPT` command to save the results.
+
+You can cancel the calibration process at any time with `ABORT`.
+
+### Applying a Known Force or Load
+
+The `CALIBRATE GRAMS=nnn` step can be accomplished in a number of ways. If your
+load cell is under a platform like a bed or filament holder it might be easiest
+to put a known mass on the platform. E.g. you could use a couple of 1KG filament
+spools.
+
+If your load cell is in the printer's toolhead a different approach is easier.
+Put a digital scale on the printers bed and gently lower the toolhead onto the
+scale (or raise the bed into the toolhead if your bed moves). You may be able to
+do this using the `FORCE_MOVE` command. But more likely you will have to
+manually moving the z axis with the motors off until the toolhead presses on the
+scale.
+
+A good calibration force would ideally be a large percentage of the load cell's
+rated capacity. E.g. if you have a 5Kg load cell you would ideally calibrate it
+with a 5kg mass. This might work well with under-bed sensors that have to
+support a lot of weight. For toolhead probes this may not be a load that your
+printer bed or toolhead can tolerate without damage. Do try to use at least 1Kg
+of force, most printers should tolerate this without issue.
+
+When calibrating make careful note of the values reported:
+
+```
+$ CALIBRATE GRAMS=555
+// Calibration value: -2.78% (-59803108), Counts/gram: 73039.78739,
+Total capacity: +/- 29.14Kg
+```
+
+The `Total capacity` should be close to the theoretical rating of the load cell
+based on the sensor's capacity. If it is much larger you could have used a
+higher gain setting in the sensor or a more sensitive load cell. This isn't as
+critical for 32bit and 24bit sensors but is much more critical for low bit width
+sensors.
+
+## Reading Force Data
+Force data can be read with a GCode command:
+
+```
+LOAD_CELL_READ
+// 10.6g (1.94%)
+```
+
+Data is also continuously read and can be consumed from the load_cell printer
+object in a macro:
+
+```
+{% set grams = printer.load_cell.force_g %}
+```
+
+This provides an average force over the last 1 second, similar to how
+temperature sensors work.
+
+## Taring a Load Cell
+Taring, sometimes called zeroing, sets the current weight reported by the
+load_cell to 0. This is useful for measuring relative to a known weight. e.g.
+when measuring a filament spool, using `LOAD_CELL_TARE` sets the weight to 0.
+Then as filament is printed the load_cell will report the weight of the
+filament used.
+
+```
+LOAD_CELL_TARE
+// Load cell tare value: 5.32% (445903)
+```
+
+The current tare value is reported in the printers status and can be read in
+a macro:
+
+```
+{% set tare_counts = printer.load_cell.tare_counts %}
+```
+
+# Load Cell Probes
+
+## Related Documentation
+
+* [load_cell_probe Config Reference](Config_Reference.md#load_cell_probe)
+* [load_cell_probe G-Code Commands](G-Codes.md#load_cell_probe)
+* [load_cell_probe Statuc Reference](Status_Reference.md#load_cell_probe)
+
+## Load Cell Probe Safety
+
+Because load cells are a direct nozzle contact probe there is a risk of
+damage to your printer if too much force is used. The load cell probing system
+includes a number of safety checks that try to keep your machine safe from
+excessive force to the toolhead. It's important to understand what they are
+and how they work as you can defeat most of them with poorly chosen config
+values.
+
+#### Calibration Check
+Every time a homing move starts, load_cell_probe checks
+that the load_cell is calibrated. If not it will stop the move with an error:
+`!! Load Cell not calibrated`.
+
+#### `counts_per_gram`
+This setting is used to convert raw sensor counts into grams. All the safety
+limits are in gram units for your convenience. If the `counts_per_gram`
+setting is not accurate you can easily exceed the safe force on the toolhead.
+You should never guess this value. Use `LOAD_CELL_CALIBRATE` to find your load
+cells actual `counts_per_gram`.
+
+#### `trigger_force`
+This is the force in grams that triggers the endstop to halt the homing move.
+When a homing move starts the endstop tares itself with the current reading
+from the load cell. `trigger_force` is measured from that tare value. There is
+always some overshoot of this value when the probe collides with the bed,
+so be conservative. e.g. a setting of 100g could result in 350g of peak force
+before the toolhead stops. This overshoot will increase with faster probing
+`speed`, a low ADC sample rate or [multi MCU homing](Multi_MCU_Homing.md).
+
+#### `reference_tare_counts`
+This is the baseline tare value that is set by `LOAD_CELL_CALIBRATE`.
+This value works with `force_safety_limit` to limit the maximum force on the
+toolhead.
+
+#### `force_safety_limit`
+This is the maximum absolute force, relative to `reference_tare_counts`,
+that the probe will allow while homing or probing. If the MCU sees this
+force exceeded it will shut down the printer with the error `!! Load cell
+endstop: too much force!`. There are a number of ways this can be triggered:
+
+The first risk this protects against is picking too large of a value for
+`drift_filter_cutoff_frequency`. This can cause the drift filter to filter out
+a probe event and continue the homing move. If this happens the
+`force_safety_limit` acts as a backup protection.
+
+The second problem is probing repeatedly in one place. Klipper does not retract
+the probe when doing a single `PROBE` command. This can result
+in force applied to the toolhead at the end of a probing cycle. Because
+external forces can vary greatly between probing locations,
+`load_cell_probe` performs a tare before beginning each probe. If you repeat
+the `PROBE` command, load_cell_probe will tare the endstop at the current force.
+Multiple cycles of this will result in ever-increasing force on the toolhead.
+`force_safety_limit` stops this cycle from running out of control.
+
+Another way this run-away can happen is damage to a strain gauge. If the metal
+part is permanently bent it will change the `reference_tare_counts` of the
+device. This puts the starting tare value much closer to the limit making it
+more likely to be violated. You want to be notified if this is happening
+because your hardware has been permanently damaged.
+
+The final way this can be triggered is due to temperature changes. If your
+strain gauges are heated their `reference_tare_counts` may be very different
+at ambient temperature vs operating temperature. In this case you may need
+to increase the `force_safety_limit` to allow for thermal changes.
+
+#### Load Cell Endstop Watchdog Task
+When homing the load_cell_endstop starts a task on the MCU to trac
+measurements arriving from the sensor. If the sensor fails to send
+measurements for 2 sample periods the watchdog will shut down the printer
+with an error `!! LoadCell Endstop timed out waiting on ADC data`.
+
+If this happens, the most likely cause is a fault from the ADC. Inadequate
+grounding of your printer can be the root cause. The frame, power supply
+case and pint bed should all be connected to ground. You may need to ground
+the frame in multiple places. Anodized aluminum extrusions do not conduct
+electricity well. You might need to sand the area where the grounding wire
+is attached to make good electrical contact.
+
+## Load Cell Probe Setup
+
+This section covers the process for commissioning a load cell probe.
+
+### Verify the Load Cell First
+
+A `[load_cell_probe]` is also a `[load_cell]` and G-code commands related to
+`[load_cell]` work with `[load_cell_probe]`. Before attempting to use a load
+cell probe, follow the directions for
+[calibrating the load cell](Load_Cell.md#calibrating-a-load-cell) with
+`CALIBRATE_LOAD_CELL` and checking its operation with `LOAD_CELL_DIAGNOSTIC`.
+
+### Verify Probe Operation With LOAD_CELL_TEST_TAP
+
+Use the command `LOAD_CELL_TEST_TAP` to test the operation of the load cell
+probe before actually trying to probe with it. This command detects taps,
+just like the PROBE command, but it does not move the z axis. By default, it
+listens for 3 taps before ending the test. You have 30 seconds to do each
+tap, if no taps are detected the command will time out.
+
+If this test fails, check your configuration and `LOAD_CELL_DIAGNOSTIC`
+carefully to look for issues.
+
+Load cell probes don't support the `QUERY_ENDSTOPS` or `QUERY_PROBE`
+commands. Use `LOAD_CELL_TEST_TAP` for testing functionality before probing.
+
+### Homing Macros
+
+Load cell probe is not an endstop and doesn't support `endstop:
+prove:z_virtual_endstop`. For the time being you'll need to configure your z
+axis with an MCU pin as its endstop. You won't actually be using the pin but
+for the time being you have to configure something.
+
+To home the axis with just the probe you need to set up a custom homing
+macro. This requires setting up
+[homing_override](Config_Reference.md#homing_override).
+
+Here is a simple macro that can accomplish this. Note that the
+`_HOME_Z_FROM_LAST_PROBE` macro has to be separate because of the way macros
+work. The sub-call is needed so that the `_HOME_Z_FROM_LAST_PROBE` macro can
+see the result of the probe in `printer.probe.last_z_result`.
+
+```gcode
+[gcode_macro _HOME_Z_FROM_LAST_PROBE]
+gcode:
+    {% set z_probed = printer.probe.last_z_result %}
+    {% set z_position = printer.toolhead.position[2] %}
+    {% set z_actual = z_position - z_probed %}
+    SET_KINEMATIC_POSITION Z={z_actual}
+
+[gcode_macro _HOME_Z]
+gcode:
+    SET_GCODE_OFFSET Z=0  # load cell probes dont need a Z offset
+    # position toolhead for homing Z, edit for your printers size
+    #G90  # absolute move
+    #G1 Y50 X50 F{5 * 60}  # move to X/Y position for homing
+
+    # soft home the z axis to its limit so it can be moved:
+    SET_KINEMATIC_POSITION Z={printer.toolhead.axis_maximum[2]}
+
+    # Fast approach and tap
+    PROBE PROBE_SPEED={5 * 60}  # override the speed for faster homing
+    _HOME_Z_FROM_LAST_PROBE
+
+    # lift z to 2mm
+    G91  # relative move
+    G1 Z2 F{5 * 60}
+
+    # probe at standard speed
+    PROBE
+    _HOME_Z_FROM_LAST_PROBE
+
+    # lift z to 10mm for clearance
+    G91  # relative move
+    G1 Z10 F{5 * 60}
+```
+
+### Suggested Probing Temperature
+
+Currently, we suggest keeping the nozzle temperature below the level that causes
+the filament to ooze while homing and probing. 140C is a good starting
+point. This temperature is also low enough not to scar PEI build surfaces.
+
+Fouling of the nozzle and the print bed due to oozing filament is the #1 source
+of probing error with the load cell probe. Klipper does not yet have a universal
+way to detect poor quality taps due to filament ooze. The existing code may
+decide that a tap is valid when it is of poor quality. Classifying these poor
+quality taps is an area of active research.
+
+Klipper also lacks support for re-locating a probe point if the
+location has become fouled by filament ooze. Modules like `quad_gantry_level`
+will repeatedly probe the same coordinates even if a probe previously failed
+there.
+
+Give the above it is strongly suggested not to probe at printing temperatures.
+
+### Hot Nozzle Protection
+
+The Voron project has a great macro for protecting your print surface from the
+hot nozzle. See [Voron Tap's
+`activate_gcode`](https://github.com/VoronDesign/Voron-Tap/blob/main/config/tap_klipper_instructions.md)
+
+It is highly suggested to add something like this to your config.
+
+### Nozzle Cleaning
+
+Before probing the nozzle should be clean. You could do this manually before
+every print. You can also implement a nozzle scrubber and automate the process.
+Here is a suggested sequence:
+
+1. Wait for the nozzle to heat up to probing temp (e.g. `M109 S140`)
+1. Home the machine (`G28`)
+1. Scrub the nozzle on a brush
+1. Heat soak the print bed
+1. Perform probing tasks: QGL, bed mesh etc.
+
+### Temperature Compensation for Nozzle Growth
+
+If you are probing at a safe temperature, the nozzle will expand after
+heating to printing temperatures. This will cause the nozzle to get longer
+and closer to the print surface. You can compensate for this with
+[[z_thermal_adjust]](Config_Reference.md#z_thermal_adjust). This adjustment will
+work across a range of printing
+temperatures from PLA to PC.
+
+#### Calculating the `temp_coeff` for `[z_thermal_adjust]`
+
+The easiest way to do this is to measure at 2 different temperatures.
+Ideally these should be the upper and lower limits of the printing
+temperature range. E.g. 180C and 290C. You can perform a `PROBE_ACCURACY` at
+both temperatures and then calculate the difference of the `average z` at both.
+
+The adjustment value is the change in nozzle length divided by the change in
+temperature. e.g.
+
+```
+temp_coeff = -0.05 / (290 - 180) = -0.00045455
+```
+
+The expected result is a negative number. Positive values for `temp_coeff` move
+the nozzle closer to the bed and negative values move it further away.
+Expect to have to move the nozzle further away as it gets longer when hot.
+
+#### Configure `[z_thermal_adjust]`
+Set up z_thermal_adjust to reference the `extruder` as the source of temperature
+data. E.g.:
+
+```
+[z_thermal_adjust nozzle]
+temp_coeff=-0.00045455
+sensor_type: temperature_combined
+sensor_list: extruder
+combination_method: max
+min_temp: 0
+max_temp: 400
+max_z_adjustment: 0.1
+```
+
+## Continuous Tare Filters for Toolhead Load Cells
+
+Klipper implements a configurable IIR filter on the MCU to provide continuous
+tareing of the load cell while probing. Continuous taring means the 0 value
+moves with drift caused by external factors like bowden tubes and thermal
+changes. This is aimed at toolhead sensors and moving beds that experience lots
+of external forces that change while probing.
+
+### Installing SciPy
+
+The filtering code uses the excellent [SciPy](https://scipy.org/) library to
+compute the filter coefficients based on the values your enter into the config.
+
+Pre-compiled SciPi builds are available for Python 3 on 32 bit Raspberry Pi
+systems. 32 bit + Python 3 is strongly recommended because it will streamline
+your installation experience. It does work with Python 2 but installation can
+take 30+ minutes and require installing additional tools.
+
+```bash
+~/klippy-env/bin/pip install scipy
+```
+
+### Filter Workbench
+
+The filter parameters should be selected based on drift seen on the printer
+during normal operation. A Jupyter notebook is provided in scripts,
+[filter_workbench.ipynb](../scripts/filter_workbench.ipynb), to perform a
+detailed investigation with real captured data and FFTs.
+
+### Filtering Suggestions
+
+For those just trying to get a filter working follow these suggestions:
+
+* The only essential option is `drift_filter_cutoff_frequency`. A conservative
+  starting value is `0.5`Hz. Prusa shipped the MK4 with a setting of `0.8`Hz and
+  the XL with `11.2`Hz. This is probably a safe range to experiment with. This
+  value should be increased only until normal drift due to bowden tube force is
+  eliminated. Setting this value too high will result in slow triggering and
+  excess force going through the toolhead.
+* Keep `trigger_force` low. The default is `75`g. The drift filter keeps the
+  internal grams value very close to 0 so a large trigger force is not needed.
+* Keep `force_safety_limit` to a conservative value. The default value is 2Kg
+  and should keep your toolhead safe while experimenting. If you hit this limit
+  the `drift_filter_cutoff_frequency` value may be too high.
+
+## Suggestions for Load Cell Tool Boards
+
+This section covers suggestions for those developing toolhead boards that want
+to support [load_cell_probe]
+
+### ADC Sensor Selection & Board Development Hints
+
+Ideally a sensor would meet these criteria:
+
+* At least 24 bits wide
+* Use SPI communications
+* Has a pin can be used to indicate sample ready without SPI communications.
+  This is often called the "data ready" or "DRDY" pin. Checking a pin is much
+  faster than running an SPI query.
+* Has a programmable gain amplifier gain setting of 128. This should eliminate
+  the need for a separate amplifier.
+* Indicates via SPI if the sensor has been reset. Detecting resets avoids
+  timing errors in homing and using noisy data at startup. It can also help
+  users
+  track down wiring and grounding issues.
+* A selectable sample rate between 350Hz and 2Khz. Very high sample rates don't
+  turn out to be beneficial in our 3D printers because they produce so much
+  noise
+  when moving fast. Sample rates below 250Hz will require slower probing speeds.
+  They also increase the force on the toolhead due to longer delays between
+  measurements. E.g. a 500Hz sensor moving at 5mm/s has the same safety factor
+  as
+  a 100Hz sensor moving at only 1mm/s.
+* If designing for under-bed applications, and you want to sense multiple load
+  cells, use a chip that can sample all of its inputs simultaneously. Multiplex
+  ADCs that require switching channels have a settling of several samples after
+  each channel switch making them unsuitable for probing applications.
+
+Implementing support for a new sensor chip is not particularly difficult with
+Klipper's `bulk_sensor` and `load_cell_endstop` infrastructure.
+
+### 5V Power Filtering
+
+It is strongly suggested to use larger capacitors than specified by the ADC chip
+manufacturer. ADC chips are usually targeted at low noise environments, like
+battery powered devices. Sensor manufacturers suggested application notes
+generally assume a quiet power supply. Treat their suggested capacitor values as
+minimums.
+
+3D printers put huge amounts of noise onto the 5V bus and this can ruin the
+sensor's accuracy. Test the sensor on the board with a typical 3D printer power
+supply and active stepper drivers before deciding on smoothing capacitor sizes.
+
+### Grounding & Ground Planes
+
+Analog ADC chips contain components that are very vulnerable to noise and
+ESD. A large ground plane on the first board layer under the chip can help with
+noise. Keep the chip away from power sections and DC to DC converters. The board
+should have proper grounding back to the DC supply.
+
+### HX711 and HX717 Notes
+
+This sensor is popular because of its low cost and availability in the
+supply chain. However, this is a sensor with some drawbacks:
+
+* The HX71x sensors use bit-bang communication which has a high overhead on the
+  MCU. Using a sensor that communicates via SPI would save resources on the tool
+  board's CPU.
+* The HX71x lacks a way to communicate reset events to the MCU. Klipper detects
+  resets with a timing heuristic but this is not ideal. Resets indicate a
+  problem with wiring or grounding.
+* For probing applications the HX717 version is strongly preferred because
+  of its higher sample rate (320 vs 80). Probing speed on the HX711 should be
+  limited to less than 2mm/s.
+* The sample rate on the HX71x cannot be set from klipper's config. If you have
+  the 10SPS version of the sensor (which is widely distributed) it needs to
+  be physically re-wired to run at 80SPS.

docs/Measuring_Resonances.md

@@ -1,24 +1,26 @@
 # Measuring Resonances
 
-Klipper has built-in support for the ADXL345, MPU-9250 and LIS2DW compatible
+Klipper has built-in support for the ADXL345, MPU-9250, LIS2DW and LIS3DH compatible
 accelerometers which can be used to measure resonance frequencies of the printer
 for different axes, and auto-tune [input shapers](Resonance_Compensation.md) to
 compensate for resonances. Note that using accelerometers requires some
-soldering and crimping. The ADXL345/LIS2DW can be connected to the SPI interface
+soldering and crimping. The ADXL345 can be connected to the SPI interface
 of a Raspberry Pi or MCU board (it needs to be reasonably fast). The MPU family can
 be connected to the I2C interface of a Raspberry Pi directly, or to an I2C
-interface of an MCU board that supports 400kbit/s *fast mode* in Klipper.
+interface of an MCU board that supports 400kbit/s *fast mode* in Klipper. The
+LIS2DW and LIS3DH can be connected to either SPI or I2C with the same considerations
+as above.
 
 When sourcing accelerometers, be aware that there are a variety of different PCB
 board designs and different clones of them. If it is going to be connected to a
 5V printer MCU ensure it has a voltage regulator and level shifters.
 
-For ADXL345s/LIS2DWs, make sure that the board supports SPI mode (a small number of
+For ADXL345s, make sure that the board supports SPI mode (a small number of
 boards appear to be hard-configured for I2C by pulling SDO to GND).
 
-For MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500s there are also a variety of
-board designs and clones with different I2C pull-up resistors which will need
-supplementing.
+For MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500/ICM20948s and LIS2DW/LIS3DH there
+are also a variety of board designs and clones with different I2C pull-up resistors
+which will need supplementing.
 
 ## MCUs with Klipper I2C *fast-mode* Support
 
@@ -27,6 +29,7 @@ supplementing.
 | Raspberry Pi | 3B+, Pico | 3A, 3A+, 3B, 4 |
 | AVR ATmega | ATmega328p | ATmega32u4, ATmega128, ATmega168, ATmega328, ATmega644p, ATmega1280, ATmega1284, ATmega2560 |
 | AVR AT90 | - | AT90usb646, AT90usb1286 |
+| SAMD | SAMC21G18 | SAMC21G18, SAMD21G18, SAMD21E18, SAMD21J18, SAMD21E15, SAMD51G19, SAMD51J19, SAMD51N19, SAMD51P20, SAME51J19, SAME51N19, SAME54P20 |
 
 ## Installation instructions
 
@@ -133,7 +136,7 @@ GND+SCL
 
 Note that unlike a cable shield, any GND(s) should be connected at both ends.
 
-#### MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500
+#### MPU-9250/MPU-9255/MPU-6515/MPU-6050/MPU-6500/ICM20948
 
 These accelerometers have been tested to work over I2C on the RPi, RP2040 (Pico)
 and AVR at 400kbit/s (*fast mode*). Some MPU accelerometer modules include
@@ -149,7 +152,7 @@ Recommended connection scheme for I2C on the Raspberry Pi:
 | SDA | 03 | GPIO02 (SDA1) |
 | SCL | 05 | GPIO03 (SCL1) |
 
-The RPi has buit-in 1.8K pull-ups on both SCL and SDA.
+The RPi has built-in 1.8K pull-ups on both SCL and SDA.
 
 ![MPU-9250 connected to Pi](img/mpu9250-PI-fritzing.png)
 
@@ -207,17 +210,25 @@ software dependencies not installed by default. First, run on your Raspberry Pi
 the following commands:
 ```
 sudo apt update
-sudo apt install python3-numpy python3-matplotlib libatlas-base-dev
+sudo apt install python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev
 ```
 
 Next, in order to install NumPy in the Klipper environment, run the command:
 ```
-~/klippy-env/bin/pip install -v numpy
+~/klippy-env/bin/pip install -v "numpy<1.26"
 ```
 Note that, depending on the performance of the CPU, it may take *a lot*
 of time, up to 10-20 minutes. Be patient and wait for the completion of
 the installation. On some occasions, if the board has too little RAM
-the installation may fail and you will need to enable swap.
+the installation may fail and you will need to enable swap. Also note
+the forced version, due to newer versions of NumPY having requirements
+that may not be satisfied in some klipper python environments.
+
+Once installed please check that no errors show from the command:
+```
+~/klippy-env/bin/python -c 'import numpy;'
+```
+The correct output should simply be a new line.
 
 #### Configure ADXL345 With RPi
 
@@ -305,7 +316,7 @@ you'll also want to modify your `printer.cfg` file to include this:
 
 Restart Klipper via the `RESTART` command.
 
-#### Configure LIS2DW series
+#### Configure LIS2DW series over SPI
 
 ```
 [mcu lis]
@@ -344,6 +355,7 @@ accel_chip: mpu9250
 probe_points:
     100, 100, 20  # an example
 ```
+If you are using the ICM20948, replace instances of "mpu9250" with "icm20948".
 
 #### Configure MPU-9520 Compatibles With Pico
 
@@ -366,6 +378,7 @@ probe_points:
 [static_digital_output pico_3V3pwm] # Improve power stability
 pins: pico:gpio23
 ```
+If you are using the ICM20948, replace instances of "mpu9250" with "icm20948".
 
 #### Configure MPU-9520 Compatibles with AVR
 
@@ -384,6 +397,7 @@ accel_chip: mpu9250
 probe_points:
     100, 100, 20  # an example
 ```
+If you are using the ICM20948, replace instances of "mpu9250" with "icm20948".
 
 Restart Klipper via the `RESTART` command.
 
@@ -450,7 +464,11 @@ TEST_RESONANCES AXIS=Y
 ```
 This will generate 2 CSV files (`/tmp/resonances_x_*.csv` and
 `/tmp/resonances_y_*.csv`). These files can be processed with the stand-alone
-script on a Raspberry Pi. To do that, run the following commands:
+script on a Raspberry Pi. This script is intended to be run with a single CSV
+file for each axis measured, although it can be used with multiple CSV files
+if you desire to average the results. Averaging results can be useful, for
+example, if resonance tests were done at multiple test points. Delete the extra
+CSV files if you do not desire to average them.
 ```
 ~/klipper/scripts/calibrate_shaper.py /tmp/resonances_x_*.csv -o /tmp/shaper_calibrate_x.png
 ~/klipper/scripts/calibrate_shaper.py /tmp/resonances_y_*.csv -o /tmp/shaper_calibrate_y.png
@@ -662,10 +680,41 @@ The same notice applies to the input shaper
 `max_accel` value after the auto-calibration, and the suggested acceleration
 limits will not be applied automatically.
 
+Keep in mind that the maximum acceleration without too much smoothing depends
+on the `square_corner_velocity`. The general recommendation is not to change
+it from its default value 5.0, and this is the value used by default by the
+`calibrate_shaper.py` script. If you did change it though, you should inform
+the script about it by passing `--square_corner_velocity=...` parameter, e.g.
+```
+~/klipper/scripts/calibrate_shaper.py /tmp/resonances_x_*.csv -o /tmp/shaper_calibrate_x.png --square_corner_velocity=10.0
+```
+so that it can calculate the maximum acceleration recommendations correctly.
+Note that the `SHAPER_CALIBRATE` command already takes the configured
+`square_corner_velocity` parameter into account, and there is no need
+to specify it explicitly.
+
 If you are doing a shaper re-calibration and the reported smoothing for the
 suggested shaper configuration is almost the same as what you got during the
 previous calibration, this step can be skipped.
 
+### Unreliable measurements of resonance frequencies
+
+Sometimes the resonance measurements can produce bogus results, leading to
+the incorrect suggestions for the input shapers. This can be caused by a
+variety of reasons, including running fans on the toolhead, incorrect
+position or non-rigid mounting of the accelerometer, or mechanical problems
+such as loose belts or binding or bumpy axis. Keep in mind that all fans
+should be disabled for resonance testing, especially the noisy ones, and
+that the accelerometer should be rigidly mounted on the corresponding
+moving part (e.g. on the bed itself for the bed slinger, or on the extruder
+of the printer itself and not the carriage, and some people get better
+results by mounting the accelerometer on the nozzle itself). As for
+mechanical problems, the user should inspect if there is any fault that
+can be fixed with a moving axis (e.g. linear guide rails cleaned up and
+lubricated and V-slot wheels tension adjusted correctly). If none of that
+helps, a user may try the other shapers from the produced list besides the
+one recommended by default.
+
 ### Testing custom axes
 
 `TEST_RESONANCES` command supports custom axes. While this is not really

docs/Multi_MCU_Homing.md

@@ -31,9 +31,15 @@ overshoot and account for it in its calculations. However, it is
 important that the hardware design is capable of handling overshoot
 without causing damage to the machine.
 
-Should Klipper detect a communication issue between micro-controllers
-during multi-mcu homing then it will raise a "Communication timeout
-during homing" error.
+In order to use this "multi-mcu homing" capability the hardware must
+have predictably low latency between the host computer and all of the
+micro-controllers. Typically the round-trip time must be consistently
+less than 10ms. High latency (even for short periods) is likely to
+result in homing failures.
+
+Should high latency result in a failure (or if some other
+communication issue is detected) then Klipper will raise a
+"Communication timeout during homing" error.
 
 Note that an axis with multiple steppers (eg, `stepper_z` and
 `stepper_z1`) need to be on the same micro-controller in order to use

docs/OctoPrint.md

@@ -0,0 +1,79 @@
+# OctoPrint for Klipper
+
+Klipper has a few options for its front ends, Octoprint was the first
+and original front end for Klipper. This document will give
+a brief overview of installing with this option.
+
+## Install with OctoPi
+
+Start by installing [OctoPi](https://github.com/guysoft/OctoPi) on the
+Raspberry Pi computer. Use OctoPi v0.17.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 if needed.
+
+After installing OctoPi and upgrading OctoPrint, it will be necessary
+to ssh into the target machine to run a handful of system commands.
+
+Start by running these commands on your host device:
+
+__If you do not have git installed, please do so with:__
+```
+sudo apt install git
+```
+then proceed:
+```
+cd ~
+git clone https://github.com/Klipper3d/klipper
+./klipper/scripts/install-octopi.sh
+```
+
+The above will download Klipper, install the needed system dependencies,
+setup Klipper to run at system startup, and start the Klipper host
+software. It will require an internet connection and it may take a few
+minutes to complete.
+
+## Installing with KIAUH
+
+KIAUH can be used to install OctoPrint on a variety of Linux based systems
+that run a form of Debian. More information can be found
+at https://github.com/dw-0/kiauh
+
+## Configuring OctoPrint to use Klipper
+
+The OctoPrint web server needs to be configured to communicate with the Klipper
+host software. Using a web browser, login to the OctoPrint web page and then
+configure the following items:
+
+Navigate to the Settings tab (the wrench icon at the top of the page).
+Under "Serial Connection" in "Additional serial ports" add:
+
+```
+~/printer_data/comms/klippy.serial
+```
+Then click "Save".
+
+_In some older setups this address may be `/tmp/printer`_
+
+
+Enter the Settings tab again and under "Serial Connection" change the "Serial Port"
+setting to the one added above.
+
+In the Settings tab, navigate to the "Behavior" sub-tab and select the
+"Cancel any ongoing prints but stay connected to the printer" option. Click "Save".
+
+From the main page, under the "Connection" section (at the top left of the page)
+make sure the "Serial Port" is set to the new additional one added
+and click "Connect". (If it is not in the available selection then
+try reloading the page.)
+
+Once connected, navigate to the "Terminal" tab and type "status" (without the quotes)
+into the command entry box and click "Send". The terminal window will likely report
+there is an error opening the config file - that means OctoPrint is successfully
+communicating with Klipper.
+
+Please proceed to [Installation.md](Installation.md) and the
+_Building and flashing the micro-controller_ section

docs/Overview.md

@@ -17,6 +17,7 @@ communication with the Klipper developers.
 ## Installation and Configuration
 
 - [Installation](Installation.md): Guide to installing Klipper.
+  - [Octoprint](OctoPrint.md): Guide to installing Octoprint with Klipper.
 - [Config Reference](Config_Reference.md): Description of config
   parameters.
   - [Rotation Distance](Rotation_Distance.md): Calculating the
@@ -99,3 +100,5 @@ communication with the Klipper developers.
     troubleshooting CAN bus.
 - [TSL1401CL filament width sensor](TSL1401CL_Filament_Width_Sensor.md)
 - [Hall filament width sensor](Hall_Filament_Width_Sensor.md)
+- [Eddy Current Inductive probe](Eddy_Probe.md)
+- [Load Cells](Load_Cell.md)

docs/Pressure_Advance.md

@@ -22,7 +22,7 @@ Use a slicer to generate g-code for the large hollow square found in
 [docs/prints/square_tower.stl](prints/square_tower.stl). Use a high
 speed (eg, 100mm/s), zero infill, and a coarse layer height (the layer
 height should be around 75% of the nozzle diameter). Make sure any
-"dynamic acceleration control" is disabled in the slicer.
+"dynamic acceleration control" and "scarf joint" seams are disabled in the slicer.
 
 Prepare for the test by issuing the following G-Code command:
 ```

docs/Probe_Calibrate.md

@@ -64,7 +64,7 @@ automatic probe point, then `ABORT` the manual probe tool and perform
 the XY probe offset calibration described above.
 
 Once the manual probe tool starts, follow the steps described at
-["the paper test"](Bed_Level.md#the-paper-test)) to determine the
+["the paper test"](Bed_Level.md#the-paper-test) to determine the
 actual distance between the nozzle and bed at the given location. Once
 those steps are complete one can `ACCEPT` the position and save the
 results to the config file with:

docs/Releases.md

@@ -3,6 +3,35 @@
 History of Klipper releases. Please see
 [installation](Installation.md) for information on installing Klipper.
 
+## Klipper 0.13.0
+
+Available on 20250411. Major changes in this release:
+* New "sweeping vibrations" resonance testing mechanism for input
+  shaper.
+* Fans and GPIO pins can now be assigned a formula (via Jinja2
+  "templates").
+* The bed_mesh code now supports "adaptive bed mesh". The area probed
+  can be adjusted for the size of the print.
+* A new `minimum_cruise_ratio` kinematic parameter has been added (it
+  replaces the previous `max_accel_to_decel` parameter).
+* Several new sensors added:
+  * Support for ldc1612 "eddy" current sensors. This includes probing
+    support, fast "scan" probing, and temperature calibration.
+  * New support for "load cell" measurements. Support for connecting
+    these load cells to hx71x and ads1220 ADC sensors.
+  * Support for BMP180, BMP388, and SHT3x temperature sensors. Support
+    for measuring temperature with ADS1x1x ADC chips.
+  * New lis3dh and icm20948 accelerometer support.
+  * Support for mt6816 and mt6826s "hall angle" sensors.
+* New micro-controller improvements:
+  * New support for rp2350 micro-controllers.
+  * Existing rp2040 chips now run at 200MHz (up from 125Mhz).
+  * The micro-controller code can now define many more commands (up to
+    16384 from 128).
+* Other modules added: aip31068_spi, canbus_stats, error_mcu,
+  garbage_collection, pwm_cycle_time, pwm_tool, garbage_collection.
+* Several bug fixes and code cleanups.
+
 ## Klipper 0.12.0
 
 Available on 20231110. Major changes in this release:

docs/Resonance_Compensation.md

@@ -48,8 +48,8 @@ First, measure the **ringing frequency**.
    to 5.0. It is not advised to increase it when using input shaper
    because it can cause more smoothing in parts - it is better to use
    higher acceleration value instead.
-2. Increase `max_accel_to_decel` by issuing the following command:
-   `SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`
+2. Disable the `minimum_cruise_ratio` feature by issuing the following
+   command: `SET_VELOCITY_LIMIT MINIMUM_CRUISE_RATIO=0`
 3. Disable Pressure Advance: `SET_PRESSURE_ADVANCE ADVANCE=0`
 4. If you have already added `[input_shaper]` section to the printer.cfg,
    execute `SET_INPUT_SHAPER SHAPER_FREQ_X=0 SHAPER_FREQ_Y=0` command. If you
@@ -149,7 +149,7 @@ a few other related parameters.
 Print the ringing test model as follows:
 
 1. Restart the firmware: `RESTART`
-2. Prepare for test: `SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`
+2. Prepare for test: `SET_VELOCITY_LIMIT MINIMUM_CRUISE_RATIO=0`
 3. Disable Pressure Advance: `SET_PRESSURE_ADVANCE ADVANCE=0`
 4. Execute: `SET_INPUT_SHAPER SHAPER_TYPE=MZV`
 5. Execute the command:
@@ -270,7 +270,7 @@ frequencies after enabling [input_shaper], this section will not help with that.
 Assuming that you have sliced the ringing model with suggested
 parameters, complete the following steps for each of the axes X and Y:
 
-1. Prepare for test: `SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`
+1. Prepare for test: `SET_VELOCITY_LIMIT MINIMUM_CRUISE_RATIO=0`
 2. Make sure Pressure Advance is disabled: `SET_PRESSURE_ADVANCE ADVANCE=0`
 3. Execute: `SET_INPUT_SHAPER SHAPER_TYPE=ZV`
 4. From the existing ringing test model with your chosen input shaper select
@@ -331,7 +331,7 @@ with suggested parameters, print the test model 3 times as
 follows. First time, prior to printing, run
 
 1. `RESTART`
-2. `SET_VELOCITY_LIMIT ACCEL_TO_DECEL=7000`
+2. `SET_VELOCITY_LIMIT MINIMUM_CRUISE_RATIO=0`
 3. `SET_PRESSURE_ADVANCE ADVANCE=0`
 4. `SET_INPUT_SHAPER SHAPER_TYPE=2HUMP_EI SHAPER_FREQ_X=60 SHAPER_FREQ_Y=60`
 5. `TUNING_TOWER COMMAND=SET_VELOCITY_LIMIT PARAMETER=ACCEL START=1500 STEP_DELTA=500 STEP_HEIGHT=5`

docs/Skew_Correction.md

@@ -21,7 +21,7 @@ or by issuing a `SET_SKEW CLEAR=1` gcode.
 
 ## Take your measurements
 
-The `[skew_correcton]` module requires 3 measurements for each plane you want
+The `[skew_correction]` module requires 3 measurements for each plane you want
 to correct; the length from Corner A to Corner C, the length from Corner B
 to Corner D, and the length from Corner A to Corner D.  When measuring length
 AD do not include the flats on the corners that some test objects provide.
@@ -31,7 +31,7 @@ AD do not include the flats on the corners that some test objects provide.
 ## Configure your skew
 
 Make sure `[skew_correction]` is in printer.cfg.  You may now use the `SET_SKEW`
-gcode to configure skew_correcton.  For example, if your measured lengths
+gcode to configure skew_correction.  For example, if your measured lengths
 along XY are as follows:
 
 ```

docs/Slicers.md

@@ -121,5 +121,5 @@ M104 S0
 before the macro call. Also note that SuperSlicer has a
 "custom gcode only" button option, which achieves the same outcome.
 
-An example of a START_PRINT macro using these paramaters can
+An example of a START_PRINT macro using these parameters can
 be found in config/sample-macros.cfg

docs/Sponsors.md

@@ -17,7 +17,6 @@ serve the 3D printing community better. Follow them on
 ## Sponsors
 
 [<img src="./img/sponsors/obico-light-horizontal.png" width="200" style="margin:25px" />](https://obico.io/klipper.html?source=klipper_sponsor)
-[<img src="./img/sponsors/peopoly-logo.png" width="200" style="margin:25px" />](https://peopoly.net)
 
 ## Klipper Developers
 

docs/Status_Reference.md

@@ -31,7 +31,7 @@ The following information is available in the
 ## bed_screws
 
 The following information is available in the
-`Config_Reference.md#bed_screws` object:
+[bed_screws](Config_Reference.md#bed_screws) object:
 - `is_active`: Returns True if the bed screws adjustment tool is currently
 active.
 - `state`: The bed screws adjustment tool state. It is one of
@@ -39,6 +39,27 @@ the following strings: "adjust", "fine".
 - `current_screw`: The index for the current screw being adjusted.
 - `accepted_screws`: The number of accepted screws.
 
+## canbus_stats
+
+The following information is available in the `canbus_stats
+some_mcu_name` object (this object is automatically available if an
+mcu is configured to use canbus):
+- `rx_error`: The number of receive errors detected by the
+  micro-controller canbus hardware.
+- `tx_error`: The number of transmit errors detected by the
+  micro-controller canbus hardware.
+- `tx_retries`: The number of transmit attempts that were retried due
+  to bus contention or errors.
+- `bus_state`: The status of the interface (typically "active" for a
+  bus in normal operation, "warn" for a bus with recent errors,
+  "passive" for a bus that will no longer transmit canbus error
+  frames, or "off" for a bus that will no longer transmit or receive
+  messages).
+
+Note that only the rp2XXX micro-controllers report a non-zero
+`tx_retries` field and the rp2XXX micro-controllers always report
+`tx_error` as zero and `bus_state` as "active".
+
 ## configfile
 
 The following information is available in the `configfile` object
@@ -168,6 +189,12 @@ The following information is available in the
   module. These settings may differ from the config file if a
   `SET_RETRACTION` command alters them.
 
+## gcode
+
+The following information is available in the `gcode` object:
+- `commands`: Returns a list of all currently available commands. For each
+  command, if a help string is defined it will also be provided.
+
 ## gcode_button
 
 The following information is available in
@@ -215,6 +242,8 @@ The following information is available in the `gcode_move` object
 The following information is available in the
 [hall_filament_width_sensor](Config_Reference.md#hall_filament_width_sensor)
 object:
+- all items from
+  [filament_switch_sensor](Status_Reference.md#filament_switch_sensor)
 - `is_active`: Returns True if the sensor is currently active.
 - `Diameter`: The last reading from the sensor in mm.
 - `Raw`: The last raw ADC reading from the sensor.
@@ -262,6 +291,9 @@ is always available):
 - `printing_time`: The amount of time (in seconds) the printer has
   been in the "Printing" state (as tracked by the idle_timeout
   module).
+- `idle_timeout`: The current 'timeout' (in seconds)
+   to wait for the gcode to be triggered.
+   (as set by [SET_IDLE_TIMEOUT](G-Codes.md#set_idle_timeout))
 
 ## led
 
@@ -271,11 +303,31 @@ The following information is available for each `[led led_name]`,
 - `color_data`: A list of color lists containing the RGBW values for a
   led in the chain. Each value is represented as a float from 0.0 to
   1.0. Each color list contains 4 items (red, green, blue, white) even
-  if the underyling LED supports fewer color channels. For example,
+  if the underlying LED supports fewer color channels. For example,
   the blue value (3rd item in color list) of the second neopixel in a
   chain could be accessed at
   `printer["neopixel <config_name>"].color_data[1][2]`.
 
+## load_cell
+
+The following information is available for each `[load_cell name]`:
+- 'is_calibrated': True/False is the load cell calibrated
+- 'counts_per_gram': The number of raw sensor counts that equals 1 gram of force
+- 'reference_tare_counts': The reference number of raw sensor counts for 0 force
+- 'tare_counts': The current number of raw sensor counts for 0 force
+- 'force_g': The force in grams, averaged over the last polling period.
+- 'min_force_g': The minimum force in grams, over the last polling period.
+- 'max_force_g': The maximum force in grams, over the last polling period.
+
+## load_cell_probe
+
+The following information is available for `[load_cell_probe]`:
+- all items from [load_cell](Status_Reference.md#load_cell)
+- all items from [probe](Status_Reference.md#probe)
+- 'endstop_tare_counts': the load cell probe keeps a tare value independent of
+the load cell. This re-set at the start of each probe.
+- 'last_trigger_time': timestamp of the last homing trigger
+
 ## manual_probe
 
 The following information is available in the
@@ -318,7 +370,8 @@ is defined):
 ## output_pin
 
 The following information is available in
-[output_pin some_name](Config_Reference.md#output_pin) objects:
+[output_pin some_name](Config_Reference.md#output_pin) and
+[pwm_tool some_name](Config_Reference.md#pwm_tool) objects:
 - `value`: The "value" of the pin, as set by a `SET_PIN` command.
 
 ## palette2
@@ -367,6 +420,13 @@ is defined):
   template expansion, the PROBE (or similar) command must be run prior
   to the macro containing this reference.
 
+## pwm_cycle_time
+
+The following information is available in
+[pwm_cycle_time some_name](Config_Reference.md#pwm_cycle_time)
+objects:
+- `value`: The "value" of the pin, as set by a `SET_PIN` command.
+
 ## quad_gantry_level
 
 The following information is available in the `quad_gantry_level` object
@@ -412,6 +472,12 @@ The following information is available in
 - `printer["servo <config_name>"].value`: The last setting of the PWM
   pin (a value between 0.0 and 1.0) associated with the servo.
 
+## skew_correction.py
+
+The following information is available in the `skew_correction` object (this
+object is available if any skew_correction is defined):
+- `current_profile_name`: Returns the name of the currently loaded SKEW_PROFILE.
+
 ## stepper_enable
 
 The following information is available in the `stepper_enable` object (this
@@ -431,6 +497,7 @@ The following information is available in
 
 [bme280 config_section_name](Config_Reference.md#bmp280bme280bme680-temperature-sensor),
 [htu21d config_section_name](Config_Reference.md#htu21d-sensor),
+[sht3x config_section_name](Config_Reference.md#sht31-sensor),
 [lm75 config_section_name](Config_Reference.md#lm75-temperature-sensor),
 [temperature_host config_section_name](Config_Reference.md#host-temperature-sensor)
 and
@@ -438,7 +505,7 @@ and
 objects:
 - `temperature`: The last read temperature from the sensor.
 - `humidity`, `pressure`, `gas`: The last read values from the sensor
-  (only on bme280, htu21d, and lm75 sensors).
+  (only on bme280, htu21d, sht3x and lm75 sensors).
 
 ## temperature_fan
 
@@ -497,7 +564,7 @@ The following information is available in the `toolhead` object
   limit value (eg, `axis_minimum.x`, `axis_maximum.z`).
 - For Delta printers the `cone_start_z` is the max z height at
   maximum radius (`printer.toolhead.cone_start_z`).
-- `max_velocity`, `max_accel`, `max_accel_to_decel`,
+- `max_velocity`, `max_accel`, `minimum_cruise_ratio`,
   `square_corner_velocity`: The current printing limits that are in
   effect. This may differ from the config file settings if a
   `SET_VELOCITY_LIMIT` (or `M204`) command alters them at run-time.
@@ -515,6 +582,12 @@ on a cartesian, hybrid_corexy or hybrid_corexz robot
 - `carriage_1`: The mode of the carriage 1. Possible values are:
   "INACTIVE", "PRIMARY", "COPY", and "MIRROR".
 
+On a `generic_cartesian` kinematic, the following information is
+available in `dual_carriage`:
+- `carriages["<carriage>"]`: The mode of the carriage `<carriage>`. Possible
+  values are "INACTIVE" and "PRIMARY" for the primary carriage and "INACTIVE",
+  "PRIMARY", "COPY", and "MIRROR" for the dual carriage.
+
 ## virtual_sdcard
 
 The following information is available in the

docs/TMC_Drivers.md

@@ -83,6 +83,10 @@ setting `stealthchop_threshold` to 999999). Unfortunately, the drivers
 often produce poor and confusing results if the mode changes while the
 motor is at a non-zero velocity.
 
+Note that the `stealthchop_threshold` config option does not impact
+sensorless homing as Klipper automatically switches the TMC driver to
+an appropriate mode during sensorless homing operations.
+
 ## TMC interpolate setting introduces small position deviation
 
 The TMC driver `interpolate` setting may reduce the audible noise of

docs/Using_PWM_Tools.md

@@ -1,7 +1,7 @@
 # Using PWM tools
 
 This document describes how to setup a PWM-controlled laser or spindle
-using `output_pin` and some macros.
+using `pwm_tool` and some macros.
 
 ## How does it work?
 
@@ -26,14 +26,6 @@ so that when your host or MCU encounters an error, the tool will stop.
 
 For an example configuration, see [config/sample-pwm-tool.cfg](/config/sample-pwm-tool.cfg).
 
-## Current Limitations
-
-There is a limitation of how frequent PWM updates may occur.
-While being very precise, a PWM update may only occur every 0.1 seconds,
-rendering it almost useless for raster engraving.
-However, there exists an [experimental branch](https://github.com/Cirromulus/klipper/tree/laser_tool) with its own tradeoffs.
-In long term, it is planned to add this functionality to main-line klipper.
-
 ## Commands
 
 `M3/M4 S<value>` : Set PWM duty-cycle. Values between 0 and 255.

docs/_klipper3d/README

@@ -8,13 +8,13 @@ directory, the docs/CNAME file also controls the website generation.
 To test deploy the main English site locally one can use commands
 similar to the following:
 
-virtualenv ~/mkdocs-env && ~/python-env/bin/pip install -r ~/klipper/docs/_klipper3d/mkdocs-requirements.txt
+virtualenv ~/mkdocs-env && ~/mkdocs-env/bin/pip install -r ~/klipper/docs/_klipper3d/mkdocs-requirements.txt
 cd ~/klipper && ~/mkdocs-env/bin/mkdocs serve --config-file ~/klipper/docs/_klipper3d/mkdocs.yml -a 0.0.0.0:8000
 
 To test deploy the multi-language site locally one can use commands
 similar to the following:
 
-virtualenv ~/mkdocs-env && ~/python-env/bin/pip install -r ~/klipper/docs/_klipper3d/mkdocs-requirements.txt
+virtualenv ~/mkdocs-env && ~/mkdocs-env/bin/pip install -r ~/klipper/docs/_klipper3d/mkdocs-requirements.txt
 source ~/mkdocs-env/bin/activate
 cd ~/klipper && ./docs/_klipper3d/build-translations.sh
 cd ~/klipper/site/ && python3 -m http.server 8000

docs/_klipper3d/mkdocs-requirements.txt

@@ -1,6 +1,6 @@
 # Python virtualenv module requirements for mkdocs
-jinja2==3.0.3
-mkdocs==1.2.3
+jinja2==3.1.6
+mkdocs==1.2.4
 mkdocs-material==8.1.3
 mkdocs-simple-hooks==0.1.3
 mkdocs-exclude==1.0.2

docs/_klipper3d/mkdocs.yml

@@ -71,7 +71,7 @@ extra:
   # https://squidfunk.github.io/mkdocs-material/setup/setting-up-site-analytics/#site-search-tracking
   analytics:
     provider: google
-    property: UA-138371409-1
+    property: G-VEN1PGNQL4
   # Language Selection
   alternate:
     - name: English
@@ -88,7 +88,9 @@ nav:
   - Config_Changes.md
   - Contact.md
   - Installation and Configuration:
-    - Installation.md
+    - Installation:
+      - Installation.md
+      - OctoPrint.md
     - Configuration Reference:
       - Config_Reference.md
       - Rotation_Distance.md
@@ -138,4 +140,6 @@ nav:
     - CANBUS_Troubleshooting.md
     - TSL1401CL_Filament_Width_Sensor.md
     - Hall_Filament_Width_Sensor.md
+    - Eddy_Probe.md
+    - Load_Cell.md
   - Sponsors.md

docs/index.md

@@ -6,13 +6,14 @@ title: Welcome
 
 ![](img/klipper-logo.png){ .center-image }
 
-Klipper is a 3d-Printer firmware. It combines the power of a general
-purpose computer with one or more micro-controllers. See the
-[features](Features.md) document for more information on why you
-should use Klipper.
+The Klipper firmware controls 3d-Printers. It combines the power of a
+general purpose computer with one or more micro-controllers. See the
+[features document](Features.md) for more information on why you
+should use the Klipper software.
 
-To begin using Klipper start by [installing](Installation.md) it.
+Start by [installing Klipper software](Installation.md).
 
-Klipper is Free Software. Read the [documentation](Overview.md) or
-view [the Klipper code on github](https://github.com/Klipper3d/klipper).
-We depend on the generous support from our [sponsors](Sponsors.md).
+Klipper software is Free Software. Read the
+[documentation](Overview.md), see the [license](../COPYING), or
+[download](https://github.com/Klipper3d/Klipper) the software. We
+depend on the generous support from our [sponsors](Sponsors.md).

klippy/chelper/__init__.py

@@ -17,16 +17,16 @@ COMPILE_ARGS = ("-Wall -g -O2 -shared -fPIC"
                 " -o %s %s")
 SSE_FLAGS = "-mfpmath=sse -msse2"
 SOURCE_FILES = [
-    'pyhelper.c', 'serialqueue.c', 'stepcompress.c', 'itersolve.c', 'trapq.c',
-    'pollreactor.c', 'msgblock.c', 'trdispatch.c',
+    'pyhelper.c', 'serialqueue.c', 'stepcompress.c', 'steppersync.c',
+    'itersolve.c', 'trapq.c', 'pollreactor.c', 'msgblock.c', 'trdispatch.c',
     'kin_cartesian.c', 'kin_corexy.c', 'kin_corexz.c', 'kin_delta.c',
     'kin_deltesian.c', 'kin_polar.c', 'kin_rotary_delta.c', 'kin_winch.c',
-    'kin_extruder.c', 'kin_shaper.c', 'kin_idex.c',
+    'kin_extruder.c', 'kin_shaper.c', 'kin_idex.c', 'kin_generic.c'
 ]
 DEST_LIB = "c_helper.so"
 OTHER_FILES = [
-    'list.h', 'serialqueue.h', 'stepcompress.h', 'itersolve.h', 'pyhelper.h',
-    'trapq.h', 'pollreactor.h', 'msgblock.h'
+    'list.h', 'serialqueue.h', 'stepcompress.h', 'steppersync.h',
+    'itersolve.h', 'pyhelper.h', 'trapq.h', 'pollreactor.h', 'msgblock.h'
 ]
 
 defs_stepcompress = """
@@ -49,27 +49,33 @@ defs_stepcompress = """
         , uint64_t clock);
     int stepcompress_queue_msg(struct stepcompress *sc
         , uint32_t *data, int len);
+    int stepcompress_queue_mq_msg(struct stepcompress *sc, uint64_t req_clock
+        , uint32_t *data, int len);
     int stepcompress_extract_old(struct stepcompress *sc
         , struct pull_history_steps *p, int max
         , uint64_t start_clock, uint64_t end_clock);
+    void stepcompress_set_stepper_kinematics(struct stepcompress *sc
+        , struct stepper_kinematics *sk);
+"""
 
+defs_steppersync = """
     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);
+    int32_t steppersync_generate_steps(struct steppersync *ss
+        , double gen_steps_time, uint64_t flush_clock);
+    void steppersync_history_expire(struct steppersync *ss, uint64_t end_clock);
     int steppersync_flush(struct steppersync *ss, uint64_t move_clock);
 """
 
 defs_itersolve = """
-    int32_t itersolve_generate_steps(struct stepper_kinematics *sk
-        , double flush_time);
     double itersolve_check_active(struct stepper_kinematics *sk
         , double flush_time);
     int32_t itersolve_is_active_axis(struct stepper_kinematics *sk, char axis);
-    void itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq);
-    void itersolve_set_stepcompress(struct stepper_kinematics *sk
-        , struct stepcompress *sc, double step_dist);
+    void itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq
+        , double step_dist);
     double itersolve_calc_position_from_coord(struct stepper_kinematics *sk
         , double x, double y, double z);
     void itersolve_set_position(struct stepper_kinematics *sk
@@ -92,7 +98,8 @@ defs_trapq = """
         , double start_pos_x, double start_pos_y, double start_pos_z
         , double axes_r_x, double axes_r_y, double axes_r_z
         , double start_v, double cruise_v, double accel);
-    void trapq_finalize_moves(struct trapq *tq, double print_time);
+    void trapq_finalize_moves(struct trapq *tq, double print_time
+        , double clear_history_time);
     void trapq_set_position(struct trapq *tq, double print_time
         , double pos_x, double pos_y, double pos_z);
     int trapq_extract_old(struct trapq *tq, struct pull_move *p, int max
@@ -102,6 +109,12 @@ defs_trapq = """
 defs_kin_cartesian = """
     struct stepper_kinematics *cartesian_stepper_alloc(char axis);
 """
+defs_kin_generic_cartesian = """
+    struct stepper_kinematics *generic_cartesian_stepper_alloc(double a_x
+        , double a_y, double a_z);
+    void generic_cartesian_stepper_set_coeffs(struct stepper_kinematics *sk
+        , double a_x, double a_y, double a_z);
+"""
 
 defs_kin_corexy = """
     struct stepper_kinematics *corexy_stepper_alloc(char type);
@@ -138,8 +151,9 @@ defs_kin_winch = """
 
 defs_kin_extruder = """
     struct stepper_kinematics *extruder_stepper_alloc(void);
+    void extruder_stepper_free(struct stepper_kinematics *sk);
     void extruder_set_pressure_advance(struct stepper_kinematics *sk
-        , double pressure_advance, double smooth_time);
+        , double print_time, double pressure_advance, double smooth_time);
 """
 
 defs_kin_shaper = """
@@ -149,6 +163,7 @@ defs_kin_shaper = """
         , int n, double a[], double t[]);
     int input_shaper_set_sk(struct stepper_kinematics *sk
         , struct stepper_kinematics *orig_sk);
+    void input_shaper_update_sk(struct stepper_kinematics *sk);
     struct stepper_kinematics * input_shaper_alloc(void);
 """
 
@@ -170,7 +185,7 @@ defs_serialqueue = """
     };
 
     struct serialqueue *serialqueue_alloc(int serial_fd, char serial_fd_type
-        , int client_id);
+        , int client_id, char name[16]);
     void serialqueue_exit(struct serialqueue *sq);
     void serialqueue_free(struct serialqueue *sq);
     struct command_queue *serialqueue_alloc_commandqueue(void);
@@ -207,6 +222,7 @@ defs_trdispatch = """
 defs_pyhelper = """
     void set_python_logging_callback(void (*func)(const char *));
     double get_monotonic(void);
+    int set_thread_name(char name[16]);
 """
 
 defs_std = """
@@ -215,10 +231,11 @@ defs_std = """
 
 defs_all = [
     defs_pyhelper, defs_serialqueue, defs_std, defs_stepcompress,
-    defs_itersolve, defs_trapq, defs_trdispatch,
+    defs_steppersync, defs_itersolve, defs_trapq, defs_trdispatch,
     defs_kin_cartesian, defs_kin_corexy, defs_kin_corexz, defs_kin_delta,
     defs_kin_deltesian, defs_kin_polar, defs_kin_rotary_delta, defs_kin_winch,
     defs_kin_extruder, defs_kin_shaper, defs_kin_idex,
+    defs_kin_generic_cartesian,
 ]
 
 # Update filenames to an absolute path
@@ -257,11 +274,33 @@ def do_build_code(cmd):
         logging.error(msg)
         raise Exception(msg)
 
+# Build the main c_helper.so c code library
+def check_build_c_library():
+    srcdir = os.path.dirname(os.path.realpath(__file__))
+    srcfiles = get_abs_files(srcdir, SOURCE_FILES)
+    ofiles = get_abs_files(srcdir, OTHER_FILES)
+    destlib = get_abs_files(srcdir, [DEST_LIB])[0]
+    if not check_build_code(srcfiles+ofiles+[__file__], destlib):
+        # Code already built
+        return destlib
+    # Select command line options
+    if check_gcc_option(SSE_FLAGS):
+        cmd = "%s %s %s" % (GCC_CMD, SSE_FLAGS, COMPILE_ARGS)
+    else:
+        cmd = "%s %s" % (GCC_CMD, COMPILE_ARGS)
+    # Invoke compiler
+    logging.info("Building C code module %s", DEST_LIB)
+    tempdestlib = get_abs_files(srcdir, ["_temp_" + DEST_LIB])[0]
+    do_build_code(cmd % (tempdestlib, ' '.join(srcfiles)))
+    # Rename from temporary file to final file name
+    os.rename(tempdestlib, destlib)
+    return destlib
+
 FFI_main = None
 FFI_lib = None
 pyhelper_logging_callback = None
 
-# Hepler invoked from C errorf() code to log errors
+# Helper invoked from C errorf() code to log errors
 def logging_callback(msg):
     logging.error(FFI_main.string(msg))
 
@@ -269,17 +308,9 @@ def logging_callback(msg):
 def get_ffi():
     global FFI_main, FFI_lib, pyhelper_logging_callback
     if FFI_lib is None:
-        srcdir = os.path.dirname(os.path.realpath(__file__))
-        srcfiles = get_abs_files(srcdir, SOURCE_FILES)
-        ofiles = get_abs_files(srcdir, OTHER_FILES)
-        destlib = get_abs_files(srcdir, [DEST_LIB])[0]
-        if check_build_code(srcfiles+ofiles+[__file__], destlib):
-            if check_gcc_option(SSE_FLAGS):
-                cmd = "%s %s %s" % (GCC_CMD, SSE_FLAGS, COMPILE_ARGS)
-            else:
-                cmd = "%s %s" % (GCC_CMD, COMPILE_ARGS)
-            logging.info("Building C code module %s", DEST_LIB)
-            do_build_code(cmd % (destlib, ' '.join(srcfiles)))
+        # Check if library needs to be built, and build if so
+        destlib = check_build_c_library()
+        # Open library
         FFI_main = cffi.FFI()
         for d in defs_all:
             FFI_main.cdef(d)

klippy/chelper/itersolve.c

@@ -26,8 +26,8 @@ struct timepos {
 
 // Generate step times for a portion of a move
 static int32_t
-itersolve_gen_steps_range(struct stepper_kinematics *sk, struct move *m
-                          , double abs_start, double abs_end)
+itersolve_gen_steps_range(struct stepper_kinematics *sk, struct stepcompress *sc
+                          , struct move *m, double abs_start, double abs_end)
 {
     sk_calc_callback calc_position_cb = sk->calc_position_cb;
     double half_step = .5 * sk->step_dist;
@@ -37,7 +37,7 @@ itersolve_gen_steps_range(struct stepper_kinematics *sk, struct move *m
     if (end > m->move_t)
         end = m->move_t;
     struct timepos old_guess = {start, sk->commanded_pos}, guess = old_guess;
-    int sdir = stepcompress_get_step_dir(sk->sc);
+    int sdir = stepcompress_get_step_dir(sc);
     int is_dir_change = 0, have_bracket = 0, check_oscillate = 0;
     double target = sk->commanded_pos + (sdir ? half_step : -half_step);
     double last_time=start, low_time=start, high_time=start + SEEK_TIME_RESET;
@@ -99,13 +99,13 @@ itersolve_gen_steps_range(struct stepper_kinematics *sk, struct move *m
             if (!have_bracket || high_time - low_time > .000000001) {
                 if (!is_dir_change && rel_dist >= -half_step)
                     // Avoid rollback if stepper fully reaches step position
-                    stepcompress_commit(sk->sc);
+                    stepcompress_commit(sc);
                 // Guess is not close enough - guess again with new time
                 continue;
             }
         }
         // Found next step - submit it
-        int ret = stepcompress_append(sk->sc, sdir, m->print_time, guess.time);
+        int ret = stepcompress_append(sc, sdir, m->print_time, guess.time);
         if (ret)
             return ret;
         target = sdir ? target+half_step+half_step : target-half_step-half_step;
@@ -143,8 +143,9 @@ check_active(struct stepper_kinematics *sk, struct move *m)
 }
 
 // Generate step times for a range of moves on the trapq
-int32_t __visible
-itersolve_generate_steps(struct stepper_kinematics *sk, double flush_time)
+int32_t
+itersolve_generate_steps(struct stepper_kinematics *sk, struct stepcompress *sc
+                         , double flush_time)
 {
     double last_flush_time = sk->last_flush_time;
     sk->last_flush_time = flush_time;
@@ -170,15 +171,15 @@ itersolve_generate_steps(struct stepper_kinematics *sk, double flush_time)
                 while (--skip_count && pm->print_time > abs_start)
                     pm = list_prev_entry(pm, node);
                 do {
-                    int32_t ret = itersolve_gen_steps_range(sk, pm, abs_start
-                                                            , flush_time);
+                    int32_t ret = itersolve_gen_steps_range(
+                        sk, sc, pm, abs_start, flush_time);
                     if (ret)
                         return ret;
                     pm = list_next_entry(pm, node);
                 } while (pm != m);
             }
             // Generate steps for this move
-            int32_t ret = itersolve_gen_steps_range(sk, m, last_flush_time
+            int32_t ret = itersolve_gen_steps_range(sk, sc, m, last_flush_time
                                                     , flush_time);
             if (ret)
                 return ret;
@@ -195,8 +196,8 @@ itersolve_generate_steps(struct stepper_kinematics *sk, double flush_time)
                 double abs_end = force_steps_time;
                 if (abs_end > flush_time)
                     abs_end = flush_time;
-                int32_t ret = itersolve_gen_steps_range(sk, m, last_flush_time
-                                                        , abs_end);
+                int32_t ret = itersolve_gen_steps_range(
+                    sk, sc, m, last_flush_time, abs_end);
                 if (ret)
                     return ret;
                 skip_count = 1;
@@ -240,16 +241,10 @@ itersolve_is_active_axis(struct stepper_kinematics *sk, char axis)
 }
 
 void __visible
-itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq)
+itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq
+                    , double step_dist)
 {
     sk->tq = tq;
-}
-
-void __visible
-itersolve_set_stepcompress(struct stepper_kinematics *sk
-                           , struct stepcompress *sc, double step_dist)
-{
-    sk->sc = sc;
     sk->step_dist = step_dist;
 }
 

klippy/chelper/itersolve.h

@@ -26,12 +26,11 @@ struct stepper_kinematics {
 };
 
 int32_t itersolve_generate_steps(struct stepper_kinematics *sk
-                                 , double flush_time);
+                                 , struct stepcompress *sc, double flush_time);
 double itersolve_check_active(struct stepper_kinematics *sk, double flush_time);
 int32_t itersolve_is_active_axis(struct stepper_kinematics *sk, char axis);
-void itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq);
-void itersolve_set_stepcompress(struct stepper_kinematics *sk
-                                , struct stepcompress *sc, double step_dist);
+void itersolve_set_trapq(struct stepper_kinematics *sk, struct trapq *tq
+                         , double step_dist);
 double itersolve_calc_position_from_coord(struct stepper_kinematics *sk
                                           , double x, double y, double z);
 void itersolve_set_position(struct stepper_kinematics *sk

klippy/chelper/kin_extruder.c

@@ -9,9 +9,15 @@
 #include <string.h> // memset
 #include "compiler.h" // __visible
 #include "itersolve.h" // struct stepper_kinematics
+#include "list.h" // list_node
 #include "pyhelper.h" // errorf
 #include "trapq.h" // move_get_distance
 
+struct pa_params {
+    double pressure_advance, active_print_time;
+    struct list_node node;
+};
+
 // Without pressure advance, the extruder stepper position is:
 //     extruder_position(t) = nominal_position(t)
 // When pressure advance is enabled, additional filament is pushed
@@ -52,17 +58,25 @@ extruder_integrate_time(double base, double start_v, double half_accel
 
 // Calculate the definitive integral of extruder for a given move
 static double
-pa_move_integrate(struct move *m, double pressure_advance
+pa_move_integrate(struct move *m, struct list_head *pa_list
                   , double base, double start, double end, double time_offset)
 {
     if (start < 0.)
         start = 0.;
     if (end > m->move_t)
         end = m->move_t;
-    // Calculate base position and velocity with pressure advance
+    // Determine pressure_advance value
     int can_pressure_advance = m->axes_r.y != 0.;
-    if (!can_pressure_advance)
-        pressure_advance = 0.;
+    double pressure_advance = 0.;
+    if (can_pressure_advance) {
+        struct pa_params *pa = list_last_entry(pa_list, struct pa_params, node);
+        while (unlikely(pa->active_print_time > m->print_time) &&
+                !list_is_first(&pa->node, pa_list)) {
+            pa = list_prev_entry(pa, node);
+        }
+        pressure_advance = pa->pressure_advance;
+    }
+    // Calculate base position and velocity with pressure advance
     base += pressure_advance * m->start_v;
     double start_v = m->start_v + pressure_advance * 2. * m->half_accel;
     // Calculate definitive integral
@@ -75,20 +89,20 @@ pa_move_integrate(struct move *m, double pressure_advance
 // Calculate the definitive integral of the extruder over a range of moves
 static double
 pa_range_integrate(struct move *m, double move_time
-                   , double pressure_advance, double hst)
+                   , struct list_head *pa_list, double hst)
 {
     // Calculate integral for the current move
     double res = 0., start = move_time - hst, end = move_time + hst;
     double start_base = m->start_pos.x;
-    res += pa_move_integrate(m, pressure_advance, 0., start, move_time, start);
-    res -= pa_move_integrate(m, pressure_advance, 0., move_time, end, end);
+    res += pa_move_integrate(m, pa_list, 0., start, move_time, start);
+    res -= pa_move_integrate(m, pa_list, 0., move_time, end, end);
     // Integrate over previous moves
     struct move *prev = m;
     while (unlikely(start < 0.)) {
         prev = list_prev_entry(prev, node);
         start += prev->move_t;
         double base = prev->start_pos.x - start_base;
-        res += pa_move_integrate(prev, pressure_advance, base, start
+        res += pa_move_integrate(prev, pa_list, base, start
                                  , prev->move_t, start);
     }
     // Integrate over future moves
@@ -96,14 +110,15 @@ pa_range_integrate(struct move *m, double move_time
         end -= m->move_t;
         m = list_next_entry(m, node);
         double base = m->start_pos.x - start_base;
-        res -= pa_move_integrate(m, pressure_advance, base, 0., end, end);
+        res -= pa_move_integrate(m, pa_list, base, 0., end, end);
     }
     return res;
 }
 
 struct extruder_stepper {
     struct stepper_kinematics sk;
-    double pressure_advance, half_smooth_time, inv_half_smooth_time2;
+    struct list_head pa_list;
+    double half_smooth_time, inv_half_smooth_time2;
 };
 
 static double
@@ -116,22 +131,45 @@ extruder_calc_position(struct stepper_kinematics *sk, struct move *m
         // Pressure advance not enabled
         return m->start_pos.x + move_get_distance(m, move_time);
     // Apply pressure advance and average over smooth_time
-    double area = pa_range_integrate(m, move_time, es->pressure_advance, hst);
+    double area = pa_range_integrate(m, move_time, &es->pa_list, hst);
     return m->start_pos.x + area * es->inv_half_smooth_time2;
 }
 
 void __visible
-extruder_set_pressure_advance(struct stepper_kinematics *sk
+extruder_set_pressure_advance(struct stepper_kinematics *sk, double print_time
                               , double pressure_advance, double smooth_time)
 {
     struct extruder_stepper *es = container_of(sk, struct extruder_stepper, sk);
-    double hst = smooth_time * .5;
+    double hst = smooth_time * .5, old_hst = es->half_smooth_time;
     es->half_smooth_time = hst;
     es->sk.gen_steps_pre_active = es->sk.gen_steps_post_active = hst;
+
+    // Cleanup old pressure advance parameters
+    double cleanup_time = sk->last_flush_time - (old_hst > hst ? old_hst : hst);
+    struct pa_params *first_pa = list_first_entry(
+            &es->pa_list, struct pa_params, node);
+    while (!list_is_last(&first_pa->node, &es->pa_list)) {
+        struct pa_params *next_pa = list_next_entry(first_pa, node);
+        if (next_pa->active_print_time >= cleanup_time) break;
+        list_del(&first_pa->node);
+        first_pa = next_pa;
+    }
+
     if (! hst)
         return;
     es->inv_half_smooth_time2 = 1. / (hst * hst);
-    es->pressure_advance = pressure_advance;
+
+    if (list_last_entry(&es->pa_list, struct pa_params, node)->pressure_advance
+            == pressure_advance) {
+        // Retain old pa_params
+        return;
+    }
+    // Add new pressure advance parameters
+    struct pa_params *pa = malloc(sizeof(*pa));
+    memset(pa, 0, sizeof(*pa));
+    pa->pressure_advance = pressure_advance;
+    pa->active_print_time = print_time;
+    list_add_tail(&pa->node, &es->pa_list);
 }
 
 struct stepper_kinematics * __visible
@@ -141,5 +179,22 @@ extruder_stepper_alloc(void)
     memset(es, 0, sizeof(*es));
     es->sk.calc_position_cb = extruder_calc_position;
     es->sk.active_flags = AF_X;
+    list_init(&es->pa_list);
+    struct pa_params *pa = malloc(sizeof(*pa));
+    memset(pa, 0, sizeof(*pa));
+    list_add_tail(&pa->node, &es->pa_list);
     return &es->sk;
 }
+
+void __visible
+extruder_stepper_free(struct stepper_kinematics *sk)
+{
+    struct extruder_stepper *es = container_of(sk, struct extruder_stepper, sk);
+    while (!list_empty(&es->pa_list)) {
+        struct pa_params *pa = list_first_entry(
+                &es->pa_list, struct pa_params, node);
+        list_del(&pa->node);
+        free(pa);
+    }
+    free(sk);
+}

klippy/chelper/kin_generic.c

@@ -0,0 +1,52 @@
+// Generic cartesian kinematics stepper position calculation
+//
+// Copyright (C) 2024  Dmitry Butyugin <dmbutyugin@google.com>
+//
+// This file may be distributed under the terms of the GNU GPLv3 license.
+
+#include <stddef.h> // offsetof
+#include <stdlib.h> // malloc
+#include <string.h> // memset
+#include "compiler.h" // __visible
+#include "itersolve.h" // struct stepper_kinematics
+#include "trapq.h" // move_get_coord
+
+struct generic_cartesian_stepper {
+    struct stepper_kinematics sk;
+    struct coord a;
+};
+
+static double
+generic_cartesian_stepper_calc_position(struct stepper_kinematics *sk
+                                        , struct move *m, double move_time)
+{
+    struct generic_cartesian_stepper *cs = container_of(
+            sk, struct generic_cartesian_stepper, sk);
+    struct coord c = move_get_coord(m, move_time);
+    return cs->a.x * c.x + cs->a.y * c.y + cs->a.z * c.z;
+}
+
+void __visible
+generic_cartesian_stepper_set_coeffs(struct stepper_kinematics *sk
+                                     , double a_x, double a_y, double a_z)
+{
+    struct generic_cartesian_stepper *cs = container_of(
+            sk, struct generic_cartesian_stepper, sk);
+    cs->a.x = a_x;
+    cs->a.y = a_y;
+    cs->a.z = a_z;
+    cs->sk.active_flags = 0;
+    if (a_x) cs->sk.active_flags |= AF_X;
+    if (a_y) cs->sk.active_flags |= AF_Y;
+    if (a_z) cs->sk.active_flags |= AF_Z;
+}
+
+struct stepper_kinematics * __visible
+generic_cartesian_stepper_alloc(double a_x, double a_y, double a_z)
+{
+    struct generic_cartesian_stepper *cs = malloc(sizeof(*cs));
+    memset(cs, 0, sizeof(*cs));
+    cs->sk.calc_position_cb = generic_cartesian_stepper_calc_position;
+    generic_cartesian_stepper_set_coeffs(&cs->sk, a_x, a_y, a_z);
+    return &cs->sk;
+}

klippy/chelper/kin_idex.c

@@ -77,5 +77,6 @@ dual_carriage_alloc(void)
     struct dual_carriage_stepper *dc = malloc(sizeof(*dc));
     memset(dc, 0, sizeof(*dc));
     dc->m.move_t = 2. * DUMMY_T;
+    dc->x_scale = dc->y_scale = 1.0;
     return &dc->sk;
 }

klippy/chelper/kin_shaper.c

@@ -156,25 +156,14 @@ shaper_xy_calc_position(struct stepper_kinematics *sk, struct move *m
     return is->orig_sk->calc_position_cb(is->orig_sk, &is->m, DUMMY_T);
 }
 
-int __visible
-input_shaper_set_sk(struct stepper_kinematics *sk
-                    , struct stepper_kinematics *orig_sk)
+// A callback that forwards post_cb call to the original kinematics
+static void
+shaper_commanded_pos_post_fixup(struct stepper_kinematics *sk)
 {
     struct input_shaper *is = container_of(sk, struct input_shaper, sk);
-    if (orig_sk->active_flags == AF_X)
-        is->sk.calc_position_cb = shaper_x_calc_position;
-    else if (orig_sk->active_flags == AF_Y)
-        is->sk.calc_position_cb = shaper_y_calc_position;
-    else if (orig_sk->active_flags & (AF_X | AF_Y))
-        is->sk.calc_position_cb = shaper_xy_calc_position;
-    else
-        return -1;
-    is->sk.active_flags = orig_sk->active_flags;
-    is->orig_sk = orig_sk;
-    is->sk.commanded_pos = orig_sk->commanded_pos;
-    is->sk.last_flush_time = orig_sk->last_flush_time;
-    is->sk.last_move_time = orig_sk->last_move_time;
-    return 0;
+    is->orig_sk->commanded_pos = sk->commanded_pos;
+    is->orig_sk->post_cb(is->orig_sk);
+    sk->commanded_pos = is->orig_sk->commanded_pos;
 }
 
 static void
@@ -195,6 +184,44 @@ shaper_note_generation_time(struct input_shaper *is)
     is->sk.gen_steps_post_active = post_active;
 }
 
+void __visible
+input_shaper_update_sk(struct stepper_kinematics *sk)
+{
+    struct input_shaper *is = container_of(sk, struct input_shaper, sk);
+    if ((is->orig_sk->active_flags & (AF_X | AF_Y)) == (AF_X | AF_Y))
+        is->sk.calc_position_cb = shaper_xy_calc_position;
+    else if (is->orig_sk->active_flags & AF_X)
+        is->sk.calc_position_cb = shaper_x_calc_position;
+    else if (is->orig_sk->active_flags & AF_Y)
+        is->sk.calc_position_cb = shaper_y_calc_position;
+    is->sk.active_flags = is->orig_sk->active_flags;
+    shaper_note_generation_time(is);
+}
+
+int __visible
+input_shaper_set_sk(struct stepper_kinematics *sk
+                    , struct stepper_kinematics *orig_sk)
+{
+    struct input_shaper *is = container_of(sk, struct input_shaper, sk);
+    if (orig_sk->active_flags == AF_X)
+        is->sk.calc_position_cb = shaper_x_calc_position;
+    else if (orig_sk->active_flags == AF_Y)
+        is->sk.calc_position_cb = shaper_y_calc_position;
+    else if (orig_sk->active_flags & (AF_X | AF_Y))
+        is->sk.calc_position_cb = shaper_xy_calc_position;
+    else
+        return -1;
+    is->sk.active_flags = orig_sk->active_flags;
+    is->orig_sk = orig_sk;
+    is->sk.commanded_pos = orig_sk->commanded_pos;
+    is->sk.last_flush_time = orig_sk->last_flush_time;
+    is->sk.last_move_time = orig_sk->last_move_time;
+    if (orig_sk->post_cb) {
+        is->sk.post_cb = shaper_commanded_pos_post_fixup;
+    }
+    return 0;
+}
+
 int __visible
 input_shaper_set_shaper_params(struct stepper_kinematics *sk, char axis
                                , int n, double a[], double t[])

klippy/chelper/pyhelper.c

@@ -10,6 +10,8 @@
 #include <stdio.h> // fprintf
 #include <string.h> // strerror
 #include <time.h> // struct timespec
+#include <linux/prctl.h>  // PR_SET_NAME
+#include <sys/prctl.h>  // prctl
 #include "compiler.h" // __visible
 #include "pyhelper.h" // get_monotonic
 
@@ -92,3 +94,10 @@ dump_string(char *outbuf, int outbuf_size, char *inbuf, int inbuf_size)
     *o = '\0';
     return outbuf;
 }
+
+// Set custom thread names
+int __visible
+set_thread_name(char name[16])
+{
+    return prctl(PR_SET_NAME, name);
+}

klippy/chelper/pyhelper.h

@@ -7,5 +7,6 @@ void set_python_logging_callback(void (*func)(const char *));
 void errorf(const char *fmt, ...) __attribute__ ((format (printf, 1, 2)));
 void report_errno(char *where, int rc);
 char *dump_string(char *outbuf, int outbuf_size, char *inbuf, int inbuf_size);
+int set_thread_name(char name[16]);
 
 #endif // pyhelper.h