docs: Fix typos (#6032)
Signed-off-by: Thijs Triemstra <info@collab.nl>
This commit is contained in:
parent
aca0c71a2b
commit
848a78d1a5
|
@ -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.
|
||||
|
||||
![bedmesh_round_basic](img/bedmesh_round_basic.svg)
|
||||
|
@ -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,
|
||||
|
@ -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
|
||||
|
||||
|
@ -263,9 +263,9 @@ fade_target: 0
|
|||
|
||||
### The Relative Reference Index
|
||||
|
||||
Most probes are suceptible to drift, ie: inaccuracies in probing introduced by
|
||||
Most probes are susceptible 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
|
||||
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.
|
||||
These printers can benefit from configuring the relative reference index.
|
||||
|
||||
|
|
|
@ -305,7 +305,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 +382,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 +390,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 +419,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 +448,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 +458,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:
|
||||
```
|
||||
|
|
|
@ -346,7 +346,7 @@ max_z_velocity:
|
|||
#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 becomming completely horizontal,
|
||||
# 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
|
||||
|
@ -383,7 +383,7 @@ arm_x_length:
|
|||
# for stepper_right, this parameter defaults to the value specified for
|
||||
# stepper_left.
|
||||
|
||||
# The stepper_right section is used to desribe the stepper controlling the
|
||||
# The stepper_right section is used to describe the stepper controlling the
|
||||
# right tower.
|
||||
[stepper_right]
|
||||
|
||||
|
@ -4323,7 +4323,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]
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -15,7 +15,7 @@ Klipper has several compelling features:
|
|||
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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -19,7 +19,7 @@ that it has a voltage regulator and a level shifter.
|
|||
### Wiring
|
||||
|
||||
An ethernet cable with shielded twisted pairs (cat5e or better) is recommended
|
||||
for signal integrety over a long distance. If you still experience signal integrity
|
||||
for signal integrity over a long distance. If you still experience signal integrity
|
||||
issues (SPI/I2C errors), shorten the cable.
|
||||
|
||||
Connect ethernet cable shielding to the controller board/RPI ground.
|
||||
|
@ -41,7 +41,7 @@ SCLK+CS
|
|||
|
||||
|
||||
**Note: Many MCUs will work with an ADXL345 in SPI mode(eg Pi Pico), wiring and
|
||||
configuration will vary according to your specific board and avaliable pins.**
|
||||
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
|
||||
|
@ -49,7 +49,7 @@ 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) |
|
||||
|
@ -310,7 +310,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).
|
||||
|
@ -550,9 +550,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
|
||||
|
|
|
@ -54,7 +54,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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -127,13 +127,13 @@ 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
|
||||
|
|
Loading…
Reference in New Issue