docs: Use hash marks for header lines
Consistently use leading hash marks (#) to note section headers. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
This commit is contained in:
Kevin O'Connor
parent
afca515e2c
commit
37efd1b8f1
|
|
@ -4,8 +4,7 @@ This document describes Klipper's Application Programmer Interface
|
|||
(API). This interface enables external applications to query and
|
||||
control the Klipper host software.
|
||||
|
||||
Enabling the API socket
|
||||
-----------------------
|
||||
## Enabling the API socket
|
||||
|
||||
In order to use the API server, the klippy.py host software must be
|
||||
started with the `-a` parameter. For example:
|
||||
|
|
@ -17,8 +16,7 @@ This causes the host software to create a Unix Domain Socket. A client
|
|||
can then open a connection on that socket and send commands to
|
||||
Klipper.
|
||||
|
||||
Request format
|
||||
--------------
|
||||
## Request format
|
||||
|
||||
Messages sent and received on the socket are JSON encoded strings
|
||||
terminated by an ASCII 0x03 character:
|
||||
|
|
@ -38,8 +36,7 @@ be on a single line, and it will automatically append the 0x03
|
|||
terminator when transmitting a request. (The Klipper API server does
|
||||
not have a newline requirement.)
|
||||
|
||||
API Protocol
|
||||
------------
|
||||
## API Protocol
|
||||
|
||||
The command protocol used on the communication socket is inspired by
|
||||
[json-rpc](https://www.jsonrpc.org/).
|
||||
|
|
@ -92,8 +89,7 @@ which could cause the associated response to be sent out of order with
|
|||
respect to responses from other requests. A JSON request will never
|
||||
pause the processing of future JSON requests.
|
||||
|
||||
Subscriptions
|
||||
-------------
|
||||
## Subscriptions
|
||||
|
||||
Some Klipper "endpoint" requests allow one to "subscribe" to future
|
||||
asynchronous update messages.
|
||||
|
|
@ -120,8 +116,7 @@ with "endpoint" specific contents to the response template and then
|
|||
send that template. If a "response_template" field is not provided
|
||||
then it defaults to an empty dictionary (`{}`).
|
||||
|
||||
Available "endpoints"
|
||||
---------------------
|
||||
## Available "endpoints"
|
||||
|
||||
By convention, Klipper "endpoints" are of the form
|
||||
`<module_name>/<some_name>`. When making a request to an "endpoint",
|
||||
|
|
|
|||
|
|
@ -1,7 +1,6 @@
|
|||
# BL-Touch
|
||||
|
||||
Connecting BL-Touch
|
||||
-------------------
|
||||
## Connecting BL-Touch
|
||||
|
||||
A **warning** before you start: Avoid touching the BL-Touch pin with
|
||||
your bare fingers, since it is quite sensitive to finger grease. And
|
||||
|
|
@ -39,8 +38,7 @@ It's important that the z_hop movement in safe_z_home is high enough
|
|||
that the probe doesn't hit anything even if the probe pin happens to
|
||||
be in its lowest state.
|
||||
|
||||
Initial tests
|
||||
-------------
|
||||
## Initial tests
|
||||
|
||||
Before moving on, verify that the BL-Touch is mounted at the correct
|
||||
height, the pin should be roughly 2 mm above the nozzle when retracted
|
||||
|
|
@ -83,8 +81,7 @@ doesn't stop when you touch the pin.
|
|||
If that was successful, do another `G28` (or `PROBE`) but this time
|
||||
let it touch the bed as it should.
|
||||
|
||||
BL-Touch gone bad
|
||||
-----------------
|
||||
## BL-Touch gone bad
|
||||
|
||||
Once the BL-Touch is in inconsistent state, it starts blinking red.
|
||||
You can force it to leave that state by issuing:
|
||||
|
|
@ -106,8 +103,7 @@ right position so it is able to lower and raise the pin and the red
|
|||
light turns on and of. Use the `reset`, `pin_up` and `pin_down`
|
||||
commands to achieve this.
|
||||
|
||||
BL-Touch "clones"
|
||||
-----------------
|
||||
## BL-Touch "clones"
|
||||
|
||||
Many BL-Touch "clone" devices work correctly with Klipper using the
|
||||
default configuration. However, some "clone" devices may require
|
||||
|
|
@ -144,8 +140,7 @@ the second query reports "probe: TRIGGERED" then it indicates that
|
|||
`pin_up_reports_not_triggered` should be set to False in the Klipper
|
||||
config file.
|
||||
|
||||
BL-Touch v3
|
||||
-----------
|
||||
## BL-Touch v3
|
||||
|
||||
Some BL-Touch v3.0 and BL-Touch 3.1 devices may require configuring
|
||||
`probe_with_touch_mode` in the printer config file.
|
||||
|
|
@ -172,8 +167,7 @@ probe. If configuring this value on a "clone" or older BL-Touch
|
|||
device, be sure to test the probe accuracy before and after setting
|
||||
this value (use the `PROBE_ACCURACY` command to test).
|
||||
|
||||
Multi-probing without stowing
|
||||
-----------------------------
|
||||
## Multi-probing without stowing
|
||||
|
||||
By default, Klipper will deploy the probe at the start of each probe
|
||||
attempt and then stow the probe afterwards. This repetitive deploying
|
||||
|
|
@ -203,8 +197,7 @@ to True. On these devices it is a good idea to test the probe accuracy
|
|||
before and after setting `probe_with_touch_mode` (use the
|
||||
`PROBE_ACCURACY` command to test).
|
||||
|
||||
Calibrating the BL-Touch offsets
|
||||
--------------------------------
|
||||
## Calibrating the BL-Touch offsets
|
||||
|
||||
Follow the directions in the [Probe Calibrate](Probe_Calibrate.md)
|
||||
guide to set the x_offset, y_offset, and z_offset config parameters.
|
||||
|
|
@ -218,8 +211,7 @@ far above the nozzle as possible to avoid it touching printed parts.
|
|||
If an adjustment is made to the probe position, then rerun the probe
|
||||
calibration steps.
|
||||
|
||||
BL-Touch output mode
|
||||
--------------------
|
||||
## BL-Touch output mode
|
||||
|
||||
* A BL-Touch V3.0 supports setting a 5V or OPEN-DRAIN output mode,
|
||||
a BL-Touch V3.1 supports this too, but can also store this in its
|
||||
|
|
|
|||
|
|
@ -2,8 +2,7 @@
|
|||
|
||||
This document describes Klipper benchmarks.
|
||||
|
||||
Micro-controller Benchmarks
|
||||
---------------------------
|
||||
## Micro-controller Benchmarks
|
||||
|
||||
This section describes the mechanism used to generate the Klipper
|
||||
micro-controller step rate benchmarks.
|
||||
|
|
@ -25,7 +24,7 @@ or other innocuous pins. **Always verify that it is safe to drive the
|
|||
configured pins prior to running a benchmark.** It is not recommended
|
||||
to drive an actual stepper during a benchmark.
|
||||
|
||||
### Step rate benchmark test ###
|
||||
### Step rate benchmark test
|
||||
|
||||
The test is performed using the console.py tool (described in
|
||||
[Debugging.md](Debugging.md)). The micro-controller is configured for
|
||||
|
|
@ -88,7 +87,7 @@ delay"). This configuration is believed to be valid in real-world
|
|||
usage when one is solely using Trinamic stepper drivers. The results
|
||||
of these benchmarks are not reported in the Features.md document.
|
||||
|
||||
### AVR step rate benchmark ###
|
||||
### AVR step rate benchmark
|
||||
|
||||
The following configuration sequence is used on AVR chips:
|
||||
```
|
||||
|
|
@ -111,7 +110,7 @@ results match tests on both a 16Mhz at90usb and a 16Mhz atmega2560).
|
|||
| 2 stepper | 296 |
|
||||
| 3 stepper | 472 |
|
||||
|
||||
### Arduino Due step rate benchmark ###
|
||||
### Arduino Due step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the Due:
|
||||
```
|
||||
|
|
@ -133,7 +132,7 @@ The test was last run on commit `8d4a5c16` with gcc version
|
|||
| 1 stepper (no delay) | 77 |
|
||||
| 3 stepper (no delay) | 299 |
|
||||
|
||||
### Duet Maestro step rate benchmark ###
|
||||
### Duet Maestro step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the Duet Maestro:
|
||||
```
|
||||
|
|
@ -155,7 +154,7 @@ The test was last run on commit `8d4a5c16` with gcc version
|
|||
| 1 stepper (no delay) | 70 |
|
||||
| 3 stepper (no delay) | 254 |
|
||||
|
||||
### Duet Wifi step rate benchmark ###
|
||||
### Duet Wifi step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the Duet Wifi:
|
||||
```
|
||||
|
|
@ -179,7 +178,7 @@ The test was last run on commit `59a60d68` with gcc version
|
|||
| 3 stepper | 525 |
|
||||
| 4 stepper | 703 |
|
||||
|
||||
### Beaglebone PRU step rate benchmark ###
|
||||
### Beaglebone PRU step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the PRU:
|
||||
```
|
||||
|
|
@ -200,7 +199,7 @@ The test was last run on commit `b161a69e` with gcc version `pru-gcc
|
|||
| 2 stepper | 853 |
|
||||
| 3 stepper | 883 |
|
||||
|
||||
### STM32F042 step rate benchmark ###
|
||||
### STM32F042 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the STM32F042:
|
||||
```
|
||||
|
|
@ -220,7 +219,7 @@ The test was last run on commit `0b0c47c5` with gcc version
|
|||
| 2 stepper | 328 |
|
||||
| 3 stepper | 558 |
|
||||
|
||||
### STM32F103 step rate benchmark ###
|
||||
### STM32F103 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the STM32F103:
|
||||
```
|
||||
|
|
@ -242,7 +241,7 @@ The test was last run on commit `8d4a5c16` with gcc version
|
|||
| 1 stepper (no delay) | 71 |
|
||||
| 3 stepper (no delay) | 288 |
|
||||
|
||||
### STM32F4 step rate benchmark ###
|
||||
### STM32F4 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the STM32F4:
|
||||
```
|
||||
|
|
@ -277,7 +276,7 @@ using a 168Mhz clock).
|
|||
| 1 stepper (no delay) | 52 |
|
||||
| 3 stepper (no delay) | 226 |
|
||||
|
||||
### LPC176x step rate benchmark ###
|
||||
### LPC176x step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the LPC176x:
|
||||
```
|
||||
|
|
@ -308,7 +307,7 @@ results were obtained by overclocking an LPC1768 to 120Mhz.
|
|||
| 1 stepper (no delay) | 56 |
|
||||
| 3 stepper (no delay) | 240 |
|
||||
|
||||
### SAMD21 step rate benchmark ###
|
||||
### SAMD21 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the SAMD21:
|
||||
```
|
||||
|
|
@ -331,7 +330,7 @@ micro-controller.
|
|||
| 1 stepper (no delay) | 83 |
|
||||
| 3 stepper (no delay) | 321 |
|
||||
|
||||
### SAMD51 step rate benchmark ###
|
||||
### SAMD51 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the SAMD51:
|
||||
```
|
||||
|
|
@ -362,7 +361,7 @@ micro-controller.
|
|||
| 1 stepper (no delay) | 42 |
|
||||
| 3 stepper (no delay) | 194 |
|
||||
|
||||
### RP2040 step rate benchmark ###
|
||||
### RP2040 step rate benchmark
|
||||
|
||||
The following configuration sequence is used on the RP2040:
|
||||
|
||||
|
|
@ -388,7 +387,7 @@ Pico board.
|
|||
| 1 stepper (no delay) | 5 |
|
||||
| 3 stepper (no delay) | 22 |
|
||||
|
||||
### Linux MCU step rate benchmark ###
|
||||
### Linux MCU step rate benchmark
|
||||
|
||||
The following configuration sequence is used on a Raspberry Pi:
|
||||
```
|
||||
|
|
@ -409,7 +408,7 @@ The test was last run on commit `db0fb5d5` with gcc version `gcc
|
|||
| 2 stepper | 350 |
|
||||
| 3 stepper | 400 |
|
||||
|
||||
## Command dispatch benchmark ##
|
||||
## Command dispatch benchmark
|
||||
|
||||
The command dispatch benchmark tests how many "dummy" commands the
|
||||
micro-controller can process. It is primarily a test of the hardware
|
||||
|
|
@ -450,8 +449,7 @@ hub.
|
|||
| stm32f446 (USB) | 870K | 01d2183f | arm-none-eabi-gcc (Fedora 7.4.0-1.fc30) 7.4.0 |
|
||||
| rp2040 (USB) | 873K | c5667193 | arm-none-eabi-gcc (Fedora 10.2.0-4.fc34) 10.2.0 |
|
||||
|
||||
Host Benchmarks
|
||||
---------------
|
||||
## Host Benchmarks
|
||||
|
||||
It is possible to run timing tests on the host software using the
|
||||
"batch mode" processing mechanism (described in
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ application. This document is not an authoritative reference; it is
|
|||
intended as a collection of useful information that the Klipper
|
||||
developers have accumulated.
|
||||
|
||||
## AVR micro-controllers ##
|
||||
## AVR micro-controllers
|
||||
|
||||
|
||||
In general, the Arduino project is a good reference for bootloaders
|
||||
|
|
@ -46,7 +46,7 @@ use.
|
|||
The "avrdude" program is the most common tool used to flash atmega
|
||||
chips (both bootloader flashing and application flashing).
|
||||
|
||||
### Atmega2560 ###
|
||||
### Atmega2560
|
||||
|
||||
This chip is typically found in the "Arduino Mega" and is very common
|
||||
in 3d printer boards.
|
||||
|
|
@ -65,7 +65,7 @@ To flash an application use something like:
|
|||
avrdude -cwiring -patmega2560 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
|
||||
```
|
||||
|
||||
### Atmega1280 ###
|
||||
### Atmega1280
|
||||
|
||||
This chip is typically found in earlier versions of the "Arduino
|
||||
Mega".
|
||||
|
|
@ -84,7 +84,7 @@ To flash an application use something like:
|
|||
avrdude -carduino -patmega1280 -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
|
||||
```
|
||||
|
||||
### Atmega1284p ###
|
||||
### Atmega1284p
|
||||
|
||||
This chip is commonly found in "Melzi" style 3d printer boards.
|
||||
|
||||
|
|
@ -109,7 +109,7 @@ application use something like this instead:
|
|||
avrdude -carduino -patmega1284p -P/dev/ttyACM0 -b57600 -D -Uflash:w:out/klipper.elf.hex:i
|
||||
```
|
||||
|
||||
### At90usb1286 ###
|
||||
### At90usb1286
|
||||
|
||||
This document does not cover the method to flash a bootloader to the
|
||||
At90usb1286 nor does it cover general application flashing to this
|
||||
|
|
@ -124,7 +124,7 @@ One can flash an application with it using something like:
|
|||
teensy_loader_cli --mcu=at90usb1286 out/klipper.elf.hex -v
|
||||
```
|
||||
|
||||
### Atmega168 ###
|
||||
### Atmega168
|
||||
|
||||
The atmega168 has limited flash space. If using a bootloader, it is
|
||||
recommended to use the Optiboot bootloader. To flash that bootloader
|
||||
|
|
@ -143,8 +143,7 @@ like:
|
|||
avrdude -carduino -patmega168 -P/dev/ttyACM0 -b115200 -D -Uflash:w:out/klipper.elf.hex:i
|
||||
```
|
||||
|
||||
SAM3 micro-controllers (Arduino Due)
|
||||
------------------------------------
|
||||
## SAM3 micro-controllers (Arduino Due)
|
||||
|
||||
It is not common to use a bootloader with the SAM3 mcu. The chip
|
||||
itself has a ROM that allows the flash to be programmed from 3.3V
|
||||
|
|
@ -167,8 +166,7 @@ bossac -U -p /dev/ttyACM0 -a -e -w out/klipper.bin -v -b
|
|||
bossac -U -p /dev/ttyACM0 -R
|
||||
```
|
||||
|
||||
SAM4 micro-controllers (Duet Wifi)
|
||||
----------------------------------
|
||||
## SAM4 micro-controllers (Duet Wifi)
|
||||
|
||||
It is not common to use a bootloader with the SAM4 mcu. The chip
|
||||
itself has a ROM that allows the flash to be programmed from 3.3V
|
||||
|
|
@ -187,8 +185,7 @@ To flash an application use something like:
|
|||
bossac --port=/dev/ttyACM0 -b -U -e -w -v -R out/klipper.bin
|
||||
```
|
||||
|
||||
SAMD21 micro-controllers (Arduino Zero)
|
||||
---------------------------------------
|
||||
## SAMD21 micro-controllers (Arduino Zero)
|
||||
|
||||
The SAMD21 bootloader is flashed via the ARM Serial Wire Debug (SWD)
|
||||
interface. This is commonly done with a dedicated SWD hardware dongle.
|
||||
|
|
@ -226,8 +223,7 @@ flash command within the first few seconds of boot - something like:
|
|||
avrdude -c stk500v2 -p atmega2560 -P /dev/ttyACM0 -u -Uflash:w:out/klipper.elf.hex:i
|
||||
```
|
||||
|
||||
SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
|
||||
--------------------------------------------------------
|
||||
## SAMD51 micro-controllers (Adafruit Metro-M4 and similar)
|
||||
|
||||
Like the SAMD21, the SAMD51 bootloader is flashed via the ARM Serial
|
||||
Wire Debug (SWD) interface. To flash a bootloader with
|
||||
|
|
@ -255,8 +251,7 @@ like:
|
|||
bossac -U -p /dev/ttyACM0 --offset=0x4000 -w out/klipper.bin -v -b -R
|
||||
```
|
||||
|
||||
STM32F103 micro-controllers (Blue Pill devices)
|
||||
-----------------------------------------------
|
||||
## STM32F103 micro-controllers (Blue Pill devices)
|
||||
|
||||
The STM32F103 devices have a ROM that can flash a bootloader or
|
||||
application via 3.3V serial. To access this ROM, one should connect
|
||||
|
|
@ -276,7 +271,7 @@ for details on enabling the full uart on the Raspberry Pi GPIO pins.
|
|||
After flashing, set both "boot 0" and "boot 1" back to low so that
|
||||
future resets boot from flash.
|
||||
|
||||
### STM32F103 with stm32duino bootloader ###
|
||||
### STM32F103 with stm32duino bootloader
|
||||
|
||||
The "stm32duino" project has a USB capable bootloader - see:
|
||||
[https://github.com/rogerclarkmelbourne/STM32duino-bootloader](https://github.com/rogerclarkmelbourne/STM32duino-bootloader)
|
||||
|
|
@ -301,7 +296,8 @@ bootloader is still active (the bootloader will flash a board led
|
|||
while it is running). Alternatively, set the "boot 0" pin to low and
|
||||
"boot 1" pin to high to stay in the bootloader after a reset.
|
||||
|
||||
### STM32F103 with HID bootloader ###
|
||||
### STM32F103 with HID bootloader
|
||||
|
||||
The [HID bootloader](https://github.com/Serasidis/STM32_HID_Bootloader) is a
|
||||
compact, driverless bootloader capable of flashing over USB. Also available
|
||||
is a [fork with builds specific to the SKR Mini E3 1.2](
|
||||
|
|
@ -389,8 +385,8 @@ not available, so it may be done by setting pin PA2 low if you flashed
|
|||
the SKR Mini E3's "PIN" document. There is a ground pin next to PA2
|
||||
which you can use to pull PA2 low.
|
||||
|
||||
STM32F4 micro-controllers (SKR Pro 1.1)
|
||||
===============================================
|
||||
## 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
|
||||
methods (see STM Document AN2606 for more information). Some
|
||||
|
|
@ -423,8 +419,7 @@ setting "boot 0" low, "boot 1" high and plugging in the device. After
|
|||
programming is complete unplug the device and set "boot 1" back to low
|
||||
so the application will be loaded.
|
||||
|
||||
LPC176x micro-controllers (Smoothieboards)
|
||||
------------------------------------------
|
||||
## LPC176x micro-controllers (Smoothieboards)
|
||||
|
||||
This document does not describe the method to flash a bootloader
|
||||
itself - see:
|
||||
|
|
@ -439,8 +434,7 @@ this bootloader is to copy the application file (eg,
|
|||
`out/klipper.bin`) to a file named `firmware.bin` on an SD card, and
|
||||
then to reboot the micro-controller with that SD card.
|
||||
|
||||
Running OpenOCD on the Raspberry PI
|
||||
-----------------------------------
|
||||
## Running OpenOCD on the Raspberry PI
|
||||
|
||||
OpenOCD is a software package that can perform low-level chip flashing
|
||||
and debugging. It can use the GPIO pins on a Raspberry Pi to
|
||||
|
|
|
|||
|
|
@ -3,8 +3,7 @@
|
|||
This document describes the overall code layout and major code flow of
|
||||
Klipper.
|
||||
|
||||
Directory Layout
|
||||
----------------
|
||||
## Directory Layout
|
||||
|
||||
The **src/** directory contains the C source for the micro-controller
|
||||
code. The **src/atsam/**, **src/atsamd/**, **src/avr/**,
|
||||
|
|
@ -40,8 +39,7 @@ contains temporary build time objects. The final micro-controller
|
|||
object that is built is **out/klipper.elf.hex** on AVR and
|
||||
**out/klipper.bin** on ARM.
|
||||
|
||||
Micro-controller code flow
|
||||
--------------------------
|
||||
## Micro-controller code flow
|
||||
|
||||
Execution of the micro-controller code starts in architecture specific
|
||||
code (eg, **src/avr/main.c**) which ultimately calls sched_main()
|
||||
|
|
@ -91,8 +89,7 @@ inlining functions across compilation units, so most of these tiny
|
|||
gpio functions are inlined into their callers, and there is no
|
||||
run-time cost to using them.
|
||||
|
||||
Klippy code overview
|
||||
--------------------
|
||||
## Klippy code overview
|
||||
|
||||
The host code (Klippy) is intended to run on a low-cost computer (such
|
||||
as a Raspberry Pi) paired with the micro-controller. The code is
|
||||
|
|
@ -117,8 +114,7 @@ response messages from the micro-controller in the Python code (see
|
|||
the log (see **klippy/queuelogger.py**) so that the other threads
|
||||
never block on log writes.
|
||||
|
||||
Code flow of a move command
|
||||
---------------------------
|
||||
## Code flow of a move command
|
||||
|
||||
A typical printer movement starts when a "G1" command is sent to the
|
||||
Klippy host and it completes when the corresponding step pulses are
|
||||
|
|
@ -229,8 +225,7 @@ kinematic classes. It's this part of the code which specifies the
|
|||
movements and their timings. The remaining parts of the processing is
|
||||
mostly just communication and plumbing.
|
||||
|
||||
Adding a host module
|
||||
--------------------
|
||||
## Adding a host module
|
||||
|
||||
The Klippy host code has a dynamic module loading capability. If a
|
||||
config section named "[my_module]" is found in the printer config file
|
||||
|
|
@ -309,8 +304,7 @@ The following may also be useful:
|
|||
sure to place a copyright notice at the top of the module. See the
|
||||
existing modules for the preferred format.
|
||||
|
||||
Adding new kinematics
|
||||
---------------------
|
||||
## Adding new kinematics
|
||||
|
||||
This section provides some tips on adding support to Klipper for
|
||||
additional types of printer kinematics. This type of activity requires
|
||||
|
|
@ -349,8 +343,7 @@ Useful steps:
|
|||
to micro-controller commands. This is useful to exercise corner
|
||||
cases and to check for regressions.
|
||||
|
||||
Porting to a new micro-controller
|
||||
---------------------------------
|
||||
## Porting to a new micro-controller
|
||||
|
||||
This section provides some tips on porting Klipper's micro-controller
|
||||
code to a new architecture. This type of activity requires good
|
||||
|
|
@ -402,8 +395,7 @@ Useful steps:
|
|||
the micro-controller with the main klippy.py program.
|
||||
9. Consider adding build test cases in the test/ directory.
|
||||
|
||||
Coordinate Systems
|
||||
------------------
|
||||
## Coordinate Systems
|
||||
|
||||
Internally, Klipper primarily tracks the position of the toolhead in
|
||||
cartesian coordinates that are relative to the coordinate system
|
||||
|
|
@ -488,8 +480,7 @@ cartesian coordinates relative to the coordinate system specified in
|
|||
the config file) after a `G28` home command. The `SET_GCODE_OFFSET`
|
||||
command can alter this value.
|
||||
|
||||
Time
|
||||
----
|
||||
## Time
|
||||
|
||||
Fundamental to the operation of Klipper is the handling of clocks,
|
||||
times, and timestamps. Klipper executes actions on the printer by
|
||||
|
|
|
|||
|
|
@ -197,7 +197,7 @@ stepper_position = (sqrt(arm_length^2
|
|||
+ cartesian_z_position)
|
||||
```
|
||||
|
||||
### Stepper motor acceleration limits ###
|
||||
### Stepper motor acceleration limits
|
||||
|
||||
With delta kinematics it is possible for a move that is accelerating
|
||||
in cartesian space to require an acceleration on a particular stepper
|
||||
|
|
@ -218,7 +218,7 @@ this limit, moves at the extreme edge of the build envelope (where a
|
|||
stepper arm may be nearly horizontal) will have a lower maximum
|
||||
acceleration and velocity.
|
||||
|
||||
### Extruder kinematics ###
|
||||
### Extruder kinematics
|
||||
|
||||
Klipper implements extruder motion in its own kinematic class. Since
|
||||
the timing and speed of each print head movement is fully known for
|
||||
|
|
@ -232,7 +232,7 @@ generation uses the same formulas that cartesian robots use:
|
|||
stepper_position = requested_e_position
|
||||
```
|
||||
|
||||
### Pressure advance ###
|
||||
### Pressure advance
|
||||
|
||||
Experimentation has shown that it's possible to improve the modeling
|
||||
of the extruder beyond the basic extruder formula. In the ideal case,
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
Measuring Resonances
|
||||
====================
|
||||
# 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
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
Resonance Compensation
|
||||
====================
|
||||
# Resonance Compensation
|
||||
|
||||
Klipper supports Input Shaping - a technique that can be used to reduce ringing
|
||||
(also known as echoing, ghosting or rippling) in prints. Ringing is a surface
|
||||
|
|
|
|||
|
|
@ -3,8 +3,7 @@
|
|||
This document describes the process of running Klipper on a Beaglebone
|
||||
PRU.
|
||||
|
||||
Building an OS image
|
||||
--------------------
|
||||
## Building an OS image
|
||||
|
||||
Start by installing the
|
||||
[Debian 9.9 2019-08-03 4GB SD IoT](https://beagleboard.org/latest-images)
|
||||
|
|
@ -20,8 +19,7 @@ git clone https://github.com/KevinOConnor/klipper
|
|||
./klipper/scripts/install-beaglebone.sh
|
||||
```
|
||||
|
||||
Install Octoprint
|
||||
-----------------
|
||||
## Install Octoprint
|
||||
|
||||
One may then install Octoprint:
|
||||
```
|
||||
|
|
@ -56,8 +54,7 @@ sudo systemctl start octoprint
|
|||
Make sure the octoprint web server is accessible - it should be at:
|
||||
[http://beaglebone:5000/](http://beaglebone:5000/)
|
||||
|
||||
Building the micro-controller code
|
||||
----------------------------------
|
||||
## Building the micro-controller code
|
||||
|
||||
To compile the Klipper micro-controller code, start by configuring it
|
||||
for the "Beaglebone PRU":
|
||||
|
|
@ -87,15 +84,13 @@ make flash
|
|||
sudo service klipper start
|
||||
```
|
||||
|
||||
Remaining configuration
|
||||
-----------------------
|
||||
## Remaining configuration
|
||||
|
||||
Complete the installation by configuring Klipper and Octoprint
|
||||
following the instructions in
|
||||
[the main installation document](Installation.md#configuring-klipper).
|
||||
|
||||
Printing on the Beaglebone
|
||||
--------------------------
|
||||
## Printing on the Beaglebone
|
||||
|
||||
Unfortunately, the Beaglebone processor can sometimes struggle to run
|
||||
OctoPrint well. Print stalls have been known to occur on complex
|
||||
|
|
|
|||
Loading…
Reference in New Issue