mirror of
https://github.com/QIDITECH/klipper.git
synced 2026-01-30 23:48:43 +03:00
plus4的klipper版本
This commit is contained in:
whb0514
50
docs/Axis_Twist_Compensation.md
Normal file
50
docs/Axis_Twist_Compensation.md
Normal file
@@ -0,0 +1,50 @@
|
||||
# Axis Twist Compensation
|
||||
|
||||
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.
|
||||
This is common in printers with designs like the Prusa MK3, Sovol SV06 etc and is
|
||||
further described under [probe location
|
||||
bias](Probe_Calibrate.md#location-bias-check). It may result in
|
||||
probe operations such as [Bed Mesh](Bed_Mesh.md),
|
||||
[Screws Tilt Adjust](G-Codes.md#screws_tilt_adjust),
|
||||
[Z Tilt Adjust](G-Codes.md#z_tilt_adjust) etc returning inaccurate
|
||||
representations of the bed.
|
||||
|
||||
This module uses manual measurements by the user to correct the probe's results.
|
||||
Note that if your axis is significantly twisted it is strongly recommended to
|
||||
first use mechanical means to fix it prior to applying software corrections.
|
||||
|
||||
**Warning**: This module is not compatible with dockable probes yet and will
|
||||
try to probe the bed without attaching the probe if you use it.
|
||||
|
||||
## Overview of compensation usage
|
||||
|
||||
> **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
|
||||
|
||||
> **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 Reference](Config_Reference.md#axis_twist_compensation).
|
||||
|
||||
Commands for [axis_twist_compensation] can be found in the
|
||||
[G-Codes Reference](G-Codes.md#axis_twist_compensation)
|
||||
111
docs/Bed_Mesh.md
111
docs/Bed_Mesh.md
@@ -1,8 +1,8 @@
|
||||
# Bed Mesh
|
||||
|
||||
The Bed Mesh module may be used to compensate for bed surface irregularties to
|
||||
achieve a better first layer across the entire bed. It should be noted that
|
||||
software based correction will not achieve perfect results, it can only
|
||||
The Bed Mesh module may be used to compensate for bed surface irregularities
|
||||
to achieve a better first layer across the entire bed. It should be noted
|
||||
that software based correction will not achieve perfect results, it can only
|
||||
approximate the shape of the bed. Bed Mesh also cannot compensate for
|
||||
mechanical and electrical issues. If an axis is skewed or a probe is not
|
||||
accurate then the bed_mesh module will not receive accurate results from
|
||||
@@ -46,7 +46,7 @@ probe_count: 5, 3
|
||||
_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 coordiante is relative to
|
||||
zig-zag fashion. As with `mesh_min`, this coordinate is relative to
|
||||
the probe's location.
|
||||
|
||||
- `probe_count: 5, 3`\
|
||||
@@ -101,7 +101,7 @@ round_probe_count: 5
|
||||
that the center of the mesh is probed.
|
||||
|
||||
The illustration below shows how the probed points are generated. As you can see,
|
||||
setting the `mesh_origin` to (-10, 0) allows us to specifiy a larger mesh radius
|
||||
setting the `mesh_origin` to (-10, 0) allows us to specify a larger mesh radius
|
||||
of 85.
|
||||
|
||||
|
||||
@@ -114,7 +114,7 @@ Each of the advanced options apply to round beds in the same manner.
|
||||
|
||||
### Mesh Interpolation
|
||||
|
||||
While its possible to sample the probed matrix directly using simple bilinear
|
||||
While its possible to sample the probed matrix directly using simple bi-linear
|
||||
interpolation to determine the Z-Values between probed points, it is often
|
||||
useful to interpolate extra points using more advanced interpolation algorithms
|
||||
to increase mesh density. These algorithms add curvature to the mesh,
|
||||
@@ -142,7 +142,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.
|
||||
|
||||
@@ -207,7 +207,7 @@ split_delta_z: .025
|
||||
Generally the default values for these options are sufficient, in fact the
|
||||
default value of 5mm for the `move_check_distance` may be overkill. However an
|
||||
advanced user may wish to experiment with these options in an effort to squeeze
|
||||
out the optimial first layer.
|
||||
out the optimal first layer.
|
||||
|
||||
### Mesh Fade
|
||||
|
||||
@@ -255,19 +255,24 @@ fade_target: 0
|
||||
example, lets assume your homing position on the bed is an outlier, its
|
||||
.2 mm lower than the average probed height of the bed. If the `fade_target`
|
||||
is 0, fade will shrink the print by an average of .2 mm across the bed. By
|
||||
setting the `fade_target` to .2, the homed area will expand by .2 mm, however
|
||||
the rest of the bed will have an accurately sized. Generally its a good idea
|
||||
setting the `fade_target` to .2, the homed area will expand by .2 mm, however,
|
||||
the rest of the bed will be accurately sized. Generally its a good idea
|
||||
to leave `fade_target` out of the configuration so the average height of the
|
||||
mesh is used, however it may be desirable to manually adjust the fade target
|
||||
if one wants to print on a specific portion of the bed.
|
||||
|
||||
### The Relative Reference Index
|
||||
### Configuring the zero reference position
|
||||
|
||||
Most probes are suceptible to drift, ie: inaccuracies in probing introduced by
|
||||
heat or interference. This can make calculating the probe's z-offset
|
||||
challenging, particuarly at different bed temperatures. As such, some printers
|
||||
use an endstop for homing the Z axis, and a probe for calibrating the mesh.
|
||||
These printers can benefit from configuring the relative reference index.
|
||||
Many probes are susceptible to "drift", ie: inaccuracies in probing introduced
|
||||
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
|
||||
be the location on the bed where a
|
||||
[Z_ENDSTOP_CALIBRATE](./Manual_Level#calibrating-a-z-endstop)
|
||||
paper test is performed. The bed_mesh module provides the
|
||||
`zero_reference_position` option for specifying this coordinate:
|
||||
|
||||
```
|
||||
[bed_mesh]
|
||||
@@ -275,23 +280,45 @@ speed: 120
|
||||
horizontal_move_z: 5
|
||||
mesh_min: 35, 6
|
||||
mesh_max: 240, 198
|
||||
zero_reference_position: 125, 110
|
||||
probe_count: 5, 3
|
||||
relative_reference_index: 7
|
||||
```
|
||||
- `zero_reference_position: `\
|
||||
_Default Value: None (disabled)_\
|
||||
The `zero_reference_position` expects an (X, Y) coordinate matching that
|
||||
of the `reference position` described above. If the coordinate lies within
|
||||
the mesh then the mesh will be offset so the reference position applies zero
|
||||
adjustment. If the coordinate lies outside of the mesh then the coordinate
|
||||
will be probed after calibration, with the resulting z-value used as the
|
||||
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)
|
||||
```
|
||||
|
||||
- `relative_reference_index: 7`\
|
||||
_Default Value: None (disabled)_\
|
||||
When the probed points are generated they are each assigned an index. You
|
||||
can look up this index in klippy.log or by using BED_MESH_OUTPUT (see the
|
||||
section on Bed Mesh GCodes below for more information). If you assign an
|
||||
index to the `relative_reference_index` option, the value probed at this
|
||||
coordinate will replace the probe's z_offset. This effectively makes
|
||||
this coordinate the "zero" reference for the mesh.
|
||||
_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`.
|
||||
|
||||
|
||||
When using the relative reference index, you should choose the index nearest
|
||||
to the spot on the bed where Z endstop calibration was done. Note that
|
||||
when looking up the index using the log or BED_MESH_OUTPUT, you should use
|
||||
the coordinates listed under the "Probe" header to find the correct index.
|
||||
|
||||
### Faulty Regions
|
||||
|
||||
@@ -371,12 +398,12 @@ following parameters are available:
|
||||
- `MESH_ORIGIN`
|
||||
- `ROUND_PROBE_COUNT`
|
||||
- All beds:
|
||||
- `RELATIVE_REFERNCE_INDEX`
|
||||
- `ALGORITHM`
|
||||
|
||||
See the configuration documentation above for details on how each parameter
|
||||
applies to the mesh.
|
||||
|
||||
|
||||
### Profiles
|
||||
|
||||
`BED_MESH_PROFILE SAVE=<name> LOAD=<name> REMOVE=<name>`
|
||||
@@ -390,15 +417,33 @@ to write the profile to printer.cfg.
|
||||
Profiles can be loaded by executing `BED_MESH_PROFILE LOAD=<name>`.
|
||||
|
||||
It should be noted that each time a BED_MESH_CALIBRATE occurs, the current
|
||||
state is automatically saved to the _default_ profile. If this profile
|
||||
exists it is automatically loaded when Klipper starts. If this behavior
|
||||
is not desirable the _default_ profile can be removed as follows:
|
||||
state is automatically saved to the _default_ profile. The _default_ profile can be removed as follows:
|
||||
|
||||
`BED_MESH_PROFILE REMOVE=default`
|
||||
|
||||
Any other saved profile can be removed in the same fashion, replacing
|
||||
_default_ with the named profile you wish to remove.
|
||||
|
||||
|
||||
#### Loading the default profile
|
||||
|
||||
Previous versions of `bed_mesh` always loaded the profile named _default_
|
||||
on startup if it was present. This behavior has been removed in favor of
|
||||
allowing the user to determine when a profile is loaded. If a user wishes to
|
||||
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.
|
||||
|
||||
Alternatively the old behavior of loading a profile at startup can be
|
||||
restored with a `[delayed_gcode]`:
|
||||
|
||||
```ini
|
||||
[delayed_gcode bed_mesh_init]
|
||||
initial_duration: .01
|
||||
gcode:
|
||||
BED_MESH_PROFILE LOAD=default
|
||||
```
|
||||
|
||||
### Output
|
||||
|
||||
`BED_MESH_OUTPUT PGP=[0 | 1]`
|
||||
|
||||
@@ -248,6 +248,26 @@ results were obtained by running an STM32F407 binary on an STM32F446
|
||||
| 1 stepper | 46 |
|
||||
| 3 stepper | 205 |
|
||||
|
||||
### STM32H7 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on a STM32H743VIT6:
|
||||
```
|
||||
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
|
||||
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]`.
|
||||
|
||||
| stm32h7 | ticks |
|
||||
| -------------------- | ----- |
|
||||
| 1 stepper | 44 |
|
||||
| 3 stepper | 198 |
|
||||
|
||||
### STM32G0B1 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the STM32G0B1:
|
||||
@@ -334,6 +354,27 @@ micro-controller.
|
||||
| 1 stepper (200Mhz) | 39 |
|
||||
| 3 stepper (200Mhz) | 181 |
|
||||
|
||||
### AR100 step rate benchmark ###
|
||||
|
||||
The following configuration sequence is used on AR100 CPU (Allwinner A64):
|
||||
```
|
||||
allocate_oids count=3
|
||||
config_stepper oid=0 step_pin=PL10 dir_pin=PE14 invert_step=-1 step_pulse_ticks=0
|
||||
config_stepper oid=1 step_pin=PL11 dir_pin=PE15 invert_step=-1 step_pulse_ticks=0
|
||||
config_stepper oid=2 step_pin=PL12 dir_pin=PE16 invert_step=-1 step_pulse_ticks=0
|
||||
finalize_config crc=0
|
||||
|
||||
```
|
||||
|
||||
The test was last run on commit `08d037c6` with gcc version
|
||||
`or1k-linux-musl-gcc (GCC) 9.2.0` on an Allwinner A64-H
|
||||
micro-controller.
|
||||
|
||||
| AR100 R_PIO | ticks |
|
||||
| -------------------- | ----- |
|
||||
| 1 stepper | 85 |
|
||||
| 3 stepper | 359 |
|
||||
|
||||
### RP2040 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the RP2040:
|
||||
@@ -405,6 +446,7 @@ hub.
|
||||
| atmega2560 (serial) | 23K | b161a69e | avr-gcc (GCC) 4.8.1 |
|
||||
| sam3x8e (serial) | 23K | b161a69e | arm-none-eabi-gcc (Fedora 7.1.0-5.fc27) 7.1.0 |
|
||||
| at90usb1286 (USB) | 75K | 01d2183f | avr-gcc (GCC) 5.4.0 |
|
||||
| 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 |
|
||||
| pru (shared memory) | 260K | c5968a08 | pru-gcc (GCC) 8.0.0 20170530 (experimental) |
|
||||
| stm32f103 (USB) | 355K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
|
||||
|
||||
125
docs/Bootloader_Entry.md
Normal file
125
docs/Bootloader_Entry.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# Bootloader Entry
|
||||
|
||||
Klipper can be instructed to reboot into a [Bootloader](Bootloaders.md) in one
|
||||
of the following ways:
|
||||
|
||||
## Requesting the bootloader
|
||||
|
||||
### Virtual Serial
|
||||
|
||||
If a virtual (USB-ACM) serial port is in use, pulsing DTR while at 1200 baud
|
||||
will request the bootloader.
|
||||
|
||||
#### Python (with `flash_usb`)
|
||||
|
||||
To enter the bootloader using python (using `flash_usb`):
|
||||
|
||||
```shell
|
||||
> cd klipper/scripts
|
||||
> python3 -c 'import flash_usb as u; u.enter_bootloader("<DEVICE>")'
|
||||
Entering bootloader on <DEVICE>
|
||||
```
|
||||
|
||||
Where `<DEVICE>` is your serial device, such as
|
||||
`/dev/serial.by-id/usb-Klipper[...]` or `/dev/ttyACM0`
|
||||
|
||||
Note that if this fails, no output will be printed, success is indicated by
|
||||
printing `Entering bootloader on <DEVICE>`.
|
||||
|
||||
#### Picocom
|
||||
|
||||
```shell
|
||||
picocom -b 1200 <DEVICE>
|
||||
<Ctrl-A><Ctrl-P>
|
||||
```
|
||||
|
||||
Where `<DEVICE>` is your serial device, such as
|
||||
`/dev/serial.by-id/usb-Klipper[...]` or `/dev/ttyACM0`
|
||||
|
||||
`<Ctrl-A><Ctrl-P>` means
|
||||
holding `Ctrl`, pressing and releasing `a`, pressing and releasing `p`, then
|
||||
releasing `Ctrl`
|
||||
|
||||
### Physical serial
|
||||
|
||||
If a physical serial port is being used on the MCU (even if a USB serial adapter
|
||||
is being used to connect to it), sending the string
|
||||
`<SPACE><FS><SPACE>Request Serial Bootloader!!<SPACE>~` requests the bootloader.
|
||||
|
||||
`<SPACE>` is an ASCII literal space, 0x20.
|
||||
|
||||
`<FS>` is the ASCII File Separator,
|
||||
0x1c.
|
||||
|
||||
Note that this is not a valid message as per the
|
||||
[MCU Protocol](Protocol.md#micro-controller-interface), but sync characters(`~`)
|
||||
are still respected.
|
||||
|
||||
Because this message must be the only thing in the "block"
|
||||
it is received in, prefixing an extra sync character can increase reliability if
|
||||
other tools were previously accessing the serial port.
|
||||
|
||||
#### Shell
|
||||
|
||||
```shell
|
||||
stty <BAUD> < /dev/<DEVICE>
|
||||
echo $'~ \x1c Request Serial Bootloader!! ~' >> /dev/<DEVICE>
|
||||
```
|
||||
|
||||
Where `<DEVICE>` is your serial port, such as `/dev/ttyS0`, or
|
||||
`/dev/serial/by-id/gpio-serial2`, and
|
||||
|
||||
`<BAUD>` is the baud rate of the serial
|
||||
port, such as `115200`.
|
||||
|
||||
### CANBUS
|
||||
|
||||
If CANBUS is in use, a special
|
||||
[admin message](CANBUS_protocol.md#admin-messages) will request the bootloader.
|
||||
This message will be respected even if the device already has a nodeid, and will
|
||||
also be processed if the mcu is shutdown.
|
||||
|
||||
This method also applies to devices operating in
|
||||
[CANBridge](CANBUS.md#usb-to-can-bus-bridge-mode) mode.
|
||||
|
||||
#### Katapult's flashtool.py
|
||||
|
||||
```shell
|
||||
python3 ./katapult/scripts/flashtool.py -i <CAN_IFACE> -u <UUID> -r
|
||||
```
|
||||
|
||||
Where `<CAN_IFACE>` is the can interface to use. If using `can0`, both the `-i`
|
||||
and `<CAN_IFACE>` may be omitted.
|
||||
|
||||
`<UUID>` is the UUID of your CAN device.
|
||||
|
||||
See the
|
||||
[CANBUS Documentation](CANBUS.md#finding-the-canbus_uuid-for-new-micro-controllers)
|
||||
for information on finding the CAN UUID of your devices.
|
||||
|
||||
## Entering the bootloader
|
||||
|
||||
When klipper receives one of the above bootloader requests:
|
||||
|
||||
If Katapult (formerly known as CANBoot) is available, klipper will request that
|
||||
Katapult stay active on the next boot, then reset the MCU (therefore entering
|
||||
Katapult).
|
||||
|
||||
If Katapult is not available, klipper will then try to enter a
|
||||
platform-specific bootloader, such as STM32's DFU
|
||||
mode([see note](#stm32-dfu-warning)).
|
||||
|
||||
In short, Klipper will reboot to Katapult if installed, then a hardware specific
|
||||
bootloader if available.
|
||||
|
||||
For details about the specific bootloaders on various platforms see
|
||||
[Bootloaders](Bootloaders.md)
|
||||
|
||||
## Notes
|
||||
|
||||
### STM32 DFU Warning
|
||||
|
||||
Note that on some boards, like the Octopus Pro v1, entering DFU mode can cause
|
||||
undesired actions (such as powering the heater while in DFU mode). It is
|
||||
recommended to disconnect heaters, and otherwise prevent undesired operations
|
||||
when using DFU mode. Consult the documentation for your board for more details.
|
||||
@@ -185,6 +185,50 @@ To flash an application use something like:
|
||||
bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin
|
||||
```
|
||||
|
||||
## SAMDC21 micro-controllers (Duet3D Toolboard 1LC)
|
||||
|
||||
The SAMC21 is flashed via the ARM Serial Wire Debug (SWD) interface.
|
||||
This is commonly done with a dedicated SWD hardware dongle.
|
||||
Alternatively, one can use a
|
||||
[Raspberry Pi with OpenOCD](#running-openocd-on-the-raspberry-pi).
|
||||
|
||||
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
|
||||
can be done by running the following commands before invoking OpenOCD.
|
||||
```
|
||||
SWCLK=25
|
||||
SWDIO=24
|
||||
SRST=18
|
||||
|
||||
echo "Exporting SWCLK and SRST pins."
|
||||
echo $SWCLK > /sys/class/gpio/export
|
||||
echo $SRST > /sys/class/gpio/export
|
||||
echo "out" > /sys/class/gpio/gpio$SWCLK/direction
|
||||
echo "out" > /sys/class/gpio/gpio$SRST/direction
|
||||
|
||||
echo "Setting SWCLK low and pulsing SRST."
|
||||
echo "0" > /sys/class/gpio/gpio$SWCLK/value
|
||||
echo "0" > /sys/class/gpio/gpio$SRST/value
|
||||
echo "1" > /sys/class/gpio/gpio$SRST/value
|
||||
|
||||
echo "Unexporting SWCLK and SRST pins."
|
||||
echo $SWCLK > /sys/class/gpio/unexport
|
||||
echo $SRST > /sys/class/gpio/unexport
|
||||
```
|
||||
|
||||
To flash a program with OpenOCD use the following chip config:
|
||||
```
|
||||
source [find target/at91samdXX.cfg]
|
||||
```
|
||||
Obtain a program; for instance, klipper can be built for this chip.
|
||||
Flash with OpenOCD commands similar to:
|
||||
```
|
||||
at91samd chip-erase
|
||||
at91samd bootloader 0
|
||||
program out/klipper.elf verify
|
||||
```
|
||||
|
||||
## SAMD21 micro-controllers (Arduino Zero)
|
||||
|
||||
The SAMD21 bootloader is flashed via the ARM Serial Wire Debug (SWD)
|
||||
@@ -305,7 +349,7 @@ is a [fork with builds specific to the SKR Mini E3 1.2](
|
||||
https://github.com/Arksine/STM32_HID_Bootloader/releases/latest).
|
||||
|
||||
For generic STM32F103 boards such as the blue pill it is possible to flash
|
||||
the bootloader via 3.3v serial using stm32flash as noted in the stm32duino
|
||||
the bootloader via 3.3V serial using stm32flash as noted in the stm32duino
|
||||
section above, substituting the file name for the desired hid bootloader binary
|
||||
(ie: hid_generic_pc13.bin for the blue pill).
|
||||
|
||||
@@ -382,7 +426,7 @@ make flash FLASH_DEVICE=/dev/ttyACM0
|
||||
It may be necessary to manually enter the bootloader, this can be done by
|
||||
setting "boot 0" low and "boot 1" high. On the SKR Mini E3 "Boot 1" is
|
||||
not available, so it may be done by setting pin PA2 low if you flashed
|
||||
"hid_btt_skr_mini_e3.bin". This pin is labeld "TX0" on the TFT header in
|
||||
"hid_btt_skr_mini_e3.bin". This pin is labeled "TX0" on the TFT header in
|
||||
the SKR Mini E3's "PIN" document. There is a ground pin next to PA2
|
||||
which you can use to pull PA2 low.
|
||||
|
||||
@@ -390,7 +434,7 @@ which you can use to pull PA2 low.
|
||||
|
||||
The [MSC bootloader](https://github.com/Telekatz/MSC-stm32f103-bootloader) is a driverless bootloader capable of flashing over USB.
|
||||
|
||||
It is possible to flash the bootloader via 3.3v serial using stm32flash as noted
|
||||
It is possible to flash the bootloader via 3.3V serial using stm32flash as noted
|
||||
in the stm32duino section above, substituting the file name for the desired
|
||||
MSC bootloader binary (ie: MSCboot-Bluepill.bin for the blue pill).
|
||||
|
||||
@@ -419,7 +463,7 @@ It is recommended to use a ST-Link Programmer to flash CanBoot, however it
|
||||
should be possible to flash using `stm32flash` on STM32F103 devices, and
|
||||
`dfu-util` on STM32F042/STM32F072 devices. See the previous sections in this
|
||||
document for instructions on these flashing methods, substituting `canboot.bin`
|
||||
for the file name where appropriate. The CanBoot repo linked above provides
|
||||
for the file name where appropriate. The CanBoot repository linked above provides
|
||||
instructions for building the bootloader.
|
||||
|
||||
The first time CanBoot has been flashed it should detect that no application
|
||||
@@ -448,8 +492,8 @@ When building Klipper for use with CanBoot, select the 8 KiB Bootloader option.
|
||||
|
||||
## STM32F4 micro-controllers (SKR Pro 1.1)
|
||||
|
||||
STM32F4 microcontrollers come equipped with a built-in system bootloader
|
||||
capable of flashing over USB (via DFU), 3.3v Serial, and various other
|
||||
STM32F4 micro-controllers come equipped with a built-in system bootloader
|
||||
capable of flashing over USB (via DFU), 3.3V Serial, and various other
|
||||
methods (see STM Document AN2606 for more information). Some
|
||||
STM32F4 boards, such as the SKR Pro 1.1, are not able to enter the DFU
|
||||
bootloader. The HID bootloader is available for STM32F405/407
|
||||
@@ -458,8 +502,8 @@ Note that you may need to configure and build a version specific to your
|
||||
board, a [build for the SKR Pro 1.1 is available here](
|
||||
https://github.com/Arksine/STM32_HID_Bootloader/releases/latest).
|
||||
|
||||
Unless your board is DFU capable the most accessable flashing method
|
||||
is likely via 3.3v serial, which follows the same procedure as
|
||||
Unless your board is DFU capable the most accessible flashing method
|
||||
is likely via 3.3V serial, which follows the same procedure as
|
||||
[flashing the STM32F103 using stm32flash](#stm32f103-micro-controllers-blue-pill-devices).
|
||||
For example:
|
||||
```
|
||||
|
||||
@@ -4,9 +4,9 @@ This document describes Klipper's CAN bus support.
|
||||
|
||||
## Device Hardware
|
||||
|
||||
Klipper currently only supports CAN on stm32 chips. In addition, the
|
||||
micro-controller chip must support CAN and it must be on a board that
|
||||
has a CAN transceiver.
|
||||
Klipper currently supports CAN on stm32, SAME5x, and rp2040 chips. In
|
||||
addition, the micro-controller chip must be on a board that has a CAN
|
||||
transceiver.
|
||||
|
||||
To compile for CAN, run `make menuconfig` and select "CAN bus" as the
|
||||
communication interface. Finally, compile the micro-controller code
|
||||
@@ -14,44 +14,35 @@ and flash it to the target board.
|
||||
|
||||
## Host Hardware
|
||||
|
||||
In order to use a CAN bus, it is necessary to have a host adapter.
|
||||
There are currently two common options:
|
||||
|
||||
1. Use a
|
||||
[Waveshare Raspberry Pi CAN hat](https://www.waveshare.com/rs485-can-hat.htm)
|
||||
or one of its many clones.
|
||||
|
||||
2. Use a USB CAN adapter (for example
|
||||
[https://hacker-gadgets.com/product/cantact-usb-can-adapter/](https://hacker-gadgets.com/product/cantact-usb-can-adapter/)). There
|
||||
are many different USB to CAN adapters available - when choosing
|
||||
one, we recommend verifying it can run the
|
||||
[candlelight firmware](https://github.com/candle-usb/candleLight_fw).
|
||||
(Unfortunately, we've found some USB adapters run defective
|
||||
firmware and are locked down, so verify before purchasing.)
|
||||
In order to use a CAN bus, it is necessary to have a host adapter. It
|
||||
is recommended to use a "USB to CAN adapter". There are many different
|
||||
USB to CAN adapters available from different manufacturers. When
|
||||
choosing one, we recommend verifying that the firmware can be updated
|
||||
on it. (Unfortunately, we've found some USB adapters run defective
|
||||
firmware and are locked down, so verify before purchasing.) Look for
|
||||
adapters that can run Klipper directly (in its "USB to CAN bridge
|
||||
mode") or that run the
|
||||
[candlelight firmware](https://github.com/candle-usb/candleLight_fw).
|
||||
|
||||
It is also necessary to configure the host operating system to use the
|
||||
adapter. This is typically done by creating a new file named
|
||||
`/etc/network/interfaces.d/can0` with the following contents:
|
||||
```
|
||||
auto can0
|
||||
allow-hotplug can0
|
||||
iface can0 can static
|
||||
bitrate 500000
|
||||
bitrate 1000000
|
||||
up ifconfig $IFACE txqueuelen 128
|
||||
```
|
||||
|
||||
Note that the "Raspberry Pi CAN hat" also requires
|
||||
[changes to config.txt](https://www.waveshare.com/wiki/RS485_CAN_HAT).
|
||||
|
||||
## Terminating Resistors
|
||||
|
||||
A CAN bus should have two 120 ohm resistors between the CANH and CANL
|
||||
wires. Ideally, one resistor located at each the end of the bus.
|
||||
|
||||
Note that some devices have a builtin 120 ohm resistor (for example,
|
||||
the "Waveshare Raspberry Pi CAN hat" has a soldered on resistor that
|
||||
can not be easily removed). Some devices do not include a resistor at
|
||||
all. Other devices have a mechanism to select the resistor (typically
|
||||
by connecting a "pin jumper"). Be sure to check the schematics of all
|
||||
Note that some devices have a builtin 120 ohm resistor that can not be
|
||||
easily removed. Some devices do not include a resistor at all. Other
|
||||
devices have a mechanism to select the resistor (typically by
|
||||
connecting a "pin jumper"). Be sure to check the schematics of all
|
||||
devices on the CAN bus to verify that there are two and only two 120
|
||||
Ohm resistors on the bus.
|
||||
|
||||
@@ -73,7 +64,7 @@ powered and wired correctly, and then run:
|
||||
If uninitialized CAN devices are detected the above command will
|
||||
report lines like the following:
|
||||
```
|
||||
Found canbus_uuid=11aa22bb33cc
|
||||
Found canbus_uuid=11aa22bb33cc, Application: Klipper
|
||||
```
|
||||
|
||||
Each device will have a unique identifier. In the above example,
|
||||
@@ -95,22 +86,18 @@ canbus_uuid: 11aa22bb33cc
|
||||
## USB to CAN bus bridge mode
|
||||
|
||||
Some micro-controllers support selecting "USB to CAN bus bridge" mode
|
||||
during "make menuconfig". This mode may allow one to use a
|
||||
during Klipper's "make menuconfig". This mode may allow one to use a
|
||||
micro-controller as both a "USB to CAN bus adapter" and as a Klipper
|
||||
node.
|
||||
|
||||
When Klipper uses this mode the micro-controller appears as a "USB CAN
|
||||
bus adapter" under Linux. The "Klipper bridge mcu" itself will appear
|
||||
as if was on this CAN bus - it can be identified via `canbus_query.py`
|
||||
and configured like other CAN bus Klipper nodes. It will appear
|
||||
alongside other devices that are actually on the CAN bus.
|
||||
as if it was on this CAN bus - it can be identified via
|
||||
`canbus_query.py` and it must be configured like other CAN bus Klipper
|
||||
nodes.
|
||||
|
||||
Some important notes when using this mode:
|
||||
|
||||
* The "bridge mcu" is not actually on the CAN bus. Messages to and
|
||||
from it do not consume bandwidth on the CAN bus. The mcu can not be
|
||||
seen by other adapters that may be on the CAN bus.
|
||||
|
||||
* It is necessary to configure the `can0` (or similar) interface in
|
||||
Linux in order to communicate with the bus. However, Linux CAN bus
|
||||
speed and CAN bus bit-timing options are ignored by Klipper.
|
||||
@@ -118,7 +105,37 @@ Some important notes when using this mode:
|
||||
menuconfig" and the bus speed specified in Linux is ignored.
|
||||
|
||||
* Whenever the "bridge mcu" is reset, Linux will disable the
|
||||
corresponding `can0` interface. Generally, this may require running
|
||||
commands such as "ip up" to restart the interface. Thus, Klipper
|
||||
FIRMWARE_RESTART commands (or regular RESTART after a config change)
|
||||
may require restarting the `can0` interface.
|
||||
corresponding `can0` interface. To ensure proper handling of
|
||||
FIRMWARE_RESTART and RESTART commands, it is recommended to use
|
||||
`allow-hotplug` in the `/etc/network/interfaces.d/can0` file. For
|
||||
example:
|
||||
```
|
||||
allow-hotplug can0
|
||||
iface can0 can static
|
||||
bitrate 1000000
|
||||
up ifconfig $IFACE txqueuelen 128
|
||||
```
|
||||
|
||||
* The "bridge mcu" is not actually on the CAN bus. Messages to and
|
||||
from the bridge mcu will not be seen by other adapters that may be
|
||||
on the CAN bus.
|
||||
|
||||
* The available bandwidth to both the "bridge mcu" itself and all
|
||||
devices on the CAN bus is effectively limited by the CAN bus
|
||||
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.
|
||||
|
||||
* 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
|
||||
be configured in Klipper's printer.cfg file with a `serial:`
|
||||
parameter. The bridge board appears as a "USB CAN adapter" and it is
|
||||
configured in the printer.cfg as a [CAN node](#configuring-klipper).
|
||||
|
||||
## Tips for troubleshooting
|
||||
|
||||
See the [CAN bus troubleshooting](CANBUS_Troubleshooting.md) document.
|
||||
|
||||
140
docs/CANBUS_Troubleshooting.md
Normal file
140
docs/CANBUS_Troubleshooting.md
Normal file
@@ -0,0 +1,140 @@
|
||||
# CANBUS Troubleshooting
|
||||
|
||||
This document provides information on troubleshooting communication
|
||||
issues when using [Klipper with CAN bus](CANBUS.md).
|
||||
|
||||
## Verify CAN bus wiring
|
||||
|
||||
The first step in troubleshooting communication issues is to verify
|
||||
the CAN bus wiring.
|
||||
|
||||
Be sure there are exactly two 120 Ohm [terminating
|
||||
resistors](CANBUS.md#terminating-resistors) on the CAN bus. If the
|
||||
resistors are not properly installed then messages may not be able to
|
||||
be sent at all or the connection may have sporadic instability.
|
||||
|
||||
The CANH and CANL bus wiring should be twisted around each other. At a
|
||||
minimum, the wiring should have a twist every few centimeters. Avoid
|
||||
twisting the CANH and CANL wiring around power wires and ensure that
|
||||
power wires that travel parallel to the CANH and CANL wires do not
|
||||
have the same amount of twists.
|
||||
|
||||
Verify that all plugs and wire crimps on the CAN bus wiring are fully
|
||||
secured. Movement of the printer toolhead may jostle the CAN bus
|
||||
wiring causing a bad wire crimp or unsecured plug to result in
|
||||
intermittent communication errors.
|
||||
|
||||
## Check for incrementing bytes_invalid counter
|
||||
|
||||
The Klipper log file will report a `Stats` line once a second when the
|
||||
printer is active. These "Stats" lines will have a `bytes_invalid`
|
||||
counter for each micro-controller. This counter should not increment
|
||||
during normal printer operation (it is normal for the counter to be
|
||||
non-zero after a RESTART and it is not a concern if the counter
|
||||
increments once a month or so). If this counter increments on a CAN
|
||||
bus micro-controller during normal printing (it increments every few
|
||||
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 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.
|
||||
|
||||
## Obtaining candump logs
|
||||
|
||||
The CAN bus messages sent to and from the micro-controller are handled
|
||||
by the Linux kernel. It is possible to capture these messages from the
|
||||
kernel for debugging purposes. A log of these messages may be of use
|
||||
in diagnostics.
|
||||
|
||||
The Linux [can-utils](https://github.com/linux-can/can-utils) tool
|
||||
provides the capture software. It is typically installed on a machine
|
||||
by running:
|
||||
```
|
||||
sudo apt-get update && sudo apt-get install can-utils
|
||||
```
|
||||
|
||||
Once installed, one may obtain a capture of all CAN bus messages on an
|
||||
interface with the following command:
|
||||
```
|
||||
candump -tz -Ddex can0,#FFFFFFFF > mycanlog
|
||||
```
|
||||
|
||||
One can view the resulting log file (`mycanlog` in the example above)
|
||||
to see each raw CAN bus message that was sent and received by Klipper.
|
||||
Understanding the content of these messages will likely require
|
||||
low-level knowledge of Klipper's [CANBUS protocol](CANBUS_protocol.md)
|
||||
and Klipper's [MCU commands](MCU_Commands.md).
|
||||
|
||||
### Parsing Klipper messages in a candump log
|
||||
|
||||
One may use the `parsecandump.py` tool to parse the low-level Klipper
|
||||
micro-controller messages contained in a candump log. Using this tool
|
||||
is an advanced topic that requires knowledge of Klipper
|
||||
[MCU commands](MCU_Commands.md). For example:
|
||||
```
|
||||
./scripts/parsecandump.py mycanlog 108 ./out/klipper.dict
|
||||
```
|
||||
|
||||
This tool produces output similar to the [parsedump
|
||||
tool](Debugging.md#translating-gcode-files-to-micro-controller-commands). See
|
||||
the documentation for that tool for information on generating the
|
||||
Klipper micro-controller data dictionary.
|
||||
|
||||
In the above example, `108` is the [CAN bus
|
||||
id](CANBUS_protocol.md#micro-controller-id-assignment). It is a
|
||||
hexadecimal number. The id `108` is assigned by Klipper to the first
|
||||
micro-controller. If the CAN bus has multiple micro-controllers on it,
|
||||
then the second micro-controller would be `10a`, the third would be
|
||||
`10c`, and so on.
|
||||
|
||||
The candump log must be produced using the `-tz -Ddex` command-line
|
||||
arguments (for example: `candump -tz -Ddex can0,#FFFFFFFF`) in order
|
||||
to use the `parsecandump.py` tool.
|
||||
|
||||
## Using a logic analyzer on the canbus wiring
|
||||
|
||||
The [Sigrok Pulseview](https://sigrok.org/wiki/PulseView) software
|
||||
along with a low-cost
|
||||
[logic analyzer](https://en.wikipedia.org/wiki/Logic_analyzer) can be
|
||||
useful for diagnosing CAN bus signaling. This is an advanced topic
|
||||
likely only of interest to experts.
|
||||
|
||||
One can often find "USB logic analyzers" for under $15 (US pricing as
|
||||
of 2023). These devices are often listed as "Saleae logic clones" or
|
||||
as "24MHz 8 channel USB logic analyzers".
|
||||
|
||||
|
||||
|
||||
The above picture was taken while using Pulseview with a "Saleae
|
||||
clone" logic analyzer. The Sigrok and Pulseview software was installed
|
||||
on a desktop machine (also install the "fx2lafw" firmware if that is
|
||||
packaged separately). The CH0 pin on the logic analyzer was routed to
|
||||
the CAN Rx line, the CH1 pin was wired to the CAN Tx pin, and GND was
|
||||
wired to GND. Pulseview was configured to only display the D0 and D1
|
||||
lines (red "probe" icon center top toolbar). The number of samples was
|
||||
set to 5 million (top toolbar) and the sample rate was set to 24Mhz
|
||||
(top toolbar). The CAN decoder was added (yellow and green "bubble
|
||||
icon" right top toolbar). The D0 channel was labeled as RX and set to
|
||||
trigger on a falling edge (click on black D0 label at left). The D1
|
||||
channel was labeled as TX (click on brown D1 label at left). The CAN
|
||||
decoder was configured for 1Mbit rate (click on green CAN label at
|
||||
left). The CAN decoder was moved to the top of the display (click and
|
||||
drag green CAN label). Finally, the capture was started (click "Run"
|
||||
at top left) and a packet was transmitted on the CAN bus (`cansend
|
||||
can0 123#121212121212`).
|
||||
|
||||
The logic analyzer provides an independent tool for capturing packets
|
||||
and verifying bit timing.
|
||||
@@ -38,23 +38,23 @@ with a RESP_NEED_NODEID response message.
|
||||
The CMD_QUERY_UNASSIGNED message format is:
|
||||
`<1-byte message_id = 0x00>`
|
||||
|
||||
### CMD_SET_NODEID message
|
||||
### CMD_SET_KLIPPER_NODEID message
|
||||
|
||||
This command assigns a `canbus_nodeid` to the micro-controller with a
|
||||
given `canbus_uuid`.
|
||||
|
||||
The CMD_SET_NODEID message format is:
|
||||
The CMD_SET_KLIPPER_NODEID message format is:
|
||||
`<1-byte message_id = 0x01><6-byte canbus_uuid><1-byte canbus_nodeid>`
|
||||
|
||||
### RESP_NEED_NODEID message
|
||||
|
||||
The RESP_NEED_NODEID message format is:
|
||||
`<1-byte message_id = 0x20><6-byte canbus_uuid>`
|
||||
`<1-byte message_id = 0x20><6-byte canbus_uuid><1-byte set_klipper_nodeid = 0x01>`
|
||||
|
||||
## Data Packets
|
||||
|
||||
A micro-controller that has been assigned a nodeid via the
|
||||
CMD_SET_NODEID command can send and receive data packets.
|
||||
CMD_SET_KLIPPER_NODEID command can send and receive data packets.
|
||||
|
||||
The packet data in messages using the node's receive CAN bus id
|
||||
(`canbus_nodeid * 2 + 256`) are simply appended to a buffer, and when
|
||||
|
||||
@@ -62,6 +62,10 @@ Common things a reviewer will look for:
|
||||
|
||||
Submissions must pass all [regression test cases](Debugging.md).
|
||||
|
||||
When fixing a defect in the code, submitters should have a general
|
||||
understanding of the root cause of that defect, and the fix should
|
||||
target that root cause.
|
||||
|
||||
Code submissions should not contain excessive debugging code,
|
||||
debugging options, nor run-time debug logging.
|
||||
|
||||
@@ -249,8 +253,8 @@ The Klipper "reviewers" are:
|
||||
| ---------------------- | ----------------- | ----------------- |
|
||||
| Dmitry Butyugin | @dmbutyugin | Input shaping, resonance testing, kinematics |
|
||||
| Eric Callahan | @Arksine | Bed leveling, MCU flashing |
|
||||
| James Hartley | @JamesH1978 | Configuration files |
|
||||
| Kevin O'Connor | @KevinOConnor | Core motion system, Micro-controller code |
|
||||
| Paul McGowan | @mental405 | Configuration files, documentation |
|
||||
|
||||
Please do not "ping" any of the reviewers and please do not direct
|
||||
submissions at them. All of the reviewers monitor the forums and PRs,
|
||||
|
||||
@@ -8,6 +8,89 @@ All dates in this document are approximate.
|
||||
|
||||
## Changes
|
||||
|
||||
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
|
||||
of the carriages with each other. Additionally, the homing order of the primary
|
||||
and the dual carriage is changed in some configurations (certain configurations
|
||||
when both carriages home in the same direction, see
|
||||
[[dual_carriage] configuration reference](./Config_Reference.md#dual_carriage)
|
||||
for more details).
|
||||
|
||||
20230810: The flash-sdcard.sh script now supports both variants of the
|
||||
Bigtreetech SKR-3, STM32H743 and STM32H723. For this, the original tag
|
||||
of btt-skr-3 now has changed to be either btt-skr-3-h743 or btt-skr-3-h723.
|
||||
|
||||
20230729: The exported status for `dual_carriage` is changed. Instead of
|
||||
exporting `mode` and `active_carriage`, the individual modes for each
|
||||
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
|
||||
[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
|
||||
for the `BED_MESH_CALIBRATE` gcode command.
|
||||
|
||||
20230530: The default canbus frequency in "make menuconfig" is
|
||||
now 1000000. If using canbus and using canbus with some other
|
||||
frequency is required, then be sure to select "Enable extra low-level
|
||||
configuration options" and specify the desired "CAN bus speed" in
|
||||
"make menuconfig" when compiling and flashing the micro-controller.
|
||||
|
||||
20230525: `SHAPER_CALIBRATE` command immediately applies input shaper
|
||||
parameters if `[input_shaper]` was enabled already.
|
||||
|
||||
20230407: The `stalled_bytes` counter in the log and in the
|
||||
`printer.mcu.last_stats` field has been renamed to `upcoming_bytes`.
|
||||
|
||||
20230323: On tmc5160 drivers `multistep_filt` is now enabled by default. Set
|
||||
`driver_MULTISTEP_FILT: False` in the tmc5160 config for the previous behavior.
|
||||
|
||||
20230304: The `SET_TMC_CURRENT` command now properly adjusts the globalscaler
|
||||
register for drivers that have it. This removes a limitation where on tmc5160,
|
||||
the currents could not be raised higher with `SET_TMC_CURRENT` than the
|
||||
`run_current` value set in the config file.
|
||||
However, this has a side effect: After running `SET_TMC_CURRENT`, the stepper
|
||||
must be held at standstill for >130ms in case StealthChop2 is used so that the
|
||||
AT#1 calibration gets executed by the driver.
|
||||
|
||||
20230202: The format of the `printer.screws_tilt_adjust` status
|
||||
information has changed. The information is now stored as a dictionary of
|
||||
screws with the resulting measurements. See the
|
||||
[status reference](Status_Reference.md#screws_tilt_adjust) for details.
|
||||
|
||||
20230201: The `[bed_mesh]` module no longer loads the `default` profile
|
||||
on startup. It is recommended that users who use the `default` profile
|
||||
add `BED_MESH_PROFILE LOAD=default` to their `START_PRINT` macro (or
|
||||
to their slicer's "Start G-Code" configuration when applicable).
|
||||
|
||||
20230103: It is now possible with the flash-sdcard.sh script to flash
|
||||
both variants of the Bigtreetech SKR-2, STM32F407 and STM32F429.
|
||||
This means that the original tag of btt-skr2 now has changed to either
|
||||
btt-skr-2-f407 or btt-skr-2-f429.
|
||||
|
||||
20221128: Klipper v0.11.0 released.
|
||||
|
||||
20221122: Previously, with safe_z_home, it was possible that the
|
||||
z_hop after the g28 homing would go in the negative z direction.
|
||||
Now, a z_hop is performed after g28 only if it results in a positive
|
||||
hop, mirroring the behavior of the z_hop that occurs before
|
||||
the g28 homing.
|
||||
|
||||
20220616: It was previously possible to flash an rp2040 in bootloader
|
||||
mode by running `make flash FLASH_DEVICE=first`. The equivalent
|
||||
command is now `make flash FLASH_DEVICE=2e8a:0003`.
|
||||
|
||||
@@ -85,20 +85,25 @@ The printer section controls high level printer settings.
|
||||
kinematics:
|
||||
# The type of printer in use. This option may be one of: cartesian,
|
||||
# corexy, corexz, hybrid_corexy, hybrid_corexz, rotary_delta, delta,
|
||||
# polar, winch, or none. This
|
||||
# parameter must be specified.
|
||||
# deltesian, polar, winch, or none. This parameter must be specified.
|
||||
max_velocity:
|
||||
# Maximum velocity (in mm/s) of the toolhead (relative to the
|
||||
# print). This parameter must be specified.
|
||||
# print). This value may be changed at runtime using the
|
||||
# SET_VELOCITY_LIMIT command. This parameter must be specified.
|
||||
max_accel:
|
||||
# Maximum acceleration (in mm/s^2) of the toolhead (relative to the
|
||||
# print). This parameter must be specified.
|
||||
# print). Although this parameter is described as a "maximum"
|
||||
# acceleration, in practice most moves that accelerate or decelerate
|
||||
# will do so at the rate specified here. The value specified here
|
||||
# may be changed at runtime using the SET_VELOCITY_LIMIT command.
|
||||
# This parameter must be specified.
|
||||
#max_accel_to_decel:
|
||||
# A pseudo acceleration (in mm/s^2) controlling how fast the
|
||||
# toolhead may go from acceleration to deceleration. It is used to
|
||||
# reduce the top speed of short zig-zag moves (and thus reduce
|
||||
# printer vibration from these moves). The default is half of
|
||||
# max_accel.
|
||||
# printer vibration from these moves). The value specified here may
|
||||
# be changed at runtime using the SET_VELOCITY_LIMIT command. The
|
||||
# default is half of max_accel.
|
||||
#square_corner_velocity: 5.0
|
||||
# The maximum velocity (in mm/s) that the toolhead may travel a 90
|
||||
# degree corner at. A non-zero value can reduce changes in extruder
|
||||
@@ -108,7 +113,9 @@ max_accel:
|
||||
# larger than 90 degrees will have a higher cornering velocity while
|
||||
# corners with angles less than 90 degrees will have a lower
|
||||
# cornering velocity. If this is set to zero then the toolhead will
|
||||
# decelerate to zero at each corner. The default is 5mm/s.
|
||||
# decelerate to zero at each corner. The value specified here may be
|
||||
# changed at runtime using the SET_VELOCITY_LIMIT command. The
|
||||
# default is 5mm/s.
|
||||
```
|
||||
|
||||
### [stepper]
|
||||
@@ -318,6 +325,81 @@ radius:
|
||||
# just prior to starting a probe operation. The default is 5.
|
||||
```
|
||||
|
||||
### Deltesian Kinematics
|
||||
|
||||
See [example-deltesian.cfg](../config/example-deltesian.cfg) for an
|
||||
example deltesian kinematics config file.
|
||||
|
||||
Only parameters specific to deltesian printers are described here - see
|
||||
[common kinematic settings](#common-kinematic-settings) for available
|
||||
parameters.
|
||||
|
||||
```
|
||||
[printer]
|
||||
kinematics: deltesian
|
||||
max_z_velocity:
|
||||
# For deltesian printers, this limits the maximum velocity (in mm/s) of
|
||||
# moves with z axis movement. This setting can be used to reduce the
|
||||
# maximum speed of up/down moves (which require a higher step rate
|
||||
# than other moves on a deltesian printer). The default is to use
|
||||
# max_velocity for max_z_velocity.
|
||||
#max_z_accel:
|
||||
# This sets the maximum acceleration (in mm/s^2) of movement along
|
||||
# the z axis. Setting this may be useful if the printer can reach higher
|
||||
# acceleration on XY moves than Z moves (eg, when using input shaper).
|
||||
# The default is to use max_accel for max_z_accel.
|
||||
#minimum_z_position: 0
|
||||
# The minimum Z position that the user may command the head to move
|
||||
# to. The default is 0.
|
||||
#min_angle: 5
|
||||
# This represents the minimum angle (in degrees) relative to horizontal
|
||||
# that the deltesian arms are allowed to achieve. This parameter is
|
||||
# intended to restrict the arms from becoming completely horizontal,
|
||||
# which would risk accidental inversion of the XZ axis. The default is 5.
|
||||
#print_width:
|
||||
# The distance (in mm) of valid toolhead X coordinates. One may use
|
||||
# this setting to customize the range checking of toolhead moves. If
|
||||
# a large value is specified here then it may be possible to command
|
||||
# the toolhead into a collision with a tower. This setting usually
|
||||
# corresponds to bed width (in mm).
|
||||
#slow_ratio: 3
|
||||
# The ratio used to limit velocity and acceleration on moves near the
|
||||
# extremes of the X axis. If vertical distance divided by horizontal
|
||||
# distance exceeds the value of slow_ratio, then velocity and
|
||||
# acceleration are limited to half their nominal values. If vertical
|
||||
# distance divided by horizontal distance exceeds twice the value of
|
||||
# the slow_ratio, then velocity and acceleration are limited to one
|
||||
# quarter of their nominal values. The default is 3.
|
||||
|
||||
# The stepper_left section is used to describe the stepper controlling
|
||||
# the left tower. This section also controls the homing parameters
|
||||
# (homing_speed, homing_retract_dist) for all towers.
|
||||
[stepper_left]
|
||||
position_endstop:
|
||||
# Distance (in mm) between the nozzle and the bed when the nozzle is
|
||||
# in the center of the build area and the endstops are triggered. This
|
||||
# parameter must be provided for stepper_left; for stepper_right this
|
||||
# parameter defaults to the value specified for stepper_left.
|
||||
arm_length:
|
||||
# Length (in mm) of the diagonal rod that connects the tower carriage to
|
||||
# the print head. This parameter must be provided for stepper_left; for
|
||||
# stepper_right, this parameter defaults to the value specified for
|
||||
# stepper_left.
|
||||
arm_x_length:
|
||||
# Horizontal distance between the print head and the tower when the
|
||||
# printers is homed. This parameter must be provided for stepper_left;
|
||||
# for stepper_right, this parameter defaults to the value specified for
|
||||
# stepper_left.
|
||||
|
||||
# The stepper_right section is used to describe the stepper controlling the
|
||||
# right tower.
|
||||
[stepper_right]
|
||||
|
||||
# The stepper_y section is used to describe the stepper controlling
|
||||
# the Y axis in a deltesian robot.
|
||||
[stepper_y]
|
||||
```
|
||||
|
||||
### CoreXY Kinematics
|
||||
|
||||
See [example-corexy.cfg](../config/example-corexy.cfg) for an example
|
||||
@@ -892,10 +974,18 @@ Visual Examples:
|
||||
# be applied to change the amount of slope interpolated. Larger
|
||||
# numbers will increase the amount of slope, which results in more
|
||||
# curvature in the mesh. Default is .2.
|
||||
#zero_reference_position:
|
||||
# An optional X,Y coordinate that specifies the location on the bed
|
||||
# where Z = 0. When this option is specified the mesh will be offset
|
||||
# so that zero Z adjustment occurs at this location. The default is
|
||||
# no zero reference.
|
||||
#relative_reference_index:
|
||||
# A point index in the mesh to reference all z values to. Enabling
|
||||
# this parameter produces a mesh relative to the probed z position
|
||||
# at the provided index.
|
||||
# **DEPRECATED, use the "zero_reference_position" option**
|
||||
# The legacy option superceded by the "zero reference position".
|
||||
# Rather than a coordinate this option takes an integer "index" that
|
||||
# refers to the location of one of the generated points. It is recommended
|
||||
# to use the "zero_reference_position" instead of this option for new
|
||||
# configurations. The default is no relative reference index.
|
||||
#faulty_region_1_min:
|
||||
#faulty_region_1_max:
|
||||
# Optional points that define a faulty region. See docs/Bed_Mesh.md
|
||||
@@ -1019,12 +1109,12 @@ information.
|
||||
# The height (in mm) that the head should be commanded to move to
|
||||
# just prior to starting a probe operation. The default is 5.
|
||||
#screw_thread: CW-M3
|
||||
# The type of screw used for bed level, M3, M4 or M5 and the
|
||||
# direction of the knob used to level the bed, clockwise decrease
|
||||
# counter-clockwise decrease.
|
||||
# The type of screw used for bed leveling, M3, M4, or M5, and the
|
||||
# rotation direction of the knob that is used to level the bed.
|
||||
# Accepted values: CW-M3, CCW-M3, CW-M4, CCW-M4, CW-M5, CCW-M5.
|
||||
# Default value is CW-M3, most printers use an M3 screw and
|
||||
# turning the knob clockwise decrease distance.
|
||||
# Default value is CW-M3 which most printers use. A clockwise
|
||||
# rotation of the knob decreases the gap between the nozzle and the
|
||||
# bed. Conversely, a counter-clockwise rotation increases the gap.
|
||||
```
|
||||
|
||||
### [z_tilt]
|
||||
@@ -1131,6 +1221,45 @@ the nature of skew correction these lengths are set via gcode. See
|
||||
[skew_correction]
|
||||
```
|
||||
|
||||
### [z_thermal_adjust]
|
||||
|
||||
Temperature-dependant toolhead Z position adjustment. Compensate for vertical
|
||||
toolhead movement caused by thermal expansion of the printer's frame in
|
||||
real-time using a temperature sensor (typically coupled to a vertical section
|
||||
of frame).
|
||||
|
||||
See also: [extended g-code commands](G-Codes.md#z_thermal_adjust).
|
||||
|
||||
```
|
||||
[z_thermal_adjust]
|
||||
#temp_coeff:
|
||||
# The temperature coefficient of expansion, in mm/degC. For example, a
|
||||
# temp_coeff of 0.01 mm/degC will move the Z axis downwards by 0.01 mm for
|
||||
# every degree Celsius that the temperature sensor increases. Defaults to
|
||||
# 0.0 mm/degC, which applies no adjustment.
|
||||
#smooth_time:
|
||||
# Smoothing window applied to the temperature sensor, in seconds. Can reduce
|
||||
# motor noise from excessive small corrections in response to sensor noise.
|
||||
# The default is 2.0 seconds.
|
||||
#z_adjust_off_above:
|
||||
# Disables adjustments above this Z height [mm]. The last computed correction
|
||||
# will remain applied until the toolhead moves below the specified Z height
|
||||
# again. The default is 99999999.0 mm (always on).
|
||||
#max_z_adjustment:
|
||||
# Maximum absolute adjustment that can be applied to the Z axis [mm]. The
|
||||
# default is 99999999.0 mm (unlimited).
|
||||
#sensor_type:
|
||||
#sensor_pin:
|
||||
#min_temp:
|
||||
#max_temp:
|
||||
# Temperature sensor configuration.
|
||||
# See the "extruder" section for the definition of the above
|
||||
# parameters.
|
||||
#gcode_id:
|
||||
# See the "heater_generic" section for the definition of this
|
||||
# parameter.
|
||||
```
|
||||
|
||||
## Customized homing
|
||||
|
||||
### [safe_z_home]
|
||||
@@ -1525,17 +1654,41 @@ cs_pin:
|
||||
# measurements.
|
||||
```
|
||||
|
||||
### [lis2dw]
|
||||
|
||||
Support for LIS2DW accelerometers.
|
||||
|
||||
```
|
||||
[lis2dw]
|
||||
cs_pin:
|
||||
# The SPI enable pin for the sensor. This parameter must be provided.
|
||||
#spi_speed: 5000000
|
||||
# The SPI speed (in hz) to use when communicating with the chip.
|
||||
# The default is 5000000.
|
||||
#spi_bus:
|
||||
#spi_software_sclk_pin:
|
||||
#spi_software_mosi_pin:
|
||||
#spi_software_miso_pin:
|
||||
# See the "common SPI settings" section for a description of the
|
||||
# above parameters.
|
||||
#axes_map: x, y, z
|
||||
# See the "adxl345" section for information on this parameter.
|
||||
```
|
||||
|
||||
### [mpu9250]
|
||||
|
||||
Support for mpu9250 and mpu6050 accelerometers (one may define any
|
||||
number of sections with an "mpu9250" prefix).
|
||||
Support for MPU-9250, MPU-9255, MPU-6515, MPU-6050, and MPU-6500
|
||||
accelerometers (one may define any number of sections with an
|
||||
"mpu9250" prefix).
|
||||
|
||||
```
|
||||
[mpu9250 my_accelerometer]
|
||||
#i2c_address:
|
||||
# Default is 104 (0x68).
|
||||
# Default is 104 (0x68). If AD0 is high, it would be 0x69 instead.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed: 400000
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters. The default "i2c_speed" is 400000.
|
||||
@@ -1835,6 +1988,35 @@ z_offset:
|
||||
# See the "probe" section for more information on the parameters above.
|
||||
```
|
||||
|
||||
### [axis_twist_compensation]
|
||||
|
||||
A tool to compensate for inaccurate probe readings due to twist in X gantry. See
|
||||
the [Axis Twist Compensation Guide](Axis_Twist_Compensation.md) for more
|
||||
detailed information regarding symptoms, configuration and setup.
|
||||
|
||||
```
|
||||
[axis_twist_compensation]
|
||||
#speed: 50
|
||||
# The speed (in mm/s) of non-probing moves during the calibration.
|
||||
# The default is 50.
|
||||
#horizontal_move_z: 5
|
||||
# The height (in mm) that the head should be commanded to move to
|
||||
# just prior to starting a probe operation. The default is 5.
|
||||
calibrate_start_x: 20
|
||||
# Defines the minimum X coordinate of the calibration
|
||||
# This should be the X coordinate that positions the nozzle at the starting
|
||||
# calibration position. This parameter must be provided.
|
||||
calibrate_end_x: 200
|
||||
# Defines the maximum X coordinate of the calibration
|
||||
# This should be the X coordinate that positions the nozzle at the ending
|
||||
# calibration position. This parameter must be provided.
|
||||
calibrate_y: 112.5
|
||||
# Defines the Y coordinate of the calibration
|
||||
# This should be the Y coordinate that positions the nozzle during the
|
||||
# calibration process. This parameter must be provided and is recommended to
|
||||
# be near the center of the bed
|
||||
```
|
||||
|
||||
## Additional stepper motors and extruders
|
||||
|
||||
### [stepper_z1]
|
||||
@@ -1883,14 +2065,32 @@ for an example configuration.
|
||||
|
||||
### [dual_carriage]
|
||||
|
||||
Support for cartesian printers with dual carriages on a single
|
||||
axis. The active carriage is set via the SET_DUAL_CARRIAGE extended
|
||||
g-code command. The "SET_DUAL_CARRIAGE CARRIAGE=1" command will
|
||||
activate the carriage defined in this section (CARRIAGE=0 will return
|
||||
activation to the primary carriage). Dual carriage support is
|
||||
typically combined with extra extruders - the SET_DUAL_CARRIAGE
|
||||
command is often called at the same time as the ACTIVATE_EXTRUDER
|
||||
command. Be sure to park the carriages during deactivation.
|
||||
Support for cartesian and hybrid_corexy/z printers with dual carriages
|
||||
on a single axis. The carriage mode can be set via the
|
||||
SET_DUAL_CARRIAGE extended g-code command. For example,
|
||||
"SET_DUAL_CARRIAGE CARRIAGE=1" command will activate the carriage defined
|
||||
in this section (CARRIAGE=0 will return activation to the primary carriage).
|
||||
Dual carriage support is typically combined with extra extruders - the
|
||||
SET_DUAL_CARRIAGE command is often called at the same time as the
|
||||
ACTIVATE_EXTRUDER command. Be sure to park the carriages during deactivation.
|
||||
Note that during G28 homing, typically the primary carriage is homed first
|
||||
followed by the carriage defined in the `[dual_carriage]` config section.
|
||||
However, the `[dual_carriage]` carriage will be homed first if both carriages
|
||||
home in a positive direction and the [dual_carriage] carriage has a
|
||||
`position_endstop` greater than the primary carriage, or if both carriages home
|
||||
in a negative direction and the `[dual_carriage]` carriage has a
|
||||
`position_endstop` less than the primary carriage.
|
||||
|
||||
Additionally, one could use "SET_DUAL_CARRIAGE CARRIAGE=1 MODE=COPY" or
|
||||
"SET_DUAL_CARRIAGE CARRIAGE=1 MODE=MIRROR" commands to activate either copying
|
||||
or mirroring mode of the dual carriage, in which case it will follow the
|
||||
motion of the carriage 0 accordingly. These commands can be used to print
|
||||
two parts simultaneously - either two identical parts (in COPY mode) or
|
||||
mirrored parts (in MIRROR mode). Note that COPY and MIRROR modes also require
|
||||
appropriate configuration of the extruder on the dual carriage, which can
|
||||
typically be achieved with
|
||||
"SYNC_EXTRUDER_MOTION MOTION_QUEUE=extruder EXTRUDER=<dual_carriage_extruder>"
|
||||
or a similar command.
|
||||
|
||||
See [sample-idex.cfg](../config/sample-idex.cfg) for an example
|
||||
configuration.
|
||||
@@ -1900,6 +2100,15 @@ configuration.
|
||||
axis:
|
||||
# The axis this extra carriage is on (either x or y). This parameter
|
||||
# must be provided.
|
||||
#safe_distance:
|
||||
# The minimum distance (in mm) to enforce between the dual and the primary
|
||||
# carriages. If a G-Code command is executed that will bring the carriages
|
||||
# closer than the specified limit, such a command will be rejected with an
|
||||
# error. If safe_distance is not provided, it will be inferred from
|
||||
# position_min and position_max for the dual and primary carriages. If set
|
||||
# to 0 (or safe_distance is unset and position_min and position_max are
|
||||
# identical for the primary and dual carraiges), the carriages proximity
|
||||
# checks will be disabled.
|
||||
#step_pin:
|
||||
#dir_pin:
|
||||
#enable_pin:
|
||||
@@ -2144,7 +2353,7 @@ temperature sensors that are reported via the M105 command.
|
||||
|
||||
Klipper includes definitions for many types of temperature sensors.
|
||||
These sensors may be used in any config section that requires a
|
||||
temperature sensor (such as an `[extruder]` or `[heated_bed]`
|
||||
temperature sensor (such as an `[extruder]` or `[heater_bed]`
|
||||
section).
|
||||
|
||||
### Common thermistors
|
||||
@@ -2239,9 +2448,9 @@ sensor_pin:
|
||||
# name in the above list.
|
||||
```
|
||||
|
||||
### BMP280/BME280/BME680 temperature sensor
|
||||
### BMP180/BMP280/BME280/BME680 temperature sensor
|
||||
|
||||
BMP280/BME280/BME680 two wire interface (I2C) environmental sensors.
|
||||
BMP180/BMP280/BME280/BME680 two wire interface (I2C) environmental sensors.
|
||||
Note that these sensors are not intended for use with extruders and
|
||||
heater beds, but rather for monitoring ambient temperature (C),
|
||||
pressure (hPa), relative humidity and in case of the BME680 gas level.
|
||||
@@ -2252,13 +2461,39 @@ temperature.
|
||||
```
|
||||
sensor_type: BME280
|
||||
#i2c_address:
|
||||
# Default is 118 (0x76). Some BME280 sensors have an address of 119
|
||||
# Default is 118 (0x76). The BMP180 and some BME280 sensors have an address of 119
|
||||
# (0x77).
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
```
|
||||
|
||||
### AHT10/AHT20/AHT21 temperature sensor
|
||||
|
||||
AHT10/AHT20/AHT21 two wire interface (I2C) environmental sensors.
|
||||
Note that these sensors are not intended for use with extruders and
|
||||
heater beds, but rather for monitoring ambient temperature (C) and
|
||||
relative humidity. See
|
||||
[sample-macros.cfg](../config/sample-macros.cfg) for a gcode_macro
|
||||
that may be used to report humidity in addition to temperature.
|
||||
|
||||
```
|
||||
sensor_type: AHT10
|
||||
# Also use AHT10 for AHT20 and AHT21 sensors.
|
||||
#i2c_address:
|
||||
# Default is 56 (0x38). Some AHT10 sensors give the option to use
|
||||
# 57 (0x39) by moving a resistor.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
#aht10_report_time:
|
||||
# Interval in seconds between readings. Default is 30, minimum is 5
|
||||
```
|
||||
|
||||
### HTU21D sensor
|
||||
@@ -2277,6 +2512,8 @@ sensor_type:
|
||||
# Default is 64 (0x40).
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -2310,6 +2547,8 @@ sensor_type: LM75
|
||||
# (usually with jumpers or hard wired).
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -2320,7 +2559,7 @@ sensor_type: LM75
|
||||
|
||||
### Builtin micro-controller temperature sensor
|
||||
|
||||
The atsam, atsamd, and stm32 micro-controllers contain an internal
|
||||
The atsam, atsamd, stm32 and rp2040 micro-controllers contain an internal
|
||||
temperature sensor. One can use the "temperature_mcu" sensor to
|
||||
monitor these temperatures.
|
||||
|
||||
@@ -2381,6 +2620,24 @@ serial_no:
|
||||
# The micro-controller to read from. Must be the host_mcu
|
||||
```
|
||||
|
||||
### Combined temperature sensor
|
||||
|
||||
Combined temperature sensor is a virtual temperature sensor based on several other sensors. This sensor can be used with extruders, heater_generic and heater beds.
|
||||
|
||||
```
|
||||
sensor_type: temperature_combined
|
||||
#sensor_list:
|
||||
# Must be provided. List of sensors to combine to new "virtual"
|
||||
# sensor.
|
||||
# E.g. 'temperature_sensor sensor1,extruder,heater_bed'
|
||||
#combination_method:
|
||||
# Must be provided. Combination method used for the sensor.
|
||||
# Available options are 'max', 'min', 'mean'.
|
||||
#maximum_deviation:
|
||||
# Must be provided. Maximum permissible deviation between the sensors
|
||||
# to combine (e.g. 5 degrees). To disable it, use a large value (e.g. 999.9)
|
||||
```
|
||||
|
||||
## Fans
|
||||
|
||||
### [fan]
|
||||
@@ -2446,6 +2703,12 @@ pin:
|
||||
# enough for fans below 10000 RPM at 2 PPR. This must be smaller than
|
||||
# 30/(tachometer_ppr*rpm), with some margin, where rpm is the
|
||||
# maximum speed (in RPM) of the fan.
|
||||
#enable_pin:
|
||||
# Optional pin to enable power to the fan. This can be useful for fans
|
||||
# with dedicated PWM inputs. Some of these fans stay on even at 0% PWM
|
||||
# input. In such a case, the PWM pin can be used normally, and e.g. a
|
||||
# ground-switched FET(standard fan pin) can be used to control power to
|
||||
# the fan.
|
||||
```
|
||||
|
||||
### [heater_fan]
|
||||
@@ -2456,7 +2719,7 @@ whenever its associated heater is active. By default, a heater_fan has
|
||||
a shutdown_speed equal to max_power.
|
||||
|
||||
```
|
||||
[heater_fan my_nozzle_fan]
|
||||
[heater_fan heatbreak_cooling_fan]
|
||||
#pin:
|
||||
#max_power:
|
||||
#shutdown_speed:
|
||||
@@ -2467,6 +2730,7 @@ a shutdown_speed equal to max_power.
|
||||
#tachometer_pin:
|
||||
#tachometer_ppr:
|
||||
#tachometer_poll_interval:
|
||||
#enable_pin:
|
||||
# See the "fan" section for a description of the above parameters.
|
||||
#heater: extruder
|
||||
# Name of the config section defining the heater that this fan is
|
||||
@@ -2503,6 +2767,7 @@ watched component.
|
||||
#tachometer_pin:
|
||||
#tachometer_ppr:
|
||||
#tachometer_poll_interval:
|
||||
#enable_pin:
|
||||
# See the "fan" section for a description of the above parameters.
|
||||
#fan_speed: 1.0
|
||||
# The fan speed (expressed as a value from 0.0 to 1.0) that the fan
|
||||
@@ -2548,6 +2813,7 @@ information.
|
||||
#tachometer_pin:
|
||||
#tachometer_ppr:
|
||||
#tachometer_poll_interval:
|
||||
#enable_pin:
|
||||
# See the "fan" section for a description of the above parameters.
|
||||
#sensor_type:
|
||||
#sensor_pin:
|
||||
@@ -2605,6 +2871,7 @@ with the SET_FAN_SPEED [gcode command](G-Codes.md#fan_generic).
|
||||
#tachometer_pin:
|
||||
#tachometer_ppr:
|
||||
#tachometer_poll_interval:
|
||||
#enable_pin:
|
||||
# See the "fan" section for a description of the above parameters.
|
||||
```
|
||||
|
||||
@@ -2707,6 +2974,8 @@ PCA9533 LED support. The PCA9533 is used on the mightyboard.
|
||||
# the PCA9533/1, 99 for the PCA9533/2. The default is 98.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -2728,6 +2997,8 @@ PCA9632 LED support. The PCA9632 is used on the FlashForge Dreamer.
|
||||
# 96, 97, 98, or 99. The default is 98.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -2864,6 +3135,27 @@ pin:
|
||||
# parameter.
|
||||
```
|
||||
|
||||
### [pwm_tool]
|
||||
|
||||
Pulse width modulation digital output pins capable of high speed
|
||||
updates (one may define any number of sections with an "output_pin"
|
||||
prefix). Pins configured here will be setup as output pins and one may
|
||||
modify them at run-time using "SET_PIN PIN=my_pin VALUE=.1" type
|
||||
extended [g-code commands](G-Codes.md#output_pin).
|
||||
|
||||
```
|
||||
[pwm_tool my_tool]
|
||||
pin:
|
||||
# The pin to configure as an output. This parameter must be provided.
|
||||
#value:
|
||||
#shutdown_value:
|
||||
#maximum_mcu_duration:
|
||||
#cycle_time: 0.100
|
||||
#hardware_pwm: False
|
||||
#scale:
|
||||
# See the "output_pin" section for the definition of these parameters.
|
||||
```
|
||||
|
||||
### [static_digital_output]
|
||||
|
||||
Statically configured digital output pins (one may define any number
|
||||
@@ -2949,6 +3241,30 @@ run_current:
|
||||
# set, "stealthChop" mode will be enabled if the stepper motor
|
||||
# velocity is below this value. The default is 0, which disables
|
||||
# "stealthChop" mode.
|
||||
#driver_MSLUT0: 2863314260
|
||||
#driver_MSLUT1: 1251300522
|
||||
#driver_MSLUT2: 608774441
|
||||
#driver_MSLUT3: 269500962
|
||||
#driver_MSLUT4: 4227858431
|
||||
#driver_MSLUT5: 3048961917
|
||||
#driver_MSLUT6: 1227445590
|
||||
#driver_MSLUT7: 4211234
|
||||
#driver_W0: 2
|
||||
#driver_W1: 1
|
||||
#driver_W2: 1
|
||||
#driver_W3: 1
|
||||
#driver_X1: 128
|
||||
#driver_X2: 255
|
||||
#driver_X3: 255
|
||||
#driver_START_SIN: 0
|
||||
#driver_START_SIN90: 247
|
||||
# These fields control the Microstep Table registers directly. The optimal
|
||||
# wave table is specific to each motor and might vary with current. An
|
||||
# optimal configuration will have minimal print artifacts caused by
|
||||
# non-linear stepper movement. The values specified above are the default
|
||||
# values used by the driver. The value must be specified as a decimal integer
|
||||
# (hex form is not supported). In order to compute the wave table fields,
|
||||
# see the tmc2130 "Calculation Sheet" from the Trinamic website.
|
||||
#driver_IHOLDDELAY: 8
|
||||
#driver_TPOWERDOWN: 0
|
||||
#driver_TBL: 1
|
||||
@@ -3018,6 +3334,7 @@ run_current:
|
||||
# set, "stealthChop" mode will be enabled if the stepper motor
|
||||
# velocity is below this value. The default is 0, which disables
|
||||
# "stealthChop" mode.
|
||||
#driver_MULTISTEP_FILT: True
|
||||
#driver_IHOLDDELAY: 8
|
||||
#driver_TPOWERDOWN: 20
|
||||
#driver_TBL: 2
|
||||
@@ -3059,6 +3376,7 @@ run_current:
|
||||
# The address of the TMC2209 chip for UART messages (an integer
|
||||
# between 0 and 3). This is typically used when multiple TMC2209
|
||||
# chips are connected to the same UART pin. The default is zero.
|
||||
#driver_MULTISTEP_FILT: True
|
||||
#driver_IHOLDDELAY: 8
|
||||
#driver_TPOWERDOWN: 20
|
||||
#driver_TBL: 2
|
||||
@@ -3159,6 +3477,130 @@ run_current:
|
||||
# HDEC) is interpreted as the MSB of HSTRT in this case).
|
||||
```
|
||||
|
||||
### [tmc2240]
|
||||
|
||||
Configure a TMC2240 stepper motor driver via SPI bus or UART. To use this
|
||||
feature, define a config section with a "tmc2240" prefix followed by
|
||||
the name of the corresponding stepper config section (for example,
|
||||
"[tmc2240 stepper_x]").
|
||||
|
||||
```
|
||||
[tmc2240 stepper_x]
|
||||
cs_pin:
|
||||
# The pin corresponding to the TMC2240 chip select line. This pin
|
||||
# will be set to low at the start of SPI messages and raised to high
|
||||
# after the message completes. This parameter must be provided.
|
||||
#spi_speed:
|
||||
#spi_bus:
|
||||
#spi_software_sclk_pin:
|
||||
#spi_software_mosi_pin:
|
||||
#spi_software_miso_pin:
|
||||
# See the "common SPI settings" section for a description of the
|
||||
# above parameters.
|
||||
#uart_pin:
|
||||
# The pin connected to the TMC2240 DIAG1/SW line. If this parameter
|
||||
# is provided UART communication is used rather then SPI.
|
||||
#chain_position:
|
||||
#chain_length:
|
||||
# These parameters configure an SPI daisy chain. The two parameters
|
||||
# define the stepper position in the chain and the total chain length.
|
||||
# Position 1 corresponds to the stepper that connects to the MOSI signal.
|
||||
# The default is to not use an SPI daisy chain.
|
||||
#interpolate: True
|
||||
# If true, enable step interpolation (the driver will internally
|
||||
# step at a rate of 256 micro-steps). The default is True.
|
||||
run_current:
|
||||
# The amount of current (in amps RMS) to configure the driver to use
|
||||
# during stepper movement. This parameter must be provided.
|
||||
#hold_current:
|
||||
# The amount of current (in amps RMS) to configure the driver to use
|
||||
# when the stepper is not moving. Setting a hold_current is not
|
||||
# recommended (see TMC_Drivers.md for details). The default is to
|
||||
# not reduce the current.
|
||||
#rref: 12000
|
||||
# The resistance (in ohms) of the resistor between IREF and GND. The
|
||||
# default is 12000.
|
||||
#stealthchop_threshold: 0
|
||||
# The velocity (in mm/s) to set the "stealthChop" threshold to. When
|
||||
# set, "stealthChop" mode will be enabled if the stepper motor
|
||||
# velocity is below this value. The default is 0, which disables
|
||||
# "stealthChop" mode.
|
||||
#driver_MSLUT0: 2863314260
|
||||
#driver_MSLUT1: 1251300522
|
||||
#driver_MSLUT2: 608774441
|
||||
#driver_MSLUT3: 269500962
|
||||
#driver_MSLUT4: 4227858431
|
||||
#driver_MSLUT5: 3048961917
|
||||
#driver_MSLUT6: 1227445590
|
||||
#driver_MSLUT7: 4211234
|
||||
#driver_W0: 2
|
||||
#driver_W1: 1
|
||||
#driver_W2: 1
|
||||
#driver_W3: 1
|
||||
#driver_X1: 128
|
||||
#driver_X2: 255
|
||||
#driver_X3: 255
|
||||
#driver_START_SIN: 0
|
||||
#driver_START_SIN90: 247
|
||||
#driver_OFFSET_SIN90: 0
|
||||
# These fields control the Microstep Table registers directly. The optimal
|
||||
# wave table is specific to each motor and might vary with current. An
|
||||
# optimal configuration will have minimal print artifacts caused by
|
||||
# non-linear stepper movement. The values specified above are the default
|
||||
# values used by the driver. The value must be specified as a decimal integer
|
||||
# (hex form is not supported). In order to compute the wave table fields,
|
||||
# see the tmc2130 "Calculation Sheet" from the Trinamic website.
|
||||
# Additionally, this driver also has the OFFSET_SIN90 field which can be used
|
||||
# to tune a motor with unbalanced coils. See the `Sine Wave Lookup Table`
|
||||
# section in the datasheet for information about this field and how to tune
|
||||
# it.
|
||||
#driver_MULTISTEP_FILT: True
|
||||
#driver_IHOLDDELAY: 6
|
||||
#driver_IRUNDELAY: 4
|
||||
#driver_TPOWERDOWN: 10
|
||||
#driver_TBL: 2
|
||||
#driver_TOFF: 3
|
||||
#driver_HEND: 2
|
||||
#driver_HSTRT: 5
|
||||
#driver_FD3: 0
|
||||
#driver_TPFD: 4
|
||||
#driver_CHM: 0
|
||||
#driver_VHIGHFS: 0
|
||||
#driver_VHIGHCHM: 0
|
||||
#driver_DISS2G: 0
|
||||
#driver_DISS2VS: 0
|
||||
#driver_PWM_AUTOSCALE: True
|
||||
#driver_PWM_AUTOGRAD: True
|
||||
#driver_PWM_FREQ: 0
|
||||
#driver_FREEWHEEL: 0
|
||||
#driver_PWM_GRAD: 0
|
||||
#driver_PWM_OFS: 29
|
||||
#driver_PWM_REG: 4
|
||||
#driver_PWM_LIM: 12
|
||||
#driver_SGT: 0
|
||||
#driver_SEMIN: 0
|
||||
#driver_SEUP: 0
|
||||
#driver_SEMAX: 0
|
||||
#driver_SEDN: 0
|
||||
#driver_SEIMIN: 0
|
||||
#driver_SFILT: 0
|
||||
#driver_SG4_ANGLE_OFFSET: 1
|
||||
# Set the given register during the configuration of the TMC2240
|
||||
# chip. This may be used to set custom motor parameters. The
|
||||
# defaults for each parameter are next to the parameter name in the
|
||||
# above list.
|
||||
#diag0_pin:
|
||||
#diag1_pin:
|
||||
# The micro-controller pin attached to one of the DIAG lines of the
|
||||
# TMC2240 chip. Only a single diag pin should be specified. The pin
|
||||
# is "active low" and is thus normally prefaced with "^!". Setting
|
||||
# this creates a "tmc2240_stepper_x:virtual_endstop" virtual pin
|
||||
# which may be used as the stepper's endstop_pin. Doing this enables
|
||||
# "sensorless homing". (Be sure to also set driver_SGT to an
|
||||
# appropriate sensitivity value.) The default is to not enable
|
||||
# sensorless homing.
|
||||
```
|
||||
|
||||
### [tmc5160]
|
||||
|
||||
Configure a TMC5160 stepper motor driver via SPI bus. To use this
|
||||
@@ -3204,6 +3646,31 @@ run_current:
|
||||
# set, "stealthChop" mode will be enabled if the stepper motor
|
||||
# velocity is below this value. The default is 0, which disables
|
||||
# "stealthChop" mode.
|
||||
#driver_MSLUT0: 2863314260
|
||||
#driver_MSLUT1: 1251300522
|
||||
#driver_MSLUT2: 608774441
|
||||
#driver_MSLUT3: 269500962
|
||||
#driver_MSLUT4: 4227858431
|
||||
#driver_MSLUT5: 3048961917
|
||||
#driver_MSLUT6: 1227445590
|
||||
#driver_MSLUT7: 4211234
|
||||
#driver_W0: 2
|
||||
#driver_W1: 1
|
||||
#driver_W2: 1
|
||||
#driver_W3: 1
|
||||
#driver_X1: 128
|
||||
#driver_X2: 255
|
||||
#driver_X3: 255
|
||||
#driver_START_SIN: 0
|
||||
#driver_START_SIN90: 247
|
||||
# These fields control the Microstep Table registers directly. The optimal
|
||||
# wave table is specific to each motor and might vary with current. An
|
||||
# optimal configuration will have minimal print artifacts caused by
|
||||
# non-linear stepper movement. The values specified above are the default
|
||||
# values used by the driver. The value must be specified as a decimal integer
|
||||
# (hex form is not supported). In order to compute the wave table fields,
|
||||
# see the tmc2130 "Calculation Sheet" from the Trinamic website.
|
||||
#driver_MULTISTEP_FILT: True
|
||||
#driver_IHOLDDELAY: 6
|
||||
#driver_TPOWERDOWN: 10
|
||||
#driver_TBL: 2
|
||||
@@ -3232,6 +3699,10 @@ run_current:
|
||||
#driver_SEDN: 0
|
||||
#driver_SEIMIN: 0
|
||||
#driver_SFILT: 0
|
||||
#driver_DRVSTRENGTH: 0
|
||||
#driver_BBMCLKS: 4
|
||||
#driver_BBMTIME: 0
|
||||
#driver_FILT_ISENSE: 0
|
||||
# Set the given register during the configuration of the TMC5160
|
||||
# chip. This may be used to set custom motor parameters. The
|
||||
# defaults for each parameter are next to the parameter name in the
|
||||
@@ -3302,6 +3773,8 @@ i2c_address:
|
||||
# parameter must be provided.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -3338,6 +3811,8 @@ prefix).
|
||||
# is 96.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
@@ -3608,6 +4083,8 @@ lcd_type:
|
||||
# Set to either "ssd1306" or "sh1106" for the given display type.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# Optional parameters available for displays connected via an i2c
|
||||
# bus. See the "common I2C settings" section for a description of
|
||||
@@ -3952,6 +4429,9 @@ adc2:
|
||||
# command.
|
||||
#min_diameter: 1.0
|
||||
# Minimal diameter for trigger virtual filament_switch_sensor.
|
||||
#max_diameter:
|
||||
# Maximum diameter for triggering virtual filament_switch_sensor.
|
||||
# The default is default_nominal_filament_diameter + max_difference.
|
||||
#use_current_dia_while_delay: False
|
||||
# Use the current diameter instead of the nominal diameter while
|
||||
# the measurement delay has not run through.
|
||||
@@ -3988,13 +4468,11 @@ i2c_address:
|
||||
# 113. This parameter must be provided.
|
||||
#i2c_mcu:
|
||||
#i2c_bus:
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
#i2c_speed:
|
||||
# See the "common I2C settings" section for a description of the
|
||||
# above parameters.
|
||||
#i2c_bus:
|
||||
# If the I2C implementation of your micro-controller supports
|
||||
# multiple I2C busses, you may specify the bus name here. The
|
||||
# default is to use the default micro-controller i2c bus.
|
||||
```
|
||||
|
||||
### [samd_sercom]
|
||||
@@ -4151,7 +4629,7 @@ serial:
|
||||
#auto_load_speed: 2
|
||||
# Extrude feedrate when autoloading, default is 2 (mm/s)
|
||||
#auto_cancel_variation: 0.1
|
||||
# Auto cancel print when ping varation is above this threshold
|
||||
# Auto cancel print when ping variation is above this threshold
|
||||
```
|
||||
|
||||
### [angle]
|
||||
@@ -4217,20 +4695,20 @@ SPI bus.
|
||||
The following parameters are generally available for devices using an
|
||||
I2C bus.
|
||||
|
||||
Note that Klipper's current micro-controller support for i2c is
|
||||
generally not tolerant to line noise. Unexpected errors on the i2c
|
||||
Note that Klipper's current micro-controller support for I2C is
|
||||
generally not tolerant to line noise. Unexpected errors on the I2C
|
||||
wires may result in Klipper raising a run-time error. Klipper's
|
||||
support for error recovery varies between each micro-controller type.
|
||||
It is generally recommended to only use i2c devices that are on the
|
||||
It is generally recommended to only use I2C devices that are on the
|
||||
same printed circuit board as the micro-controller.
|
||||
|
||||
Most Klipper micro-controller implementations only support an
|
||||
`i2c_speed` of 100000. The Klipper "linux" micro-controller supports a
|
||||
400000 speed, but it must be
|
||||
`i2c_speed` of 100000 (*standard mode*, 100kbit/s). The Klipper "Linux"
|
||||
micro-controller supports a 400000 speed (*fast mode*, 400kbit/s), but it must be
|
||||
[set in the operating system](RPi_microcontroller.md#optional-enabling-i2c)
|
||||
and the `i2c_speed` parameter is otherwise ignored. The Klipper
|
||||
"rp2040" micro-controller supports a rate of 400000 via the
|
||||
`i2c_speed` parameter. All other Klipper micro-controllers use a
|
||||
"RP2040" micro-controller and ATmega AVR family support a rate of 400000
|
||||
via the `i2c_speed` parameter. All other Klipper micro-controllers use a
|
||||
100000 rate and ignore the `i2c_speed` parameter.
|
||||
|
||||
```
|
||||
@@ -4244,9 +4722,16 @@ and the `i2c_speed` parameter is otherwise ignored. The Klipper
|
||||
# If the micro-controller supports multiple I2C busses then one may
|
||||
# specify the micro-controller bus name here. The default depends on
|
||||
# the type of micro-controller.
|
||||
#i2c_software_scl_pin:
|
||||
#i2c_software_sda_pin:
|
||||
# Specify these parameters to use micro-controller software based
|
||||
# I2C "bit-banging" support. The two parameters should the two pins
|
||||
# on the micro-controller to use for the scl and sda wires. The
|
||||
# default is to use hardware based I2C support as specified by the
|
||||
# i2c_bus parameter.
|
||||
#i2c_speed:
|
||||
# The I2C speed (in Hz) to use when communicating with the device.
|
||||
# The Klipper implementation on most micro-controllers is hard-coded
|
||||
# to 100000 and changing this value has no effect. The default is
|
||||
# 100000.
|
||||
# 100000. Linux, RP2040 and ATmega support 400000.
|
||||
```
|
||||
|
||||
@@ -15,10 +15,7 @@ config file is successfully loaded.
|
||||
## Verify temperature
|
||||
|
||||
Start by verifying that temperatures are being properly reported.
|
||||
Navigate to the Octoprint temperature tab.
|
||||
|
||||
|
||||
|
||||
Navigate to the temperature graph section in the user interface.
|
||||
Verify that the temperature of the nozzle and bed (if applicable) are
|
||||
present and not increasing. If it is increasing, remove power from the
|
||||
printer. If the temperatures are not accurate, review the
|
||||
@@ -26,28 +23,25 @@ printer. If the temperatures are not accurate, review the
|
||||
|
||||
## Verify M112
|
||||
|
||||
Navigate to the Octoprint terminal tab and issue an M112 command in
|
||||
the terminal box. This command requests Klipper to go into a
|
||||
"shutdown" state. It will cause Octoprint to disconnect from Klipper -
|
||||
navigate to the Connection area and click on "Connect" to cause
|
||||
Octoprint to reconnect. Then navigate to the Octoprint temperature tab
|
||||
and verify that temperatures continue to update and the temperatures
|
||||
are not increasing. If temperatures are increasing, remove power from
|
||||
the printer.
|
||||
|
||||
The M112 command causes Klipper to go into a "shutdown" state. To
|
||||
clear this state, issue a FIRMWARE_RESTART command in the Octoprint
|
||||
terminal tab.
|
||||
Navigate to the command console and issue an M112
|
||||
command in the terminal box. This command requests Klipper to go into a
|
||||
"shutdown" state. It will cause an error to show,
|
||||
which can be cleared with a FIRMWARE_RESTART command in the
|
||||
command console. Octoprint will also require a reconnect. Then navigate
|
||||
to the temperature graph section and verify that temperatures continue
|
||||
to update and the temperatures are not increasing.
|
||||
If temperatures are increasing, remove power from the printer.
|
||||
|
||||
## Verify heaters
|
||||
|
||||
Navigate to the Octoprint temperature tab and type in 50 followed by
|
||||
enter in the "Tool" temperature box. The extruder temperature in the
|
||||
graph should start to increase (within about 30 seconds or so). Then
|
||||
go to the "Tool" temperature drop-down box and select "Off". After
|
||||
several minutes the temperature should start to return to its initial
|
||||
room temperature value. If the temperature does not increase then
|
||||
verify the "heater_pin" setting in the config.
|
||||
Navigate to the temperature graph section and type in 50 followed by
|
||||
enter in the extruder/tool temperature box.
|
||||
The extruder temperature in the graph should start to increase
|
||||
(within about 30 seconds or so). Then go to the extruder temperature
|
||||
drop-down box and select "Off". After several minutes the temperature
|
||||
should start to return to its initial room temperature value. If the
|
||||
temperature does not increase then verify the "heater_pin" setting
|
||||
in the config.
|
||||
|
||||
If the printer has a heated bed then perform the above test again with
|
||||
the bed.
|
||||
@@ -60,21 +54,20 @@ the motors. If any of the axes still can not move freely, then verify
|
||||
the stepper "enable_pin" configuration for the given axis. On most
|
||||
commodity stepper motor drivers, the motor enable pin is "active low"
|
||||
and therefore the enable pin should have a "!" before the pin (for
|
||||
example, "enable_pin: !ar38").
|
||||
example, "enable_pin: !PA1").
|
||||
|
||||
## Verify endstops
|
||||
|
||||
Manually move all the printer axes so that none of them are in contact
|
||||
with an endstop. Send a QUERY_ENDSTOPS command via the Octoprint
|
||||
terminal tab. It should respond with the current state of all of the
|
||||
configured endstops and they should all report a state of "open". For
|
||||
each of the endstops, rerun the QUERY_ENDSTOPS command while manually
|
||||
triggering the endstop. The QUERY_ENDSTOPS command should report the
|
||||
endstop as "TRIGGERED".
|
||||
with an endstop. Send a QUERY_ENDSTOPS command via the command console.
|
||||
It should respond with the current state of all of the configured endstops
|
||||
and they should all report a state of "open". For each of the endstops,
|
||||
rerun the QUERY_ENDSTOPS command while manually triggering the endstop.
|
||||
The QUERY_ENDSTOPS command should report the endstop as "TRIGGERED".
|
||||
|
||||
If the endstop appears inverted (it reports "open" when triggered and
|
||||
vice-versa) then add a "!" to the pin definition (for example,
|
||||
"endstop_pin: ^!ar3"), or remove the "!" if there is already one
|
||||
"endstop_pin: ^!PA2"), or remove the "!" if there is already one
|
||||
present.
|
||||
|
||||
If the endstop does not change at all then it generally indicates that
|
||||
@@ -87,12 +80,13 @@ resistor and the '^' should be present).
|
||||
|
||||
Use the STEPPER_BUZZ command to verify the connectivity of each
|
||||
stepper motor. Start by manually positioning the given axis to a
|
||||
midway point and then run `STEPPER_BUZZ STEPPER=stepper_x`. The
|
||||
STEPPER_BUZZ command will cause the given stepper to move one
|
||||
millimeter in a positive direction and then it will return to its
|
||||
starting position. (If the endstop is defined at position_endstop=0
|
||||
then at the start of each movement the stepper will move away from the
|
||||
endstop.) It will perform this oscillation ten times.
|
||||
midway point and then run `STEPPER_BUZZ STEPPER=stepper_x` in the
|
||||
command console. The STEPPER_BUZZ command will cause the given
|
||||
stepper to move one millimeter in a positive direction and then it
|
||||
will return to its starting position. (If the endstop is defined at
|
||||
position_endstop=0 then at the start of each movement the stepper
|
||||
will move away from the endstop.) It will perform this oscillation
|
||||
ten times.
|
||||
|
||||
If the stepper does not move at all, then verify the "enable_pin" and
|
||||
"step_pin" settings for the stepper. If the stepper motor moves but
|
||||
@@ -119,11 +113,11 @@ Rerun the endstop and stepper motor verification steps if necessary.
|
||||
## Verify extruder motor
|
||||
|
||||
To test the extruder motor it will be necessary to heat the extruder
|
||||
to a printing temperature. Navigate to the Octoprint temperature tab
|
||||
to a printing temperature. Navigate to the temperature graph section
|
||||
and select a target temperature from the temperature drop-down box (or
|
||||
manually enter an appropriate temperature). Wait for the printer to
|
||||
reach the desired temperature. Then navigate to the Octoprint control
|
||||
tab and click the "Extrude" button. Verify that the extruder motor
|
||||
reach the desired temperature. Then navigate to the command console and
|
||||
click the "Extrude" button. Verify that the extruder motor
|
||||
turns in the correct direction. If it does not, see the
|
||||
troubleshooting tips in the previous section to confirm the
|
||||
"enable_pin", "step_pin", and "dir_pin" settings for the extruder.
|
||||
@@ -137,8 +131,8 @@ necessary to calibrate the PID settings on each printer (PID settings
|
||||
found in other firmwares or in the example configuration files often
|
||||
work poorly).
|
||||
|
||||
To calibrate the extruder, navigate to the OctoPrint terminal tab and
|
||||
run the PID_CALIBRATE command. For example: `PID_CALIBRATE
|
||||
To calibrate the extruder, navigate to the command console
|
||||
and run the PID_CALIBRATE command. For example: `PID_CALIBRATE
|
||||
HEATER=extruder TARGET=170`
|
||||
|
||||
At the completion of the tuning test run `SAVE_CONFIG` to update the
|
||||
|
||||
137
docs/Contact.md
137
docs/Contact.md
@@ -2,24 +2,18 @@
|
||||
|
||||
This document provides contact information for Klipper.
|
||||
|
||||
1. [Community Forum](#community-forum)
|
||||
2. [Discord Chat](#discord-chat)
|
||||
3. [I have a question about Klipper](#i-have-a-question-about-klipper)
|
||||
4. [I have a feature request](#i-have-a-feature-request)
|
||||
5. [Help! It doesn't work!](#help-it-doesnt-work)
|
||||
6. [I have diagnosed a defect in the Klipper software](#i-have-diagnosed-a-defect-in-the-klipper-software)
|
||||
7. [I am making changes that I'd like to include in Klipper](#i-am-making-changes-that-id-like-to-include-in-klipper)
|
||||
|
||||
## Community Forum
|
||||
## Discourse Forum
|
||||
|
||||
There is a
|
||||
[Klipper Community Discourse server](https://community.klipper3d.org)
|
||||
for discussions on Klipper.
|
||||
for "forum" style discussions on Klipper. Note that Discourse is not
|
||||
Discord.
|
||||
|
||||
## Discord Chat
|
||||
|
||||
There is a Discord server dedicated to Klipper at:
|
||||
[https://discord.klipper3d.org](https://discord.klipper3d.org).
|
||||
[https://discord.klipper3d.org](https://discord.klipper3d.org). Note
|
||||
that Discord is not Discourse.
|
||||
|
||||
This server is run by a community of Klipper enthusiasts dedicated to
|
||||
discussions on Klipper. It allows users to chat with other users in
|
||||
@@ -32,41 +26,29 @@ Many questions we receive are already answered in the
|
||||
documentation and follow the directions provided there.
|
||||
|
||||
It is also possible to search for similar questions in the
|
||||
[Klipper Community Forum](#community-forum).
|
||||
[Klipper Discourse Forum](#discourse-forum).
|
||||
|
||||
If you are interested in sharing your knowledge and experience with
|
||||
other Klipper users then you can join the
|
||||
[Klipper Community Forum](#community-forum) or
|
||||
[Klipper Discourse Forum](#discourse-forum) or
|
||||
[Klipper Discord Chat](#discord-chat). Both are communities where
|
||||
Klipper users can discuss Klipper with other users.
|
||||
|
||||
Many questions we receive are general 3d-printing questions that are
|
||||
not specific to Klipper. If you have a general question or are
|
||||
experiencing general printing problems, then you will likely get a
|
||||
better response by asking in a general 3d-printing forum or a forum
|
||||
dedicated to your printer hardware.
|
||||
|
||||
Do not open a Klipper github issue to ask a question.
|
||||
If you have a general question or are experiencing general printing
|
||||
problems, then also consider a general 3d-printing forum or a forum
|
||||
dedicated to the printer hardware.
|
||||
|
||||
## I have a feature request
|
||||
|
||||
All new features require someone interested and able to implement that
|
||||
feature. If you are interested in helping to implement or test a new
|
||||
feature, you can search for ongoing developments in the
|
||||
[Klipper Community Forum](#community-forum). There is also
|
||||
[Klipper Discourse Forum](#discourse-forum). There is also
|
||||
[Klipper Discord Chat](#discord-chat) for discussions between
|
||||
collaborators.
|
||||
|
||||
Do not open a Klipper github issue to request a feature.
|
||||
|
||||
## Help! It doesn't work!
|
||||
|
||||
Unfortunately, we receive many more requests for help than we could
|
||||
possibly answer. Most problem reports we see are eventually tracked
|
||||
down to:
|
||||
1. Subtle errors in the hardware, or
|
||||
2. Not following all the steps described in the Klipper documentation.
|
||||
|
||||
If you are experiencing problems we recommend you carefully read the
|
||||
[Klipper documentation](Overview.md) and double check that all steps
|
||||
were followed.
|
||||
@@ -75,91 +57,78 @@ If you are experiencing a printing problem, then we recommend
|
||||
carefully inspecting the printer hardware (all joints, wires, screws,
|
||||
etc.) and verify nothing is abnormal. We find most printing problems
|
||||
are not related to the Klipper software. If you do find a problem with
|
||||
the printer hardware then you will likely get a better response by
|
||||
searching in a general 3d-printing forum or in a forum dedicated to
|
||||
your printer hardware.
|
||||
the printer hardware then consider searching general 3d-printing
|
||||
forums or forums dedicated to the printer hardware.
|
||||
|
||||
It is also possible to search for similar issues in the
|
||||
[Klipper Community Forum](#community-forum).
|
||||
[Klipper Discourse Forum](#discourse-forum).
|
||||
|
||||
If you are interested in sharing your knowledge and experience with
|
||||
other Klipper users then you can join the
|
||||
[Klipper Community Forum](#community-forum) or
|
||||
[Klipper Discourse Forum](#discourse-forum) or
|
||||
[Klipper Discord Chat](#discord-chat). Both are communities where
|
||||
Klipper users can discuss Klipper with other users.
|
||||
|
||||
Do not open a Klipper github issue to request help.
|
||||
|
||||
## I have diagnosed a defect in the Klipper software
|
||||
## I found a bug in the Klipper software
|
||||
|
||||
Klipper is an open-source project and we appreciate when collaborators
|
||||
diagnose errors in the software.
|
||||
|
||||
Problems should be reported in the
|
||||
[Klipper Discourse Forum](#discourse-forum).
|
||||
|
||||
There is important information that will be needed in order to fix a
|
||||
bug. Please follow these steps:
|
||||
1. Be sure the bug is in the Klipper software. If you are thinking
|
||||
"there is a problem, I can't figure out why, and therefore it is a
|
||||
Klipper bug", then **do not** open a github issue. In that case,
|
||||
someone interested and able will need to first research and
|
||||
diagnose the root cause of the problem. If you would like to share
|
||||
the results of your research or check if other users are
|
||||
experiencing similar issues then you can search the
|
||||
[Klipper Community Forum](#community-forum).
|
||||
2. Make sure you are running unmodified code from
|
||||
1. Make sure you are running unmodified code from
|
||||
[https://github.com/Klipper3d/klipper](https://github.com/Klipper3d/klipper).
|
||||
If the code has been modified or is obtained from another source,
|
||||
then you will need to reproduce the problem on the unmodified code
|
||||
from
|
||||
then you should reproduce the problem on the unmodified code from
|
||||
[https://github.com/Klipper3d/klipper](https://github.com/Klipper3d/klipper)
|
||||
prior to reporting an issue.
|
||||
3. If possible, run an `M112` command in the OctoPrint terminal window
|
||||
immediately after the undesirable event occurs. This causes Klipper
|
||||
to go into a "shutdown state" and it will cause additional
|
||||
debugging information to be written to the log file.
|
||||
4. Obtain the Klipper log file from the event. The log file has been
|
||||
prior to reporting.
|
||||
2. If possible, run an `M112` command immediately after the
|
||||
undesirable event occurs. This causes Klipper to go into a
|
||||
"shutdown state" and it will cause additional debugging information
|
||||
to be written to the log file.
|
||||
3. Obtain the Klipper log file from the event. The log file has been
|
||||
engineered to answer common questions the Klipper developers have
|
||||
about the software and its environment (software version, hardware
|
||||
type, configuration, event timing, and hundreds of other
|
||||
questions).
|
||||
1. The Klipper log file is located in `/tmp/klippy.log` on the
|
||||
Klipper "host" computer (the Raspberry Pi).
|
||||
2. An "scp" or "sftp" utility is needed to copy this log file to
|
||||
your desktop computer. The "scp" utility comes standard with
|
||||
Linux and MacOS desktops. There are freely available scp
|
||||
utilities for other desktops (eg, WinSCP). If using a graphical
|
||||
scp utility that can not directly copy `/tmp/klippy.log` then
|
||||
repeatedly click on `..` or `parent folder` until you get to the
|
||||
root directory, click on the `tmp` folder, and then select the
|
||||
`klippy.log` file.
|
||||
3. Copy the log file to your desktop so that it can be attached to
|
||||
1. Dedicated Klipper web interfaces have the ability to directly
|
||||
obtain the Klipper log file. It's the easiest way to obtain the
|
||||
log when using one of these interfaces. Otherwise, an "scp" or
|
||||
"sftp" utility is needed to copy the log file to your desktop
|
||||
computer. The "scp" utility comes standard with Linux and MacOS
|
||||
desktops. There are freely available scp utilities for other
|
||||
desktops (eg, WinSCP). The log file may be located in the
|
||||
`~/printer_data/logs/klippy.log` file (if using a graphical scp
|
||||
utility, look for the "printer_data" folder, then the "logs"
|
||||
folder under that, then the `klippy.log` file). The log file may
|
||||
alternatively be located in the `/tmp/klippy.log` file (if using
|
||||
a graphical scp utility that can not directly copy
|
||||
`/tmp/klippy.log` then repeatedly click on `..` or
|
||||
"parent folder" until reaching the root directory, click on
|
||||
the `tmp` folder, and then select the `klippy.log` file).
|
||||
2. Copy the log file to your desktop so that it can be attached to
|
||||
an issue report.
|
||||
4. Do not modify the log file in any way; do not provide a snippet
|
||||
3. Do not modify the log file in any way; do not provide a snippet
|
||||
of the log. Only the full unmodified log file provides the
|
||||
necessary information.
|
||||
5. If the log file is very large (eg, greater than 2MB) then one
|
||||
may need to compress the log with zip or gzip.
|
||||
5. Open a new github issue at
|
||||
[https://github.com/Klipper3d/klipper/issues](https://github.com/Klipper3d/klipper/issues)
|
||||
and provide a clear description of the problem. The Klipper
|
||||
developers need to understand what steps were taken, what the
|
||||
desired outcome was, and what outcome actually occurred. The
|
||||
Klipper log file **must be attached** to that ticket:
|
||||
|
||||
|
||||
4. It is a good idea to compress the log file with zip or gzip.
|
||||
5. Open a new topic on the [Klipper Discourse Forum](#discourse-forum)
|
||||
and provide a clear description of the problem. Other Klipper
|
||||
contributors will need to understand what steps were taken, what
|
||||
the desired outcome was, and what outcome actually occurred. The
|
||||
compressed Klipper log file should be attached to that topic.
|
||||
|
||||
## I am making changes that I'd like to include in Klipper
|
||||
|
||||
Klipper is open-source software and we appreciate new contributions.
|
||||
|
||||
New contributions (for both code and documentation) are submitted via
|
||||
Github Pull Requests. See the [CONTRIBUTING document](CONTRIBUTING.md)
|
||||
for important information.
|
||||
See the [CONTRIBUTING document](CONTRIBUTING.md) for information.
|
||||
|
||||
There are several
|
||||
[documents for developers](Overview.md#developer-documentation). If
|
||||
you have questions on the code then you can also ask in the
|
||||
[Klipper Community Forum](#community-forum) or on the
|
||||
[Klipper Community Discord](#discord-chat). If you would like to
|
||||
provide an update on your current progress then you can open a Github
|
||||
issue with the location of your code, an overview of the changes, and
|
||||
a description of its current status.
|
||||
[Klipper Discourse Forum](#discourse-forum) or on the
|
||||
[Klipper Discord Chat](#discord-chat).
|
||||
|
||||
@@ -216,7 +216,7 @@ after the above compilation:
|
||||
```
|
||||
ls ./build/pysimulavr/_pysimulavr.*.so
|
||||
```
|
||||
This commmand should report a specific file (e.g.
|
||||
This command should report a specific file (e.g.
|
||||
**./build/pysimulavr/_pysimulavr.cpython-39-x86_64-linux-gnu.so**) and
|
||||
not an error.
|
||||
|
||||
|
||||
@@ -12,10 +12,10 @@ Klipper has several compelling features:
|
||||
kinematic estimations (such as the Bresenham algorithm) - instead it
|
||||
calculates precise step times based on the physics of acceleration
|
||||
and the physics of the machine kinematics. More precise stepper
|
||||
movement translates to quieter and more stable printer operation.
|
||||
movement provides quieter and more stable printer operation.
|
||||
|
||||
* Best in class performance. Klipper is able to achieve high stepping
|
||||
rates on both new and old micro-controllers. Even old 8bit
|
||||
rates on both new and old micro-controllers. Even old 8-bit
|
||||
micro-controllers can obtain rates over 175K steps per second. On
|
||||
more recent micro-controllers, several million steps per second are
|
||||
possible. Higher stepper rates enable higher print velocities. The
|
||||
@@ -53,7 +53,14 @@ Klipper has several compelling features:
|
||||
types of robots easier and it keeps timing precise even with complex
|
||||
kinematics (no "line segmentation" is needed).
|
||||
|
||||
* Portable code. Klipper works on ARM, AVR, and PRU based
|
||||
* Klipper is hardware agnostic. One should get the same precise timing
|
||||
independent of the low-level electronics hardware. The Klipper
|
||||
micro-controller code is designed to faithfully follow the schedule
|
||||
provided by the Klipper host software (or prominently alert the user
|
||||
if it is unable to). This makes it easier to use available hardware,
|
||||
to upgrade to new hardware, and to have confidence in the hardware.
|
||||
|
||||
* Portable code. Klipper works on ARM, AVR, PRU, and other
|
||||
micro-controllers. Existing "reprap" style printers can run Klipper
|
||||
without hardware modification - just add a Raspberry Pi. Klipper's
|
||||
internal code layout makes it easier to support other
|
||||
@@ -78,9 +85,10 @@ Klipper has several compelling features:
|
||||
|
||||
Klipper supports many standard 3d printer features:
|
||||
|
||||
* Works with Octoprint. This allows the printer to be controlled using
|
||||
* Several web interfaces available. Works with Mainsail, Fluidd,
|
||||
OctoPrint and others. This allows the printer to be controlled using
|
||||
a regular web-browser. The same Raspberry Pi that runs Klipper can
|
||||
also run Octoprint.
|
||||
also run the web interface.
|
||||
|
||||
* Standard G-Code support. Common g-code commands that are produced by
|
||||
typical "slicers" (SuperSlicer, Cura, PrusaSlicer, etc.) are
|
||||
@@ -90,25 +98,31 @@ Klipper supports many standard 3d printer features:
|
||||
extruders on independent carriages (IDEX) are also supported.
|
||||
|
||||
* Support for cartesian, delta, corexy, corexz, hybrid-corexy,
|
||||
hybrid-corexz, rotary delta, polar, and cable winch style printers.
|
||||
hybrid-corexz, deltesian, rotary delta, polar, and cable winch style
|
||||
printers.
|
||||
|
||||
* Automatic bed leveling support. Klipper can be configured for basic
|
||||
bed tilt detection or full mesh bed leveling. If the bed uses
|
||||
multiple Z steppers then Klipper can also level by independently
|
||||
manipulating the Z steppers. Most Z height probes are supported,
|
||||
including BL-Touch probes and servo activated probes.
|
||||
including BL-Touch probes and servo activated probes. Probes may be
|
||||
calibrated for axis twist compensation.
|
||||
|
||||
* Automatic delta calibration support. The calibration tool can
|
||||
perform basic height calibration as well as an enhanced X and Y
|
||||
dimension calibration. The calibration can be done with a Z height
|
||||
probe or via manual probing.
|
||||
|
||||
* Run-time "exclude object" support. When configured, this module may
|
||||
facilitate canceling of just one object in a multi-part print.
|
||||
|
||||
* Support for common temperature sensors (eg, common thermistors,
|
||||
AD595, AD597, AD849x, PT100, PT1000, MAX6675, MAX31855, MAX31856,
|
||||
MAX31865, BME280, HTU21D, DS18B20, 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 Raspberry Pi.
|
||||
MAX31865, BME280, HTU21D, DS18B20, AHT10, 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
|
||||
Raspberry Pi.
|
||||
|
||||
* Basic thermal heater protection enabled by default.
|
||||
|
||||
@@ -117,9 +131,9 @@ Klipper supports many standard 3d printer features:
|
||||
speed can be monitored on fans that have a tachometer.
|
||||
|
||||
* Support for run-time configuration of TMC2130, TMC2208/TMC2224,
|
||||
TMC2209, TMC2660, and TMC5160 stepper motor drivers. There is also
|
||||
support for current control of traditional stepper drivers via
|
||||
AD5206, MCP4451, MCP4728, MCP4018, and PWM pins.
|
||||
TMC2209, TMC2240, TMC2660, and TMC5160 stepper motor drivers. There
|
||||
is also support for current control of traditional stepper drivers
|
||||
via AD5206, DAC084S085, MCP4451, MCP4728, MCP4018, and PWM pins.
|
||||
|
||||
* Support for common LCD displays attached directly to the printer. A
|
||||
default menu is also available. The contents of the display and menu
|
||||
@@ -139,8 +153,8 @@ Klipper supports many standard 3d printer features:
|
||||
* Support for filament presence sensors, filament motion sensors, and
|
||||
filament width sensors.
|
||||
|
||||
* Support for measuring and recording acceleration using an adxl345
|
||||
accelerometer.
|
||||
* Support for measuring and recording acceleration using adxl345,
|
||||
mpu9250, mpu6050, and lis2dw12 accelerometers.
|
||||
|
||||
* Support for limiting the top speed of short "zigzag" moves to reduce
|
||||
printer vibration and noise. See the [kinematics](Kinematics.md)
|
||||
@@ -173,8 +187,10 @@ represent total number of steps per second on the micro-controller.
|
||||
| RP2040 | 2400K | 1636K |
|
||||
| SAM4E8E | 2500K | 1674K |
|
||||
| SAMD51 | 3077K | 1885K |
|
||||
| AR100 | 3529K | 2507K |
|
||||
| STM32F407 | 3652K | 2459K |
|
||||
| STM32F446 | 3913K | 2634K |
|
||||
| STM32H743 | 9091K | 6061K |
|
||||
|
||||
If unsure of the micro-controller on a particular board, find the
|
||||
appropriate [config file](../config/), and look for the
|
||||
|
||||
214
docs/G-Codes.md
214
docs/G-Codes.md
@@ -146,14 +146,15 @@ The following commands are available when the
|
||||
(also see the [bed mesh guide](Bed_Mesh.md)).
|
||||
|
||||
#### BED_MESH_CALIBRATE
|
||||
`BED_MESH_CALIBRATE [METHOD=manual] [<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. See the PROBE command for details on the optional probe
|
||||
parameters. If METHOD=manual is specified then the manual probing tool
|
||||
is activated - see the MANUAL_PROBE command above for details on the
|
||||
additional commands available while this tool is active.
|
||||
`BED_MESH_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.
|
||||
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.
|
||||
|
||||
#### BED_MESH_OUTPUT
|
||||
`BED_MESH_OUTPUT PGP=[<0:1>]`: This command outputs the current probed
|
||||
@@ -207,13 +208,14 @@ The following commands are available when the
|
||||
[bed_tilt config section](Config_Reference.md#bed_tilt) is enabled.
|
||||
|
||||
#### BED_TILT_CALIBRATE
|
||||
`BED_TILT_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`: This
|
||||
command will probe the points specified in the config and then
|
||||
recommend updated x and y tilt adjustments. See the PROBE command for
|
||||
details on the optional probe parameters. If METHOD=manual is
|
||||
specified then the manual probing tool is activated - see the
|
||||
MANUAL_PROBE command above for details on the additional commands
|
||||
available while this tool is active.
|
||||
`BED_TILT_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>]
|
||||
[<probe_parameter>=<value>]`: This command will probe the points specified in
|
||||
the config and then recommend updated x and y tilt adjustments. 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.
|
||||
|
||||
### [bltouch]
|
||||
|
||||
@@ -262,13 +264,14 @@ The following commands are available when the
|
||||
is enabled (also see the [delta calibrate guide](Delta_Calibrate.md)).
|
||||
|
||||
#### DELTA_CALIBRATE
|
||||
`DELTA_CALIBRATE [METHOD=manual] [<probe_parameter>=<value>]`: This
|
||||
command will probe seven points on the bed and recommend updated
|
||||
endstop positions, tower angles, and radius. 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.
|
||||
`DELTA_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=<value>]
|
||||
[<probe_parameter>=<value>]`: This command will probe seven points on the bed
|
||||
and recommend updated endstop positions, tower angles, and radius. 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.
|
||||
|
||||
#### DELTA_ANALYZE
|
||||
`DELTA_ANALYZE`: This command is used during enhanced delta
|
||||
@@ -307,9 +310,33 @@ The following command is available when the
|
||||
enabled.
|
||||
|
||||
#### SET_DUAL_CARRIAGE
|
||||
`SET_DUAL_CARRIAGE CARRIAGE=[0|1]`: This command will set the active
|
||||
carriage. It is typically invoked from the activate_gcode and
|
||||
deactivate_gcode fields in a multiple extruder configuration.
|
||||
`SET_DUAL_CARRIAGE CARRIAGE=[0|1] [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).
|
||||
|
||||
#### SAVE_DUAL_CARRIAGE_STATE
|
||||
`SAVE_DUAL_CARRIAGE_STATE [NAME=<state_name>]`: Save the current positions
|
||||
of the dual carriages and their modes. Saving and restoring DUAL_CARRIAGE
|
||||
state can be useful in scripts and macros, as well as in homing routine
|
||||
overrides. If NAME is provided it allows one to name the saved state
|
||||
to the given string. If NAME is not provided it defaults to "default".
|
||||
|
||||
#### RESTORE_DUAL_CARRIAGE_STATE
|
||||
`RESTORE_DUAL_CARRIAGE_STATE [NAME=<state_name>] [MOVE=[0|1] [MOVE_SPEED=<speed>]]`:
|
||||
Restore the previously saved positions of the dual carriages and their modes,
|
||||
unless "MOVE=0" is specified, in which case only the saved modes will be
|
||||
restored, but not the positions of the carriages. If positions are being
|
||||
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.
|
||||
|
||||
### [endstop_phase]
|
||||
|
||||
@@ -549,8 +576,9 @@ clears any error state from the micro-controller.
|
||||
The following standard G-Code commands are available if a
|
||||
[gcode_arcs config section](Config_Reference.md#gcode_arcs) is
|
||||
enabled:
|
||||
- Controlled Arc Move (G2 or G3): `G2 [X<pos>] [Y<pos>] [Z<pos>]
|
||||
[E<pos>] [F<speed>] I<value> J<value>`
|
||||
- Arc Move Clockwise (G2), Arc Move Counter-clockwise (G3): `G2|G3 [X<pos>] [Y<pos>] [Z<pos>]
|
||||
[E<pos>] [F<speed>] I<value> J<value>|I<value> K<value>|J<value> K<value>`
|
||||
- Arc Plane Select: G17 (XY plane), G18 (XZ plane), G19 (YZ plane)
|
||||
|
||||
### [gcode_macro]
|
||||
|
||||
@@ -746,6 +774,20 @@ 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.
|
||||
|
||||
### [mcp4018]
|
||||
|
||||
The following command is available when a
|
||||
[mcp4018 config section](Config_Reference.md#mcp4018) is
|
||||
enabled.
|
||||
|
||||
#### SET_DIGIPOT
|
||||
|
||||
`SET_DIGIPOT DIGIPOT=config_name WIPER=<value>`: This command will
|
||||
change the current value of the digipot. This value should typically
|
||||
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
|
||||
@@ -792,13 +834,22 @@ 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>`:
|
||||
Note - hardware PWM does not currently support the CYCLE_TIME
|
||||
parameter and will use the cycle time defined in the config.
|
||||
`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.
|
||||
|
||||
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).
|
||||
|
||||
### [palette2]
|
||||
|
||||
@@ -874,6 +925,18 @@ the paused state is fresh for each print.
|
||||
#### CANCEL_PRINT
|
||||
`CANCEL_PRINT`: Cancels the current print.
|
||||
|
||||
### [print_stats]
|
||||
|
||||
The print_stats module is automatically loaded.
|
||||
|
||||
#### SET_PRINT_STATS_INFO
|
||||
`SET_PRINT_STATS_INFO [TOTAL_LAYER=<total_layer_count>] [CURRENT_LAYER=
|
||||
<current_layer>]`: Pass slicer info like layer act and total to Klipper.
|
||||
Add `SET_PRINT_STATS_INFO [TOTAL_LAYER=<total_layer_count>]` to your
|
||||
slicer start gcode section and `SET_PRINT_STATS_INFO [CURRENT_LAYER=
|
||||
<current_layer>]` at the layer change gcode section to pass layer
|
||||
information from your slicer to Klipper.
|
||||
|
||||
### [probe]
|
||||
|
||||
The following commands are available when a
|
||||
@@ -980,7 +1043,7 @@ 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>]
|
||||
[FREQ_END=<max_freq>] [HZ_PER_SEC=<hz_per_sec>] [CHIPS=<adxl345_chip_name>]
|
||||
[MAX_SMOOTHING=<max_smoothing>]`: 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
|
||||
@@ -994,7 +1057,9 @@ frequency responses and the different input shapers values are written
|
||||
to a CSV file(s) `/tmp/calibration_data_<axis>_<name>.csv`. Unless
|
||||
specified, NAME defaults to the current time in "YYYYMMDD_HHMMSS"
|
||||
format. Note that the suggested input shaper parameters can be
|
||||
persisted in the config by issuing `SAVE_CONFIG` command.
|
||||
persisted in the config by issuing `SAVE_CONFIG` command, and if
|
||||
`[input_shaper]` was already enabled previously, these parameters
|
||||
take effect immediately.
|
||||
|
||||
### [respond]
|
||||
|
||||
@@ -1043,16 +1108,17 @@ is enabled (also see the
|
||||
|
||||
#### SCREWS_TILT_CALCULATE
|
||||
`SCREWS_TILT_CALCULATE [DIRECTION=CW|CCW] [MAX_DEVIATION=<value>]
|
||||
[<probe_parameter>=<value>]`: This command will invoke the bed screws
|
||||
adjustment tool. It will command the nozzle to different locations (as
|
||||
defined in the config file) probing the z height and calculate the
|
||||
number of knob turns to adjust the bed level. If DIRECTION is
|
||||
specified, the knob turns will all be in the same direction, clockwise
|
||||
(CW) or counterclockwise (CCW). See the PROBE command for details on
|
||||
the optional probe parameters. IMPORTANT: You MUST always do a G28
|
||||
before using this command. If MAX_DEVIATION is specified, the command
|
||||
will raise a gcode error if any difference in the screw height
|
||||
relative to the base screw height is greater than the value provided.
|
||||
[HORIZONTAL_MOVE_Z=<value>] [<probe_parameter>=<value>]`: This command will
|
||||
invoke the bed screws adjustment tool. It will command the nozzle to different
|
||||
locations (as defined in the config file) probing the z height and calculate
|
||||
the number of knob turns to adjust the bed level. If DIRECTION is specified,
|
||||
the knob turns will all be in the same direction, clockwise (CW) or
|
||||
counterclockwise (CCW). See the PROBE command for details on the optional probe
|
||||
parameters. IMPORTANT: You MUST always do a G28 before using this command. If
|
||||
MAX_DEVIATION is specified, the command will raise a gcode error if any
|
||||
difference in the screw height relative to the base screw height is greater
|
||||
than the value provided. The optional `HORIZONTAL_MOVE_Z` value overrides the
|
||||
`horizontal_move_z` option specified in the config file.
|
||||
|
||||
### [sdcard_loop]
|
||||
|
||||
@@ -1180,8 +1246,9 @@ The following commands are available when any of the
|
||||
are enabled.
|
||||
|
||||
#### DUMP_TMC
|
||||
`DUMP_TMC STEPPER=<name>`: This command will read the TMC driver
|
||||
registers and report their values.
|
||||
`DUMP_TMC STEPPER=<name> [REGISTER=<name>]`: This command will read all TMC
|
||||
driver registers and report their values. If a REGISTER is provided, only
|
||||
the specified register will be dumped.
|
||||
|
||||
#### INIT_TMC
|
||||
`INIT_TMC STEPPER=<name>`: This command will initialize the TMC
|
||||
@@ -1191,16 +1258,22 @@ turned off then back on.
|
||||
#### SET_TMC_CURRENT
|
||||
`SET_TMC_CURRENT STEPPER=<name> CURRENT=<amps> HOLDCURRENT=<amps>`:
|
||||
This will adjust the run and hold currents of the TMC driver.
|
||||
(HOLDCURRENT is not applicable to tmc2660 drivers.)
|
||||
`HOLDCURRENT` is not applicable to tmc2660 drivers.
|
||||
When used on a driver which has the `globalscaler` field (tmc5160 and tmc2240),
|
||||
if StealthChop2 is used, the stepper must be held at standstill for >130ms so
|
||||
that the driver executes the AT#1 calibration.
|
||||
|
||||
#### SET_TMC_FIELD
|
||||
`SET_TMC_FIELD STEPPER=<name> FIELD=<field> VALUE=<value>`: This will
|
||||
alter the value of the specified register field of the TMC driver.
|
||||
`SET_TMC_FIELD STEPPER=<name> FIELD=<field> VALUE=<value> VELOCITY=<value>`:
|
||||
This will alter the value of the specified register field of the TMC driver.
|
||||
This command is intended for low-level diagnostics and debugging only
|
||||
because changing the fields during run-time can lead to undesired and
|
||||
potentially dangerous behavior of your printer. Permanent changes
|
||||
should be made using the printer configuration file instead. No sanity
|
||||
checks are performed for the given values.
|
||||
A VELOCITY can also be specified instead of a VALUE. This velocity is
|
||||
converted to the 20bit TSTEP based value representation. Only use the VELOCITY
|
||||
argument for fields that represent velocities.
|
||||
|
||||
### [toolhead]
|
||||
|
||||
@@ -1208,8 +1281,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.
|
||||
[ACCEL_TO_DECEL=<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]
|
||||
|
||||
@@ -1267,13 +1343,43 @@ 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
|
||||
[z_thermal_adjust config section](Config_Reference.md#z_thermal_adjust)
|
||||
is enabled.
|
||||
|
||||
#### SET_Z_THERMAL_ADJUST
|
||||
`SET_Z_THERMAL_ADJUST [ENABLE=<0:1>] [TEMP_COEFF=<value>] [REF_TEMP=<value>]`:
|
||||
Enable or disable the Z thermal adjustment with `ENABLE`. Disabling does not
|
||||
remove any adjustment already applied, but will freeze the current adjustment
|
||||
value - this prevents potentially unsafe downward Z movement. Re-enabling can
|
||||
potentially cause upward tool movement as the adjustment is updated and applied.
|
||||
`TEMP_COEFF` allows run-time tuning of the adjustment temperature coefficient
|
||||
(i.e. the `TEMP_COEFF` config parameter). `TEMP_COEFF` values are not saved to
|
||||
the config. `REF_TEMP` manually overrides the reference temperature typically
|
||||
set during homing (for use in e.g. non-standard homing routines) - will be reset
|
||||
automatically upon homing.
|
||||
|
||||
### [z_tilt]
|
||||
|
||||
The following commands are available when the
|
||||
[z_tilt config section](Config_Reference.md#z_tilt) is enabled.
|
||||
|
||||
#### Z_TILT_ADJUST
|
||||
`Z_TILT_ADJUST [<probe_parameter>=<value>]`: This command will probe
|
||||
the points specified in the config and then make independent
|
||||
adjustments to each Z stepper to compensate for tilt. See the PROBE
|
||||
command for details on the optional probe parameters.
|
||||
`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.
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This document describes Filament Width Sensor host module. Hardware used for
|
||||
developing this host module is based on two Hall linear sensors (ss49e for
|
||||
example). Sensors in the body are located opposite sides. Principle of operation:
|
||||
example). Sensors in the body are located on opposite sides. Principle of operation:
|
||||
two hall sensors work in differential mode, temperature drift same for sensor.
|
||||
Special temperature compensation not needed.
|
||||
|
||||
@@ -18,9 +18,9 @@ To use Hall filament width sensor, read
|
||||
|
||||
Sensor generates two analog output based on calculated filament width. Sum of
|
||||
output voltage always equals to detected filament width. Host module monitors
|
||||
voltage changes and adjusts extrusion multiplier. I use aux2 connector on
|
||||
ramps-like board analog11 and analog12 pins. You can use different pins and
|
||||
differenr boards.
|
||||
voltage changes and adjusts extrusion multiplier. I use the aux2 connector on
|
||||
a ramps-like board with the analog11 and analog12 pins. You can use different pins
|
||||
and different boards.
|
||||
|
||||
## Template for menu variables
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
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
|
||||
Raspberry Pi 2 (or later) 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).
|
||||
|
||||
@@ -50,7 +50,7 @@ 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
|
||||
ssh utility to connect to the Raspberry Pi (`ssh pi@octopi` -- password
|
||||
is "raspberry") and run the following commands:
|
||||
|
||||
```
|
||||
@@ -135,18 +135,18 @@ 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
|
||||
"/tmp/printer". Then click "Save".
|
||||
`/tmp/printer`. Then click "Save".
|
||||
|
||||
Enter the Settings tab again and under "Serial Connection" change the
|
||||
"Serial Port" setting to "/tmp/printer".
|
||||
"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
|
||||
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"
|
||||
@@ -165,8 +165,8 @@ 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).
|
||||
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
|
||||
|
||||
@@ -1,55 +1,182 @@
|
||||
# Measuring Resonances
|
||||
|
||||
Klipper has built-in support for ADXL345 accelerometer, 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 ADXL345 requires some soldering and crimping. ADXL345 can be
|
||||
connected to a Raspberry Pi directly, or to an SPI interface of an MCU
|
||||
board (it needs to be reasonably fast).
|
||||
Klipper has built-in support for the ADXL345, MPU-9250 and LIS2DW 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
|
||||
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.
|
||||
|
||||
When sourcing ADXL345, be aware that there is a variety of different PCB
|
||||
board designs and different clones of them. Make sure that the board supports
|
||||
SPI mode (small number of boards appear to be hard-configured for I2C by
|
||||
pulling SDO to GND), and, if it is going to be connected to a 5V printer MCU,
|
||||
that it has a voltage regulator and a level shifter.
|
||||
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
|
||||
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.
|
||||
|
||||
## MCUs with Klipper I2C *fast-mode* Support
|
||||
|
||||
| MCU Family | MCU(s) Tested | MCU(s) with Support |
|
||||
|:--:|:--|:--|
|
||||
| Raspberry Pi | 3B+, Pico | 3A, 3A+, 3B, 4 |
|
||||
| AVR ATmega | ATmega328p | ATmega32u4, ATmega128, ATmega168, ATmega328, ATmega644p, ATmega1280, ATmega1284, ATmega2560 |
|
||||
| AVR AT90 | - | AT90usb646, AT90usb1286 |
|
||||
|
||||
## Installation instructions
|
||||
|
||||
### Wiring
|
||||
|
||||
An ethernet cable with shielded twisted pairs (cat5e or better) is recommended
|
||||
for signal integrity over a long distance. If you still experience signal
|
||||
integrity issues (SPI/I2C errors):
|
||||
|
||||
- Double check the wiring with a digital multimeter for:
|
||||
- Correct connections when turned off (continuity)
|
||||
- Correct power and ground voltages
|
||||
- I2C only:
|
||||
- Check the SCL and SDA lines' resistances to 3.3V are in the range of 900
|
||||
ohms to 1.8K
|
||||
- For full technical details consult [chapter 7 of the I2C-bus specification
|
||||
and user manual UM10204](https://www.pololu.com/file/0J435/UM10204.pdf)
|
||||
for *fast-mode*
|
||||
- Shorten the cable
|
||||
|
||||
Connect ethernet cable shielding only to the MCU board/Pi ground.
|
||||
|
||||
***Double-check your wiring before powering up to prevent
|
||||
damaging your MCU/Raspberry Pi or the accelerometer.***
|
||||
|
||||
### SPI Accelerometers
|
||||
|
||||
Suggested twisted pair order for three twisted pairs:
|
||||
|
||||
```
|
||||
GND+MISO
|
||||
3.3V+MOSI
|
||||
SCLK+CS
|
||||
```
|
||||
|
||||
Note that unlike a cable shield, GND must be connected at both ends.
|
||||
|
||||
#### ADXL345
|
||||
|
||||
##### Direct to Raspberry Pi
|
||||
|
||||
**Note: Many MCUs will work with an ADXL345 in SPI mode (e.g. Pi Pico), wiring
|
||||
and configuration will vary according to your specific board and available
|
||||
pins.**
|
||||
|
||||
You need to connect ADXL345 to your Raspberry Pi via SPI. Note that the I2C
|
||||
connection, which is suggested by ADXL345 documentation, has too low throughput
|
||||
and **will not work**. The recommended connection scheme:
|
||||
|
||||
| ADXL345 pin | RPi pin | RPi pin name |
|
||||
|:--:|:--:|:--:|
|
||||
| 3V3 (or VCC) | 01 | 3.3v DC power |
|
||||
| 3V3 (or VCC) | 01 | 3.3V DC power |
|
||||
| GND | 06 | Ground |
|
||||
| CS | 24 | GPIO08 (SPI0_CE0_N) |
|
||||
| SDO | 21 | GPIO09 (SPI0_MISO) |
|
||||
| SDA | 19 | GPIO10 (SPI0_MOSI) |
|
||||
| SCL | 23 | GPIO11 (SPI0_SCLK) |
|
||||
|
||||
An alternative to the ADXL345 is the MPU-9250 (or MPU-6050). This
|
||||
accelerometer has been tested to work over I2C on the RPi at 400kbaud.
|
||||
Recommended connection scheme for I2C:
|
||||
|
||||
| MPU-9250 pin | RPi pin | RPi pin name |
|
||||
|:--:|:--:|:--:|
|
||||
| 3V3 (or VCC) | 01 | 3.3v DC power |
|
||||
| GND | 09 | Ground |
|
||||
| SDA | 03 | GPIO02 (SDA1) |
|
||||
| SCL | 05 | GPIO03 (SCL1) |
|
||||
|
||||
|
||||
Fritzing wiring diagrams for some of the ADXL345 boards:
|
||||
|
||||
|
||||
|
||||
##### Using Raspberry Pi Pico
|
||||
|
||||
Double-check your wiring before powering up the Raspberry Pi to prevent
|
||||
damaging it or the accelerometer.
|
||||
You may connect the ADXL345 to your Raspberry Pi Pico and then connect the
|
||||
Pico to your Raspberry Pi via USB. This makes it easy to reuse the
|
||||
accelerometer on other Klipper devices, as you can connect via USB instead
|
||||
of GPIO. The Pico does not have much processing power, so make sure it is
|
||||
only running the accelerometer and not performing any other duties.
|
||||
|
||||
In order to avoid damage to your RPi make sure to connect the ADXL345 to 3.3V
|
||||
only. Depending on the board's layout, a level shifter may be present, which
|
||||
makes 5V dangerous for your RPi.
|
||||
|
||||
| ADXL345 pin | Pico pin | Pico pin name |
|
||||
|:--:|:--:|:--:|
|
||||
| 3V3 (or VCC) | 36 | 3.3V DC power |
|
||||
| GND | 38 | Ground |
|
||||
| CS | 2 | GP1 (SPI0_CSn) |
|
||||
| SDO | 1 | GP0 (SPI0_RX) |
|
||||
| SDA | 5 | GP3 (SPI0_TX) |
|
||||
| SCL | 4 | GP2 (SPI0_SCK) |
|
||||
|
||||
Wiring diagrams for some of the ADXL345 boards:
|
||||
|
||||
|
||||
|
||||
### I2C Accelerometers
|
||||
|
||||
Suggested twisted pair order for three pairs (preferred):
|
||||
|
||||
```
|
||||
3.3V+GND
|
||||
SDA+GND
|
||||
SCL+GND
|
||||
```
|
||||
|
||||
or for two pairs:
|
||||
|
||||
```
|
||||
3.3V+SDA
|
||||
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
|
||||
|
||||
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
|
||||
pull-ups, but some are too large at 10K and must be changed or supplemented by
|
||||
smaller parallel resistors.
|
||||
|
||||
Recommended connection scheme for I2C on the Raspberry Pi:
|
||||
|
||||
| MPU-9250 pin | RPi pin | RPi pin name |
|
||||
|:--:|:--:|:--:|
|
||||
| VCC | 01 | 3.3v DC power |
|
||||
| GND | 09 | Ground |
|
||||
| SDA | 03 | GPIO02 (SDA1) |
|
||||
| SCL | 05 | GPIO03 (SCL1) |
|
||||
|
||||
The RPi has buit-in 1.8K pull-ups on both SCL and SDA.
|
||||
|
||||
|
||||
|
||||
Recommended connection scheme for I2C (i2c0a) on the RP2040:
|
||||
|
||||
| MPU-9250 pin | RP2040 pin | RP2040 pin name |
|
||||
|:--:|:--:|:--:|
|
||||
| VCC | 36 | 3v3 |
|
||||
| GND | 38 | Ground |
|
||||
| SDA | 01 | GP0 (I2C0 SDA) |
|
||||
| SCL | 02 | GP1 (I2C0 SCL) |
|
||||
|
||||
The Pico does not include any built-in I2C pull-up resistors.
|
||||
|
||||
|
||||
|
||||
##### Recommended connection scheme for I2C(TWI) on the AVR ATmega328P Arduino Nano:
|
||||
|
||||
| MPU-9250 pin | Atmega328P TQFP32 pin | Atmega328P pin name | Arduino Nano pin |
|
||||
|:--:|:--:|:--:|:--:|
|
||||
| VCC | 39 | - | - |
|
||||
| GND | 38 | Ground | GND |
|
||||
| SDA | 27 | SDA | A4 |
|
||||
| SCL | 28 | SCL | A5 |
|
||||
|
||||
The Arduino Nano does not include any built-in pull-up resistors nor a 3.3V
|
||||
power pin.
|
||||
|
||||
### Mounting the accelerometer
|
||||
|
||||
@@ -92,14 +219,18 @@ 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.
|
||||
|
||||
Afterwards, check and follow the instructions in the
|
||||
#### Configure ADXL345 With RPi
|
||||
|
||||
First, check and follow the instructions in the
|
||||
[RPi Microcontroller document](RPi_microcontroller.md) to setup the
|
||||
"linux mcu" on the Raspberry Pi.
|
||||
"linux mcu" on the Raspberry Pi. This will configure a second Klipper
|
||||
instance that runs on your Pi.
|
||||
|
||||
Make sure the Linux SPI driver is enabled by running `sudo
|
||||
raspi-config` and enabling SPI under the "Interfacing options" menu.
|
||||
|
||||
For the ADXL345, add the following to the printer.cfg file:
|
||||
Add the following to the printer.cfg file:
|
||||
|
||||
```
|
||||
[mcu rpi]
|
||||
serial: /tmp/klipper_host_mcu
|
||||
@@ -115,9 +246,91 @@ probe_points:
|
||||
It is advised to start with 1 probe point, in the middle of the print bed,
|
||||
slightly above it.
|
||||
|
||||
For the MPU-9250, make sure the Linux I2C driver is enabled and the baud rate is
|
||||
#### Configure ADXL345 With Pi Pico
|
||||
|
||||
##### Flash the Pico Firmware
|
||||
|
||||
On your Raspberry Pi, compile the firmware for the Pico.
|
||||
|
||||
```
|
||||
cd ~/klipper
|
||||
make clean
|
||||
make menuconfig
|
||||
```
|
||||
|
||||
|
||||
Now, while holding down the `BOOTSEL` button on the Pico, connect the Pico to
|
||||
the Raspberry Pi via USB. Compile and flash the firmware.
|
||||
```
|
||||
make flash FLASH_DEVICE=first
|
||||
```
|
||||
|
||||
If that fails, you will be told which `FLASH_DEVICE` to use. In this example,
|
||||
that's ```make flash FLASH_DEVICE=2e8a:0003```.
|
||||
|
||||
|
||||
##### Configure the Connection
|
||||
|
||||
The Pico will now reboot with the new firmware and should show up as a serial
|
||||
device. Find the pico serial device with `ls /dev/serial/by-id/*`. You can
|
||||
now add an `adxl.cfg` file with the following settings:
|
||||
|
||||
```
|
||||
[mcu adxl]
|
||||
# Change <mySerial> to whatever you found above. For example,
|
||||
# usb-Klipper_rp2040_E661640843545B2E-if00
|
||||
serial: /dev/serial/by-id/usb-Klipper_rp2040_<mySerial>
|
||||
|
||||
[adxl345]
|
||||
cs_pin: adxl:gpio1
|
||||
spi_bus: spi0a
|
||||
axes_map: x,z,y
|
||||
|
||||
[resonance_tester]
|
||||
accel_chip: adxl345
|
||||
probe_points:
|
||||
# Somewhere slightly above the middle of your print bed
|
||||
147,154, 20
|
||||
|
||||
[output_pin power_mode] # Improve power stability
|
||||
pin: adxl:gpio23
|
||||
```
|
||||
|
||||
If setting up the ADXL345 configuration in a separate file, as shown above,
|
||||
you'll also want to modify your `printer.cfg` file to include this:
|
||||
|
||||
```
|
||||
[include adxl.cfg] # Comment this out when you disconnect the accelerometer
|
||||
```
|
||||
|
||||
Restart Klipper via the `RESTART` command.
|
||||
|
||||
#### Configure LIS2DW series
|
||||
|
||||
```
|
||||
[mcu lis]
|
||||
# Change <mySerial> to whatever you found above. For example,
|
||||
# usb-Klipper_rp2040_E661640843545B2E-if00
|
||||
serial: /dev/serial/by-id/usb-Klipper_rp2040_<mySerial>
|
||||
|
||||
[lis2dw]
|
||||
cs_pin: lis:gpio1
|
||||
spi_bus: spi0a
|
||||
axes_map: x,z,y
|
||||
|
||||
[resonance_tester]
|
||||
accel_chip: lis2dw
|
||||
probe_points:
|
||||
# Somewhere slightly above the middle of your print bed
|
||||
147,154, 20
|
||||
```
|
||||
|
||||
#### Configure MPU-6000/9000 series With RPi
|
||||
|
||||
Make sure the Linux I2C driver is enabled and the baud rate is
|
||||
set to 400000 (see [Enabling I2C](RPi_microcontroller.md#optional-enabling-i2c)
|
||||
section for more details). Then, add the following to the printer.cfg:
|
||||
|
||||
```
|
||||
[mcu rpi]
|
||||
serial: /tmp/klipper_host_mcu
|
||||
@@ -132,6 +345,46 @@ probe_points:
|
||||
100, 100, 20 # an example
|
||||
```
|
||||
|
||||
#### Configure MPU-9520 Compatibles With Pico
|
||||
|
||||
Pico I2C is set to 400000 on default. Simply add the following to the
|
||||
printer.cfg:
|
||||
|
||||
```
|
||||
[mcu pico]
|
||||
serial: /dev/serial/by-id/<your Pico's serial ID>
|
||||
|
||||
[mpu9250]
|
||||
i2c_mcu: pico
|
||||
i2c_bus: i2c0a
|
||||
|
||||
[resonance_tester]
|
||||
accel_chip: mpu9250
|
||||
probe_points:
|
||||
100, 100, 20 # an example
|
||||
|
||||
[static_digital_output pico_3V3pwm] # Improve power stability
|
||||
pins: pico:gpio23
|
||||
```
|
||||
|
||||
#### Configure MPU-9520 Compatibles with AVR
|
||||
|
||||
AVR I2C will be set to 400000 by the mpu9250 option. Simply add the following
|
||||
to the printer.cfg:
|
||||
|
||||
```
|
||||
[mcu nano]
|
||||
serial: /dev/serial/by-id/<your nano's serial ID>
|
||||
|
||||
[mpu9250]
|
||||
i2c_mcu: nano
|
||||
|
||||
[resonance_tester]
|
||||
accel_chip: mpu9250
|
||||
probe_points:
|
||||
100, 100, 20 # an example
|
||||
```
|
||||
|
||||
Restart Klipper via the `RESTART` command.
|
||||
|
||||
## Measuring the resonances
|
||||
@@ -154,10 +407,15 @@ Recv: // adxl345 values (x, y, z): 470.719200, 941.438400, 9728.196800
|
||||
```
|
||||
|
||||
If you get an error like `Invalid adxl345 id (got xx vs e5)`, where `xx`
|
||||
is some other ID, it is indicative of the connection problem with ADXL345,
|
||||
is some other ID, immediately try again. There's an issue with SPI
|
||||
initialization. If you still get an error, it is indicative of the connection
|
||||
problem with ADXL345,
|
||||
or the faulty sensor. Double-check the power, the wiring (that it matches
|
||||
the schematics, no wire is broken or loose, etc.), and soldering quality.
|
||||
|
||||
**If you are using a MPU-9250 compatible accelerometer and it shows up as
|
||||
`mpu-unknown`, use with caution! They are probably refurbished chips!**
|
||||
|
||||
Next, try running `MEASURE_AXES_NOISE` in Octoprint, you should get some
|
||||
baseline numbers for the noise of accelerometer on the axes (should be
|
||||
somewhere in the range of ~1-100). Too high axes noise (e.g. 1000 and more)
|
||||
@@ -233,7 +491,7 @@ or you can choose some other configuration yourself based on the generated
|
||||
charts: peaks in the power spectral density on the charts correspond to
|
||||
the resonance frequencies of the printer.
|
||||
|
||||
Note that alternatively you can run the input shaper autocalibration
|
||||
Note that alternatively you can run the input shaper auto-calibration
|
||||
from Klipper [directly](#input-shaper-auto-calibration), which can be
|
||||
convenient, for example, for the input shaper
|
||||
[re-calibration](#input-shaper-re-calibration).
|
||||
@@ -245,10 +503,11 @@ of the accelerometer between the measurements for X and Y axes: measure the
|
||||
resonances of X axis with the accelerometer attached to the toolhead and the
|
||||
resonances of Y axis - to the bed (the usual bed slinger setup).
|
||||
|
||||
However, you can also connect two accelerometers simultaneously, though they
|
||||
must be connected to different boards (say, to an RPi and printer MCU board), or
|
||||
to two different physical SPI interfaces on the same board (rarely available).
|
||||
Then they can be configured in the following manner:
|
||||
However, you can also connect two accelerometers simultaneously, though the
|
||||
ADXL345 must be connected to different boards (say, to an RPi and printer MCU
|
||||
board), or to two different physical SPI interfaces on the same board (rarely
|
||||
available). Then they can be configured in the following manner:
|
||||
|
||||
```
|
||||
[adxl345 hotend]
|
||||
# Assuming `hotend` chip is connected to an RPi
|
||||
@@ -265,6 +524,30 @@ accel_chip_y: adxl345 bed
|
||||
probe_points: ...
|
||||
```
|
||||
|
||||
Two MPUs can share one I2C bus, but they **cannot** measure simultaneously as
|
||||
the 400kbit/s I2C bus is not fast enough. One must have its AD0 pin pulled-down
|
||||
to 0V (address 104) and the other its AD0 pin pulled-up to 3.3V (address 105):
|
||||
|
||||
```
|
||||
[mpu9250 hotend]
|
||||
i2c_mcu: rpi
|
||||
i2c_bus: i2c.1
|
||||
i2c_address: 104 # This MPU has pin AD0 pulled low
|
||||
|
||||
[mpu9250 bed]
|
||||
i2c_mcu: rpi
|
||||
i2c_bus: i2c.1
|
||||
i2c_address: 105 # This MPU has pin AD0 pulled high
|
||||
|
||||
[resonance_tester]
|
||||
# Assuming the typical setup of the bed slinger printer
|
||||
accel_chip_x: mpu9250 hotend
|
||||
accel_chip_y: mpu9250 bed
|
||||
probe_points: ...
|
||||
```
|
||||
[Test with each MPU individually before connecting both to the bus for easy
|
||||
debugging.]
|
||||
|
||||
Then the commands `TEST_RESONANCES AXIS=X` and `TEST_RESONANCES AXIS=Y`
|
||||
will use the correct accelerometer for each axis.
|
||||
|
||||
@@ -473,9 +756,9 @@ supplying `AXIS=` parameter, like
|
||||
SHAPER_CALIBRATE AXIS=X
|
||||
```
|
||||
|
||||
**Warning!** It is not advisable to run the shaper autocalibration very
|
||||
**Warning!** It is not advisable to run the shaper auto-calibration very
|
||||
frequently (e.g. before every print, or every day). In order to determine
|
||||
resonance frequencies, autocalibration creates intensive vibrations on each of
|
||||
resonance frequencies, auto-calibration creates intensive vibrations on each of
|
||||
the axes. Generally, 3D printers are not designed to withstand a prolonged
|
||||
exposure to vibrations near the resonance frequencies. Doing so may increase
|
||||
wear of the printer components and reduce their lifespan. There is also an
|
||||
|
||||
@@ -35,6 +35,8 @@ communication with the Klipper developers.
|
||||
locations.
|
||||
- [Endstop phase](Endstop_Phase.md): Stepper assisted Z endstop
|
||||
positioning.
|
||||
- [Axis Twist Compensation](Axis_Twist_Compensation.md): A tool to compensate
|
||||
for inaccurate probe readings due to twist in X gantry.
|
||||
- [Resonance compensation](Resonance_Compensation.md): A tool to
|
||||
reduce ringing in prints.
|
||||
- [Measuring resonances](Measuring_Resonances.md): Information on
|
||||
@@ -54,7 +56,7 @@ communication with the Klipper developers.
|
||||
perfectly square.
|
||||
- [PWM tools](Using_PWM_Tools.md): Guide on how to use PWM controlled
|
||||
tools such as lasers or spindles.
|
||||
- [Exclude Object](Exclude_Object.md): The guide to the Exclude Objecs
|
||||
- [Exclude Object](Exclude_Object.md): The guide to the Exclude Objects
|
||||
implementation.
|
||||
|
||||
## Developer Documentation
|
||||
@@ -91,6 +93,9 @@ communication with the Klipper developers.
|
||||
Beaglebone PRU.
|
||||
- [Bootloaders](Bootloaders.md): Developer information on
|
||||
micro-controller flashing.
|
||||
- [Bootloader Entry](Bootloader_Entry.md): Requesting the bootloader.
|
||||
- [CAN bus](CANBUS.md): Information on using CAN bus with Klipper.
|
||||
- [CAN bus troubleshooting](CANBUS_Troubleshooting.md): Tips for
|
||||
troubleshooting CAN bus.
|
||||
- [TSL1401CL filament width sensor](TSL1401CL_Filament_Width_Sensor.md)
|
||||
- [Hall filament width sensor](Hall_Filament_Width_Sensor.md)
|
||||
|
||||
@@ -27,4 +27,4 @@ follows: `python2 scripts/make_version.py YOURDISTRONAME > klippy/.version`.
|
||||
## Sample packaging script
|
||||
|
||||
klipper-git is packaged for Arch Linux, and has a PKGBUILD (package build
|
||||
script) available at [Arch User Repositiory](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-git).
|
||||
script) available at [Arch User Repository](https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=klipper-git).
|
||||
|
||||
@@ -25,8 +25,8 @@ must run before the klippy process.
|
||||
After installing Klipper, install the script. run:
|
||||
```
|
||||
cd ~/klipper/
|
||||
sudo cp "./scripts/klipper-mcu-start.sh" /etc/init.d/klipper_mcu
|
||||
sudo update-rc.d klipper_mcu defaults
|
||||
sudo cp ./scripts/klipper-mcu.service /etc/systemd/system/
|
||||
sudo systemctl enable klipper-mcu.service
|
||||
```
|
||||
|
||||
## Building the micro-controller code
|
||||
@@ -198,18 +198,28 @@ default on a Raspberry and can be activated by adding a line to
|
||||
dtoverlay=pwm,pin=12,func=4
|
||||
```
|
||||
This example enables only PWM0 and routes it to gpio12. If both PWM
|
||||
channels need to be enabled you can use `pwm-2chan`.
|
||||
channels need to be enabled you can use `pwm-2chan`:
|
||||
```
|
||||
# Enable pwmchip sysfs interface
|
||||
dtoverlay=pwm-2chan,pin=12,func=4,pin2=13,func2=4
|
||||
```
|
||||
This example additionally enables PWM1 and routes it to gpio13.
|
||||
|
||||
The overlay does not expose the pwm line on sysfs on boot and needs to
|
||||
be exported by echo'ing the number of the pwm channel to
|
||||
`/sys/class/pwm/pwmchip0/export`:
|
||||
`/sys/class/pwm/pwmchip0/export`. This will create device `/sys/class/pwm/pwmchip0/pwm0` in the
|
||||
filesystem. The easiest way to do this is by adding this to
|
||||
`/etc/rc.local` before the `exit 0` line:
|
||||
```
|
||||
# Enable pwmchip sysfs interface
|
||||
echo 0 > /sys/class/pwm/pwmchip0/export
|
||||
```
|
||||
|
||||
This will create device `/sys/class/pwm/pwmchip0/pwm0` in the
|
||||
filesystem. The easiest way to do this is by adding this to
|
||||
`/etc/rc.local` before the `exit 0` line.
|
||||
When using both PWM channels, the number of the second channel needs to be echo'd as well:
|
||||
```
|
||||
# Enable pwmchip sysfs interface
|
||||
echo 0 > /sys/class/pwm/pwmchip0/export
|
||||
echo 1 > /sys/class/pwm/pwmchip0/export
|
||||
```
|
||||
|
||||
With the sysfs in place, you can now use either the pwm channel(s) by
|
||||
adding the following piece of configuration to your `printer.cfg`:
|
||||
@@ -219,9 +229,17 @@ pin: host:pwmchip0/pwm0
|
||||
pwm: True
|
||||
hardware_pwm: True
|
||||
cycle_time: 0.000001
|
||||
|
||||
[output_pin beeper]
|
||||
pin: host:pwmchip0/pwm1
|
||||
pwm: True
|
||||
hardware_pwm: True
|
||||
value: 0
|
||||
shutdown_value: 0
|
||||
cycle_time: 0.0005
|
||||
```
|
||||
This will add hardware pwm control to gpio12 on the Pi (because the
|
||||
overlay was configured to route pwm0 to pin=12).
|
||||
This will add hardware pwm control to gpio12 and gpio13 on the Pi (because the
|
||||
overlay was configured to route pwm0 to pin=12 and pwm1 to pin=13).
|
||||
|
||||
PWM0 can be routed to gpio12 and gpio18, PWM1 can be routed to gpio13
|
||||
and gpio19:
|
||||
|
||||
@@ -3,6 +3,49 @@
|
||||
History of Klipper releases. Please see
|
||||
[installation](Installation.md) for information on installing Klipper.
|
||||
|
||||
## Klipper 0.12.0
|
||||
|
||||
Available on 20231110. Major changes in this release:
|
||||
* Support for COPY and MIRROR modes on IDEX printers.
|
||||
* Several micro-controller improvements:
|
||||
* Support for new ar100 and hc32f460 architectures.
|
||||
* Support for stm32f7, stm32g0b0, stm32g07x, stm32g4, stm32h723,
|
||||
n32g45x, samc21, and samd21j18 chip variants.
|
||||
* Improved DFU and Katapult reboot handling.
|
||||
* Improved performance on USB to CANbus bridge mode.
|
||||
* Improved performance on "linux mcu".
|
||||
* New support for software based i2c.
|
||||
* New hardware support for tmc2240 stepper motor drivers, lis2dw12
|
||||
accelerometers, and aht10 temperature sensors.
|
||||
* New axis_twist_compensation and temperature_combined modules added.
|
||||
* New support for gcode arcs in XY, XZ, and YZ planes.
|
||||
* Several bug fixes and code cleanups.
|
||||
|
||||
## Klipper 0.11.0
|
||||
|
||||
Available on 20221128. Major changes in this release:
|
||||
* Trinamic stepper motor driver "step on both edges" optimization.
|
||||
* Support for Python3. The Klipper host code will run with either
|
||||
Python2 or Python3.
|
||||
* Enhanced CAN bus support. Support for CAN bus on rp2040, stm32g0,
|
||||
stm32h7, same51, and same54 chips. Support for "USB to CAN bus
|
||||
bridge" mode.
|
||||
* Support for CanBoot bootloader.
|
||||
* Support for mpu9250 and mpu6050 accelerometers.
|
||||
* Improved error handling for max31856, max31855, max31865, and
|
||||
max6675 temperature sensors.
|
||||
* It is now possible to configure LEDs to update during long running
|
||||
G-Code commands using LED "template" support.
|
||||
* Several micro-controller improvements. New support for stm32h743,
|
||||
stm32h750, stm32l412, stm32g0b1, same70, same51, and same54 chips.
|
||||
Support for i2c reads on atsamd and stm32f0. Hardware pwm support on
|
||||
stm32. Linux mcu signal based event dispatch. New rp2040 support for
|
||||
"make flash", i2c, and rp2040-e5 USB errata.
|
||||
* New modules added: angle, dac084S085, exclude_object, led, mpu9250,
|
||||
pca9632, smart_effector, z_thermal_adjust. New deltesian kinematics
|
||||
added. New dump_mcu tool added.
|
||||
* Several bug fixes and code cleanups.
|
||||
|
||||
## Klipper 0.10.0
|
||||
|
||||
Available on 20210929. Major changes in this release:
|
||||
|
||||
@@ -418,18 +418,34 @@ if necessary.
|
||||
|
||||
### Is dual carriage setup supported with input shapers?
|
||||
|
||||
There is no dedicated support for dual carriages with input shapers, but it does
|
||||
not mean this setup will not work. One should run the tuning twice for each
|
||||
of the carriages, and calculate the ringing frequencies for X and Y axes for
|
||||
each of the carriages independently. Then put the values for carriage 0 into
|
||||
[input_shaper] section, and change the values on the fly when changing
|
||||
carriages, e.g. as a part of some macro:
|
||||
```
|
||||
SET_DUAL_CARRIAGE CARRIAGE=1
|
||||
SET_INPUT_SHAPER SHAPER_FREQ_X=... SHAPER_FREQ_Y=...
|
||||
Yes. In this case, one should measure the resonances twice for each carriage.
|
||||
For example, if the second (dual) carriage is installed on X axis, it is
|
||||
possible to set different input shapers for X axis for the primary and dual
|
||||
carriages. However, the input shaper for Y axis should be the same for both
|
||||
carriages (as ultimately this axis is driven by one or more stepper motors each
|
||||
commanded to perform exactly the same steps). One possibility to configure
|
||||
the input shaper for such setups is to keep `[input_shaper]` section empty and
|
||||
additionally define a `[delayed_gcode]` section in the `printer.cfg` as follows:
|
||||
```
|
||||
[input_shaper]
|
||||
# Intentionally empty
|
||||
|
||||
And similarly when switching back to carriage 0.
|
||||
[delayed_gcode init_shaper]
|
||||
initial_duration: 0.1
|
||||
gcode:
|
||||
SET_DUAL_CARRIAGE CARRIAGE=1
|
||||
SET_INPUT_SHAPER SHAPER_TYPE_X=<dual_carriage_shaper> SHAPER_FREQ_X=<dual_carriage_freq> SHAPER_TYPE_Y=<y_shaper> SHAPER_FREQ_Y=<y_freq>
|
||||
SET_DUAL_CARRIAGE CARRIAGE=0
|
||||
SET_INPUT_SHAPER SHAPER_TYPE_X=<primary_carriage_shaper> SHAPER_FREQ_X=<primary_carriage_freq> SHAPER_TYPE_Y=<y_shaper> SHAPER_FREQ_Y=<y_freq>
|
||||
```
|
||||
Note that `SHAPER_TYPE_Y` and `SHAPER_FREQ_Y` should be the same in both
|
||||
commands. It is also possible to put a similar snippet into the start g-code
|
||||
in the slicer, however then the shaper will not be enabled until any print
|
||||
is started.
|
||||
|
||||
Note that the input shaper only needs to be configured once. Subsequent changes
|
||||
of the carriages or their modes via `SET_DUAL_CARRIAGE` command will preserve
|
||||
the configured input shaper parameters.
|
||||
|
||||
### Does input_shaper affect print time?
|
||||
|
||||
|
||||
@@ -48,7 +48,7 @@ All options can be viewed by the help screen:
|
||||
./scripts/flash-sdcard.sh -h
|
||||
SD Card upload utility for Klipper
|
||||
|
||||
usage: flash_sdcard.sh [-h] [-l] [-b <baud>] [-f <firmware>]
|
||||
usage: flash_sdcard.sh [-h] [-l] [-c] [-b <baud>] [-f <firmware>]
|
||||
<device> <board>
|
||||
|
||||
positional arguments:
|
||||
@@ -58,6 +58,7 @@ positional arguments:
|
||||
optional arguments:
|
||||
-h show this message
|
||||
-l list available boards
|
||||
-c run flash check/verify only (skip upload)
|
||||
-b <baud> serial baud rate (default is 250000)
|
||||
-f <firmware> path to klipper.bin
|
||||
```
|
||||
@@ -78,6 +79,14 @@ Note that when upgrading a MKS Robin E3 it is not necessary to manually run
|
||||
`update_mks_robin.py` and supply the resulting binary to `flash-sdcard.sh`.
|
||||
This procedure is automated during the upload process.
|
||||
|
||||
The `-c` option is used to perform a check or verify-only operation
|
||||
to test if the board is running the specified firmware correctly. This
|
||||
option is primarily intended for cases where a manual power-cycle is
|
||||
necessary to complete the flashing procedure, such as with bootloaders that
|
||||
use SDIO mode instead of SPI to access their SD Cards. (See Caveats below)
|
||||
But, it can also be used anytime to verify if the code flashed into the board
|
||||
matches the version in your build folder on any supported board.
|
||||
|
||||
## Caveats
|
||||
|
||||
- As mentioned in the introduction, this method only works for upgrading
|
||||
@@ -89,7 +98,16 @@ This procedure is automated during the upload process.
|
||||
the current version.
|
||||
- Only boards that use SPI for SD Card communication are supported.
|
||||
Boards that use SDIO, such as the Flymaker Flyboard and MKS Robin Nano
|
||||
V1/V2, will not work.
|
||||
V1/V2, will not work in SDIO mode. However, it's usually possible to
|
||||
flash such boards using Software SPI mode instead. But if the board's
|
||||
bootloader only uses SDIO mode to access the SD Card, a power-cycle of
|
||||
the board and SD Card will be necessary so that the mode can switch from SPI
|
||||
back to SDIO to complete reflashing. Such boards should be defined with
|
||||
`skip_verify` enabled to skip the verify step immediately after flashing.
|
||||
Then after the manual power-cycle, you can rerun the exact same
|
||||
`./scripts/flash-sdcard.sh` command, but add the `-c` option to complete
|
||||
the check/verify operation. See [Flashing Boards that use SDIO](#flashing-boards-that-use-sdio)
|
||||
for examples.
|
||||
|
||||
## Board Definitions
|
||||
|
||||
@@ -109,26 +127,34 @@ BOARD_DEFS = {
|
||||
```
|
||||
|
||||
The following fields may be specified:
|
||||
- `mcu`: The mcu type. This can be retrevied after configuring the build
|
||||
- `mcu`: The mcu type. This can be retrieved after configuring the build
|
||||
via `make menuconfig` by running `cat .config | grep CONFIG_MCU`. This
|
||||
field is required.
|
||||
- `spi_bus`: The SPI bus connected to the SD Card. This should be retreived
|
||||
- `spi_bus`: The SPI bus connected to the SD Card. This should be retrieved
|
||||
from the board's schematic. This field is required.
|
||||
- `cs_pin`: The Chip Select Pin connected to the SD Card. This should be
|
||||
retreived from the board schematic. This field is required.
|
||||
retrieved from the board schematic. This field is required.
|
||||
- `firmware_path`: The path on the SD Card where firmware should be
|
||||
transferred. The default is `firmware.bin`.
|
||||
- `current_firmware_path` The path on the SD Card where the renamed firmware
|
||||
- `current_firmware_path`: The path on the SD Card where the renamed firmware
|
||||
file is located after a successful flash. The default is `firmware.cur`.
|
||||
- `skip_verify`: This defines a boolean value which tells the scripts to skip
|
||||
the firmware verification step during the flashing process. The default
|
||||
is `False`. It can be set to `True` for boards that require a manual
|
||||
power-cycle to complete flashing. To verify the firmware afterward, run
|
||||
the script again with the `-c` option to perform the verification step.
|
||||
[See caveats with SDIO cards](#caveats)
|
||||
|
||||
If software SPI is required the `spi_bus` field should be set to `swspi`
|
||||
If software SPI is required, the `spi_bus` field should be set to `swspi`
|
||||
and the following additional field should be specified:
|
||||
- `spi_pins`: This should be 3 comma separated pins that are connected to
|
||||
the SD Card in the format of `miso,mosi,sclk`.
|
||||
|
||||
It should be exceedingly rare that Software SPI is necessary, typically only
|
||||
boards with design errors will require it. The `btt-skr-pro` board definition
|
||||
provides an example.
|
||||
boards with design errors or boards that normally only support SDIO mode for
|
||||
their SD Card will require it. The `btt-skr-pro` board definition provides an
|
||||
example of the former, and the `btt-octopus-f446-v1` board definition
|
||||
provides an example of the latter.
|
||||
|
||||
Prior to creating a new board definition one should check to see if an
|
||||
existing board definition meets the criteria necessary for the new board.
|
||||
@@ -144,4 +170,86 @@ BOARD_ALIASES = {
|
||||
|
||||
If you need a new board definition and you are uncomfortable with the
|
||||
procedure outlined above it is recommended that you request one in
|
||||
the [Klipper Community Discord](Contact.md#discord).
|
||||
the [Klipper Discord](Contact.md).
|
||||
|
||||
## Flashing Boards that use SDIO
|
||||
|
||||
[As mentioned in the Caveats](#caveats), boards whose bootloader uses
|
||||
SDIO mode to access their SD Card require a power-cycle of the board,
|
||||
and specifically the SD Card itself, in order to switch from the SPI Mode
|
||||
used while writing the file to the SD Card back to SDIO mode for the
|
||||
bootloader to flash it into the board. These board definitions will
|
||||
use the `skip_verify` flag, which tells the flashing tool to stop after
|
||||
writing the firmware to the SD Card so that the board can be manually
|
||||
power-cycled and the verification step deferred until that's complete.
|
||||
|
||||
There are two scenarios -- one with the RPi Host running on a separate
|
||||
power supply and the other when the RPi Host is running on the same
|
||||
power supply as the main board being flashed. The difference is whether
|
||||
or not it's necessary to also shutdown the RPi and then `ssh` again after
|
||||
the flashing is complete in order to do the verification step, or if the
|
||||
verification can be done immediately. Here's examples of the two scenarios:
|
||||
|
||||
### SDIO Programming with RPi on Separate Power Supply
|
||||
|
||||
A typical session with the RPi on a Separate Power Supply looks like the
|
||||
following. You will, of course, need to use your proper device path and
|
||||
board name:
|
||||
```
|
||||
sudo service klipper stop
|
||||
cd ~/klipper
|
||||
git pull
|
||||
make clean
|
||||
make menuconfig
|
||||
make
|
||||
./scripts/flash-sdcard.sh /dev/ttyACM0 btt-octopus-f446-v1
|
||||
[[[manually power-cycle the printer board here when instructed]]]
|
||||
./scripts/flash-sdcard.sh -c /dev/ttyACM0 btt-octopus-f446-v1
|
||||
sudo service klipper start
|
||||
```
|
||||
|
||||
### SDIO Programming with RPi on the Same Power Supply
|
||||
|
||||
A typical session with the RPi on the Same Power Supply looks like the
|
||||
following. You will, of course, need to use your proper device path and
|
||||
board name:
|
||||
```
|
||||
sudo service klipper stop
|
||||
cd ~/klipper
|
||||
git pull
|
||||
make clean
|
||||
make menuconfig
|
||||
make
|
||||
./scripts/flash-sdcard.sh /dev/ttyACM0 btt-octopus-f446-v1
|
||||
sudo shutdown -h now
|
||||
[[[wait for the RPi to shutdown, then power-cycle and ssh again to the RPi when it restarts]]]
|
||||
sudo service klipper stop
|
||||
cd ~/klipper
|
||||
./scripts/flash-sdcard.sh -c /dev/ttyACM0 btt-octopus-f446-v1
|
||||
sudo service klipper start
|
||||
```
|
||||
|
||||
In this case, since the RPi Host is being restarted, which will restart
|
||||
the `klipper` service, it's necessary to stop `klipper` again before doing
|
||||
the verification step and restart it after verification is complete.
|
||||
|
||||
### SDIO to SPI Pin Mapping
|
||||
|
||||
If your board's schematic uses SDIO for its SD Card, you can map the pins
|
||||
as described in the chart below to determine the compatible Software SPI
|
||||
pins to assign in the `board_defs.py` file:
|
||||
|
||||
| SD Card Pin | Micro SD Card Pin | SDIO Pin Name | SPI Pin Name |
|
||||
| :---------: | :----------------: | :--------------: | :--------------: |
|
||||
| 9 | 1 | DATA2 | None (PU)* |
|
||||
| 1 | 2 | CD/DATA3 | CS |
|
||||
| 2 | 3 | CMD | MOSI |
|
||||
| 4 | 4 | +3.3V (VDD) | +3.3V (VDD) |
|
||||
| 5 | 5 | CLK | SCLK |
|
||||
| 3 | 6 | GND (VSS) | GND (VSS) |
|
||||
| 7 | 7 | DATA0 | MISO |
|
||||
| 8 | 8 | DATA1 | None (PU)* |
|
||||
| N/A | 9 | Card Detect (CD) | Card Detect (CD) |
|
||||
| 6 | 10 | GND | GND |
|
||||
|
||||
\* None (PU) indicates an unused pin with a pull-up resistor
|
||||
|
||||
@@ -87,3 +87,39 @@ Klipper's maximum extrusion cross-section check.
|
||||
|
||||
In contrast, it is okay (and often helpful) to use a slicer's
|
||||
"retract" setting, "wipe" setting, and/or "wipe on retract" setting.
|
||||
|
||||
## START_PRINT macros
|
||||
|
||||
When using a START_PRINT macro or similar, it is useful to sometimes
|
||||
pass through parameters from the slicer variables to the macro.
|
||||
|
||||
In Cura, to pass through temperatures, the following start gcode
|
||||
would be used:
|
||||
|
||||
```
|
||||
START_PRINT BED_TEMP={material_bed_temperature_layer_0} EXTRUDER_TEMP={material_print_temperature_layer_0}
|
||||
```
|
||||
|
||||
In slic3r derivatives such as PrusaSlicer and SuperSlicer, the
|
||||
following would be used:
|
||||
|
||||
```
|
||||
START_PRINT EXTRUDER_TEMP=[first_layer_temperature] BED_TEMP=[first_layer_bed_temperature]
|
||||
```
|
||||
|
||||
Also note that these slicers will insert their own heating codes when
|
||||
certain conditions are not met. In Cura, the existence of the
|
||||
`{material_bed_temperature_layer_0}` and `{material_print_temperature_layer_0}`
|
||||
variables is enough to mitigate this. In slic3r derivatives,
|
||||
you would use:
|
||||
|
||||
```
|
||||
M140 S0
|
||||
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
|
||||
be found in config/sample-macros.cfg
|
||||
|
||||
@@ -6,7 +6,7 @@ sponsors.
|
||||
|
||||
## BIGTREETECH
|
||||
|
||||
[<img src="./img/sponsors/BTT_BTT.png" width="200" />](https://bigtree-tech.com/collections/all-products)
|
||||
[<img src="./img/sponsors/BTT_BTT.png" width="200" style="margin:25px"/>](https://bigtree-tech.com/collections/all-products)
|
||||
|
||||
BIGTREETECH is the official mainboard sponsor of Klipper. BIGTREETECH
|
||||
is committed to developing innovative and competitive products to
|
||||
@@ -14,12 +14,17 @@ serve the 3D printing community better. Follow them on
|
||||
[Facebook](https://www.facebook.com/BIGTREETECH) or
|
||||
[Twitter](https://twitter.com/BigTreeTech).
|
||||
|
||||
## 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
|
||||
|
||||
### Kevin O'Connor
|
||||
|
||||
Kevin is the original author and current maintainer of Klipper. Kevin
|
||||
has a Patreon page at:
|
||||
Kevin is the original author and current maintainer of Klipper. Donate
|
||||
at: [https://ko-fi.com/koconnor](https://ko-fi.com/koconnor) or
|
||||
[https://www.patreon.com/koconnor](https://www.patreon.com/koconnor)
|
||||
|
||||
### Eric Callahan
|
||||
|
||||
@@ -28,6 +28,17 @@ The following information is available in the
|
||||
- `profiles`: The set of currently defined profiles as setup
|
||||
using BED_MESH_PROFILE.
|
||||
|
||||
## bed_screws
|
||||
|
||||
The following information is available in the
|
||||
`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
|
||||
the following strings: "adjust", "fine".
|
||||
- `current_screw`: The index for the current screw being adjusted.
|
||||
- `accepted_screws`: The number of accepted screws.
|
||||
|
||||
## configfile
|
||||
|
||||
The following information is available in the `configfile` object
|
||||
@@ -109,6 +120,16 @@ The following information is available in the
|
||||
- `excluded_objects`: An array of strings listing the names of excluded objects.
|
||||
- `current_object`: The name of the object currently being printed.
|
||||
|
||||
## extruder_stepper
|
||||
|
||||
The following information is available for extruder_stepper objects (as well as
|
||||
[extruder](Config_Reference.md#extruder) objects):
|
||||
- `pressure_advance`: The current [pressure advance](Pressure_Advance.md) value.
|
||||
- `smooth_time`: The current pressure advance smooth time.
|
||||
- `motion_queue`: The name of the extruder that this extruder stepper is
|
||||
currently synchronized to. This is reported as `None` if the extruder stepper
|
||||
is not currently associated with an extruder.
|
||||
|
||||
## fan
|
||||
|
||||
The following information is available in
|
||||
@@ -147,6 +168,18 @@ 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
|
||||
[gcode_button some_name](Config_Reference.md#gcode_button) objects:
|
||||
- `state`: The current button state returned as "PRESSED" or "RELEASED"
|
||||
|
||||
## gcode_macro
|
||||
|
||||
The following information is available in
|
||||
@@ -218,6 +251,11 @@ object is available if any heater is defined):
|
||||
temperature sensors by their full config section names,
|
||||
e.g. `["extruder", "heater_bed", "heater_generic my_custom_heater",
|
||||
"temperature_sensor electronics_temp"]`.
|
||||
- `available_monitors`: Returns a list of all currently available
|
||||
temperature monitors by their full config section names,
|
||||
e.g. `["tmc2240 stepper_x"]`. While a temperature sensor is always
|
||||
available to read, a temperature monitor may not be available and
|
||||
will return null in such case.
|
||||
|
||||
## idle_timeout
|
||||
|
||||
@@ -286,7 +324,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
|
||||
@@ -312,8 +351,12 @@ The following information is available in the `print_stats` object
|
||||
[virtual_sdcard](Config_Reference.md#virtual_sdcard) config section is
|
||||
defined):
|
||||
- `filename`, `total_duration`, `print_duration`, `filament_used`,
|
||||
`state`, `message`: Estimated information about the current print
|
||||
when a virtual_sdcard print is active.
|
||||
`state`, `message`: Estimated information about the current print when a
|
||||
virtual_sdcard print is active.
|
||||
- `info.total_layer`: The total layer value of the last `SET_PRINT_STATS_INFO
|
||||
TOTAL_LAYER=<value>` G-Code command.
|
||||
- `info.current_layer`: The current layer value of the last
|
||||
`SET_PRINT_STATS_INFO CURRENT_LAYER=<value>` G-Code command.
|
||||
|
||||
## probe
|
||||
|
||||
@@ -321,6 +364,7 @@ The following information is available in the
|
||||
[probe](Config_Reference.md#probe) object (this object is also
|
||||
available if a [bltouch](Config_Reference.md#bltouch) config section
|
||||
is defined):
|
||||
- `name`: Returns the name of the probe in use.
|
||||
- `last_query`: Returns True if the probe was reported as "triggered"
|
||||
during the last QUERY_PROBE command. Note, if this is used in a
|
||||
macro, due to the order of template expansion, the QUERY_PROBE
|
||||
@@ -347,6 +391,27 @@ The following information is available in the `query_endstops` object
|
||||
the QUERY_ENDSTOP command must be run prior to the macro containing
|
||||
this reference.
|
||||
|
||||
## screws_tilt_adjust
|
||||
|
||||
The following information is available in the `screws_tilt_adjust`
|
||||
object:
|
||||
- `error`: Returns True if the most recent `SCREWS_TILT_CALCULATE`
|
||||
command included the `MAX_DEVIATION` parameter and any of the probed
|
||||
screw points exceeded the specified `MAX_DEVIATION`.
|
||||
- `max_deviation`: Return the last `MAX_DEVIATION` value of the most
|
||||
recent `SCREWS_TILT_CALCULATE` command.
|
||||
- `results["<screw>"]`: A dictionary containing the following keys:
|
||||
- `z`: The measured Z height of the screw location.
|
||||
- `sign`: A string specifying the direction to turn to screw for the
|
||||
necessary adjustment. Either "CW" for clockwise or "CCW" for
|
||||
counterclockwise.
|
||||
- `adjust`: The number of screw turns to adjust the screw, given in
|
||||
the format "HH:MM," where "HH" is the number of full screw turns
|
||||
and "MM" is the number of "minutes of a clock face" representing
|
||||
a partial screw turn. (E.g. "01:15" would mean to turn the screw
|
||||
one and a quarter revolutions.)
|
||||
- `is_base`: Returns True if this is the base screw.
|
||||
|
||||
## servo
|
||||
|
||||
The following information is available in
|
||||
@@ -354,6 +419,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.
|
||||
|
||||
## stepper_enable
|
||||
|
||||
The following information is available in the `stepper_enable` object (this
|
||||
object is available if any stepper is defined):
|
||||
- `steppers["<stepper>"]`: Returns True if the given stepper is enabled.
|
||||
|
||||
## system_stats
|
||||
|
||||
The following information is available in the `system_stats` object
|
||||
@@ -368,8 +439,9 @@ 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),
|
||||
[lm75 config_section_name](Config_Reference.md#lm75-temperature-sensor),
|
||||
and
|
||||
[temperature_host config_section_name](Config_Reference.md#host-temperature-sensor)
|
||||
and
|
||||
[temperature_combined config_section_name](Config_Reference.md#combined-temperature-sensor)
|
||||
objects:
|
||||
- `temperature`: The last read temperature from the sensor.
|
||||
- `humidity`, `pressure`, `gas`: The last read values from the sensor
|
||||
@@ -407,6 +479,9 @@ objects (eg, `[tmc2208 stepper_x]`):
|
||||
- `drv_status`: The results of the last driver status query. (Only
|
||||
non-zero fields are reported.) This field will be null if the driver
|
||||
is not enabled (and thus is not periodically queried).
|
||||
- `temperature`: The internal temperature reported by the driver. This
|
||||
field will be null if the driver is not enabled or if the driver
|
||||
does not support temperature reporting.
|
||||
- `run_current`: The currently set run current.
|
||||
- `hold_current`: The currently set hold current.
|
||||
|
||||
@@ -427,6 +502,8 @@ The following information is available in the `toolhead` object
|
||||
- `axis_minimum`, `axis_maximum`: The axis travel limits (mm) after
|
||||
homing. It is possible to access the x, y, z components of this
|
||||
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`,
|
||||
`square_corner_velocity`: The current printing limits that are in
|
||||
effect. This may differ from the config file settings if a
|
||||
@@ -439,10 +516,11 @@ The following information is available in the `toolhead` object
|
||||
|
||||
The following information is available in
|
||||
[dual_carriage](Config_Reference.md#dual_carriage)
|
||||
on a hybrid_corexy or hybrid_corexz robot
|
||||
- `mode`: The current mode. Possible values are: "FULL_CONTROL"
|
||||
- `active_carriage`: The current active carriage.
|
||||
Possible values are: "CARRIAGE_0", "CARRIAGE_1"
|
||||
on a cartesian, hybrid_corexy or hybrid_corexz robot
|
||||
- `carriage_0`: The mode of the carriage 0. Possible values are:
|
||||
"INACTIVE" and "PRIMARY".
|
||||
- `carriage_1`: The mode of the carriage 1. Possible values are:
|
||||
"INACTIVE", "PRIMARY", "COPY", and "MIRROR".
|
||||
|
||||
## virtual_sdcard
|
||||
|
||||
@@ -464,6 +542,19 @@ object is always available):
|
||||
- `state_message`: A human readable string giving additional context
|
||||
on the current Klipper state.
|
||||
|
||||
## z_thermal_adjust
|
||||
|
||||
The following information is available in the `z_thermal_adjust` object (this
|
||||
object is available if [z_thermal_adjust](Config_Reference.md#z_thermal_adjust)
|
||||
is defined).
|
||||
- `enabled`: Returns True if adjustment is enabled.
|
||||
- `temperature`: Current (smoothed) temperature of the defined sensor. [degC]
|
||||
- `measured_min_temp`: Minimum measured temperature. [degC]
|
||||
- `measured_max_temp`: Maximum measured temperature. [degC]
|
||||
- `current_z_adjust`: Last computed Z adjustment [mm].
|
||||
- `z_adjust_ref_temperature`: Current reference temperature used for calculation
|
||||
of Z `current_z_adjust` [degC].
|
||||
|
||||
## z_tilt
|
||||
|
||||
The following information is available in the `z_tilt` object (this
|
||||
|
||||
@@ -267,10 +267,11 @@ For tmc2130, tmc5160, and tmc2660:
|
||||
SET_TMC_FIELD STEPPER=stepper_x FIELD=sgt VALUE=-64
|
||||
```
|
||||
|
||||
Then issue a `G28 X0` command and verify the axis does not move at
|
||||
all. If the axis does move, then issue an `M112` to halt the printer -
|
||||
something is not correct with the diag/sg_tst pin wiring or
|
||||
configuration and it must be corrected before continuing.
|
||||
Then issue a `G28 X0` command and verify the axis does not move at all
|
||||
or quickly stops moving. If the axis does not stop, then issue an
|
||||
`M112` to halt the printer - something is not correct with the
|
||||
diag/sg_tst pin wiring or configuration and it must be corrected
|
||||
before continuing.
|
||||
|
||||
Next, continually decrease the sensitivity of the `VALUE` setting and
|
||||
run the `SET_TMC_FIELD` `G28 X0` commands again to find the highest
|
||||
@@ -408,6 +409,23 @@ restrictions:
|
||||
limit (which may skew the stall detection). The pause is necessary
|
||||
to ensure the driver's stall flag is cleared prior to homing again.
|
||||
|
||||
An example CoreXY homing macro might look like:
|
||||
```
|
||||
[gcode_macro HOME]
|
||||
gcode:
|
||||
G90
|
||||
# Home Z
|
||||
G28 Z0
|
||||
G1 Z10 F1200
|
||||
# Home Y
|
||||
G28 Y0
|
||||
G1 Y5 F1200
|
||||
# Home X
|
||||
G4 P2000
|
||||
G28 X0
|
||||
G1 X5 F1200
|
||||
```
|
||||
|
||||
## Querying and diagnosing driver settings
|
||||
|
||||
The `[DUMP_TMC command](G-Codes.md#dump_tmc) is a useful tool when
|
||||
@@ -526,7 +544,7 @@ hot. Typical solutions are to decrease the stepper motor current,
|
||||
increase cooling on the stepper motor driver, and/or increase cooling
|
||||
on the stepper motor.
|
||||
|
||||
#### TMC reports error: `... ShortToGND` OR `LowSideShort`
|
||||
#### TMC reports error: `... ShortToGND` OR `ShortToSupply`
|
||||
|
||||
This indicates the driver has disabled itself because it detected very
|
||||
high current passing through the driver. This may indicate a loose or
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -101,6 +101,7 @@ nav:
|
||||
- Manual_Level.md
|
||||
- Bed_Mesh.md
|
||||
- Endstop_Phase.md
|
||||
- Axis_Twist_Compensation.md
|
||||
- Resonance Compensation:
|
||||
- Resonance_Compensation.md
|
||||
- Measuring_Resonances.md
|
||||
@@ -132,7 +133,9 @@ nav:
|
||||
- RPi_microcontroller.md
|
||||
- Beaglebone.md
|
||||
- Bootloaders.md
|
||||
- Bootloader_Entry.md
|
||||
- CANBUS.md
|
||||
- CANBUS_Troubleshooting.md
|
||||
- TSL1401CL_Filament_Width_Sensor.md
|
||||
- Hall_Filament_Width_Sensor.md
|
||||
- Sponsors.md
|
||||
|
||||
BIN
docs/img/adxl345-pico.png
Normal file
BIN
docs/img/adxl345-pico.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 502 KiB |
BIN
docs/img/flash_rp2040_FLASH_DEVICE.png
Normal file
BIN
docs/img/flash_rp2040_FLASH_DEVICE.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 17 KiB |
BIN
docs/img/klipper_pico_menuconfig.png
Normal file
BIN
docs/img/klipper_pico_menuconfig.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 5.9 KiB |
BIN
docs/img/mpu9250-PI-fritzing.png
Normal file
BIN
docs/img/mpu9250-PI-fritzing.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 102 KiB |
BIN
docs/img/mpu9250-PICO-fritzing.png
Normal file
BIN
docs/img/mpu9250-PICO-fritzing.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
BIN
docs/img/pulseview-canbus.png
Normal file
BIN
docs/img/pulseview-canbus.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
BIN
docs/img/sponsors/obico-light-horizontal.png
Normal file
BIN
docs/img/sponsors/obico-light-horizontal.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 30 KiB |
BIN
docs/img/sponsors/peopoly-logo.png
Normal file
BIN
docs/img/sponsors/peopoly-logo.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 66 KiB |
Reference in New Issue
Block a user