diff --git a/.github/workflows/klipper3d-deploy.yaml b/.github/workflows/cd-docs.yaml similarity index 65% rename from .github/workflows/klipper3d-deploy.yaml rename to .github/workflows/cd-docs.yaml index 4754cffb8..e3d49d618 100644 --- a/.github/workflows/klipper3d-deploy.yaml +++ b/.github/workflows/cd-docs.yaml @@ -1,4 +1,4 @@ -name: klipper3d deploy +name: docs deployment on: workflow_dispatch: push: @@ -6,7 +6,7 @@ on: - master paths: - docs/** - - .github/workflows/klipper3d-deploy.yaml + - .github/workflows/cd-docs.yaml jobs: deploy: @@ -20,17 +20,21 @@ jobs: python-version: "3.10" - uses: actions/cache@v3 + id: pip-cache with: path: ~/.cache/pip - key: ${{ runner.os }}-pip-${{ hashFiles('docs/_klipper3d/mkdocs-requirements.txt') }} + key: ${{ runner.os }}-pip-${{ hashFiles('docs/_kalico/mkdocs-requirements.txt') }} restore-keys: | ${{ runner.os }}-pip- - name: Install dependencies - run: pip install -r docs/_klipper3d/mkdocs-requirements.txt + if: steps.pip-cache.outputs.cache-hit != 'true' + run: pip install -r docs/_kalico/mkdocs-requirements.txt - name: Build MkDocs Pages - run: docs/_klipper3d/build-translations.sh + run: | + cd docs/ + mkdocs build -f _kalico/mkdocs.yml - name: Deploy uses: JamesIves/github-pages-deploy-action@v4.4.3 diff --git a/.github/workflows/ci-docs_test.yaml b/.github/workflows/ci-docs_test.yaml new file mode 100644 index 000000000..31d1638d7 --- /dev/null +++ b/.github/workflows/ci-docs_test.yaml @@ -0,0 +1,34 @@ +name: docs deployment +on: + pull_request: + paths: + - docs/** + - .github/workflows/ci-docs_test.yaml + +jobs: + deploy: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + + - name: Setup python + uses: actions/setup-python@v4 + with: + python-version: "3.10" + + - uses: actions/cache@v3 + id: pip-cache + with: + path: ~/.cache/pip + key: ${{ runner.os }}-pip-${{ hashFiles('docs/_kalico/mkdocs-requirements.txt') }} + restore-keys: | + ${{ runner.os }}-pip- + + - name: Install dependencies + if: steps.pip-cache.outputs.cache-hit != 'true' + run: pip install -r docs/_kalico/mkdocs-requirements.txt + + - name: Build MkDocs Pages + run: | + cd docs/ + mkdocs build -f _kalico/mkdocs.yml --strict diff --git a/.gitignore b/.gitignore index 14b15b235..424cd74e8 100644 --- a/.gitignore +++ b/.gitignore @@ -1,6 +1,8 @@ +# development out *.so *.pyc +__pycache__/ .config .config.old klippy/.version @@ -12,3 +14,11 @@ _test_.* klippy/plugins/* !klippy/plugins/__init__.py .vscode + +# docs +site/ +.env/ +.venv/ +env/ +venv/ +mkdocs-env/ diff --git a/README.md b/README.md index a890b4f40..3c668b218 100644 --- a/README.md +++ b/README.md @@ -1,8 +1,8 @@ -

Danger-Klipper Logo

+

Kalico Logo

-[![Action Status](https://github.com/DangerKlippers/danger-klipper/actions/workflows/ci-build_test.yaml/badge.svg?branch=master)](https://github.com/DangerKlippers/danger-klipper/actions/workflows/ci-build_test.yaml) +[![Action Status](https://github.com/kalico-crew/kalico/actions/workflows/ci-build_test.yaml/badge.svg?branch=master)](https://github.com/kalico-crew/kalico/actions/workflows/ci-build_test.yaml) -# Welcome to the Danger Klipper project! +# Welcome to the Kalico project! This is a community-maintained fork of the [Klipper](https://github.com/Klipper3d/klipper) firmware. @@ -10,140 +10,140 @@ Our goal is to support features and behavior that could be "risky" if used incor If I want my printer to light itself on fire, I should be able to make my printer light itself on fire. -See the [Danger Features document](https://dangerklipper.io/Danger_Features.html) for more information on *some* of the differences from Klipper. +See the [Danger Features document](https://docs.kalico.gg/Danger_Features.html) for more information on *some* of the differences from Klipper. ## Features merged into the master branch: -- [core: no Python2 tests; no PRU boards](https://github.com/DangerKlippers/danger-klipper/pull/39) +- [core: no Python2 tests; no PRU boards](https://github.com/kalico-crew/kalico/pull/39) -- [core: git-untracked folder, plugins for user-plugins](https://github.com/DangerKlippers/danger-klipper/pull/82) +- [core: git-untracked folder, plugins for user-plugins](https://github.com/kalico-crew/kalico/pull/82) -- [core: danger_options](https://github.com/DangerKlippers/danger-klipper/pull/67) +- [core: danger_options](https://github.com/kalico-crew/kalico/pull/67) -- [core: rotate log file at every restart](https://github.com/DangerKlippers/danger-klipper/pull/181) +- [core: rotate log file at every restart](https://github.com/kalico-crew/kalico/pull/181) -- [fan: normalising Fan PWM power](https://github.com/DangerKlippers/danger-klipper/pull/44) ([klipper#6307](https://github.com/Klipper3d/klipper/pull/6307)) +- [fan: normalising Fan PWM power](https://github.com/kalico-crew/kalico/pull/44) ([klipper#6307](https://github.com/Klipper3d/klipper/pull/6307)) -- [fan: reverse FAN](https://github.com/DangerKlippers/danger-klipper/pull/51) ([klipper#4983](https://github.com/Klipper3d/klipper/pull/4983)) +- [fan: reverse FAN](https://github.com/kalico-crew/kalico/pull/51) ([klipper#4983](https://github.com/Klipper3d/klipper/pull/4983)) -- [heaters: modify PID without reload](https://github.com/DangerKlippers/danger-klipper/pull/35) +- [heaters: modify PID without reload](https://github.com/kalico-crew/kalico/pull/35) -- [heaters: MPC temperature control](https://github.com/DangerKlippers/danger-klipper/pull/333) +- [heaters: MPC temperature control](https://github.com/kalico-crew/kalico/pull/333) -- [heaters: velocity PID](https://github.com/DangerKlippers/danger-klipper/pull/47) ([klipper#6272](https://github.com/Klipper3d/klipper/pull/6272)) +- [heaters: velocity PID](https://github.com/kalico-crew/kalico/pull/47) ([klipper#6272](https://github.com/Klipper3d/klipper/pull/6272)) -- [heaters: PID-Profiles](https://github.com/DangerKlippers/danger-klipper/pull/162) +- [heaters: PID-Profiles](https://github.com/kalico-crew/kalico/pull/162) -- [heaters: expose heater thermistor out of min/max](https://github.com/DangerKlippers/danger-klipper/pull/182) +- [heaters: expose heater thermistor out of min/max](https://github.com/kalico-crew/kalico/pull/182) -- [heaters/fan: new heated_fan module](https://github.com/DangerKlippers/danger-klipper/pull/259) +- [heaters/fan: new heated_fan module](https://github.com/kalico-crew/kalico/pull/259) -- [gcode: jinja2.ext.do extension](https://github.com/DangerKlippers/danger-klipper/pull/26) ([klipper#5149](https://github.com/Klipper3d/klipper/pull/5149)) +- [gcode: jinja2.ext.do extension](https://github.com/kalico-crew/kalico/pull/26) ([klipper#5149](https://github.com/Klipper3d/klipper/pull/5149)) -- [gcode: gcode_shell_command](https://github.com/DangerKlippers/danger-klipper/pull/71) ([klipper#2173](https://github.com/Klipper3d/klipper/pull/2173) / [kiuah](https://github.com/dw-0/kiauh/blob/master/resources/gcode_shell_command.py) ) +- [gcode: gcode_shell_command](https://github.com/kalico-crew/kalico/pull/71) ([klipper#2173](https://github.com/Klipper3d/klipper/pull/2173) / [kiuah](https://github.com/dw-0/kiauh/blob/master/resources/gcode_shell_command.py) ) -- [gcode: expose math functions to gcode macros](https://github.com/DangerKlippers/danger-klipper/pull/173) ([klipper#4072](https://github.com/Klipper3d/klipper/pull/4072)) +- [gcode: expose math functions to gcode macros](https://github.com/kalico-crew/kalico/pull/173) ([klipper#4072](https://github.com/Klipper3d/klipper/pull/4072)) -- [gcode: HEATER_INTERRUPT gcode command](https://github.com/DangerKlippers/danger-klipper/pull/94) +- [gcode: HEATER_INTERRUPT gcode command](https://github.com/kalico-crew/kalico/pull/94) -- [gcode: RELOAD_GCODE_MACROS command](https://github.com/DangerKlippers/danger-klipper/pull/305) +- [gcode: RELOAD_GCODE_MACROS command](https://github.com/kalico-crew/kalico/pull/305) -- [probe: dockable Probe](https://github.com/DangerKlippers/danger-klipper/pull/43) ([klipper#4328](https://github.com/Klipper3d/klipper/pull/4328)) +- [probe: dockable Probe](https://github.com/kalico-crew/kalico/pull/43) ([klipper#4328](https://github.com/Klipper3d/klipper/pull/4328)) -- [probe: drop the first result](https://github.com/DangerKlippers/danger-klipper/pull/2) ([klipper#3397](https://github.com/Klipper3d/klipper/issues/3397)) +- [probe: drop the first result](https://github.com/kalico-crew/kalico/pull/2) ([klipper#3397](https://github.com/Klipper3d/klipper/issues/3397)) -- [probe: z_calibration](https://github.com/DangerKlippers/danger-klipper/pull/31) ([klipper#4614](https://github.com/Klipper3d/klipper/pull/4614) / [protoloft/z_calibration](https://github.com/protoloft/klipper_z_calibration)) +- [probe: z_calibration](https://github.com/kalico-crew/kalico/pull/31) ([klipper#4614](https://github.com/Klipper3d/klipper/pull/4614) / [protoloft/z_calibration](https://github.com/protoloft/klipper_z_calibration)) -- [z_tilt: z-tilt calibration](https://github.com/DangerKlippers/danger-klipper/pull/105) ([klipper3d#4083](https://github.com/Klipper3d/klipper/pull/4083) / [dk/ztilt_calibration](https://github.com/DangerKlippers/danger-klipper/pull/54)) +- [z_tilt: z-tilt calibration](https://github.com/kalico-crew/kalico/pull/105) ([klipper3d#4083](https://github.com/Klipper3d/klipper/pull/4083) / [dk/ztilt_calibration](https://github.com/kalico-crew/kalico/pull/54)) -- [stepper: home_current](https://github.com/DangerKlippers/danger-klipper/pull/65) +- [stepper: home_current](https://github.com/kalico-crew/kalico/pull/65) -- [stepper: current_change_dwell_time](https://github.com/DangerKlippers/danger-klipper/pull/90) +- [stepper: current_change_dwell_time](https://github.com/kalico-crew/kalico/pull/90) -- [homing: post-home retract](https://github.com/DangerKlippers/danger-klipper/pull/65) +- [homing: post-home retract](https://github.com/kalico-crew/kalico/pull/65) -- [homing: sensorless minimum home distance](https://github.com/DangerKlippers/danger-klipper/pull/65) +- [homing: sensorless minimum home distance](https://github.com/kalico-crew/kalico/pull/65) -- [homing: min_home_dist](https://github.com/DangerKlippers/danger-klipper/pull/90) +- [homing: min_home_dist](https://github.com/kalico-crew/kalico/pull/90) -- [virtual_sdcard: scanning of subdirectories](https://github.com/DangerKlippers/danger-klipper/pull/68) ([klipper#6327](https://github.com/Klipper3d/klipper/pull/6327)) +- [virtual_sdcard: scanning of subdirectories](https://github.com/kalico-crew/kalico/pull/68) ([klipper#6327](https://github.com/Klipper3d/klipper/pull/6327)) -- [retraction: z_hop while retracting](https://github.com/DangerKlippers/danger-klipper/pull/83) ([klipper#6311](https://github.com/Klipper3d/klipper/pull/6311)) +- [retraction: z_hop while retracting](https://github.com/kalico-crew/kalico/pull/83) ([klipper#6311](https://github.com/Klipper3d/klipper/pull/6311)) -- [danger_options: allow plugins to override conflicting extras](https://github.com/DangerKlippers/danger-klipper/pull/82) +- [danger_options: allow plugins to override conflicting extras](https://github.com/kalico-crew/kalico/pull/82) -- [danger_options: expose the multi mcu homing timeout as a parameter](https://github.com/DangerKlippers/danger-klipper/pull/93) +- [danger_options: expose the multi mcu homing timeout as a parameter](https://github.com/kalico-crew/kalico/pull/93) -- [danger_options: option to configure the homing elapsed distance tolerance](https://github.com/DangerKlippers/danger-klipper/pull/110) +- [danger_options: option to configure the homing elapsed distance tolerance](https://github.com/kalico-crew/kalico/pull/110) -- [danger_options: option to ignore ADC out of range](https://github.com/DangerKlippers/danger-klipper/pull/129) +- [danger_options: option to ignore ADC out of range](https://github.com/kalico-crew/kalico/pull/129) -- [temperature_mcu: add reference_voltage](https://github.com/DangerKlippers/danger-klipper/pull/99) ([klipper#5713](https://github.com/Klipper3d/klipper/pull/5713)) +- [temperature_mcu: add reference_voltage](https://github.com/kalico-crew/kalico/pull/99) ([klipper#5713](https://github.com/Klipper3d/klipper/pull/5713)) -- [adxl345: improve ACCELEROMETER_QUERY command](https://github.com/DangerKlippers/danger-klipper/pull/124) +- [adxl345: improve ACCELEROMETER_QUERY command](https://github.com/kalico-crew/kalico/pull/124) -- [extruder: add flag to use the PA constant from a trapq move vs a cached value](https://github.com/DangerKlippers/danger-klipper/pull/132) +- [extruder: add flag to use the PA constant from a trapq move vs a cached value](https://github.com/kalico-crew/kalico/pull/132) -- [force_move: turn on by default](https://github.com/DangerKlippers/danger-klipper/pull/135) +- [force_move: turn on by default](https://github.com/kalico-crew/kalico/pull/135) -- [respond: turn on by default](https://github.com/DangerKlippers/danger-klipper/pull/296) +- [respond: turn on by default](https://github.com/kalico-crew/kalico/pull/296) -- [exclude_object: turn on by default](https://github.com/DangerKlippers/danger-klipper/pull/306) +- [exclude_object: turn on by default](https://github.com/kalico-crew/kalico/pull/306) -- [bed_mesh: add bed_mesh_default config option](https://github.com/DangerKlippers/danger-klipper/pull/143) +- [bed_mesh: add bed_mesh_default config option](https://github.com/kalico-crew/kalico/pull/143) -- [config: CONFIG_SAVE updates included files](https://github.com/DangerKlippers/danger-klipper/pull/153) +- [config: CONFIG_SAVE updates included files](https://github.com/kalico-crew/kalico/pull/153) -- [kinematics: independent X&Y accel/velocity for corexy and cartesian](https://github.com/DangerKlippers/danger-klipper/pull/4) +- [kinematics: independent X&Y accel/velocity for corexy and cartesian](https://github.com/kalico-crew/kalico/pull/4) -- [kinematics: independent X&Y accel/velocity for corexz](https://github.com/DangerKlippers/danger-klipper/pull/267) +- [kinematics: independent X&Y accel/velocity for corexz](https://github.com/kalico-crew/kalico/pull/267) -- [idle_timeout: allow the idle timeout to be disabled](https://github.com/DangerKlippers/danger-klipper/issues/165) +- [idle_timeout: allow the idle timeout to be disabled](https://github.com/kalico-crew/kalico/issues/165) -- [canbus: custom CAN bus uuid hash for deterministic uuids](https://github.com/DangerKlippers/danger-klipper/pull/156) +- [canbus: custom CAN bus uuid hash for deterministic uuids](https://github.com/kalico-crew/kalico/pull/156) -- [filament_switch|motion_sensor: runout distance, smart and runout gcode](https://github.com/DangerKlippers/danger-klipper/pull/158) +- [filament_switch|motion_sensor: runout distance, smart and runout gcode](https://github.com/kalico-crew/kalico/pull/158) -- [z_tilt|qgl: custom threshold for probe_points_increasing check](https://github.com/DangerKlippers/danger-klipper/pull/189) +- [z_tilt|qgl: custom threshold for probe_points_increasing check](https://github.com/kalico-crew/kalico/pull/189) -- [save_config: save without restarting the firmware](https://github.com/DangerKlippers/danger-klipper/pull/191) +- [save_config: save without restarting the firmware](https://github.com/kalico-crew/kalico/pull/191) -- [configfile: recursive globs](https://github.com/DangerKlippers/danger-klipper/pull/200) / ([klipper#6375](https://github.com/Klipper3d/klipper/pull/6375)) +- [configfile: recursive globs](https://github.com/kalico-crew/kalico/pull/200) / ([klipper#6375](https://github.com/Klipper3d/klipper/pull/6375)) -- [temperature_fan: curve control algorithm](https://github.com/DangerKlippers/danger-klipper/pull/193) +- [temperature_fan: curve control algorithm](https://github.com/kalico-crew/kalico/pull/193) -- [shaper_calibrate: store and expose accel_per_hz](https://github.com/DangerKlippers/danger-klipper/pull/224) +- [shaper_calibrate: store and expose accel_per_hz](https://github.com/kalico-crew/kalico/pull/224) -- [resonance_tester: accepts ACCEL_PER_HZ in TEST_RESONANCES](https://github.com/DangerKlippers/danger-klipper/pull/312) +- [resonance_tester: accepts ACCEL_PER_HZ in TEST_RESONANCES](https://github.com/kalico-crew/kalico/pull/312) -- [mcu: support for AT32F403](https://github.com/DangerKlippers/danger-klipper/pull/284) +- [mcu: support for AT32F403](https://github.com/kalico-crew/kalico/pull/284) -- [z_tilt, quad_gantry_level: adaptive horizontal move z](https://github.com/DangerKlippers/danger-klipper/pull/336) +- [z_tilt, quad_gantry_level: adaptive horizontal move z](https://github.com/kalico-crew/kalico/pull/336) -- [core: non-critical-mcus](https://github.com/DangerKlippers/danger-klipper/pull/339) +- [core: non-critical-mcus](https://github.com/kalico-crew/kalico/pull/339) -- [gcode_macros: !python templates](https://github.com/DangerKlippers/danger-klipper/pull/360) +- [gcode_macros: !python templates](https://github.com/kalico-crew/kalico/pull/360) -- [core: action_log](https://github.com/DangerKlippers/danger-klipper/pull/367) +- [core: action_log](https://github.com/kalico-crew/kalico/pull/367) -- [danger_options: configurable homing constants](https://github.com/DangerKlippers/danger-klipper/pull/378) +- [danger_options: configurable homing constants](https://github.com/kalico-crew/kalico/pull/378) If you're feeling adventurous, take a peek at the extra features in the bleeding-edge-v2 branch [feature documentation](docs/Bleeding_Edge.md) and [feature configuration reference](docs/Config_Reference_Bleeding_Edge.md): -- [extruder/pa: do not smooth base extruder position, only advance](https://github.com/DangerKlippers/danger-klipper/pull/266) +- [extruder/pa: do not smooth base extruder position, only advance](https://github.com/kalico-crew/kalico/pull/266) -- [dmbutyugin's advanced-features branch - Pull Request #262](https://github.com/DangerKlippers/danger-klipper/pull/262) +- [dmbutyugin's advanced-features branch - Pull Request #262](https://github.com/kalico-crew/kalico/pull/262) - stepper: high precision stepping protocol - extruder: sync extruder motion with input shaper - extruder: new print_pa_tower utility - input_shaper: smooth input shapers - input_shaper: new print_ringing_tower utility -## Switch to Danger Klipper +## Switch to Kalico > [!NOTE] -> Any add-on modules you are using will need to be reinstalled after switching to Danger Klipper. This includes things like Beacon support, led-effect, etc. +> Any add-on modules you are using will need to be reinstalled after switching to Kalico. This includes things like Beacon support, led-effect, etc. > > Any data in ~/printer_data such as printer configs and macros will be unaffected. @@ -155,10 +155,10 @@ If desired, make a backup copy of your existing Klipper installation by running: mv ~/klipper ~/klipper_old ``` -Then clone the Danger Klipper repo and restart the klipper service: +Then clone the Kalico repo and restart the klipper service: ```bash -git clone https://github.com/DangerKlippers/danger-klipper.git ~/klipper +git clone https://github.com/kalico-crew/kalico.git ~/klipper sudo systemctl restart klipper ``` @@ -166,13 +166,13 @@ sudo systemctl restart klipper For users that are not comfortable using Git directly, [KIAUH v6](https://github.com/dw-0/kiauh) is able to use custom repositories. -To do this, add the Danger Klipper repo to KIAUH's custom repository settings with the following steps: +To do this, add the Kalico repo to KIAUH's custom repository settings with the following steps: From the KIAUH menu select: - [S] Settings - 1\) Set custom Klipper repository -- Use `https://github.com/DangerKlippers/danger-klipper` as the new repository URL +- Use `https://github.com/kalico-crew/kalico` as the new repository URL - Use `master` or `bleeding-edge-v2` as the new branch name - Select 'Y' to apply the changes - Enter 'B' for back twice @@ -183,7 +183,7 @@ Can switch back to mainline klipper at any time via a `git checkout upstream_mas ```bash cd ~/klipper -git remote add danger https://github.com/DangerKlippers/danger-klipper.git +git remote add danger https://github.com/kalico-crew/kalico.git git checkout -b upstream-master origin/master git branch -D master git checkout -b master danger/master @@ -193,17 +193,15 @@ sudo systemctl restart moonraker --- -"Dangerous Klipper for dangerous users" - -Klipper is a 3d-Printer firmware. It combines the power of a general +Kalico is a 3d-Printer firmware. It combines the power of a general purpose computer with one or more micro-controllers. See the -[features document](https://dangerklipper.io/Features.html) for more -information on why you should use Klipper. +[features document](https://docs.kalico.gg/Features.html) for more +information on why you should use Kalico. -To begin using Klipper start by -[installing](https://dangerklipper.io/Installation.html) it. +To begin using Kalico start by +[installing](https://docs.kalico.gg/Installation.html) it. -Klipper is Free Software. See the [license](COPYING) or read the -[documentation](https://dangerklipper.io/Overview.html). +Kalico is Free Software. See the [license](COPYING) or read the +[documentation](https://docs.kalico.gg/Overview.html). -[![Join me on Discord](https://discord.com/api/guilds/1029426383614648421/widget.png?style=banner2)](https://discord.gg/armchairengineeringsux) +[![Join me on Discord](https://discord.com/api/guilds/1297243471442214913/widget.png?style=banner2)](https://kalico.gg/discord) diff --git a/docs/API_Server.md b/docs/API_Server.md index 3da4584b1..ee92b8929 100644 --- a/docs/API_Server.md +++ b/docs/API_Server.md @@ -1,8 +1,8 @@ # API server -This document describes Klipper's Application Programmer Interface +This document describes Kalico's Application Programmer Interface (API). This interface enables external applications to query and -control the Klipper host software. +control the Kalico host software. ## Enabling the API socket @@ -14,10 +14,10 @@ started with the `-a` parameter. For example: 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. +Kalico. See the [Moonraker](https://github.com/Arksine/moonraker) project for -a popular tool that can forward HTTP requests to Klipper's API Server +a popular tool that can forward HTTP requests to Kalico's API Server Unix Domain Socket. ## Request format @@ -28,16 +28,16 @@ terminated by an ASCII 0x03 character: <0x03><0x03>... ``` -Klipper contains a `scripts/whconsole.py` tool that can perform the +Kalico contains a `scripts/whconsole.py` tool that can perform the above message framing. For example: ``` ~/klipper/scripts/whconsole.py /tmp/klippy_uds ``` This tool can read a series of JSON commands from stdin, send them to -Klipper, and report the results. The tool expects each JSON command to +Kalico, and report the results. The tool expects each JSON command to be on a single line, and it will automatically append the 0x03 -terminator when transmitting a request. (The Klipper API server does +terminator when transmitting a request. (The Kalico API server does not have a newline requirement.) ## API Protocol @@ -63,17 +63,17 @@ term "dictionary" to describe a "JSON object" - a mapping of key/value pairs contained within `{}`.) The request dictionary must contain a "method" parameter that is the -string name of an available Klipper "endpoint". +string name of an available Kalico "endpoint". The request dictionary may contain a "params" parameter which must be of a dictionary type. The "params" provide additional parameter -information to the Klipper "endpoint" handling the request. Its +information to the Kalico "endpoint" handling the request. Its content is specific to the "endpoint". The request dictionary may contain an "id" parameter which may be of -any JSON type. If "id" is present then Klipper will respond to the +any JSON type. If "id" is present then Kalico will respond to the request with a response message containing that "id". If "id" is -omitted (or set to a JSON "null" value) then Klipper will not provide +omitted (or set to a JSON "null" value) then Kalico will not provide any response to the request. A response message is a JSON dictionary containing "id" and "result". The "result" is always a dictionary - its contents are specific to the "endpoint" handling the request. @@ -87,7 +87,7 @@ might result in an error response such as: `{"id": 123, "error": {"message": "Must home axis first: 200.000 0.000 0.000 [0.000]", "error": "WebRequestError"}}` -Klipper will always start processing requests in the order that they +Kalico will always start processing requests in the order that they are received. However, some request may not complete immediately, which could cause the associated response to be sent out of order with respect to responses from other requests. A JSON request will never @@ -95,7 +95,7 @@ pause the processing of future JSON requests. ## Subscriptions -Some Klipper "endpoint" requests allow one to "subscribe" to future +Some Kalico "endpoint" requests allow one to "subscribe" to future asynchronous update messages. For example: @@ -107,7 +107,7 @@ may initially respond with: `{"id": 123, "result": {}}` -and cause Klipper to send future messages similar to: +and cause Kalico to send future messages similar to: `{"params": {"response": "ok B:22.8 /0.0 T0:22.4 /0.0"}, "key": 345}` @@ -115,14 +115,14 @@ A subscription request accepts a "response_template" dictionary in the "params" field of the request. That "response_template" dictionary is used as a template for future asynchronous messages - it may contain arbitrary key/value pairs. When sending these future asynchronous -messages, Klipper will add a "params" field containing a dictionary +messages, Kalico will add a "params" field containing a dictionary 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" -By convention, Klipper "endpoints" are of the form +By convention, Kalico "endpoints" are of the form `/`. When making a request to an "endpoint", the full name must be set in the "method" parameter of the request dictionary (eg, `{"method"="gcode/restart"}`). @@ -130,19 +130,19 @@ dictionary (eg, `{"method"="gcode/restart"}`). ### info The "info" endpoint is used to obtain system and version information -from Klipper. It is also used to provide the client's version -information to Klipper. For example: +from Kalico. It is also used to provide the client's version +information to Kalico. For example: `{"id": 123, "method": "info", "params": { "client_info": { "version": "v1"}}}` If present, the "client_info" parameter must be a dictionary, but that dictionary may have arbitrary contents. Clients are encouraged to provide the name of the client and its software version when first -connecting to the Klipper API server. +connecting to the Kalico API server. ### emergency_stop -The "emergency_stop" endpoint is used to instruct Klipper to +The "emergency_stop" endpoint is used to instruct Kalico to transition to a "shutdown" state. It behaves similarly to the G-Code `M112` command. For example: `{"id": 123, "method": "emergency_stop"}` @@ -150,7 +150,7 @@ transition to a "shutdown" state. It behaves similarly to the G-Code ### register_remote_method This endpoint allows clients to register methods that can be called -from klipper. It will return an empty object upon success. +from Kalico. It will return an empty object upon success. For example: `{"id": 123, "method": "register_remote_method", @@ -159,7 +159,7 @@ For example: will return: `{"id": 123, "result": {}}` -The remote method `paneldue_beep` may now be called from Klipper. Note +The remote method `paneldue_beep` may now be called from KliKalicopper. Note that if the method takes parameters they should be provided as keyword arguments. Below is an example of how it may called from a gcode_macro: ``` @@ -168,7 +168,7 @@ gcode: {action_call_remote_method("paneldue_beep", frequency=300, duration=1.0)} ``` -When the PANELDUE_BEEP gcode macro is executed, Klipper would send something +When the PANELDUE_BEEP gcode macro is executed, Kalico would send something like the following over the socket: `{"action": "run_paneldue_beep", "params": {"frequency": 300, "duration": 1.0}}` @@ -271,7 +271,7 @@ after any pending G-Code commands complete. ### gcode/subscribe_output This endpoint is used to subscribe to G-Code terminal messages that -are generated by Klipper. For example: +are generated by Kalico. For example: `{"id": 123, "method": "gcode/subscribe_output", "params": {"response_template":{}}}` might later produce asynchronous messages such as: @@ -280,14 +280,14 @@ might later produce asynchronous messages such as: This endpoint is intended to support human interaction via a "terminal window" interface. Parsing content from the G-Code terminal output is discouraged. Use the "objects/subscribe" endpoint to obtain updates on -Klipper's state. +Kalico's state. ### motion_report/dump_stepper -This endpoint is used to subscribe to Klipper's internal stepper +This endpoint is used to subscribe to Kalico's internal stepper queue_step command stream for a stepper. Obtaining these low-level motion updates may be useful for diagnostic and debugging -purposes. Using this endpoint may increase Klipper's system load. +purposes. Using this endpoint may increase Kalico's system load. A request may look like: `{"id": 123, "method":"motion_report/dump_stepper", @@ -306,10 +306,10 @@ the fields found in later "data" responses. ### motion_report/dump_trapq -This endpoint is used to subscribe to Klipper's internal "trapezoid +This endpoint is used to subscribe to Kalico's internal "trapezoid motion queue". Obtaining these low-level motion updates may be useful for diagnostic and debugging purposes. Using this endpoint may -increase Klipper's system load. +increase Kalico's system load. A request may look like: `{"id": 123, "method": "motion_report/dump_trapq", "params": @@ -329,7 +329,7 @@ the fields found in later "data" responses. This endpoint is used to subscribe to ADXL345 accelerometer data. Obtaining these low-level motion updates may be useful for diagnostic -and debugging purposes. Using this endpoint may increase Klipper's +and debugging purposes. Using this endpoint may increase Kalico's system load. A request may look like: @@ -350,7 +350,7 @@ the fields found in later "data" responses. This endpoint is used to subscribe to [angle sensor data](Config_Reference.md#angle). Obtaining these low-level motion updates may be useful for diagnostic and debugging -purposes. Using this endpoint may increase Klipper's system load. +purposes. Using this endpoint may increase Kalico's system load. A request may look like: `{"id": 123, "method":"angle/dump_angle", @@ -368,7 +368,7 @@ the fields found in later "data" responses. This endpoint is used to subscribe to raw HX711 and HX717 ADC data. Obtaining these low-level ADC updates may be useful for diagnostic -and debugging purposes. Using this endpoint may increase Klipper's +and debugging purposes. Using this endpoint may increase Kalico's system load. A request may look like: @@ -384,7 +384,7 @@ and might later produce asynchronous messages such as: This endpoint is used to subscribe to raw ADS1220 ADC data. Obtaining these low-level ADC updates may be useful for diagnostic -and debugging purposes. Using this endpoint may increase Klipper's +and debugging purposes. Using this endpoint may increase Kalico's system load. A request may look like: diff --git a/docs/Axis_Twist_Compensation.md b/docs/Axis_Twist_Compensation.md index 0017a2279..5aeef9de4 100644 --- a/docs/Axis_Twist_Compensation.md +++ b/docs/Axis_Twist_Compensation.md @@ -35,8 +35,7 @@ points along the bed [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 +5. Perform a test print, followed by any fine-tuning as desired > **Tip:** Bed temperature and nozzle temperature and size do not seem to have > an influence to the calibration process. diff --git a/docs/BLTouch.md b/docs/BLTouch.md index 9d6a7983e..7a2af3edf 100644 --- a/docs/BLTouch.md +++ b/docs/BLTouch.md @@ -106,7 +106,7 @@ commands to achieve this. ## BL-Touch "clones" -Many BL-Touch "clone" devices work correctly with Klipper using the +Many BL-Touch "clone" devices work correctly with Kalico using the default configuration. However, some "clone" devices may not support the `QUERY_PROBE` command and some "clone" devices may require configuration of `pin_up_reports_not_triggered` or @@ -124,23 +124,23 @@ possible to perform probing and homing with these devices. On these devices the `QUERY_PROBE` command during the [initial tests](#initial-tests) will not succeed, however the subsequent `G28` (or `PROBE`) test does succeed. It may be possible to -use these "clone" devices with Klipper if one does not utilize the +use these "clone" devices with Kalico if one does not utilize the `QUERY_PROBE` command and one does not enable the `probe_with_touch_mode` feature. -Some "clone" devices are unable to perform Klipper's internal sensor +Some "clone" devices are unable to perform Kalico's internal sensor verification test. On these devices, attempts to home or probe can -result in Klipper reporting a "BLTouch failed to verify sensor state" +result in Kalico reporting a "BLTouch failed to verify sensor state" error. If this occurs, then manually run the steps to confirm the sensor pin is working as described in the [initial tests section](#initial-tests). If the `QUERY_PROBE` commands in that test always produce the expected results and "BLTouch failed to verify sensor state" errors still occur, then it may be necessary -to set `pin_up_touch_mode_reports_triggered` to False in the Klipper +to set `pin_up_touch_mode_reports_triggered` to False in the Kalico config file. A rare number of old "clone" devices are unable to report when they -have successfully raised their probe. On these devices Klipper will +have successfully raised their probe. On these devices Kalico will report a "BLTouch failed to raise probe" error after every home or probe attempt. One can test for these devices - move the head far from the bed, run `BLTOUCH_DEBUG COMMAND=pin_down`, verify the pin has @@ -149,7 +149,7 @@ open", run `BLTOUCH_DEBUG COMMAND=pin_up`, verify the pin has moved up, and run `QUERY_PROBE`. If the pin remains up, the device does not enter an error state, and the first query reports "probe: open" while the second query reports "probe: TRIGGERED" then it indicates that -`pin_up_reports_not_triggered` should be set to False in the Klipper +`pin_up_reports_not_triggered` should be set to False in the Kalico config file. ## BL-Touch v3 @@ -168,7 +168,7 @@ workaround is to set `probe_with_touch_mode: True` in the config file. The BL-Touch v3.1 may incorrectly enter an error state after a successful probe attempt. The symptoms are an occasional flashing light on the BL-Touch v3.1 that lasts for a couple of seconds after it -successfully contacts the bed. Klipper should clear this error +successfully contacts the bed. Kalico should clear this error automatically and it is generally harmless. However, one may set `probe_with_touch_mode` in the config file to avoid this issue. @@ -181,15 +181,15 @@ this value (use the `PROBE_ACCURACY` command to test). ## Multi-probing without stowing -By default, Klipper will deploy the probe at the start of each probe +By default, Kalico will deploy the probe at the start of each probe attempt and then stow the probe afterwards. This repetitive deploying and stowing of the probe may increase the total time of calibration -sequences that involve many probe measurements. Klipper supports +sequences that involve many probe measurements. Kalico supports leaving the probe deployed between consecutive probes, which can reduce the total time of probing. This mode is enabled by configuring `stow_on_each_sample` to False in the config file. -Important! Setting `stow_on_each_sample` to False can lead to Klipper +Important! Setting `stow_on_each_sample` to False can lead to Kalico making horizontal toolhead movements while the probe is deployed. Be sure to verify all probing operations have sufficient Z clearance prior to setting this value to False. If there is insufficient diff --git a/docs/Beaglebone.md b/docs/Beaglebone.md index 1b0fc0a35..34db5bc2e 100644 --- a/docs/Beaglebone.md +++ b/docs/Beaglebone.md @@ -1,6 +1,6 @@ # Beaglebone -This document describes the process of running Klipper on a Beaglebone +This document describes the process of running Kalico on a Beaglebone PRU. ## Building an OS image @@ -14,7 +14,7 @@ the instructions from the above link. Then ssh into the Beaglebone machine (`ssh debian@beaglebone` -- password is `temppwd`). -Before start installing Klipper you need to free-up additional space. +Before start installing Kalico you need to free-up additional space. there are 3 options to do that: 1. remove some BeagleBone "Demo" resources 2. if you did boot from SD-Card, and it's bigger than 4Gb - you can expand @@ -34,27 +34,27 @@ sudo resize2fs /dev/mmcblk0p1 ``` -Install Klipper by running the following +Install Kalico by running the following commands: ``` -git clone https://github.com/DangerKlippers/danger-klipper +git clone https://github.com/KalicoCrew/kalico klipper ./klipper/scripts/install-beaglebone.sh ``` -After installing Klipper you need to decide what kind of deployment do you need, +After installing Kalico you need to decide what kind of deployment do you need, but take a note that BeagleBone is 3.3v based hardware and in most cases you can't directly connect pins to 5v or 12v based hardware without conversion boards. -As Klipper have multimodule architecture on BeagleBone you can achieve many different use cases, +As Kalico have multimodule architecture on BeagleBone you can achieve many different use cases, but general ones are following: -Use case 1: Use BeagleBone only as a host system to run Klipper and additional software +Use case 1: Use BeagleBone only as a host system to run Kalico and additional software like OctoPrint/Fluidd + Moonraker/... and this configuration will be driving external micro-controllers via serial/usb/canbus connections. Use case 2: Use BeagleBone with extension board (cape) like CRAMPS board. -in this configuration BeagleBone will host Klipper + additional software, and +in this configuration BeagleBone will host Kalico + additional software, and it will drive extension board with BeagleBone PRU cores (2 additional cores 200Mh, 32Bit). Use case 3: It's same as "Use case 1" but additionally you want to drive @@ -132,7 +132,7 @@ pkg:[bb-wl18xx-firmware]:[1.20230414.0-0~bullseye+20230414] ``` -To compile the Klipper micro-controller code, start by configuring it for the "Beaglebone PRU", +To compile the Kalico micro-controller code, start by configuring it for the "Beaglebone PRU", for "BeagleBone Black" additionally disable options "Support GPIO Bit-banging devices" and disable "Support LCD devices" inside the "Optional features" because they will not fit in 8Kb PRU firmware memory, then exit and save config: @@ -203,9 +203,9 @@ you can't use them for stepper control. ## Remaining configuration -Complete the installation by configuring Klipper +Complete the installation by configuring Kalico following the instructions in -the main [Installation](Installation.md#configuring-octoprint-to-use-klipper) document. +the main [Installation](Installation.md) document. ## Printing on the Beaglebone @@ -214,7 +214,7 @@ OctoPrint well. Print stalls have been known to occur on complex prints (the printer may move faster than OctoPrint can send movement commands). If this occurs, consider using the "virtual_sdcard" feature (see [Config Reference](Config_Reference.md#virtual_sdcard) for -details) to print directly from Klipper +details) to print directly from Kalico and disable any DEBUG or VERBOSE logging options if you did enable them. diff --git a/docs/Bed_Level.md b/docs/Bed_Level.md index bff83399a..526d7fe48 100644 --- a/docs/Bed_Level.md +++ b/docs/Bed_Level.md @@ -4,7 +4,7 @@ Bed leveling (sometimes also referred to as "bed tramming") is critical to getting high quality prints. If a bed is not properly "leveled" it can lead to poor bed adhesion, "warping", and subtle problems throughout the print. This document serves as a guide to -performing bed leveling in Klipper. +performing bed leveling in Kalico. It's important to understand the goal of bed leveling. If the printer is commanded to a position `X0 Y0 Z10` during a print, then the goal @@ -106,7 +106,7 @@ it is easily accounted for later in the calibration process. **Use an automated tool to determine precise Z heights!** -Klipper has several helper scripts available (eg, MANUAL_PROBE, +Kalico has several helper scripts available (eg, MANUAL_PROBE, Z_ENDSTOP_CALIBRATE, PROBE_CALIBRATE, DELTA_CALIBRATE). See the documents [described above](#choose-the-appropriate-calibration-mechanism) to diff --git a/docs/Bed_Mesh.md b/docs/Bed_Mesh.md index 1538f6257..4bd297fd0 100644 --- a/docs/Bed_Mesh.md +++ b/docs/Bed_Mesh.md @@ -269,7 +269,7 @@ 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) +[Z_ENDSTOP_CALIBRATE](./Manual_Level.md#calibrating-a-z-endstop) paper test is performed. The bed_mesh module provides the `zero_reference_position` option for specifying this coordinate: diff --git a/docs/Benchmarks.md b/docs/Benchmarks.md index 6e96593a9..0fde84103 100644 --- a/docs/Benchmarks.md +++ b/docs/Benchmarks.md @@ -1,10 +1,10 @@ # Benchmarks -This document describes Klipper benchmarks. +This document describes Kalico benchmarks. ## Micro-controller Benchmarks -This section describes the mechanism used to generate the Klipper +This section describes the mechanism used to generate the Kalico micro-controller step rate benchmarks. The primary goal of the benchmarks is to provide a consistent @@ -15,7 +15,7 @@ platforms. The step rate benchmark is designed to find the maximum stepping rate that the hardware and software can reach. This benchmark stepping rate -is not achievable in day-to-day use as Klipper needs to perform other +is not achievable in day-to-day use as Kalico needs to perform other tasks (eg, mcu/host communication, temperature reading, endstop checking) in any real-world usage. diff --git a/docs/Bleeding_Edge.md b/docs/Bleeding_Edge.md index 0afff99ae..f6f8a0374 100644 --- a/docs/Bleeding_Edge.md +++ b/docs/Bleeding_Edge.md @@ -1,7 +1,6 @@ # Bleeding Edge Features Documentation -The following are experimental features found in the bleeding edge branch of danger klipper and should be used at your own caution. The support for these features is limited and your experience may vary! If you do use the features and find them useful, discover bugs, or have improvements please use the klipper discourse forums or discord to discuss your findings. -https://github.com/dmbutyugin/klipper/commits/advanced-features +The following are experimental features found in the bleeding edge branch of Kalico and should be used at your own caution. The support for these features is limited and your experience may vary! If you do use the features and find them useful, discover bugs, or have improvements please use the Kalico [Discord server](Contact.md#discord) to discuss your findings. Refer to the [Bleeding Edge Configuration Reference](Config_Reference_Bleeding_Edge.md) for details on printer configurations for these features. diff --git a/docs/Bootloader_Entry.md b/docs/Bootloader_Entry.md index ec27baad4..3397264ec 100644 --- a/docs/Bootloader_Entry.md +++ b/docs/Bootloader_Entry.md @@ -1,6 +1,6 @@ # Bootloader Entry -Klipper can be instructed to reboot into a [Bootloader](Bootloaders.md) in one +Kalico can be instructed to reboot into a [Bootloader](Bootloaders.md) in one of the following ways: ## Requesting the bootloader @@ -99,17 +99,17 @@ for information on finding the CAN UUID of your devices. ## Entering the bootloader -When klipper receives one of the above bootloader requests: +When Kalico receives one of the above bootloader requests: -If Katapult (formerly known as CANBoot) is available, klipper will request that +If Katapult (formerly known as CANBoot) is available, Kalico 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 +If Katapult is not available, Kalico 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 +In short, Kalico will reboot to Katapult if installed, then a hardware specific bootloader if available. For details about the specific bootloaders on various platforms see diff --git a/docs/Bootloaders.md b/docs/Bootloaders.md index 56a810955..0b0da9b6b 100644 --- a/docs/Bootloaders.md +++ b/docs/Bootloaders.md @@ -1,11 +1,11 @@ # Bootloaders This document provides information on common bootloaders found on -micro-controllers that Klipper supports. +micro-controllers that Kalico supports. The bootloader is 3rd-party software that runs on the micro-controller when it is first powered on. It is typically used to flash a new -application (eg, Klipper) to the micro-controller without requiring +application (eg, Kalico) to the micro-controller without requiring specialized hardware. Unfortunately, there is no industry wide standard for flashing a micro-controller, nor is there a standard bootloader that works across all micro-controllers. Worse, it is @@ -22,7 +22,7 @@ bootloader to flash an application where possible. This document attempts to describe common bootloaders, the steps needed to flash a bootloader, and the steps needed to flash an application. This document is not an authoritative reference; it is -intended as a collection of useful information that the Klipper +intended as a collection of useful information that the Kalico developers have accumulated. ## AVR micro-controllers @@ -221,7 +221,7 @@ 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. +Obtain a program; for instance, Kalico can be built for this chip. Flash with OpenOCD commands similar to: ``` at91samd chip-erase @@ -414,11 +414,11 @@ If the bootloader is running you can flash with something like: ``` ~/klipper/lib/hidflash/hid-flash ~/klipper/out/klipper.bin ``` -alternatively, you can use `make flash` to flash klipper directly: +alternatively, you can use `make flash` to flash Kalico directly: ``` make flash FLASH_DEVICE=1209:BEBA ``` -OR if klipper has been previously flashed: +OR if Kalico has been previously flashed: ``` make flash FLASH_DEVICE=/dev/ttyACM0 ``` @@ -455,8 +455,8 @@ onto which the klipper.bin file can be copied. ### STM32F103/STM32F0x2 with CanBoot bootloader The [CanBoot](https://github.com/Arksine/CanBoot) bootloader provides an option -for uploading Klipper firmware over the CANBUS. The bootloader itself is -derived from Klipper's source code. Currently CanBoot supports the STM32F103, +for uploading Kalico firmware over the CANBUS. The bootloader itself is +derived from Kalico's source code. Currently CanBoot supports the STM32F103, STM32F042, and STM32F072 models. It is recommended to use a ST-Link Programmer to flash CanBoot, however it @@ -471,7 +471,7 @@ is present and enter the bootloader. If this doesn't occur it is possible to enter the bootloader by pressing the reset button twice in succession. The `flash_can.py` utility supplied in the `lib/canboot` folder may be used to -upload Klipper firmware. The device UUID is necessary to flash. If you do not +upload Kalico firmware. The device UUID is necessary to flash. If you do not have a UUID it is possible to query nodes currently running the bootloader: ``` python3 flash_can.py -q @@ -488,7 +488,7 @@ Where `aabbccddeeff` is replaced by your UUID. Note that the `-i` and `-f` options may be omitted, they default to `can0` and `~/klipper/out/klipper.bin` respectively. -When building Klipper for use with CanBoot, select the 8 KiB Bootloader option. +When building Kalico for use with CanBoot, select the 8 KiB Bootloader option. ## STM32F4 micro-controllers (SKR Pro 1.1) @@ -636,7 +636,7 @@ command.) ### OpenOCD and gdb -It is possible to use OpenOCD with gdb to debug Klipper. The following +It is possible to use OpenOCD with gdb to debug Kalico. The following commands assume one is running gdb on a desktop class machine. Add the following to the OpenOCD config file: diff --git a/docs/CANBUS.md b/docs/CANBUS.md index 226b73497..a7ad34c45 100644 --- a/docs/CANBUS.md +++ b/docs/CANBUS.md @@ -1,10 +1,10 @@ # CANBUS -This document describes Klipper's CAN bus support. +This document describes Kalico's CAN bus support. ## Device Hardware -Klipper currently supports CAN on stm32, SAME5x, and rp2040 chips. In +Kalico 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. @@ -20,7 +20,7 @@ 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 +adapters that can run Kalico directly (in its "USB to CAN bridge mode") or that run the [candlelight firmware](https://github.com/candle-usb/candleLight_fw). @@ -65,23 +65,23 @@ If CAN devices are detected the above command will report lines like the following: ``` Found canbus_uuid=11aa22bb33cc, Application: Klipper, Unassigned -Found canbus_uuid=11aa22bb33cc, Application: Danger-Klipper, Assigned: 77 +Found canbus_uuid=11aa22bb33cc, Application: Kalico, Assigned: 77 ``` Each device will have a unique identifier. In the above example, `11aa22bb33cc` is the micro-controller's "canbus_uuid". Note that the `canbus_query.py` tool will only report uninitialized -devices - if Klipper (or a similar tool) configures the device then it +devices - if Kalico (or a similar tool) configures the device then it will no longer appear in the list. -⚠️ Note that only devices flashed with a Danger-Klipper firmware will +⚠️ Note that only devices flashed with a Kalico firmware will respond while assigned a device node ID. Devices using a Klipper firmware will no longer appear in the list once configured -## Configuring Klipper +## Configuring Kalico -Update the Klipper [mcu configuration](Config_Reference.md#mcu) to use +Update the Kalico [mcu configuration](Config_Reference.md#mcu) to use the CAN bus to communicate with the device - for example: ``` [mcu my_can_mcu] @@ -91,21 +91,21 @@ canbus_uuid: 11aa22bb33cc ## USB to CAN bus bridge mode Some micro-controllers support selecting "USB to CAN bus bridge" mode -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 +during Kalico's "make menuconfig". This mode may allow one to use a +micro-controller as both a "USB to CAN bus adapter" and as a Kalico 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 +When Kalico uses this mode the micro-controller appears as a "USB CAN +bus adapter" under Linux. The "Kalico bridge mcu" itself will appear 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 +`canbus_query.py` and it must be configured like other CAN bus Kalico nodes. Some important notes when using this mode: * 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. + speed and CAN bus bit-timing options are ignored by Kalico. Currently, the CAN bus frequency is specified during "make menuconfig" and the bus speed specified in Linux is ignored. @@ -137,9 +137,9 @@ iface can0 can static * 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:` + be configured in Kalico'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). + configured in the printer.cfg as a [CAN node](#configuring-kalico). ## Tips for troubleshooting diff --git a/docs/CANBUS_Troubleshooting.md b/docs/CANBUS_Troubleshooting.md index de0deaf74..07b4e1e7c 100644 --- a/docs/CANBUS_Troubleshooting.md +++ b/docs/CANBUS_Troubleshooting.md @@ -1,7 +1,7 @@ # CANBUS Troubleshooting This document provides information on troubleshooting communication -issues when using [Klipper with CAN bus](CANBUS.md). +issues when using [Kalico with CAN bus](CANBUS.md). ## Verify CAN bus wiring @@ -26,7 +26,7 @@ intermittent communication errors. ## Check for incrementing bytes_invalid counter -The Klipper log file will report a `Stats` line once a second when the +The Kalico 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 @@ -54,24 +54,24 @@ part of a print. ## Use an appropriate txqueuelen setting -The Klipper code uses the Linux kernel to manage CAN bus traffic. By +The Kalico code uses the Linux kernel to manage CAN bus traffic. By default, the kernel will only queue 10 CAN transmit packets. It is recommended to [configure the can0 device](CANBUS.md#host-hardware) with a `txqueuelen 128` to increase that size. -If Klipper transmits a packet and Linux has filled all of its transmit +If Kalico transmits a packet and Linux has filled all of its transmit queue space then Linux will drop that packet and messages like the -following will appear in the Klipper log: +following will appear in the Kalico log: ``` Got error -1 in can write: (105)No buffer space available ``` -Klipper will automatically retransmit the lost messages as part of its +Kalico will automatically retransmit the lost messages as part of its normal application level message retransmit system. Thus, this log message is a warning and it does not indicate an unrecoverable error. If a complete CAN bus failure occurs (such as a CAN wire break) then Linux will not be able to transmit any messages on the CAN bus and it -is common to find the above message in the Klipper log. In this case, +is common to find the above message in the Kalico log. In this case, the log message is a symptom of a larger problem (the inability to transmit any messages) and is not directly related to Linux `txqueuelen`. @@ -86,18 +86,18 @@ than 128. A CAN bus running at a frequency of 1000000 will typically take around 120us to transmit a CAN packet. Thus a queue of 128 packets is likely to take around 15-20ms to drain. A substantially larger queue could cause excessive spikes in message round-trip-time -which could lead to unrecoverable errors. Said another way, Klipper's +which could lead to unrecoverable errors. Said another way, Kalico's application retransmit system is more robust if it does not have to wait for Linux to drain an excessively large queue of possibly stale data. This is analogous to the problem of [bufferbloat](https://en.wikipedia.org/wiki/Bufferbloat) on internet routers. -Under normal circumstances Klipper may utilize ~25 queue slots per +Under normal circumstances Kalico may utilize ~25 queue slots per MCU - typically only utilizing more slots during retransmits. -(Specifically, the Klipper host may transmit up to 192 bytes to each -Klipper MCU before receiving an acknowledgment from that MCU.) If a -single CAN bus has 5 or more Klipper MCUs on it, then it might be +(Specifically, the Kalico host may transmit up to 192 bytes to each +Kalico MCU before receiving an acknowledgment from that MCU.) If a +single CAN bus has 5 or more Kalico MCUs on it, then it might be necessary to increase the `txqueuelen` above the recommended value of 128. However, as above, care should be taken when selecting a new value to avoid excessive round-trip-time latency. @@ -123,16 +123,16 @@ 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. +to see each raw CAN bus message that was sent and received by Kalico. 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). +low-level knowledge of Kalico's [CANBUS protocol](CANBUS_protocol.md) +and Kalico's [MCU commands](MCU_Commands.md). -### Parsing Klipper messages in a candump log +### Parsing Kalico messages in a candump log -One may use the `parsecandump.py` tool to parse the low-level Klipper +One may use the `parsecandump.py` tool to parse the low-level Kalico micro-controller messages contained in a candump log. Using this tool -is an advanced topic that requires knowledge of Klipper +is an advanced topic that requires knowledge of Kalico [MCU commands](MCU_Commands.md). For example: ``` ./scripts/parsecandump.py mycanlog 108 ./out/klipper.dict @@ -141,11 +141,11 @@ is an advanced topic that requires knowledge of Klipper 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. +Kalico 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 +hexadecimal number. The id `108` is assigned by Kalico 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. diff --git a/docs/CANBUS_protocol.md b/docs/CANBUS_protocol.md index 8b6cc74fe..63221debd 100644 --- a/docs/CANBUS_protocol.md +++ b/docs/CANBUS_protocol.md @@ -1,19 +1,19 @@ # CANBUS protocol -This document describes the protocol Klipper uses to communicate over +This document describes the protocol Kalico uses to communicate over [CAN bus](https://en.wikipedia.org/wiki/CAN_bus). See -[CANBUS.md](CANBUS.md) for information on configuring Klipper with CAN +[CANBUS.md](CANBUS.md) for information on configuring Kalico with CAN bus. ## Micro-controller id assignment -Klipper uses only CAN 2.0A standard size CAN bus packets, which are +Kalico uses only CAN 2.0A standard size CAN bus packets, which are limited to 8 data bytes and an 11-bit CAN bus identifier. In order to support efficient communication, each micro-controller is assigned at run-time a unique 1-byte CAN bus nodeid (`canbus_nodeid`) for general -Klipper command and response traffic. Klipper command messages going +Kalico command and response traffic. Kalico command messages going from host to micro-controller use the CAN bus id of `canbus_nodeid * -2 + 256`, while Klipper response messages from micro-controller to +2 + 256`, while Kalico response messages from micro-controller to host use `canbus_nodeid * 2 + 256 + 1`. Each micro-controller has a factory assigned unique chip identifier @@ -60,7 +60,7 @@ 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 a complete [mcu protocol message](Protocol.md) is found its contents are parsed and processed. The data is treated as a byte stream - there -is no requirement for the start of a Klipper message block to align +is no requirement for the start of a Kalico message block to align with the start of a CAN bus packet. Similarly, mcu protocol message responses are sent from diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 12eec5432..5c53dd611 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -1,17 +1,17 @@ -# Contributing to Danger-Klipper +# Contributing to Kalico -Thank you for contributing to Danger-Klipper! This document describes the -process for contributing changes to Danger-Klipper. +Thank you for contributing to Kalico! This document describes the +process for contributing changes to Kalico. Please see the [contact page](Contact.md) for information on reporting an issue or for details on contacting the developers. ## Overview of Contribution Process -Contributions to Danger-Klipper generally follow a high-level process: +Contributions to Kalico generally follow a high-level process: 1. A submitter starts by creating a - [GitHub Pull Request](https://github.com/DangerKlippers/danger-klipper/pulls) + [GitHub Pull Request](https://github.com/KalicoCrew/kalico/pulls) when a submission is ready for widespread deployment. 2. When a [reviewer](#reviewers) is available to [review](#what-to-expect-in-a-review) the submission, they will @@ -20,18 +20,18 @@ Contributions to Danger-Klipper generally follow a high-level process: follows documented guidelines. 3. After a successful review, the reviewer will "approve the review" on GitHub and a [maintainer](#reviewers) will commit the change to - the Danger-Klipper master branch. + the Kalico `main` branch. When working on enhancements, consider starting (or contributing to) a -thread on [#danger-klipper Discord channel](Contact.md). +thread on [Kalico Discord server](Contact.md#discord). An ongoing discussion on the forum can improve visibility of development work and may attract others interested in testing new work. ## What to expect in a review -Contributions to Danger-Klipper are reviewed before merging. The primary goal +Contributions to Kalico are reviewed before merging. The primary goal of the review process is to check for defects and to check that the -submission follows guidelines specified in the Danger-Klipper documentation. +submission follows guidelines specified in the Kalico documentation. It is understood that there are many ways to accomplish a task; it is not the intent of the review to discuss the "best" implementation. @@ -53,10 +53,10 @@ Common things a reviewer will look for: of printers within a few weeks of acceptance. Quality of submissions is therefore considered a priority. - The main [DangerKlippers/danger-klipper](https://github.com/DangerKlippers/danger-klipper) + The main [KalicoCrew/kalico](https://github.com/KalicoCrew/kalico) GitHub repository might accept experimental work, but we encourage submitters should perform experimentation, debugging, and testing in - their own repositories. The [#danger-klipper Discord channel](Contact.md) + their own repositories. The [Kalico Discord server](Contact.md#discord) is a good place to raise awareness of new work and to find users interested in providing real-world feedback. @@ -87,7 +87,7 @@ Common things a reviewer will look for: cases this will be obvious to both the submitter and the reviewer, and it is not explicitly stated during a review. - Submissions to the master Danger-Klipper branch are expected to have a + Submissions to the `main` Kalico branch are expected to have a noteworthy target audience. As a general "rule of thumb", submissions should target a user base of at least a 100 real-world users. @@ -107,9 +107,9 @@ Common things a reviewer will look for: ...", or for example "print time of real-world object X on a Foomatic X900 printer went from 4 hours to 3.5 hours". It is understood that testing of this type can take significant time and - effort. Some of Klipper's most notable features took months of + effort. Some of Kalico's most notable features took months of discussion, rework, testing, and documentation prior to being - merged into the master branch. + merged into the `main` branch. All new modules, config options, commands, command parameters, and documents should have "high impact". We do not want to burden users @@ -139,7 +139,7 @@ Common things a reviewer will look for: to that file is discouraged. Code taken from 3rd party sources must be compatible with the - Klipper license (GNU GPLv3). Large 3rd party code additions should + Kalico license (GNU GPLv3). Large 3rd party code additions should be added to the `lib/` directory (and follow the format described in [lib/README](../lib/README)). @@ -148,14 +148,14 @@ Common things a reviewer will look for: real name. It indicates the submitter agrees with the [developer certificate of origin](developer-certificate-of-origin). -4. Does the submission follow guidelines specified in the Klipper +4. Does the submission follow guidelines specified in the Kalico documentation? In particular, code should follow the guidelines in [Code_Overview.md](Code_Overview.md) and config files should follow the guidelines in [Example_Configs.md](Example_Configs.md). -5. Is the Klipper documentation updated to reflect new changes? +5. Is the Kalico documentation updated to reflect new changes? At a minimum, the reference documentation must be updated with corresponding changes to the code: @@ -173,7 +173,7 @@ Common things a reviewer will look for: New documents should be added to [Overview.md](Overview.md) and be added to the website index - [docs/_klipper3d/mkdocs.yml](../docs/_klipper3d/mkdocs.yml). + [docs/_kalico/mkdocs.yml](../docs/_kalico/mkdocs.yml). 6. Are commits well formed, address a single topic per commit, and independent? @@ -182,9 +182,9 @@ Common things a reviewer will look for: [preferred format](#format-of-commit-messages). Commits must not have a merge conflict. New additions to the - Danger- master branch are always done via a "rebase" or "squash and + Kalico `main` branch are always done via a "rebase" or "squash and rebase". It is generally not necessary for submitters to re-merge - their submission on every update to the Danger-Klipper master repository. + their submission on every update to the Kalico `main` branch. However, if there is a merge conflict, then submitters are recommended to use `git rebase` to address the conflict. @@ -197,7 +197,7 @@ Common things a reviewer will look for: general, gratuitous whitespace changes are not accepted unless they are from the established "owner" of the code being modified. -Danger-Klipper implements a soft-strict "coding style guide" on the +Kalico implements a soft-strict "coding style guide" on the Python code. Modifications to existing code should follow the high-level code flow, code indentation style, and format of that existing code. @@ -244,7 +244,7 @@ good". ### Reviewers -The Danger-Klipper "reviewers" are: +The Kalico "reviewers" are: | Name | GitHub Id | Areas of interest | | ---------------------- | ----------------- | ----------------- | @@ -255,12 +255,13 @@ 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, and will take on reviews when they have time to. -The Danger-Klipper "maintainers" are: +The Kalico "maintainers" are: | Name | GitHub name | | ---------------------- | ----------------- | | Bea Nance | @bwnance | | Rogerio Goncalves | @rogerlz | +| Lasse Dalegaard | @dalegaard | ## Format of commit messages diff --git a/docs/Code_Overview.md b/docs/Code_Overview.md index a1c7960ad..280d60088 100644 --- a/docs/Code_Overview.md +++ b/docs/Code_Overview.md @@ -1,7 +1,7 @@ # Code overview This document describes the overall code layout and major code flow of -Klipper. +Kalico. ## Directory Layout @@ -164,7 +164,7 @@ provides further information on the mechanics of moves. stored in the Move() class and is in cartesian space in units of millimeters and seconds. -* Klipper uses an +* Kalico uses an [iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm) to generate the step times for each stepper. For efficiency reasons, the stepper pulse times are generated in C code. The moves are first @@ -236,7 +236,7 @@ The Klippy host code has a dynamic module loading capability. If a config section named "[my_module]" is found in the printer config file then the software will automatically attempt to load the python module klippy/extras/my_module.py . This module system is the preferred -method for adding new functionality to Klipper. +method for adding new functionality to Kalico. The easiest way to add a new module is to use an existing module as a reference - see **klippy/extras/servo.py** as an example. @@ -326,13 +326,13 @@ The following may also be useful: `self.speed = 2. * x` over `self.speed = 2 * x`. Consistent use of floating point values can avoid hard to debug quirks in Python type conversions. -* If submitting the module for inclusion in the main Klipper code, be +* If submitting the module for inclusion in the main Kalico code, be sure to place a copyright notice at the top of the module. See the existing modules for the preferred format. ## Adding new kinematics -This section provides some tips on adding support to Klipper for +This section provides some tips on adding support to Kalico for additional types of printer kinematics. This type of activity requires excellent understanding of the math formulas for the target kinematics. It also requires software development skills - though one @@ -371,7 +371,7 @@ Useful steps: ## Porting to a new micro-controller -This section provides some tips on porting Klipper's micro-controller +This section provides some tips on porting Kalico's micro-controller code to a new architecture. This type of activity requires good knowledge of embedded development and hands-on access to the target micro-controller. @@ -381,9 +381,9 @@ Useful steps: during the port. Common examples include "CMSIS" wrappers and manufacturer "HAL" libraries. All 3rd party code needs to be GNU GPLv3 compatible. The 3rd party code should be committed to the - Klipper lib/ directory. Update the lib/README file with information + Kalico lib/ directory. Update the lib/README file with information on where and when the library was obtained. It is preferable to - copy the code into the Klipper repository unchanged, but if any + copy the code into the Kalico repository unchanged, but if any changes are required then those changes should be listed explicitly in the lib/README file. 2. Create a new architecture sub-directory in the src/ directory and @@ -406,18 +406,18 @@ Useful steps: micro-controller with it. This tool translates the low-level micro-controller communication protocol to a human readable form. 5. Add support for timer dispatch from hardware interrupts. See - Klipper - [commit 970831ee](https://github.com/DangerKlippers/danger-klipper/commit/970831ee0d3b91897196e92270d98b2a3067427f) + Kalico + [commit 970831ee](https://github.com/KalicoCrew/kalico/commit/970831ee0d3b91897196e92270d98b2a3067427f) as an example of steps 1-5 done for the LPC176x architecture. -6. Bring up basic GPIO input and output support. See Klipper - [commit c78b9076](https://github.com/DangerKlippers/danger-klipper/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54) +6. Bring up basic GPIO input and output support. See Kalico + [commit c78b9076](https://github.com/KalicoCrew/kalico/commit/c78b90767f19c9e8510c3155b89fb7ad64ca3c54) as an example of this. -7. Bring up additional peripherals - for example see Klipper commit - [65613aed](https://github.com/DangerKlippers/danger-klipper/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27), - [c812a40a](https://github.com/DangerKlippers/danger-klipper/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5), +7. Bring up additional peripherals - for example see Kalico commit + [65613aed](https://github.com/KalicoCrew/kalico/commit/65613aeddfb9ef86905cb1dade9e773a02ef3c27), + [c812a40a](https://github.com/KalicoCrew/kalico/commit/c812a40a3782415e454b04bf7bd2158a6f0ec8b5), and - [c381d03a](https://github.com/DangerKlippers/danger-klipper/commit/c381d03aad5c3ee761169b7c7bced519cc14da29). -8. Create a sample Klipper config file in the config/ directory. Test + [c381d03a](https://github.com/KalicoCrew/kalico/commit/c381d03aad5c3ee761169b7c7bced519cc14da29). +8. Create a sample Kalico config file in the config/ directory. Test the micro-controller with the main klippy.py program. 9. Consider adding build test cases in the test/ directory. @@ -437,16 +437,16 @@ Additional coding tips: ## Coordinate Systems -Internally, Klipper primarily tracks the position of the toolhead in +Internally, Kalico primarily tracks the position of the toolhead in cartesian coordinates that are relative to the coordinate system -specified in the config file. That is, most of the Klipper code will +specified in the config file. That is, most of the Kalico code will never experience a change in coordinate systems. If the user makes a request to change the origin (eg, a `G92` command) then that effect is obtained by translating future commands to the primary coordinate system. However, in some cases it is useful to obtain the toolhead position in -some other coordinate system and Klipper has several tools to +some other coordinate system and Kalico has several tools to facilitate that. This can be seen by running the GET_POSITION command. For example: @@ -521,14 +521,14 @@ command can alter this value. ## Time -Fundamental to the operation of Klipper is the handling of clocks, -times, and timestamps. Klipper executes actions on the printer by +Fundamental to the operation of Kalico is the handling of clocks, +times, and timestamps. Kalico executes actions on the printer by scheduling events to occur in the near future. For example, to turn on a fan, the code might schedule a change to a GPIO pin in a 100ms. It is rare for the code to attempt to take an instantaneous action. Thus, -the handling of time within Klipper is critical to correct operation. +the handling of time within Kalico is critical to correct operation. -There are three types of times tracked internally in the Klipper host +There are three types of times tracked internally in the Kalico host software: * System time. The system time uses the system's monotonic clock - it is a floating point number stored as seconds and it is (generally) diff --git a/docs/Config_Changes.md b/docs/Config_Changes.md index d1593a26b..228874c95 100644 --- a/docs/Config_Changes.md +++ b/docs/Config_Changes.md @@ -2,7 +2,7 @@ This document covers recent software changes to the config file that are not backwards compatible. It is a good idea to review this -document when upgrading the Klipper software. +document when upgrading the Kalico software. All dates in this document are approximate. @@ -284,7 +284,7 @@ removed in the near future. Most users can replace a `default_parameter_NAME: VALUE` config option with a line like the following in the start of the macro: ` {% set NAME = params.NAME|default(VALUE)|float %}`. See the [Command Templates -document](Command_Templates.md#macro-parameters) for examples. +document](Command_Templates.md) for examples. 20210430: The SET_VELOCITY_LIMIT (and M204) command may now set a velocity, acceleration, and square_corner_velocity larger than the diff --git a/docs/Config_Reference.md b/docs/Config_Reference.md index b99e0808c..9ffa07330 100644 --- a/docs/Config_Reference.md +++ b/docs/Config_Reference.md @@ -1,19 +1,19 @@ # Configuration reference -This document is a reference for options available in the Klipper +This document is a reference for options available in the Kalico config file. The descriptions in this document are formatted so that it is possible to cut-and-paste them into a printer config file. See the [installation document](Installation.md) for information on setting up -Klipper and choosing an initial config file. +Kalico and choosing an initial config file. ## Micro-controller configuration ### Format of micro-controller pin names Many config options require the name of a micro-controller pin. -Klipper uses the hardware names for these pins - for example `PA4`. +Kalico uses the hardware names for these pins - for example `PA4`. Pin names may be preceded by `!` to indicate that a reverse polarity should be used (eg, trigger on low instead of high). @@ -55,7 +55,7 @@ serial: # is useful on Raspberry Pi boards with micro-controllers powered # over USB - it briefly disables power to all USB ports to # accomplish a micro-controller reset. The 'command' method involves -# sending a Klipper command to the micro-controller so that it can +# sending a Kalico command to the micro-controller so that it can # reset itself. The default is 'arduino' if the micro-controller # communicates over a serial port, 'command' otherwise. #is_non_critical: False @@ -80,13 +80,13 @@ pins such as "extra_mcu:ar9" may then be used elsewhere in the config ## ⚠️ Danger Options -A collection of DangerKlipper-specific system options +A collection of Kalico-specific system options ``` [danger_options] #error_on_unused_config_options: True # If an unused config option or section should cause an error -# if False, will warn but allow klipper to still run. +# if False, will warn but allow Kalico to still run. # The default is True. #allow_plugin_override: False # Allows modules in `plugins` to override modules of the same name in `extras` @@ -334,7 +334,7 @@ max_z_accel: ### ⚠️ Cartesian Kinematics with limits for X and Y axes Behaves exactly the as cartesian kinematics, but allows to set a velocity and -acceleration limit for X and Y axis. This also makes command [`SET_KINEMATICS_LIMIT`](./G-Codes.md#⚠️-set_kinematics_limit) available to sets these limits at runtime. +acceleration limit for X and Y axis. This also makes command [`SET_KINEMATICS_LIMIT`](./G-Codes.md#set_kinematics_limit) available to sets these limits at runtime. ``` @@ -933,7 +933,7 @@ anchor_z: ### None Kinematics It is possible to define a special "none" kinematics to disable -kinematic support in Klipper. This may be useful for controlling +kinematic support in Kalico. This may be useful for controlling devices that are not typical 3d-printers or for debugging purposes. ``` @@ -1050,7 +1050,7 @@ control: #pid_Ki: #pid_Kd: # The proportional (pid_Kp), integral (pid_Ki), and derivative -# (pid_Kd) settings for the PID feedback control system. Klipper +# (pid_Kd) settings for the PID feedback control system. Kalico # evaluates the PID settings with the following general formula: # heater_pwm = (Kp*error + Ki*integral(error) - Kd*derivative(error)) / 255 # Where "error" is "requested_temperature - measured_temperature" @@ -1788,7 +1788,7 @@ explicit idle_timeout config section to change the default settings. ### [virtual_sdcard] A virtual sdcard may be useful if the host machine is not fast enough -to run OctoPrint well. It allows the Klipper host software to directly +to run OctoPrint well. It allows the Kalico host software to directly print gcode files stored in a directory on the host using standard sdcard G-Code commands (eg, M24). @@ -1826,7 +1826,7 @@ file for a Marlin compatible M808 G-Code macro. ### ⚠ [force_move] -This module is enabled by default in DangerKlipper! +This module is enabled by default in Kalico! Support manually moving stepper motors for diagnostic purposes. Note, using this feature may place the printer in an invalid state - see the @@ -1909,7 +1909,7 @@ Support for gcode arc (G2/G3) commands. ### [respond] -This module is enabled by default in DangerKlipper! +This module is enabled by default in Kalico! Enable the "M118" and "RESPOND" extended [commands](G-Codes.md#respond). @@ -1932,13 +1932,13 @@ Enable the "M118" and "RESPOND" extended ### [exclude_object] -This module is enabled by default in DangerKlipper! +This module is enabled by default in Kalico! Enables support to exclude or cancel individual objects during the printing process. See the [exclude objects guide](Exclude_Object.md) and -[command reference](G-Codes.md#excludeobject) +[command reference](G-Codes.md#exclude_object) for additional information. See the [sample-macros.cfg](../config/sample-macros.cfg) file for a Marlin/RepRapFirmware compatible M486 G-Code macro. @@ -2164,7 +2164,7 @@ main printer config file. Wildcards may also be used (eg, This tool allows a single micro-controller pin to be defined multiple times in a config file without normal error checking. This is intended for diagnostic and debugging purposes. This section is not needed -where Klipper supports using the same pin multiple times, and using +where Kalico supports using the same pin multiple times, and using this override may cause confusing and unexpected results. ``` @@ -2196,7 +2196,7 @@ pin: # than the Z steppers then it enables "multi-mcu homing". This # parameter must be provided. #deactivate_on_each_sample: True -# This determines if Klipper should execute deactivation gcode +# This determines if Kalico should execute deactivation gcode # between each probe attempt when performing a multiple probe # sequence. The default is True. #x_offset: 0.0 @@ -2273,12 +2273,12 @@ control_pin: # The amount of time (in seconds) to wait for the BLTouch pin to # move up or down. The default is 0.680 seconds. #stow_on_each_sample: True -# This determines if Klipper should command the pin to move up +# This determines if Kalico should command the pin to move up # between each probe attempt when performing a multiple probe # sequence. Read the directions in docs/BLTouch.md before setting # this to False. The default is True. #probe_with_touch_mode: False -# If this is set to True then Klipper will probe with the device in +# If this is set to True then Kalico will probe with the device in # "touch_mode". The default is False (probing in "pin_down" mode). #pin_up_reports_not_triggered: True # Set if the BLTouch consistently reports the probe in a "not @@ -2537,8 +2537,7 @@ calibrate_y: 112.5 Automatic Z offset calibration. One may define this section if the printer is able to calibrate the nozzle's offset automatically. See -[Z-Calibration guide](Z_Calibration.md) and -[command reference](G-Codes.md#automatic-z-offset-calibration) for further +[Z-Calibration guide](Z_Calibration.md) for further information. ``` @@ -2950,7 +2949,7 @@ temperature sensors that are reported via the M105 command. ## Temperature sensors -Klipper includes definitions for many types of temperature sensors. +Kalico 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 `[heater_bed]` section). @@ -3473,7 +3472,7 @@ information. #pid_Ki: #pid_Kd: # The proportional (pid_Kp), integral (pid_Ki), and derivative -# (pid_Kd) settings for the PID feedback control system. Klipper +# (pid_Kd) settings for the PID feedback control system. Kalico # evaluates the PID settings with the following general formula: # fan_pwm = max_power - (Kp*e + Ki*integral(e) - Kd*derivative(e)) / 255 # Where "e" is "target_temperature - measured_temperature" and @@ -4476,7 +4475,7 @@ sense_resistor: #⚠️driver_s2vs_level: 6 # Short to Supply tolerance, from 4 to 15 #⚠️driver_s2g_level: 6 # Short to Ground tolerance, from 2 to 15 #⚠️driver_shortdelay: 0 # Short trigger delay, 0=750ns, 1=1500ns -#⚠️driver_short_filter: 1 +#⚠️driver_short_filter: 1 # Short filtering bandwidth. 0=100ns, 1=1us (Default), 2=2us, 3=3us #diag0_pin: #diag1_pin: @@ -5250,7 +5249,7 @@ adc2: # The approximate distance (in mm) between sensor readings. The # default is 10mm. #logging: False -# Out diameter to terminal and klipper.log can be turn on|of by +# Out diameter to terminal and klippy.log can be turn on|of by # command. #min_diameter: 1.0 # Minimal diameter for trigger virtual filament_switch_sensor. @@ -5521,7 +5520,7 @@ revision: # P9_41). host_mcu: # The name of the mcu config section that communicates with the -# Klipper "linux process" mcu instance. This parameter must be +# Kalico "linux process" mcu instance. This parameter must be # provided. #standstill_power_down: False # This parameter controls the CFG6_ENN line on all stepper @@ -5897,21 +5896,21 @@ 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 +Note that Kalico'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 +wires may result in Kalico raising a run-time error. Kalico's support for error recovery varies between each micro-controller type. 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 (_standard mode_, 100kbit/s). The Klipper "Linux" +Most Kalico micro-controller implementations only support an +`i2c_speed` of 100000 (_standard mode_, 100kbit/s). The Kalico "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 +and the `i2c_speed` parameter is otherwise ignored. The Kalico "RP2040" micro-controller and ATmega AVR family and some STM32 (F0, G0, G4, L4, F7, H7) support a rate of 400000 via the `i2c_speed` parameter. -All other Klipper micro-controllers use a +All other Kalico micro-controllers use a 100000 rate and ignore the `i2c_speed` parameter. ``` @@ -5934,7 +5933,7 @@ All other Klipper micro-controllers use a # 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 +# The Kalico implementation on most micro-controllers is hard-coded # to 100000 and changing this value has no effect. The default is # 100000. Linux, RP2040 and ATmega support 400000. ``` diff --git a/docs/Config_Reference_Bleeding_Edge.md b/docs/Config_Reference_Bleeding_Edge.md index 1579155c0..2561d688e 100644 --- a/docs/Config_Reference_Bleeding_Edge.md +++ b/docs/Config_Reference_Bleeding_Edge.md @@ -1,16 +1,16 @@ # Configuration reference for Bleeding Edge features -This document is a reference for options available in the Klipper +This document is a reference for options available in the Kalico config file for bleeding edge features. Refer to the [Bleeding Edge Documentation](Bleeding_Edge.md) for details on specific features. The descriptions in this document are formatted so that it is possible to cut-and-paste them into a printer config file. See the [installation document](Installation.md) for information on setting up -Klipper and choosing an initial config file. +Kalico and choosing an initial config file. ## High precision stepping and new stepcompress protocol -This feature is enabled during klipper firmware compile +This feature is enabled during Kalico firmware compile by selecting "High-precision stepping support" option in menuconfig. The firmware then needs to be flashed to all MCU(s) using this feature. diff --git a/docs/Config_checks.md b/docs/Config_checks.md index ba4a5015f..85c6ba540 100644 --- a/docs/Config_checks.md +++ b/docs/Config_checks.md @@ -1,11 +1,11 @@ # Configuration checks This document provides a list of steps to help confirm the pin -settings in the Klipper printer.cfg file. It is a good idea to run +settings in the Kalico printer.cfg file. It is a good idea to run through these steps after following the steps in the [installation document](Installation.md). -During this guide, it may be necessary to make changes to the Klipper +During this guide, it may be necessary to make changes to the Kalico config file. Be sure to issue a RESTART command after every change to the config file to ensure that the change takes effect (type "restart" in the Octoprint terminal tab and then click "Send"). It's also a good @@ -24,7 +24,7 @@ printer. If the temperatures are not accurate, review the ## Verify M112 Navigate to the command console and issue an M112 -command in the terminal box. This command requests Klipper to go into a +command in the terminal box. This command requests Kalico 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 @@ -124,7 +124,7 @@ troubleshooting tips in the previous section to confirm the ## Calibrate PID settings -Klipper supports +Kalico supports [PID control](https://en.wikipedia.org/wiki/PID_controller) for the extruder and bed heaters. In order to use this control mechanism, it is necessary to calibrate the PID settings on each printer (PID settings @@ -148,9 +148,9 @@ command is: `PID_CALIBRATE HEATER=heater_bed TARGET=60` ## Next steps This guide is intended to help with basic verification of pin settings -in the Klipper configuration file. Be sure to read the +in the Kalico configuration file. Be sure to read the [bed leveling](Bed_Level.md) guide. Also see the [Slicers](Slicers.md) -document for information on configuring a slicer with Klipper. +document for information on configuring a slicer with Kalico. After one has verified that basic printing works, it is a good idea to consider calibrating [pressure advance](Pressure_Advance.md). diff --git a/docs/Contact.md b/docs/Contact.md index 37ae099dd..f074070f0 100644 --- a/docs/Contact.md +++ b/docs/Contact.md @@ -1,26 +1,24 @@ # Contact -This document provides contact information for Danger-Klipper. -Danger-Klipper a community-maintained fork of the Klipper firmware. +This document provides contact information for Kalico. +Kalico a community-maintained fork of the Kalico firmware. -## Discord Chat +## Discord -Danger-Klipper has a channel in the ArmchairEngineering Discord Server at -[Armchair Heavy Industries](https://discord.gg/armchairengineeringsux) +Kalico has a dedicated Discord server where you can chat with the +developers and users of Kalico in real-time. -This server is run by a community of 3D printing enthusiasts and it is not dedicated to -discussions about Danger-Klipper. It allows users to chat with other users in -real-time. +You can join the server here: +[kalico.gg/discord](https://kalico.gg/discord) -## I have a question about Klipper +## I have a question about Kalico Many questions we receive are already answered in the -[Danger Klipper](Overview.md). Please be sure to to read the +[Overview](Overview.md). Please be sure to to read the documentation and follow the directions provided there. If you are interested in sharing your knowledge and experience with -other Danger-Klipper users then you can join the -[#danger-klipper Discord channel](#discord-chat). +other Kalico users then you can join the Kalico [Discord server](#discord) If you have a general question or are experiencing general printing problems, then also consider a general 3d-printing forum or a forum @@ -30,49 +28,51 @@ dedicated to the printer hardware. 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 -[#danger-klipper Discord channel](#discord-chat). -There is also discussions between collaborators over there. +feature, you can search for ongoing developments on the +[GitHub issues](https://github.com/KalicoCrew/kalico/issues) page and +[pull requests](https://github.com/KalicoCrew/kalico/pulls) page + +There also are discussions between collaborators on the Kalico [Discord server](#discord). ## Help! It doesn't work! If you are experiencing problems we recommend you carefully read the -[Danger Klipper](Overview.md) and double check that all steps +[Overview](Overview.md) and double check that all steps were followed. 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 +are not related to the Kalico software. If you do find a problem with the printer hardware then consider searching general 3d-printing forums or forums dedicated to the printer hardware. -## I found a bug in the Danger-Klipper software +## I found a bug in the Kalico software -Danger-Klipper is an open-source project and we appreciate when collaborators +Kalico is an open-source project and we appreciate when collaborators diagnose errors in the software. -Problems should be reported in the [#danger-klipper Discord channel](#discord-chat). +Problems should be reported on the [Discord server](#discord) There is important information that will be needed in order to fix a bug. Please follow these steps: 1. Make sure you are running unmodified code from - [https://github.com/DangerKlippers/danger-klipper](https://github.com/DangerKlippers/danger-klipper). + [https://github.com/KalicoCrew/kalico](https://github.com/KalicoCrew/kalico). If the code has been modified or is obtained from another source, then you should reproduce the problem on the unmodified code from - [https://github.com/DangerKlippers/danger-klipper](https://github.com/DangerKlippers/danger-klipper) + [https://github.com/KalicoCrew/kalico](https://github.com/KalicoCrew/kalico) prior to reporting. 2. If possible, run an `M112` command immediately after the - undesirable event occurs. This causes Klipper to go into a + undesirable event occurs. This causes Kalico 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 Danger-Klipper developers have +3. Obtain the Kalico log file from the event. The log file has been + engineered to answer common questions the Kalico developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions). - 1. Dedicated Klipper web interfaces have the ability to directly - obtain the Klipper log file. It's the easiest way to obtain the + 1. Dedicated Kalico web interfaces have the ability to directly + obtain the Kalico 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 @@ -92,19 +92,18 @@ bug. Please follow these steps: of the log. Only the full unmodified log file provides the necessary information. 4. It is a good idea to compress the log file with zip or gzip. -5. Open a new thread on the [#danger-klipper Discord channel](#discord-chat) - and provide a clear description of the problem. Other Danger-Klipper +5. Open a new thread on the [Discord server](#discord) + and provide a clear description of the problem. Other Kalico 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. + compressed Kalico log file should be attached to that topic. -## I am making changes that I'd like to include in Danger-Klipper +## I am making changes that I'd like to include in Kalico -Danger-Klipper is open-source software and we appreciate new contributions. +Kalico is open-source software and we appreciate new contributions. 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 -[#danger-klipper Discord channel](#discord-chat). +you have questions on the code then you can also ask on the [Discord server](#discord) diff --git a/docs/Danger_Features.md b/docs/Danger_Features.md index 818739465..3705b3d3c 100644 --- a/docs/Danger_Features.md +++ b/docs/Danger_Features.md @@ -1,27 +1,27 @@ -# Danger Klipper additions +# Kalico additions ## Changes to Klipper defaults -- [`[force_move]`](./Config_Reference.md#⚠-force_move) is enabled by default. Use `[force_move] enable_force_move: False` to disable it +- [`[force_move]`](./Config_Reference.md#force_move) is enabled by default. Use `[force_move] enable_force_move: False` to disable it - [`[respond]`](./Config_Reference.md#respond) is enabled by default. Use `[respond] enable_respond: False` to disable it - [`[exclude_object]`](./Config_Reference.md#exclude_object) is enabled by default. Use `[exclude_object] enable_exclude_object: False` to disable it ## Additional configuration options - [`[mcu] is_non_critical`](./Config_Reference.md#mcu) enables marking of an mcu as optional - it can be freely disconnected and connected at will. (useful for MCU-based accelerometer boards, mcu-based probes that shut down in hot chambers, etc...) -- [`[danger_options]`](./Config_Reference.md#danger-options) - New configuration options to adjust klipper values that were previously hidden -- Additional kinematics versions enabled per-axis acceleration, see [limited_cartesian](./Config_Reference.md#⚠️-cartesian-kinematics-with-limits-for-x-and-y-axes) and [limited_corexy](./Config_Reference.md#⚠️-corexy-kinematics-with-limits-for-x-and-y-axes) -- `--rotate-log-at-restart` can be added to your klipper start script or service to force log rotation every restart. +- [`[danger_options]`](./Config_Reference.md#danger-options) - New configuration options to adjust Kalico values that were previously hidden +- Additional kinematics versions enabled per-axis acceleration, see [limited_cartesian](./Config_Reference.md#cartesian-kinematics-with-limits-for-x-and-y-axes) and [limited_corexy](./Config_Reference.md#corexy-kinematics-with-limits-for-x-and-y-axes) +- `--rotate-log-at-restart` can be added to your Kalico start script or service to force log rotation every restart. - [`[virtual_sdcard] with_subdirs`](./Config_Reference.md#virtual_sdcard) enables scanning of subdirectories for .gcode files, for the menu and M20/M23 commands - [`[firmware_retraction] z_hop_height`](./Config_Reference.md#firmware_retraction) adds an automatic z hop when using firmware retraction ## Enhanced behavior -- [`canbus_query.py`](./CANBUS.md#️-finding-the-canbus_uuid-for-new-micro-controllers) now responds with all Danger-Klipper devices, even after they've been assigned a node_id. +- [`canbus_query.py`](./CANBUS.md#finding-the-canbus_uuid-for-new-micro-controllers) now responds with all Kalico devices, even after they've been assigned a node_id. -## New Klipper Modules +## New Kalico Modules -- [gcode_shell_command](./G-Code_Shell_Command.md) - Execute linux commands and scripts from within Klipper +- [gcode_shell_command](./G-Code_Shell_Command.md) - Execute linux commands and scripts from within Kalico ## Sensorless Homing @@ -34,7 +34,7 @@ - [`[probe] drop_first_result: True`](./Config_Reference.md#probe) will drop the first result when probing. This can improve probe accuracy for printers that have an outlier for the first sample. - [`[dockable_probe]`](./Config_Reference.md#dockable_probe) brings helpful native support for docked probes, such as the Annex Quickdraw, Klicky/Unklicky, and countless others. -- [`[z_calibration]`](./Config_Reference.md#⚠️-z_calibration) enables automatic probe Z offset calibration using a reference endstop like the Voron 2.4 nozzle endstop. +- [`[z_calibration]`](./Config_Reference.md#z_calibration) enables automatic probe Z offset calibration using a reference endstop like the Voron 2.4 nozzle endstop. - [`[z_tilt_ng]`](./Config_Reference.md#z_tilt_ng) adds enforced 3-point z tilt calibration - [`[z_tilt/quad_gantry_level] increasing_threshold`](./Config_Reference.md#z_tilt) allows you to customize the allowed variation when probing multiple times - [`[z_tilt/quad_gantry_level] adaptive_horizontal_move_z`](./Config_Reference.md#z_tilt) adaptively decrease horizontal_move_z based on resulting error - z_tilt and QGL faster and safer! @@ -60,10 +60,10 @@ - New [`RELOAD_GCODE_MACROS`](./G-Codes.md#reload_gcode_macros) G-Code command to reload `[gcode_macro]` templates without requiring a restart. - G-Code Macros can be written in Python. Read more [here](./Command_Templates.md) -## [Plugins](./Plugins.md) +## Plugins -Extend your Danger Klipper installation with custom plugins. +Extend your Kalico installation with custom plugins. -Your python plugins can now extend [`klippy/extras`](https://github.com/DangerKlippers/danger-klipper/tree/master/klippy/extras) adding new modules to klipper without causing updates to fail due to a "dirty" git tree. +Your python plugins can now extend [`klippy/extras`](https://github.com/KalicoCrew/kalico/tree/main/klippy/extras) adding new modules to Kalico without causing updates to fail due to a "dirty" git tree. Enable `[danger_options] allow_plugin_override: True` to override existing extras. diff --git a/docs/Debugging.md b/docs/Debugging.md index fdb4be796..10ddb053b 100644 --- a/docs/Debugging.md +++ b/docs/Debugging.md @@ -1,10 +1,10 @@ # Debugging -This document describes some of the Klipper debugging tools. +This document describes some of the Kalico debugging tools. ## Running the regression tests -The main Klipper GitHub repository uses "github actions" to run a +The main Kalico GitHub repository uses "github actions" to run a series of regression tests. It can be useful to run some of these tests locally. @@ -15,7 +15,7 @@ The source code "whitespace check" can be run with: The Klippy regression test suite requires "data dictionaries" from many platforms. The easiest way to obtain them is to -[download them from github](https://github.com/DangerKlippers/danger-klipper/issues/1438). +[download them from github](https://github.com/KalicoCrew/kalico/issues/1438). Once the data dictionaries are downloaded, use the following to run the regression suite: ``` @@ -26,9 +26,9 @@ tar xfz klipper-dict-20??????.tar.gz ## Manually sending commands to the micro-controller Normally, the host klippy.py process would be used to translate gcode -commands to Klipper micro-controller commands. However, it's also +commands to Kalico micro-controller commands. However, it's also possible to manually send these MCU commands (functions marked with -the DECL_COMMAND() macro in the Klipper source code). To do so, run: +the DECL_COMMAND() macro in the Kalico source code). To do so, run: ``` ~/klippy-env/bin/python ./klippy/console.py /tmp/pseudoserial @@ -58,7 +58,7 @@ make menuconfig make ``` -Once the above is done it is possible to run Klipper in batch mode +Once the above is done it is possible to run Kalico in batch mode (see [installation](Installation.md) for the steps necessary to build the python virtual environment and a printer.cfg file): @@ -84,8 +84,8 @@ micro-controller. ## Motion analysis and data logging -Klipper supports logging its internal motion history, which can be -later analyzed. To use this feature, Klipper must be started with the +Kalico supports logging its internal motion history, which can be +later analyzed. To use this feature, Kalico must be started with the [API Server](API_Server.md) enabled. Data logging is enabled with the `data_logger.py` tool. For example: @@ -93,7 +93,7 @@ Data logging is enabled with the `data_logger.py` tool. For example: ~/klipper/scripts/motan/data_logger.py /tmp/klippy_uds mylog ``` -This command will connect to the Klipper API Server, subscribe to +This command will connect to the Kalico API Server, subscribe to status and motion information, and log the results. Two files are generated - a compressed data file and an index file (eg, `mylog.json.gz` and `mylog.index.gz`). After starting the logging, it @@ -230,16 +230,16 @@ make cfgclean python debian sudo dpkg -i build/debian/python3-simulavr*.deb ``` -To compile Klipper for use in simulavr, run: +To compile Kalico for use in simulavr, run: ``` -cd /path/to/klipper +cd /path/to/kalico make menuconfig ``` and compile the micro-controller software for an AVR atmega644p and select SIMULAVR software emulation support. Then one can compile -Klipper (run `make`) and then start the simulation with: +Kalico (run `make`) and then start the simulation with: ``` PYTHONPATH=/path/to/simulavr/build/pysimulavr/ ./scripts/avrsim.py out/klipper.elf @@ -252,7 +252,7 @@ not need to set `PYTHONPATH`, and can simply run the simulator as Then, with simulavr running in another window, one can run the following to read gcode from a file (eg, "test.gcode"), process it -with Klippy, and send it to Klipper running in simulavr (see +with Klippy, and send it to Kalico running in simulavr (see [installation](Installation.md) for the steps necessary to build the python virtual environment): diff --git a/docs/Delta_Calibrate.md b/docs/Delta_Calibrate.md index a64cab43d..11a5a5b10 100644 --- a/docs/Delta_Calibrate.md +++ b/docs/Delta_Calibrate.md @@ -1,6 +1,6 @@ # Delta calibration -This document describes Klipper's automatic calibration system for +This document describes Kalico's automatic calibration system for "delta" style printers. Delta calibration involves finding the tower endstop positions, tower @@ -18,7 +18,7 @@ improve the accuracy of those switches. ## Automatic vs manual probing -Klipper supports calibrating the delta parameters via a manual probing +Kalico supports calibrating the delta parameters via a manual probing method or via an automatic Z probe. A number of delta printer kits come with automatic Z probes that are @@ -40,7 +40,7 @@ then be sure to rerun probe calibration after any delta calibration. ## Basic delta calibration -Klipper has a DELTA_CALIBRATE command that can perform basic delta +Kalico has a DELTA_CALIBRATE command that can perform basic delta calibration. This command probes seven different points on the bed and calculates new values for the tower angles, tower endstops, and delta radius. @@ -137,7 +137,7 @@ from C label, distance from center to pillar with B label, etc.). ![delta_cal_e_step1](img/delta_cal_e_step1.png) -Enter these parameters into Klipper with a comma separated list of +Enter these parameters into Kalico with a comma separated list of floating point numbers: ``` DELTA_ANALYZE CENTER_DISTS=,,,,, @@ -155,7 +155,7 @@ the pillar across from A, and so on. ![delta_cal_e_step2](img/delta_cal_e_step2.png) -Enter these parameters into Klipper: +Enter these parameters into Kalico: ``` DELTA_ANALYZE OUTER_DISTS=,,,,, ``` @@ -169,7 +169,7 @@ spoke. ![delta_cal_e_step3](img/delta_cal_e_step3.png) -Enter them into Klipper: +Enter them into Kalico: ``` DELTA_ANALYZE CENTER_PILLAR_WIDTHS=,, ``` @@ -186,7 +186,7 @@ pillar across from A, etc.). ![delta_cal_e_step4](img/delta_cal_e_step4.png) -And enter them into Klipper: +And enter them into Kalico: ``` DELTA_ANALYZE OUTER_PILLAR_WIDTHS=,,,,, ``` diff --git a/docs/Eddy_Probe.md b/docs/Eddy_Probe.md deleted file mode 100644 index 221c855b6..000000000 --- a/docs/Eddy_Probe.md +++ /dev/null @@ -1,56 +0,0 @@ -# Eddy Current Inductive probe - -This document describes how to use an -[eddy current](https://en.wikipedia.org/wiki/Eddy_current) inductive -probe in Klipper. - -Currently, an eddy current probe can not be used for Z homing. The -sensor can only be used for Z probing. - -Start by declaring a -[probe_eddy_current config section](Config_Reference.md#probe_eddy_current) -in the printer.cfg file. It is recommended to set the `z_offset` to -0.5mm. It is typical for the sensor to require an `x_offset` and -`y_offset`. If these values are not known, one should estimate the -values during initial calibration. - -The first step in calibration is to determine the appropriate -DRIVE_CURRENT for the sensor. Home the printer and navigate the -toolhead so that the sensor is near the center of the bed and is about -20mm above the bed. Then issue an `LDC_CALIBRATE_DRIVE_CURRENT -CHIP=` command. For example, if the config section was -named `[probe_eddy_current my_eddy_probe]` then one would run -`LDC_CALIBRATE_DRIVE_CURRENT CHIP=my_eddy_probe`. This command should -complete in a few seconds. After it completes, issue a `SAVE_CONFIG` -command to save the results to the printer.cfg and restart. - -The second step in calibration is to correlate the sensor readings to -the corresponding Z heights. Home the printer and navigate the -toolhead so that the nozzle is near the center of the bed. Then run an -`PROBE_EDDY_CURRENT_CALIBRATE CHIP=my_eddy_probe` command. Once the -tool starts, follow the steps described at -["the paper test"](Bed_Level.md#the-paper-test) to determine the -actual distance between the nozzle and bed at the given location. Once -those steps are complete one can `ACCEPT` the position. The tool will -then move the the toolhead so that the sensor is above the point where -the nozzle used to be and run a series of movements to correlate the -sensor to Z positions. This will take a couple of minutes. After the -tool completes, issue a `SAVE_CONFIG` command to save the results to -the printer.cfg and restart. - -After initial calibration it is a good idea to verify that the -`x_offset` and `y_offset` are accurate. Follow the steps to -[calibrate probe x and y offsets](Probe_Calibrate.md#calibrating-probe-x-and-y-offsets). -If either the `x_offset` or `y_offset` is modified then be sure to run -the `PROBE_EDDY_CURRENT_CALIBRATE` command (as described above) after -making the change. - -Once calibration is complete, one may use all the standard Klipper -tools that use a Z probe. - -Note that eddy current sensors (and inductive probes in general) are -susceptible to "thermal drift". That is, changes in temperature can -result in changes in reported Z height. Changes in either the bed -surface temperature or sensor hardware temperature can skew the -results. It is important that calibration and probing is only done -when the printer is at a stable temperature. diff --git a/docs/Endstop_Phase.md b/docs/Endstop_Phase.md index 1921b283f..6130dfd6a 100644 --- a/docs/Endstop_Phase.md +++ b/docs/Endstop_Phase.md @@ -1,6 +1,6 @@ # Endstop phase -This document describes Klipper's stepper phase adjusted endstop +This document describes Kalico's stepper phase adjusted endstop system. This functionality can improve the accuracy of traditional endstop switches. It is most useful when using a Trinamic stepper motor driver that has run-time configuration. @@ -22,14 +22,14 @@ cycle through phases: 0, 1, 2, ... 61, 62, 63, 0, 1, 2, etc. Crucially, when the stepper motor is at a particular position on a linear rail it should always be at the same stepper phase. Thus, when a carriage triggers the endstop switch the stepper controlling that -carriage should always be at the same stepper motor phase. Klipper's +carriage should always be at the same stepper motor phase. Kalico's endstop phase system combines the stepper phase with the endstop trigger to improve the accuracy of the endstop. In order to use this functionality it is necessary to be able to identify the phase of the stepper motor. If one is using Trinamic TMC2130, TMC2208, TMC2224 or TMC2660 drivers in run-time configuration -mode (ie, not stand-alone mode) then Klipper can query the stepper +mode (ie, not stand-alone mode) then Kalico can query the stepper phase from the driver. (It is also possible to use this system on traditional stepper drivers if one can reliably reset the stepper drivers - see below for details.) @@ -53,7 +53,7 @@ five `G28` commands. After performing the above, the `ENDSTOP_PHASE_CALIBRATE` command will often report the same (or nearly the same) phase for the stepper. This phase can be saved in the config file so that all future G28 commands -use that phase. (So, in future homing operations, Klipper will obtain +use that phase. (So, in future homing operations, Kalico will obtain the same position even if the endstop triggers a little earlier or a little later.) @@ -111,7 +111,7 @@ SAVE_CONFIG * It is possible to use this system with traditional (non-Trinamic) stepper motor drivers. However, doing this requires making sure that the stepper motor drivers are reset every time the micro-controller - is reset. (If the two are always reset together then Klipper can + is reset. (If the two are always reset together then Kalico can determine the stepper phase by tracking the total number of steps it has commanded the stepper to move.) Currently, the only way to do this reliably is if both the micro-controller and stepper motor diff --git a/docs/Example_Configs.md b/docs/Example_Configs.md index fd1f22f24..513c24807 100644 --- a/docs/Example_Configs.md +++ b/docs/Example_Configs.md @@ -1,7 +1,7 @@ # Example configurations -This document contains guidelines for contributing an example Klipper -configuration to the Klipper github repository (located in the +This document contains guidelines for contributing an example Kalico +configuration to the Kalico github repository (located in the [config directory](../config/)). Note that the @@ -31,7 +31,7 @@ is also a useful resource for finding and sharing config files. 3. Do not use spaces or special characters in the config filename. The filename should contain only characters `A-Z`, `a-z`, `0-9`, `-`, and `.`. -4. Klipper must be able to start `printer`, `generic`, and `kit` +4. Kalico must be able to start `printer`, `generic`, and `kit` example config file without error. These config files should be added to the [test/klippy/printers.test](../test/klippy/printers.test) @@ -39,7 +39,7 @@ is also a useful resource for finding and sharing config files. appropriate section and in alphabetical order within that section. 5. The example configuration should be for the "stock" configuration of the printer. (There are too many "customized" configurations to - track in the main Klipper repository.) Similarly, we only add + track in the main Kalico repository.) Similarly, we only add example config files for printers, kits, and boards that have mainstream popularity (eg, there should be at least a 100 of them in active use). Consider using the @@ -101,7 +101,7 @@ is also a useful resource for finding and sharing config files. For example, a config should not specify a custom `max_extrude_cross_section`. Do not enable debugging features. For example there should not be a `force_move` config section. -10. All known boards that Klipper supports can use the default serial +10. All known boards that Kalico supports can use the default serial baud rate of 250000. Do not recommend a different baud rate in an example config file. diff --git a/docs/Exclude_Object.md b/docs/Exclude_Object.md index 5923afbed..38097a0a6 100644 --- a/docs/Exclude_Object.md +++ b/docs/Exclude_Object.md @@ -1,13 +1,13 @@ # Exclude Objects -The `[exclude_object]` module allows Klipper to exclude objects while a print is +The `[exclude_object]` module allows Kalico to exclude objects while a print is in progress. To enable this feature include an [exclude_object config section](Config_Reference.md#exclude_object) (also see the [command -reference](G-Codes.md#exclude-object) and +reference](G-Codes.md#exclude_object) and [sample-macros.cfg](../config/sample-macros.cfg) file for a Marlin/RepRapFirmware compatible M486 G-Code macro.) -Unlike other 3D printer firmware options, a printer running Klipper utilizes a +Unlike other 3D printer firmware options, a printer running Kalico utilizes a suite of components and users have many options to choose from. Therefore, in order to provide a a consistent user experience, the `[exclude_object]` module will establish a contract or API of sorts. The contract covers the contents of @@ -20,28 +20,28 @@ A typical workflow for printing a file might look like this: upload, the file is processed and `[exclude_object]` markers are added to the file. Alternately, slicers may be configured to prepare object exclusion markers natively, or in it's own pre-processing step. -2. When printing starts, Klipper will reset the `[exclude_object]` +2. When printing starts, Kalico will reset the `[exclude_object]` [status](Status_Reference.md#exclude_object). -3. When Klipper processes the `EXCLUDE_OBJECT_DEFINE` block, it will update the +3. When Kalico processes the `EXCLUDE_OBJECT_DEFINE` block, it will update the status with the known objects and pass it on to clients. 4. The client may use that information to present a UI to the user so that - progress can be tracked. Klipper will update the status to include the + progress can be tracked. Kalico will update the status to include the currently printing object which the client can use for display purposes. 5. If the user requests that an object be cancelled, the client will issue an - `EXCLUDE_OBJECT NAME=` command to Klipper. -6. When Klipper process the command, it will add the object to the list of + `EXCLUDE_OBJECT NAME=` command to Kalico. +6. When Kalico process the command, it will add the object to the list of excluded objects and update the status for the client. -7. The client will receive the updated status from Klipper and can use that +7. The client will receive the updated status from Kalico and can use that information to reflect the object's status in the UI. 8. When printing finishes, the `[exclude_object]` status will continue to be available until another action resets it. ## The GCode File The specialized gcode processing needed to support excluding objects does not -fit into Klipper's core design goals. Therefore, this module requires that the -file is processed before being sent to Klipper for printing. Using a +fit into Kalico's core design goals. Therefore, this module requires that the +file is processed before being sent to Kalico for printing. Using a post-process script in the slicer or having middleware process the file on -upload are two possibilities for preparing the file for Klipper. A reference +upload are two possibilities for preparing the file for Kalico. A reference post-processing script is available both as an executable and a python library, see [cancelobject-preprocessor](https://github.com/kageurufu/cancelobject-preprocessor). @@ -69,15 +69,15 @@ saved as strings in the object definition and provided in status updates. POLYGON=[[40,40],[50,60],[60,40]]` All available G-Code commands are documented in the [G-Code -Reference](./G-Codes.md#excludeobject) +Reference](G-Codes.md#exclude_object) ## Status Information The state of this module is provided to clients by the [exclude_object status](Status_Reference.md#exclude_object). The status is reset when: -- The Klipper firmware is restarted. -- There is a reset of the `[virtual_sdcard]`. Notably, this is reset by Klipper +- The Kalico firmware is restarted. +- There is a reset of the `[virtual_sdcard]`. Notably, this is reset by Kalico at the start of a print. - When an `EXCLUDE_OBJECT_DEFINE RESET=1` command is issued. @@ -88,12 +88,12 @@ provide clients with object names and coordinates so the UI can provide a graphical representation of the objects if desired. As the print progresses, the `exclude_object.current_object` status field will -be updated as Klipper processes `EXCLUDE_OBJECT_START` and `EXCLUDE_OBJECT_END` +be updated as Kalico processes `EXCLUDE_OBJECT_START` and `EXCLUDE_OBJECT_END` commands. The `current_object` field will be set even if the object has been excluded. Undefined objects marked with a `EXCLUDE_OBJECT_START` will be added to the known objects to assist in UI hinting, without any additional metadata. As `EXCLUDE_OBJECT` commands are issued, the list of excluded objects is -provided in the `exclude_object.excluded_objects` array. Since Klipper looks +provided in the `exclude_object.excluded_objects` array. Since Kalico looks ahead to process upcoming gcode, there may be a delay between when the command is issued and when the status is updated. diff --git a/docs/FAQ.md b/docs/FAQ.md index 417fb1d4f..17d3d0489 100644 --- a/docs/FAQ.md +++ b/docs/FAQ.md @@ -52,7 +52,7 @@ each platform. Unfortunately, there is a lot of variance in flashing methods, so the "make flash" command may not work on all boards. If you're having an intermittent failure or you do have a standard -setup, then double check that Klipper isn't running when flashing +setup, then double check that Kalico isn't running when flashing (sudo service klipper stop), make sure OctoPrint isn't trying to connect directly to the device (open the Connection tab in the web page and click Disconnect if the Serial Port is set to the device), @@ -70,15 +70,15 @@ additional information. ## How do I change the serial baud rate? -The recommended baud rate for Klipper is 250000. This baud rate works -well on all micro-controller boards that Klipper supports. If you've +The recommended baud rate for Kalico is 250000. This baud rate works +well on all micro-controller boards that Kalico supports. If you've found an online guide recommending a different baud rate, then ignore that part of the guide and continue with the default value of 250000. If you want to change the baud rate anyway, then the new rate will need to be configured in the micro-controller (during **make menuconfig**) and that updated code will need to be compiled and -flashed to the micro-controller. The Klipper printer.cfg file will +flashed to the micro-controller. The Kalico printer.cfg file will also need to be updated to match that baud rate (see the [config reference](Config_Reference.md#mcu) for details). For example: @@ -88,20 +88,20 @@ baud: 250000 ``` The baud rate shown on the OctoPrint web page has no impact on the -internal Klipper micro-controller baud rate. Always set the OctoPrint -baud rate to 250000 when using Klipper. +internal Kalico micro-controller baud rate. Always set the OctoPrint +baud rate to 250000 when using Kalico. -The Klipper micro-controller baud rate is not related to the baud rate +The Kalico micro-controller baud rate is not related to the baud rate of the micro-controller's bootloader. See the [bootloader document](Bootloaders.md) for additional information on bootloaders. -## Can I run Klipper on something other than a Raspberry Pi 3? +## Can I run Kalico on something other than a Raspberry Pi 3? The recommended hardware is a Raspberry Pi 2, Raspberry Pi 3, or Raspberry Pi 4. -Klipper will run on a Raspberry Pi 1 and on the Raspberry Pi Zero, but +Kalico will run on a Raspberry Pi 1 and on the Raspberry Pi Zero, but these boards don't have enough processing power to run OctoPrint well. It is common for print stalls to occur on these slower machines when printing directly from OctoPrint. (The printer may move faster @@ -113,36 +113,36 @@ feature when printing (see For running on the Beaglebone, see the [Beaglebone specific installation instructions](Beaglebone.md). -Klipper has been run on other machines. The Klipper host software only +Kalico has been run on other machines. The Kalico host software only requires Python running on a Linux (or similar) computer. However, if you wish to run it on a different machine you will need Linux admin knowledge to install the system prerequisites for that particular machine. See the [install-octopi.sh](../scripts/install-octopi.sh) script for further information on the necessary Linux admin steps. -If you are looking to run the Klipper host software on a low-end chip, +If you are looking to run the Kalico host software on a low-end chip, then be aware that, at a minimum, a machine with "double precision floating point" hardware is required. -If you are looking to run the Klipper host software on a shared +If you are looking to run the Kalico host software on a shared general-purpose desktop or server class machine, then note that -Klipper has some real-time scheduling requirements. If, during a +Kalico has some real-time scheduling requirements. If, during a print, the host computer also performs an intensive general-purpose computing task (such as defragmenting a hard drive, 3d rendering, -heavy swapping, etc.), then it may cause Klipper to report print +heavy swapping, etc.), then it may cause Kalico to report print errors. Note: If you are not using an OctoPi image, be aware that several Linux distributions enable a "ModemManager" (or similar) package that -can disrupt serial communication. (Which can cause Klipper to report +can disrupt serial communication. (Which can cause Kalico to report seemingly random "Lost communication with MCU" errors.) If you install -Klipper on one of these distributions you may need to disable that +Kalico on one of these distributions you may need to disable that package. -## Can I run multiple instances of Klipper on the same host machine? +## Can I run multiple instances of Kalico on the same host machine? -It is possible to run multiple instances of the Klipper host software, -but doing so requires Linux admin knowledge. The Klipper installation +It is possible to run multiple instances of the Kalico host software, +but doing so requires Linux admin knowledge. The Kalico installation scripts ultimately cause the following Unix command to be run: ``` ~/klippy-env/bin/python ~/klipper/klippy/klippy.py ~/printer.cfg -l /tmp/klippy.log @@ -162,13 +162,13 @@ as examples. ## Do I have to use OctoPrint? -The Klipper software is not dependent on OctoPrint. It is possible to -use alternative software to send commands to Klipper, but doing so +The Kalico software is not dependent on OctoPrint. It is possible to +use alternative software to send commands to Kalico, but doing so requires Linux admin knowledge. -Klipper creates a "virtual serial port" via the "/tmp/printer" file, +Kalico creates a "virtual serial port" via the "/tmp/printer" file, and it emulates a classic 3d-printer serial interface via that file. -In general, alternative software may work with Klipper as long as it +In general, alternative software may work with Kalico as long as it can be configured to use "/tmp/printer" for the printer serial port. ## Why can't I move the stepper before homing the printer? @@ -193,7 +193,7 @@ process itself (or fundamentally does not have a homing process) then consider using a safe_z_home or homing_override section in the config file. If you need to move a stepper for diagnostic or debugging purposes then consider adding a force_move section to the config -file. See [config reference](Config_Reference.md#customized_homing) +file. See [config reference](Config_Reference.md#customized-homing) for further details on these options. ## Why is the Z position_endstop set to 0.5 in the default configs? @@ -218,7 +218,7 @@ try reducing the max_z_velocity setting in the printer config. Long answer: In practice Marlin can typically only step at a rate of around 10000 steps per second. If it is requested to move at a speed that would require a higher step rate then Marlin will generally just -step as fast as it can. Klipper is able to achieve much higher step +step as fast as it can. Kalico is able to achieve much higher step rates, but the stepper motor may not have sufficient torque to move at a higher speed. So, for a Z axis with a high gearing ratio or high microsteps setting the actual obtainable max_z_velocity may be smaller @@ -228,9 +228,9 @@ than what is configured in Marlin. If using the TMC2208 (or TMC2224) driver in "standalone mode" then make sure to use the -[latest version of Klipper](#how-do-i-upgrade-to-the-latest-software). A +[latest version of Kalico](#how-do-i-upgrade-to-the-latest-software). A workaround for a TMC2208 "stealthchop" driver problem was added to -Klipper in mid-March of 2020. +Kalico in mid-March of 2020. ## I keep getting random "Lost communication with MCU" errors @@ -305,7 +305,7 @@ heaters and temperature sensors are functioning correctly. See the [config reference](Config_Reference.md#verify_heater) for further details. -## How do I convert a Marlin pin number to a Klipper pin name? +## How do I convert a Marlin pin number to a Kalico pin name? Short answer: A mapping is available in the [sample-aliases.cfg](../config/sample-aliases.cfg) file. Use that file @@ -315,11 +315,11 @@ also possible to copy the relevant config file and use the aliases in your config, but it is preferable to translate and use the actual micro-controller pin names.) Note that the sample-aliases.cfg file uses pin names that start with the prefix -"ar" instead of "D" (eg, Arduino pin `D23` is Klipper alias `ar23`) +"ar" instead of "D" (eg, Arduino pin `D23` is Kalico alias `ar23`) and the prefix "analog" instead of "A" (eg, Arduino pin `A14` is -Klipper alias `analog14`). +Kalico alias `analog14`). -Long answer: Klipper uses the standard pin names defined by the +Long answer: Kalico uses the standard pin names defined by the micro-controller. On the Atmega chips these hardware pins have names like `PA4`, `PC7`, or `PD2`. @@ -331,7 +331,7 @@ In particular the Arduino pin numbers frequently don't translate to the same hardware names. For example, `D21` is `PD0` on one common Arduino board, but is `PC7` on another common Arduino board. -To avoid this confusion, the core Klipper code uses the standard pin +To avoid this confusion, the core Kalico code uses the standard pin names defined by the micro-controller. ## Do I have to wire my device to a specific type of micro-controller pin? @@ -340,18 +340,18 @@ It depends on the type of device and type of pin: ADC pins (or Analog pins): For thermistors and similar "analog" sensors, the device must be wired to an "analog" or "ADC" capable pin -on the micro-controller. If you configure Klipper to use a pin that is -not analog capable, Klipper will report a "Not a valid ADC pin" error. +on the micro-controller. If you configure Kalico to use a pin that is +not analog capable, Kalico will report a "Not a valid ADC pin" error. -PWM pins (or Timer pins): Klipper does not use hardware PWM by default +PWM pins (or Timer pins): Kalico does not use hardware PWM by default for any device. So, in general, one may wire heaters, fans, and similar devices to any general purpose IO pin. However, fans and output_pin devices may be optionally configured to use `hardware_pwm: True`, in which case the micro-controller must support hardware PWM on -the pin (otherwise, Klipper will report a "Not a valid PWM pin" +the pin (otherwise, Kalico will report a "Not a valid PWM pin" error). -IRQ pins (or Interrupt pins): Klipper does not use hardware interrupts +IRQ pins (or Interrupt pins): Kalico does not use hardware interrupts on IO pins, so it is never necessary to wire a device to one of these micro-controller pins. @@ -371,11 +371,11 @@ general purpose IO pin. ## How do I cancel an M109/M190 "wait for temperature" request? Navigate to the OctoPrint terminal tab and issue an M112 command in -the terminal box. The M112 command will cause Klipper to enter into a +the terminal box. The M112 command will cause Kalico to enter into a "shutdown" state, and it will cause OctoPrint to disconnect from -Klipper. Navigate to the OctoPrint connection area and click on +Kalico. Navigate to the OctoPrint connection area and click on "Connect" to cause OctoPrint to reconnect. Navigate back to the -terminal tab and issue a FIRMWARE_RESTART command to clear the Klipper +terminal tab and issue a FIRMWARE_RESTART command to clear the Kalico error state. After completing this sequence, the previous heating request will be canceled and a new print may be started. @@ -397,29 +397,29 @@ only lose steps in increments of 4 full steps. (So, if one is using 16 microsteps, then a lost step on the stepper would result in the "mcu:" step counter being off by a multiple of 64 microsteps.) -## Why does Klipper report errors? I lost my print! +## Why does Kalico report errors? I lost my print! Short answer: We want to know if our printers detect a problem so that the underlying issue can be fixed and we can obtain great quality prints. We definitely do not want our printers to silently produce low quality prints. -Long answer: Klipper has been engineered to automatically workaround +Long answer: Kalico has been engineered to automatically workaround many transient problems. For example, it automatically detects communication errors and will retransmit; it schedules actions in advance and buffers commands at multiple layers to enable precise timing even with intermittent interference. However, should the software detect an error that it can not recover from, if it is commanded to take an invalid action, or if it detects it is hopelessly -unable to perform its commanded task, then Klipper will report an +unable to perform its commanded task, then Kalico will report an error. In these situations there is a high risk of producing a low-quality print (or worse). It is hoped that alerting the user will empower them to fix the underlying issue and improve the overall quality of their prints. -There are some related questions: Why doesn't Klipper pause the print +There are some related questions: Why doesn't Kalico pause the print instead? Report a warning instead? Check for errors before the print? -Ignore errors in user typed commands? etc? Currently Klipper reads +Ignore errors in user typed commands? etc? Currently Kalico reads commands using the G-Code protocol, and unfortunately the G-Code command protocol is not flexible enough to make these alternatives practical today. There is developer interest in improving the user @@ -478,7 +478,7 @@ Note that the RESTART and FIRMWARE_RESTART g-code commands do not load new software - the above "sudo service klipper restart" and "make flash" commands are needed for a software change to take effect. -## How do I uninstall Klipper? +## How do I uninstall Kalico? On the firmware end, nothing special needs to happen. Just follow the flashing directions for the new firmware. diff --git a/docs/Features.md b/docs/Features.md index fa430789f..b1aa6baad 100644 --- a/docs/Features.md +++ b/docs/Features.md @@ -1,8 +1,8 @@ # Features -Klipper has several compelling features: +Kalico has several compelling features: -* High precision stepper movement. Klipper utilizes an application +* High precision stepper movement. Kalico utilizes an application processor (such as a low-cost Raspberry Pi) when calculating printer movements. The application processor determines when to step each stepper motor, it compresses those events, transmits them to the @@ -14,7 +14,7 @@ Klipper has several compelling features: and the physics of the machine kinematics. More precise stepper movement provides quieter and more stable printer operation. -* Best in class performance. Klipper is able to achieve high stepping +* Best in class performance. Kalico is able to achieve high stepping 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 @@ -22,51 +22,51 @@ Klipper has several compelling features: stepper event timing remains precise even at high speeds which improves overall stability. -* Klipper supports printers with multiple micro-controllers. For +* Kalico supports printers with multiple micro-controllers. For example, one micro-controller could be used to control an extruder, while another controls the printer's heaters, while a third controls - the rest of the printer. The Klipper host software implements clock + the rest of the printer. The Kalico host software implements clock synchronization to account for clock drift between micro-controllers. No special code is needed to enable multiple micro-controllers - it just requires a few extra lines in the config file. * Configuration via simple config file. There's no need to reflash the - micro-controller to change a setting. All of Klipper's configuration + micro-controller to change a setting. All of Kalico's configuration is stored in a standard config file which can be easily edited. This makes it easier to setup and maintain the hardware. -* Klipper supports "Smooth Pressure Advance" - a mechanism to account +* Kalico supports "Smooth Pressure Advance" - a mechanism to account for the effects of pressure within an extruder. This reduces - extruder "ooze" and improves the quality of print corners. Klipper's + extruder "ooze" and improves the quality of print corners. Kalico's implementation does not introduce instantaneous extruder speed changes, which improves overall stability and robustness. -* Klipper supports "Input Shaping" to reduce the impact of vibrations +* Kalico supports "Input Shaping" to reduce the impact of vibrations on print quality. This can reduce or eliminate "ringing" (also known as "ghosting", "echoing", or "rippling") in prints. It may also allow one to obtain faster printing speeds while still maintaining high print quality. -* Klipper uses an "iterative solver" to calculate precise step times - from simple kinematic equations. This makes porting Klipper to new +* Kalico uses an "iterative solver" to calculate precise step times + from simple kinematic equations. This makes porting Kalico to new types of robots easier and it keeps timing precise even with complex kinematics (no "line segmentation" is needed). -* Klipper is hardware agnostic. One should get the same precise timing - independent of the low-level electronics hardware. The Klipper +* Kalico is hardware agnostic. One should get the same precise timing + independent of the low-level electronics hardware. The Kalico micro-controller code is designed to faithfully follow the schedule - provided by the Klipper host software (or prominently alert the user + provided by the Kalico 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 +* Portable code. Kalico works on ARM, AVR, PRU, and other + micro-controllers. Existing "reprap" style printers can run Kalico + without hardware modification - just add a Raspberry Pi. Kalico's internal code layout makes it easier to support other micro-controller architectures as well. -* Simpler code. Klipper uses a very high level language (Python) for +* Simpler code. Kalico uses a very high level language (Python) for most code. The kinematics algorithms, the G-code parsing, the heating and thermistor algorithms, etc. are all written in Python. This makes it easier to develop new functionality. @@ -77,17 +77,17 @@ Klipper has several compelling features: actions depending on the state of the printer. * Builtin API server. In addition to the standard G-Code interface, - Klipper supports a rich JSON based application interface. This + Kalico supports a rich JSON based application interface. This enables programmers to build external applications with detailed control of the printer. ## Additional features -Klipper supports many standard 3d printer features: +Kalico supports many standard 3d printer features: * 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 + a regular web-browser. The same Raspberry Pi that runs Kalico can also run the web interface. * Standard G-Code support. Common g-code commands that are produced by @@ -101,9 +101,9 @@ Klipper supports many standard 3d printer features: hybrid-corexz, deltesian, rotary delta, polar, and cable winch style printers. -* Automatic bed leveling support. Klipper can be configured for basic +* Automatic bed leveling support. Kalico 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 + multiple Z steppers then Kalico can also level by independently manipulating the Z steppers. Most Z height probes are supported, including BL-Touch probes and servo activated probes. Probes may be calibrated for axis twist compensation. @@ -146,7 +146,7 @@ Klipper supports many standard 3d printer features: movements in a similar direction will be optimized to reduce print stalls and improve overall print time. -* Klipper implements a "stepper phase endstop" algorithm that can +* Kalico implements a "stepper phase endstop" algorithm that can improve the accuracy of typical endstop switches. When properly tuned it can improve a print's first layer bed adhesion. @@ -163,7 +163,7 @@ Klipper supports many standard 3d printer features: * Sample configuration files are available for many common printers. Check the [config directory](../config/) for a list. -To get started with Klipper, read the [installation](Installation.md) +To get started with Kalico, read the [installation](Installation.md) guide. ## Step Benchmarks diff --git a/docs/G-Code_Shell_Command.md b/docs/G-Code_Shell_Command.md index d8e9d506b..790cd1391 100644 --- a/docs/G-Code_Shell_Command.md +++ b/docs/G-Code_Shell_Command.md @@ -2,14 +2,14 @@ ### Creator of this extension is [Arksine](https://github.com/Arksine). -This is a brief explanation of how to use the shell command extension for Klipper, which you can install with KIAUH. +This is a brief explanation of how to use the shell command extension for Kalico, which you can install with KIAUH. -After installing the extension you can execute linux commands or even scripts from within Klipper with custom commands defined in your printer.cfg. +After installing the extension you can execute linux commands or even scripts from within Kalico with custom commands defined in your printer.cfg. #### How to configure a shell command: ```shell -# Runs a linux command or script from within klipper. Note that sudo commands +# Runs a linux command or script from within Kalico. Note that sudo commands # that require password authentication are disallowed. All executable scripts # should include a shebang. # [gcode_shell_command my_shell_cmd] @@ -51,7 +51,7 @@ Content of the `gcode_shell_command` and the `gcode_macro`: ``` [gcode_shell_command print_to_file] -command: sh /home/pi/klipper_config/script.sh +command: sh /home/pi/printer_data/config/script.sh timeout: 30. verbose: True diff --git a/docs/G-Codes.md b/docs/G-Codes.md index f8e7f635d..24f94c06b 100644 --- a/docs/G-Codes.md +++ b/docs/G-Codes.md @@ -1,11 +1,11 @@ # G-Codes -This document describes the commands that Klipper supports. These are +This document describes the commands that Kalico supports. These are commands that one may enter into the OctoPrint terminal tab. ## G-Code commands -Klipper supports the following standard G-Code commands: +Kalico supports the following standard G-Code commands: - Move (G0 or G1): `G1 [X] [Y] [Z] [E] [F]` - Dwell: `G4 P` - Move to origin: `G28 [X] [Y] [Z]` @@ -38,13 +38,13 @@ Klipper supports the following standard G-Code commands: For further details on the above commands see the [RepRap G-Code documentation](http://reprap.org/wiki/G-code). -Klipper's goal is to support the G-Code commands produced by common +Kalico's goal is to support the G-Code commands produced by common 3rd party software (eg, OctoPrint, Printrun, Slic3r, Cura, etc.) in their standard configurations. It is not a goal to support every -possible G-Code command. Instead, Klipper prefers human readable +possible G-Code command. Instead, Kalico prefers human readable ["extended G-Code commands"](#additional-commands). Similarly, the G-Code terminal output is only intended to be human readable - see the -[API Server document](API_Server.md) if controlling Klipper from +[API Server document](API_Server.md) if controlling Kalico from external software. If one requires a less common G-Code command then it may be possible @@ -55,7 +55,7 @@ example, one might use this to implement: `G12`, `G29`, `G30`, `G31`, ## Additional Commands -Klipper uses "extended" G-Code commands for general configuration and +Kalico uses "extended" G-Code commands for general configuration and status. These extended commands all follow a similar format - they start with a command name and may be followed by one or more parameters. For example: `SET_SERVO SERVO=myservo ANGLE=5.3`. In this @@ -63,7 +63,7 @@ document, the commands and parameters are shown in uppercase, however they are not case sensitive. (So, "SET_SERVO" and "set_servo" both run the same command.) -This section is organized by Klipper module name, which generally +This section is organized by Kalico module name, which generally follows the section names specified in the [printer configuration file](Config_Reference.md). Note that some modules are automatically loaded. @@ -313,8 +313,8 @@ from executing. ### [delta_calibrate] The following commands are available when the -[delta_calibrate config section](Config_Reference.md#linear-delta-kinematics) -is enabled (also see the [delta calibrate guide](Delta_Calibrate.md)). +[delta_calibrate] config section is enabled (also see the +[delta calibrate guide](Delta_Calibrate.md)). #### DELTA_CALIBRATE `DELTA_CALIBRATE [METHOD=manual] [HORIZONTAL_MOVE_Z=] @@ -457,7 +457,7 @@ cleared. Additionally including `NAME` will only reset the named object. This Provides a summary of an object in the file. With no parameters provided, this will list the defined objects known to -Klipper. Returns a list of strings, unless the `JSON` parameter is given, +Kalico. Returns a list of strings, unless the `JSON` parameter is given, when it will return object details in json format. When the `NAME` parameter is included, this defines an object to be excluded. @@ -510,7 +510,7 @@ stepper's "rotation distance" (as defined in an [extruder_stepper](Config_Reference.md#extruder_stepper) config section). If the rotation distance is a negative number then the stepper motion will be inverted (relative to the stepper direction specified in the -config file). Changed settings are not retained on Klipper reset. Use +config file). Changed settings are not retained on Kalico reset. Use with caution as small changes can result in excessive pressure between extruder and hotend. Do proper calibration with filament before use. If 'DISTANCE' value is not provided then this command will return the @@ -534,8 +534,8 @@ enabled. ### SET_HEATED_FAN_TARGET `SET_HEATED_FAN_TARGET TARGET=`: Override the `heater_temp` -setting in the [heated_fan config section]((Config_Reference.md#heated_fan)) -until Klipper is restarted. Useful for slicers to set different heated fan +setting in the [heated_fan config section](Config_Reference.md#heated_fan) +until Kalico is restarted. Useful for slicers to set different heated fan temperatures at different layers. ### [fan_generic] @@ -716,7 +716,7 @@ clears any error state from the micro-controller. `HEATER_INTERRUPT`: Interrupts a TEMPERATURE_WAIT command. #### STATUS -`STATUS`: Report the Klipper host software status. +`STATUS`: Report the Kalico host software status. #### HELP `HELP`: Report the list of available extended G-Code commands. @@ -1148,11 +1148,11 @@ The print_stats module is automatically loaded. #### SET_PRINT_STATS_INFO `SET_PRINT_STATS_INFO [TOTAL_LAYER=] [CURRENT_LAYER= -]`: Pass slicer info like layer act and total to Klipper. +]`: Pass slicer info like layer act and total to Kalico. Add `SET_PRINT_STATS_INFO [TOTAL_LAYER=]` to your slicer start gcode section and `SET_PRINT_STATS_INFO [CURRENT_LAYER= ]` at the layer change gcode section to pass layer -information from your slicer to Klipper. +information from your slicer to Kalico. ### [probe] @@ -1547,9 +1547,9 @@ description of each parameter. [SCALE=<0:1>]`: change the per-axis limits. This command is only available when `kinematics` is set to either -[`limited_cartesian`](./Config_Reference.md#⚠️-cartesian-kinematics-with-limits-for-x-and-y-axes) +[`limited_cartesian`](./Config_Reference.md#cartesian-kinematics-with-limits-for-x-and-y-axes) or -[`limited_corexy`](./Config_Reference.md#⚠️-corexy-kinematics-with-limits-for-x-and-y-axes). +[`limited_corexy`](./Config_Reference.md#corexy-kinematics-with-limits-for-x-and-y-axes). The velocity argument is not available on CoreXY. With no arguments, this command responds with the movement direction with the most acceleration or velocity. @@ -1789,7 +1789,7 @@ three possible combinations of options: ### [virtual_sdcard] -Klipper supports the following standard G-Code commands if the +Kalico supports the following standard G-Code commands if the [virtual_sdcard config section](Config_Reference.md#virtual_sdcard) is enabled: - List SD card: `M20` diff --git a/docs/Installation.md b/docs/Installation.md index 313e7d87e..fae19dcd2 100644 --- a/docs/Installation.md +++ b/docs/Installation.md @@ -1,29 +1,29 @@ # Installation These instructions assume the software will run on a linux based host -running a Klipper compatible front end. It is recommended that a +running a Kalico compatible front end. It is recommended that a SBC(Small Board Computer) such as a Raspberry Pi or Debian based Linux device be used as the host machine (see the -[FAQ](FAQ.md#can-i-run-klipper-on-something-other-than-a-raspberry-pi-3) +[FAQ](FAQ.md#can-i-run-kalico-on-something-other-than-a-raspberry-pi-3) for other options). For the purposes of these instructions host relates to the Linux device and mcu relates to the printboard. SBC relates to the term Small Board Computer such as the Raspberry Pi. -## Obtain a Klipper Configuration File +## Obtain a Kalico Configuration File -Most Klipper settings are determined by a "printer configuration file" +Most Kalico settings are determined by a "printer configuration file" printer.cfg, that will be stored on the host. An appropriate configuration -file can often be found by looking in the Klipper +file can often be found by looking in the Kalico [config directory](../config/) for a file starting with a "printer-" -prefix that corresponds to the target printer. The Klipper +prefix that corresponds to the target printer. The Kalico configuration file contains technical information about the printer that will be needed during the installation. If there isn't an appropriate printer configuration file in the -Klipper config directory then try searching the printer manufacturer's -website to see if they have an appropriate Klipper configuration file. +Kalico config directory then try searching the printer manufacturer's +website to see if they have an appropriate Kalico configuration file. If no configuration file for the printer can be found, but the type of printer control board is known, then look for an appropriate @@ -37,27 +37,27 @@ scratch. However, this requires significant technical knowledge about the printer and its electronics. It is recommended that most users start with an appropriate configuration file. If creating a new custom printer configuration file, then start with the closest example -[config file](../config/) and use the Klipper +[config file](../config/) and use the Kalico [config reference](Config_Reference.md) for further information. -## Interacting with Klipper +## Interacting with Kalico -Klipper is a 3d printer firmware, so it needs some way for the user to +Kalico is a 3d printer firmware, so it needs some way for the user to interact with it. Currently the best choices are front ends that retrieve information through the [Moonraker web API](https://moonraker.readthedocs.io/) and there is also -the option to use [Octoprint](https://octoprint.org/) to control Klipper. +the option to use [Octoprint](https://octoprint.org/) to control Kalico. -The choice is up to the user on what to use, but the underlying Klipper is the +The choice is up to the user on what to use, but the underlying Kalico is the same in all cases. We encourage users to research the options available and make an informed decision. ## Obtaining an OS image for SBC's -There are many ways to obtain an OS image for Klipper for SBC use, most depend on +There are many ways to obtain an OS image for Kalico for SBC use, most depend on what front end you wish to use. Some manafactures of these SBC boards also provide -their own Klipper-centric images. +their own Kalico-centric images. The two main Moonraker based front ends are [Fluidd](https://docs.fluidd.xyz/) and [Mainsail](https://docs.mainsail.xyz/), the latter of which has a premade install @@ -65,7 +65,7 @@ image ["MainsailOS"](https://docs-os.mainsail.xyz), this has the option for Rasp and some OrangePi variants. Fluidd can be installed via KIAUH(Klipper Install And Update Helper), which -is explained below and is a 3rd party installer for all things Klipper. +is explained below and is a 3rd party installer for all things Kalico. OctoPrint can be installed via the popular OctoPi image or via KIAUH, this process is explained in [OctoPrint.md](OctoPrint.md) @@ -75,9 +75,9 @@ process is explained in [OctoPrint.md](OctoPrint.md) Normally you would start with a base image for your SBC, RPiOS Lite for example, or in the case of a x86 Linux device, Ubuntu Server. Please note that Desktop variants are not recommended due to certain helper programs that can stop some -Klipper functions working and even mask access to some print boards. +Kalico functions working and even mask access to some print boards. -KIAUH can be used to install Klipper and its associated programs on a variety +KIAUH can be used to install Kalico and its associated programs on a variety of Linux based systems that run a form of Debian. More information can be found at https://github.com/dw-0/kiauh @@ -92,7 +92,7 @@ make menuconfig ``` The comments at the top of the -[printer configuration file](#obtain-a-klipper-configuration-file) +[printer configuration file](#obtain-a-kalico-configuration-file) should describe the settings that need to be set during "make menuconfig". Open the file in a web browser or text editor and look for these instructions near the top of the file. Once the appropriate @@ -104,10 +104,10 @@ make ``` If the comments at the top of the -[printer configuration file](#obtain-a-klipper-configuration-file) +[printer configuration file](#obtain-a-kalico-configuration-file) describe custom steps for "flashing" the final image to the printer control board then follow those steps and then proceed to -[configuring OctoPrint](#configuring-octoprint-to-use-klipper). +[configuring OctoPrint](OctoPrint.md#configuring-octoprint-to-use-kalico). Otherwise, the following steps are often used to "flash" the printer control board. First, it is necessary to determine the serial port @@ -132,7 +132,7 @@ run the command again, the missing item will be your print board(see the [FAQ](FAQ.md#wheres-my-serial-port) for more information). For common micro-controllers with STM32 or clone chips, LPC chips and -others it is usual that these need an initial Klipper flash via SD card. +others it is usual that these need an initial Kalico flash via SD card. When flashing with this method, it is important to make sure that the print board is not connected with USB to the host, due to some boards @@ -165,13 +165,13 @@ It is important to note that RP2040 chips may need to be put into Boot mode before this operation. -## Configuring Klipper +## Configuring Kalico The next step is to copy the -[printer configuration file](#obtain-a-klipper-configuration-file) to +[printer configuration file](#obtain-a-kalico-configuration-file) to the host. -Arguably the easiest way to set the Klipper configuration file is using the +Arguably the easiest way to set the Kalico configuration file is using the built in editors in Mainsail or Fluidd. These will allow the user to open the configuration examples and save them to be printer.cfg. @@ -193,7 +193,7 @@ nano ~/printer.cfg ``` It's common for each printer to have its own unique name for the -micro-controller. The name may change after flashing Klipper, so rerun +micro-controller. The name may change after flashing Kalico, so rerun these steps again even if they were already done when flashing. Run: ``` @@ -216,21 +216,21 @@ serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 After creating and editing the file it will be necessary to issue a "restart" command in the command console to load the config. A -"status" command will report the printer is ready if the Klipper +"status" command will report the printer is ready if the Kalico config file is successfully read and the micro-controller is successfully found and configured. When customizing the printer config file, it is not uncommon for -Klipper to report a configuration error. If an error occurs, make any +Kalico to report a configuration error. If an error occurs, make any necessary corrections to the printer config file and issue "restart" until "status" reports the printer is ready. -Klipper reports error messages via the command console and via pop up in +Kalico reports error messages via the command console and via pop up in Fluidd and Mainsail. The "status" command can be used to re-report error messages. A log is available and usually located in ~/printer_data/logs this is named klippy.log -After Klipper reports that the printer is ready, proceed to the +After Kalico reports that the printer is ready, proceed to the [config check document](Config_checks.md) to perform some basic checks on the definitions in the config file. See the main [documentation reference](Overview.md) for other information. diff --git a/docs/Kinematics.md b/docs/Kinematics.md index 1996579d2..dd2df3dec 100644 --- a/docs/Kinematics.md +++ b/docs/Kinematics.md @@ -1,16 +1,16 @@ # Kinematics -This document provides an overview of how Klipper implements robot +This document provides an overview of how Kalico implements robot motion (its [kinematics](https://en.wikipedia.org/wiki/Kinematics)). The contents may be of interest to both developers interested in -working on the Klipper software as well as users interested in better +working on the Kalico software as well as users interested in better understanding the mechanics of their machines. ## Acceleration -Klipper implements a constant acceleration scheme whenever the print +Kalico implements a constant acceleration scheme whenever the print head changes velocity - the velocity is gradually changed to the new -speed instead of suddenly jerking to it. Klipper always enforces +speed instead of suddenly jerking to it. Kalico always enforces acceleration between the tool head and the print. The filament leaving the extruder can be quite fragile - rapid jerks and/or extruder flow changes lead to poor quality and poor bed adhesion. Even when not @@ -20,13 +20,13 @@ filament. Limiting speed changes of the print head (relative to the print) reduces risks of disrupting the print. It is also important to limit acceleration so that the stepper motors -do not skip or put excessive stress on the machine. Klipper limits the +do not skip or put excessive stress on the machine. Kalico limits the torque on each stepper by virtue of limiting the acceleration of the print head. Enforcing acceleration at the print head naturally also limits the torque of the steppers that move the print head (the inverse is not always true). -Klipper implements constant acceleration. The key formula for constant +Kalico implements constant acceleration. The key formula for constant acceleration is: ``` velocity(time) = start_velocity + accel*time @@ -34,7 +34,7 @@ velocity(time) = start_velocity + accel*time ## Trapezoid generator -Klipper uses a traditional "trapezoid generator" to model the motion +Kalico uses a traditional "trapezoid generator" to model the motion of each move - each move has a start speed, it accelerates to a cruising speed at constant acceleration, it cruises at a constant speed, and then decelerates to the end speed using constant @@ -86,7 +86,7 @@ small junction speed is permitted. The junction speeds are determined using "approximated centripetal acceleration". Best [described by the author](https://onehossshay.wordpress.com/2011/09/24/improving_grbl_cornering_algorithm/). -However, in Klipper, junction speeds are configured by specifying the +However, in Kalico, junction speeds are configured by specifying the desired speed that a 90° corner should have (the "square corner velocity"), and the junction speeds for other angles are derived from that. @@ -98,21 +98,21 @@ end_velocity^2 = start_velocity^2 + 2*accel*move_distance ### Minimum cruise ratio -Klipper also implements a mechanism for smoothing out the motions of +Kalico also implements a mechanism for smoothing out the motions of short "zigzag" moves. Consider the following moves: ![zigzag](img/zigzag.svg.png) In the above, the frequent changes from acceleration to deceleration can cause the machine to vibrate which causes stress on the machine -and increases the noise. Klipper implements a mechanism to ensure +and increases the noise. Kalico implements a mechanism to ensure there is always some movement at a cruising speed between acceleration and deceleration. This is done by reducing the top speed of some moves (or sequence of moves) to ensure there is a minimum distance traveled at cruising speed relative to the distance traveled during acceleration and deceleration. -Klipper implements this feature by tracking both a regular move +Kalico implements this feature by tracking both a regular move acceleration as well as a virtual "acceleration to deceleration" rate: ![smoothed](img/smoothed.svg.png) @@ -137,18 +137,18 @@ Once the look-ahead process completes, the print head movement for the given move is fully known (time, start position, end position, velocity at each point) and it is possible to generate the step times for the move. This process is done within "kinematic classes" in the -Klipper code. Outside of these kinematic classes, everything is +Kalico code. Outside of these kinematic classes, everything is tracked in millimeters, seconds, and in cartesian coordinate space. It's the task of the kinematic classes to convert from this generic coordinate system to the hardware specifics of the particular printer. -Klipper uses an +Kalico uses an [iterative solver](https://en.wikipedia.org/wiki/Root-finding_algorithm) to generate the step times for each stepper. The code contains the formulas to calculate the ideal cartesian coordinates of the head at each moment in time, and it has the kinematic formulas to calculate the ideal stepper positions based on those cartesian coordinates. With -these formulas, Klipper can determine the ideal time that the stepper +these formulas, Kalico can determine the ideal time that the stepper should be at each step position. The given steps are then scheduled at these calculated times. @@ -216,7 +216,7 @@ would be smaller. Thus the higher stepper acceleration does not result in significantly higher stepper torque and it is therefore considered harmless. -However, to avoid extreme cases, Klipper enforces a maximum ceiling on +However, to avoid extreme cases, Kalico enforces a maximum ceiling on stepper acceleration of three times the printer's configured maximum move acceleration. (Similarly, the maximum velocity of the stepper is limited to three times the maximum move velocity.) In order to enforce @@ -226,7 +226,7 @@ acceleration and velocity. ### Extruder kinematics -Klipper implements extruder motion in its own kinematic class. Since +Kalico implements extruder motion in its own kinematic class. Since the timing and speed of each print head movement is fully known for each move, it's possible to calculate the step times for the extruder independently from the step time calculations of the print head @@ -270,7 +270,7 @@ See the [pressure advance](Pressure_Advance.md) document for information on how to find this pressure advance coefficient. The basic pressure advance formula can cause the extruder motor to -make sudden velocity changes. Klipper implements "smoothing" of the +make sudden velocity changes. Kalico implements "smoothing" of the extruder movement to avoid this. ![pressure-advance](img/pressure-velocity.png) diff --git a/docs/MCU_Commands.md b/docs/MCU_Commands.md index 9b8a4eb65..665767f4c 100644 --- a/docs/MCU_Commands.md +++ b/docs/MCU_Commands.md @@ -1,8 +1,8 @@ # MCU commands This document provides information on the low-level micro-controller -commands that are sent from the Klipper "host" software and processed -by the Klipper micro-controller software. This document is not an +commands that are sent from the Kalico "host" software and processed +by the Kalico micro-controller software. This document is not an authoritative reference for these commands, nor is it an exclusive list of all available commands. @@ -52,7 +52,7 @@ Most commands in the micro-controller require an initial setup before they can be successfully invoked. This section provides an overview of the configuration process. This section and the following sections are likely only of interest to developers interested in the internal -details of Klipper. +details of Kalico. When the host first connects to the micro-controller it always starts by obtaining a data dictionary (see [protocol](Protocol.md) for more @@ -178,7 +178,7 @@ This section lists some commonly used config commands. ## Common commands This section lists some commonly used run-time commands. It is likely -only of interest to developers looking to gain insight into Klipper. +only of interest to developers looking to gain insight into Kalico. * `set_digital_out_pwm_cycle oid=%c cycle_ticks=%u` : This command configures a digital output pin (as created by config_digital_out) diff --git a/docs/MPC.md b/docs/MPC.md index e8c80cfec..3c17f6f05 100644 --- a/docs/MPC.md +++ b/docs/MPC.md @@ -14,7 +14,7 @@ MPC offers several advantages over PID control: - **Effective for high and low flow hotends:** Regardless of the flow rate of the hotend, MPC maintains effective temperature control. > [!CAUTION] -> This feature controls the portions of the 3D printer that can get very hot. All standard Danger Klipper warnings apply. Please report all issues and bugs to github or discord. +> This feature controls the portions of the 3D printer that can get very hot. All standard Kalico warnings apply. Please report all issues and bugs to [GitHub](https://github.com/KalicoCrew/kalico/issues) or [Discord](Contact.md#discord). # Basic Configuration @@ -194,7 +194,7 @@ MPC_CALIBRATE HEATER=extruder FAN_BREAKPOINTS=7 After successful calibration the method will generate the key model parameters into the log for future reference. -![Calibration Parameter Output](/docs/img/MPC_calibration_output.png) +![Calibration Parameter Output](img/MPC_calibration_output.png) A `SAVE_CONFIG` command is then required to commit these calibrated model parameters to the printer config or the user can manually update the values. The _SAVE_CONFIG_ block should then look like: @@ -232,7 +232,7 @@ These model parameters are not suitable for pre-configuration or are not explici The following macro can be used to replace `M109` hotend temperature set and `M190` bed temperature set G-code commands with a macro utilizing `temperature_wait` G-codes. This can be utilized in systems where the sensor temperature takes an extended time to converge on the set temperature. > [!NOTE] -> This behaviour occurs primarily because MPC controls the modelled block temperature and not the hotend temperature sensor. For almost all cases, when temperature sensor overshoot/undershoot occurs, the block modelled temperature will be correctly at the set temperature. However, the Klipper system performs actions based on the sensor temperature only which can lead to undesirable delays in print actions with stock `M109` and `M190` commands. +> This behaviour occurs primarily because MPC controls the modelled block temperature and not the hotend temperature sensor. For almost all cases, when temperature sensor overshoot/undershoot occurs, the block modelled temperature will be correctly at the set temperature. However, the Kalico system performs actions based on the sensor temperature only which can lead to undesirable delays in print actions with stock `M109` and `M190` commands. ``` [gcode_macro M109] # Wait Hotend Temp @@ -334,7 +334,7 @@ The real-time temperatures and model states can be viewed from a browser by ente https://192.168.xxx.xxx:7125/printer/objects/query?extruder ``` -![Calibration](/docs/img/MPC_realtime_output.png) +![Calibration](img/MPC_realtime_output.png) # EXPERIMENTAL FEATURES diff --git a/docs/Manual_Level.md b/docs/Manual_Level.md index c9aafa933..b08a934af 100644 --- a/docs/Manual_Level.md +++ b/docs/Manual_Level.md @@ -44,7 +44,7 @@ crashes. Some printers have the ability to manually adjust the location of the physical endstop switch. However, it's recommended to perform Z -endstop positioning in software with Klipper - once the physical +endstop positioning in software with Kalico - once the physical location of the endstop is in a convenient location, one can make any further adjustments by running Z_ENDSTOP_CALIBRATE or by manually updating the Z position_endstop in the configuration file. @@ -55,7 +55,7 @@ The secret to getting good bed leveling with bed leveling screws is to utilize the printer's high precision motion system during the bed leveling process itself. This is done by commanding the nozzle to a position near each bed screw and then adjusting that screw until the -bed is a set distance from the nozzle. Klipper has a tool to assist +bed is a set distance from the nozzle. Kalico has a tool to assist with this. In order to use the tool it is necessary to specify each screw XY location. diff --git a/docs/Measuring_Resonances.md b/docs/Measuring_Resonances.md index 6152c6aba..114186507 100644 --- a/docs/Measuring_Resonances.md +++ b/docs/Measuring_Resonances.md @@ -1,13 +1,13 @@ # Measuring Resonances -Klipper has built-in support for the ADXL345, MPU-9250 and LIS2DW compatible +Kalico 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. +interface of an MCU board that supports 400kbit/s *fast mode* in Kalico. 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 @@ -20,7 +20,7 @@ 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 +## MCUs with Kalico I2C *fast-mode* Support | MCU Family | MCU(s) Tested | MCU(s) with Support | |:--:|:--|:--| @@ -93,7 +93,7 @@ Fritzing wiring diagrams for some of the ADXL345 boards: 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 +accelerometer on other Kalico 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. @@ -210,7 +210,7 @@ sudo apt update sudo apt install python3-numpy python3-matplotlib libatlas-base-dev libopenblas-dev ``` -Next, in order to install NumPy in the Klipper environment, run the command: +Next, in order to install NumPy in the Kalico environment, run the command: ``` ~/klippy-env/bin/pip install -v numpy ``` @@ -229,7 +229,7 @@ The correct output should simply be a new line. First, check and follow the instructions in the [RPi Microcontroller document](RPi_microcontroller.md) to setup the -"linux mcu" on the Raspberry Pi. This will configure a second Klipper +"linux mcu" on the Raspberry Pi. This will configure a second Kalico instance that runs on your Pi. Make sure the Linux SPI driver is enabled by running `sudo @@ -309,7 +309,7 @@ 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. +Restart Kalico via the `RESTART` command. #### Configure LIS2DW series @@ -391,7 +391,7 @@ probe_points: 100, 100, 20 # an example ``` -Restart Klipper via the `RESTART` command. +Restart Kalico via the `RESTART` command. ## Measuring the resonances @@ -502,7 +502,7 @@ 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 auto-calibration -from Klipper [directly](#input-shaper-auto-calibration), which can be +from Kalico [directly](#input-shaper-auto-calibration), which can be convenient, for example, for the input shaper [re-calibration](#input-shaper-re-calibration). @@ -592,7 +592,7 @@ Note that the reported `smoothing` values are some abstract projected values. These values can be used to compare different configurations: the higher the value, the more smoothing a shaper will create. However, these smoothing scores do not represent any real measure of smoothing, because the actual smoothing -depends on [`max_accel`](#selecting-max-accel) and `square_corner_velocity` +depends on [`max_accel`](#selecting-max_accel) and `square_corner_velocity` parameters. Therefore, you should print some test prints to see how much smoothing exactly a chosen configuration creates. @@ -643,7 +643,7 @@ probe_points: ... max_smoothing: 0.25 # an example ``` Then, if you [rerun](#input-shaper-re-calibration) the input shaper auto-tuning -using `SHAPER_CALIBRATE` Klipper command in the future, it will use the stored +using `SHAPER_CALIBRATE` Kalico command in the future, it will use the stored `max_smoothing` value as a reference. ### Selecting max_accel @@ -723,7 +723,7 @@ to generate `/tmp/resonances.png` comparing the resonances. Besides manually choosing the appropriate parameters for the input shaper feature, it is also possible to run the auto-tuning for the input shaper -directly from Klipper. Run the following command via Octoprint terminal: +directly from Kalico. Run the following command via Octoprint terminal: ``` SHAPER_CALIBRATE ``` @@ -749,7 +749,7 @@ To avoid too much smoothing with '3hump_ei', suggested max_accel <= 2500 mm/sec^ Recommended shaper_type_y = mzv, shaper_freq_y = 36.8 Hz ``` If you agree with the suggested parameters, you can execute `SAVE_CONFIG` -now to save them and restart the Klipper. Note that this will not update +now to save them and restart the Kalico. Note that this will not update `max_accel` value in `[printer]` section. You should update it manually following the considerations in [Selecting max_accel](#selecting-max_accel) section. diff --git a/docs/Migrating_from_Klipper.md b/docs/Migrating_from_Klipper.md new file mode 100644 index 000000000..741be7f4c --- /dev/null +++ b/docs/Migrating_from_Klipper.md @@ -0,0 +1,2 @@ +# Migrating from Klipper + diff --git a/docs/Multi_MCU_Homing.md b/docs/Multi_MCU_Homing.md index c32a5947c..2d3e31065 100644 --- a/docs/Multi_MCU_Homing.md +++ b/docs/Multi_MCU_Homing.md @@ -1,6 +1,6 @@ # Multiple Micro-controller Homing and Probing -Klipper supports a mechanism for homing with an endstop attached to +Kalico supports a mechanism for homing with an endstop attached to one micro-controller while its stepper motors are on a different micro-controller. This support is referred to as "multi-mcu homing". This feature is also used when a Z probe is on a different @@ -13,7 +13,7 @@ motors during homing and probing operations. The overshoot occurs due to possible message transmission delays between the micro-controller monitoring the endstop and the -micro-controllers moving the stepper motors. The Klipper code is +micro-controllers moving the stepper motors. The Kalico code is designed to limit this delay to no more than 25ms. (When multi-mcu homing is activated, the micro-controllers send periodic status messages and check that corresponding status messages are received @@ -26,7 +26,7 @@ overshoot. Using slower homing or probing speeds can reduce the overshoot. Stepper motor overshoot should not adversely impact the precision of -the homing and probing procedure. The Klipper code will detect the +the homing and probing procedure. The Kalico code will detect the overshoot and account for it in its calculations. However, it is important that the hardware design is capable of handling overshoot without causing damage to the machine. @@ -38,7 +38,7 @@ less than 10ms. High latency (even for short periods) is likely to result in homing failures. Should high latency result in a failure (or if some other -communication issue is detected) then Klipper will raise a +communication issue is detected) then Kalico will raise a "Communication timeout during homing" error. Note that an axis with multiple steppers (eg, `stepper_z` and diff --git a/docs/OctoPrint.md b/docs/OctoPrint.md index 7c13c4934..e2de06a0b 100644 --- a/docs/OctoPrint.md +++ b/docs/OctoPrint.md @@ -1,7 +1,7 @@ -# OctoPrint for Klipper +# Using OctoPrint -Klipper has a few options for its front ends, Octoprint was the first -and original front end for Klipper. This document will give +Kalico has a few options for its front ends, Octoprint was the first +and original front end for Kalico. This document will give a brief overview of installing with this option. ## Install with OctoPi @@ -27,12 +27,12 @@ sudo apt install git then proceed: ``` cd ~ -git clone https://github.com/Klipper3d/klipper +git clone https://github.com/KalicoCrew/kalico klipper ./klipper/scripts/install-octopi.sh ``` -The above will download Klipper, install the needed system dependencies, -setup Klipper to run at system startup, and start the Klipper host +The above will download Kalico, install the needed system dependencies, +setup Kalico to run at system startup, and start the Kalico host software. It will require an internet connection and it may take a few minutes to complete. @@ -42,9 +42,9 @@ KIAUH can be used to install OctoPrint on a variety of Linux based systems that run a form of Debian. More information can be found at https://github.com/dw-0/kiauh -## Configuring OctoPrint to use Klipper +## Configuring OctoPrint to use Kalico -The OctoPrint web server needs to be configured to communicate with the Klipper +The OctoPrint web server needs to be configured to communicate with the Kalico host software. Using a web browser, login to the OctoPrint web page and then configure the following items: @@ -73,7 +73,7 @@ try reloading the page.) Once connected, navigate to the "Terminal" tab and type "status" (without the quotes) into the command entry box and click "Send". The terminal window will likely report there is an error opening the config file - that means OctoPrint is successfully -communicating with Klipper. +communicating with Kalico. Please proceed to [Installation.md](Installation.md) and the _Building and flashing the micro-controller_ section diff --git a/docs/Overview.md b/docs/Overview.md index e9c9fd885..b9e55c622 100644 --- a/docs/Overview.md +++ b/docs/Overview.md @@ -1,30 +1,29 @@ # Overview -Welcome to the Danger-Klipper documentation. If new to Klipper, start with +Welcome to the Kalico documentation. If new to Kalico, start with the [features](Features.md) and [installation](Installation.md) documents. ## Overview information -- [Features](Features.md): A high-level list of features in Klipper. +- [Features](Features.md): A high-level list of features in Kalico. - [FAQ](FAQ.md): Frequently asked questions. -- [Releases](Releases.md): The history of Klipper releases. - [Config changes](Config_Changes.md): Recent software changes that may require users to update their printer config file. - [Contact](Contact.md): Information on bug reporting and general -communication with the Klipper developers. +communication with the Kalico developers. ## Installation and Configuration -- [Installation](Installation.md): Guide to installing Klipper. - - [Octoprint](OctoPrint.md): Guide to installing Octoprint with Klipper. +- [Installation](Installation.md): Guide to installing Kalico. + - [Octoprint](OctoPrint.md): Guide to installing Octoprint with Kalico. - [Config Reference](Config_Reference.md): Description of config parameters. - [Rotation Distance](Rotation_Distance.md): Calculating the rotation_distance stepper parameter. - [Config checks](Config_checks.md): Verify basic pin settings in the config file. -- [Bed level](Bed_Level.md): Information on "bed leveling" in Klipper. +- [Bed level](Bed_Level.md): Information on "bed leveling" in Kalico. - [Delta calibrate](Delta_Calibrate.md): Calibration of delta kinematics. - [Probe calibrate](Probe_Calibrate.md): Calibration of automatic Z @@ -44,15 +43,15 @@ communication with the Klipper developers. using adxl345 accelerometer hardware to measure resonance. - [Pressure advance](Pressure_Advance.md): Calibrate extruder pressure. -- [G-Codes](G-Codes.md): Information on commands supported by Klipper. +- [G-Codes](G-Codes.md): Information on commands supported by Kalico. - [Command Templates](Command_Templates.md): G-Code macros and conditional evaluation. - [Status Reference](Status_Reference.md): Information available to macros (and similar). - [TMC Drivers](TMC_Drivers.md): Using Trinamic stepper motor drivers - with Klipper. + with Kalico. - [Multi-MCU Homing](Multi_MCU_Homing.md): Homing and probing using multiple micro-controllers. -- [Slicers](Slicers.md): Configure "slicer" software for Klipper. +- [Slicers](Slicers.md): Configure "slicer" software for Kalico. - [Skew correction](Skew_Correction.md): Adjustments for axes not perfectly square. - [PWM tools](Using_PWM_Tools.md): Guide on how to use PWM controlled @@ -64,40 +63,39 @@ communication with the Klipper developers. - [Code overview](Code_Overview.md): Developers should read this first. -- [Kinematics](Kinematics.md): Technical details on how Klipper +- [Kinematics](Kinematics.md): Technical details on how Kalico implements motion. - [Protocol](Protocol.md): Information on the low-level messaging protocol between host and micro-controller. -- [API Server](API_Server.md): Information on Klipper's command and +- [API Server](API_Server.md): Information on Kalico's command and control API. - [MCU commands](MCU_Commands.md): A description of low-level commands implemented in the micro-controller software. -- [CAN bus protocol](CANBUS_protocol.md): Klipper CAN bus message +- [CAN bus protocol](CANBUS_protocol.md): Kalico CAN bus message format. - [Debugging](Debugging.md): Information on how to test and debug - Klipper. -- [Benchmarks](Benchmarks.md): Information on the Klipper benchmark + Kalico. +- [Benchmarks](Benchmarks.md): Information on the Kalico benchmark method. - [Contributing](CONTRIBUTING.md): Information on how to submit - improvements to Klipper. + improvements to Kalico. - [Packaging](Packaging.md): Information on building OS packages. ## Device Specific Documents - [Example configs](Example_Configs.md): Information on adding an - example config file to Klipper. + example config file to Kalico. - [SDCard Updates](SDCard_Updates.md): Flash a micro-controller by copying a binary to an sdcard in the micro-controller. - [Raspberry Pi as Micro-controller](RPi_microcontroller.md): Details for controlling devices wired to the GPIO pins of a Raspberry Pi. -- [Beaglebone](Beaglebone.md): Details for running Klipper on the +- [Beaglebone](Beaglebone.md): Details for running Kalico on the 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](CANBUS.md): Information on using CAN bus with Kalico. - [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) -- [Eddy Current Inductive probe](Eddy_Probe.md) diff --git a/docs/PID.md b/docs/PID.md index 43aa586be..edea96836 100644 --- a/docs/PID.md +++ b/docs/PID.md @@ -4,9 +4,10 @@ PID control is a widely used control method in the 3D printing world. It’s ubiquitous when it comes to temperature control, be it with heaters to generate heat or fans to remove heat. This document aims to provide a -high-level overview of what PID is and how to use it best in Klipper. +high-level overview of what PID is and how to use it best in Kalico. ## PID Calibration + ### Preparing the Calibration When a calibration test is performed external influences should be minimized as much as possible: @@ -18,7 +19,7 @@ much as possible: More important than listed above, **PID how you print**. If your part fans are on when printing, PID tune with them on. ### Choosing the right PID Algorithm -Klipper offers two different PID algorithms: Positional and Velocity +Kalico offers two different PID algorithms: Positional and Velocity * Positional (`pid`) * The standard algorithm @@ -100,10 +101,10 @@ In 2019 Brandon Taysom & Carl Sorensen published their paper "Adaptive Relay Autotuning under Static and Non-static Disturbances with Application to Friction Stir Welding", which laid out a method to generate more accurate results from a relay test. This is the PID calibration method currently used by -Klipper. +Kalico. ### Details of the Relay Test -As previously mentioned, Klipper uses a relay test for calibration purposes. A +As previously mentioned, Kalico uses a relay test for calibration purposes. A standard relay test is conceptually simple. You turn the heater’s power on and off to get it to oscillate about the target temperature, as seen in the following graph. @@ -147,7 +148,7 @@ parameters. with these parameters and restart the printer. ``` -When asymmetry starts off negative, It will not converge to zero. If Klipper +When asymmetry starts off negative, It will not converge to zero. If Kalico does not error out, the calibration run will complete and provide good PID parameters, However the heater is less likely to handle disturbances as well as a heater with power in reserve. @@ -165,7 +166,7 @@ as a heater with power in reserve. ### Pid Control Algorithms -Klipper currently supports two control algorithms: Positional and Velocity. +Kalico currently supports two control algorithms: Positional and Velocity. The fundamental difference between the two algorithms is that the Positional algorithm calculates what the PWM value should be for the current time interval, and the Velocity algorithm calculates how much the previous PWM diff --git a/docs/Packaging.md b/docs/Packaging.md index 9e9b1627b..1fd62b9da 100644 --- a/docs/Packaging.md +++ b/docs/Packaging.md @@ -1,12 +1,12 @@ -# Packaging Klipper +# Packaging Kalico -Klipper is somewhat of a packaging anomaly among python programs, as it doesn't +Kalico is somewhat of a packaging anomaly among python programs, as it doesn't use setuptools to build and install. Some notes regarding how best to package it are as follows: ## C modules -Klipper uses a C module to handle some kinematics calculations more quickly. +Kalico uses a C module to handle some kinematics calculations more quickly. This module needs to be compiled at packaging time to avoid introducing a runtime dependency on a compiler. To compile the C module, run `python2 klippy/chelper/__init__.py`. @@ -19,7 +19,7 @@ klippy`. ## Versioning -If you are building a package of Klipper from git, it is usual practice not to +If you are building a package of Kalico from git, it is usual practice not to ship a .git directory, so the versioning must be handled without git. To do this, use the script shipped in `scripts/make_version.py` which should be run as follows: `python2 scripts/make_version.py YOURDISTRONAME > klippy/.version`. diff --git a/docs/Pressure_Advance.md b/docs/Pressure_Advance.md index 2f3601cab..fdd6516e5 100644 --- a/docs/Pressure_Advance.md +++ b/docs/Pressure_Advance.md @@ -42,7 +42,7 @@ Then print the object. When fully printed the test print looks like: ![tuning_tower](img/tuning_tower.jpg) -The above TUNING_TOWER command instructs Klipper to alter the +The above TUNING_TOWER command instructs Kalico to alter the pressure_advance setting on each layer of the print. Higher layers in the print will have a larger pressure advance value set. Layers below the ideal pressure_advance setting will have blobbing at the corners, @@ -128,7 +128,7 @@ cornering speeds to their normal values. enough torque to push the required filament. If this occurs, either use a lower acceleration value or disable pressure advance. -* Once pressure advance is tuned in Klipper, it may still be useful to +* Once pressure advance is tuned in Kalico, it may still be useful to configure a small retract value in the slicer (eg, 0.75mm) and to utilize the slicer's "wipe on retract option" if available. These slicer settings may help counteract ooze caused by filament cohesion diff --git a/docs/Probe_Calibrate.md b/docs/Probe_Calibrate.md index 5f1d44365..c59bdac96 100644 --- a/docs/Probe_Calibrate.md +++ b/docs/Probe_Calibrate.md @@ -1,7 +1,7 @@ # Probe calibration This document describes the method for calibrating the X, Y, and Z -offsets of an "automatic z probe" in Klipper. This is useful for users +offsets of an "automatic z probe" in Kalico. This is useful for users that have a `[probe]` or `[bltouch]` section in their config file. ## Calibrating probe X and Y offsets @@ -47,7 +47,7 @@ the new values take effect. Providing an accurate probe z_offset is critical to obtaining high quality prints. The z_offset is the distance between the nozzle and -bed when the probe triggers. The Klipper `PROBE_CALIBRATE` tool can be +bed when the probe triggers. The Kalico `PROBE_CALIBRATE` tool can be used to obtain this value - it will run an automatic probe to measure the probe's Z trigger position and then start a manual probe to obtain the nozzle Z height. The probe z_offset will then be calculated from @@ -141,7 +141,7 @@ update the printer.cfg file and issue a `RESTART` command. If so, it is a good idea to [calibrate the z_offset](#calibrating-probe-z-offset) again. If repeatable results can not be obtained then don't use the probe for -bed leveling. Klipper has several manual probing tools that can be +bed leveling. Kalico has several manual probing tools that can be used instead - see the [Bed Level document](Bed_Level.md) for further details. diff --git a/docs/Protocol.md b/docs/Protocol.md index ce5719e19..f0a55ddcf 100644 --- a/docs/Protocol.md +++ b/docs/Protocol.md @@ -1,7 +1,7 @@ # Protocol -The Klipper messaging protocol is used for low-level communication -between the Klipper host software and the Klipper micro-controller +The Kalico messaging protocol is used for low-level communication +between the Kalico host software and the Kalico micro-controller software. At a high level the protocol can be thought of as a series of command and response strings that are compressed, transmitted, and then processed at the receiving side. An example series of commands in @@ -20,7 +20,7 @@ available commands. See the [debugging](Debugging.md) document for information on how to translate a G-Code file into its corresponding human-readable micro-controller commands. -This page provides a high-level description of the Klipper messaging +This page provides a high-level description of the Kalico messaging protocol itself. It describes how messages are declared, encoded in binary format (the "compression" scheme), and transmitted. @@ -30,7 +30,7 @@ low-bandwidth, and low-complexity for the micro-controller. ## Micro-controller Interface -The Klipper transmission protocol can be thought of as a +The Kalico transmission protocol can be thought of as a [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) mechanism between micro-controller and host. The micro-controller software declares the commands that the host may invoke along with the response @@ -229,7 +229,7 @@ the message block contents. See the [wikipedia article](https://en.wikipedia.org/wiki/Variable-length_quantity) for more information on the general format of VLQ encoded -integers. Klipper uses an encoding scheme that supports both positive +integers. Kalico uses an encoding scheme that supports both positive and negative integers. Integers close to zero use less bytes to encode and positive integers typically encode using less bytes than negative integers. The following table shows the number of bytes each integer diff --git a/docs/README.md b/docs/README.md deleted file mode 100644 index e80583ddc..000000000 --- a/docs/README.md +++ /dev/null @@ -1,2 +0,0 @@ -Welcome to the Danger-Klipper documentation. The -[overview document](Overview.md) is a good starting point. diff --git a/docs/RPi_microcontroller.md b/docs/RPi_microcontroller.md index 96ac5626f..e2c3d16fb 100644 --- a/docs/RPi_microcontroller.md +++ b/docs/RPi_microcontroller.md @@ -1,6 +1,6 @@ # RPi microcontroller -This document describes the process of running Klipper on a RPi and +This document describes the process of running Kalico on a RPi and use the same RPi as secondary mcu. ## Why use RPi as a secondary MCU? @@ -8,9 +8,9 @@ use the same RPi as secondary mcu. Often the MCUs dedicated to controlling 3D printers have a limited and pre-configured number of exposed pins to manage the main printing functions (thermal resistors, extruders, steppers ...). Using the RPi -where Klipper is installed as a secondary MCU gives the possibility to +where Kalico is installed as a secondary MCU gives the possibility to directly use the GPIOs and the buses (i2c, spi) of the RPi inside -klipper without using Octoprint plugins (if used) or external programs +Kalico without using Octoprint plugins (if used) or external programs giving the ability to control everything within the print GCODE. **Warning**: If your platform is a _Beaglebone_ and you have correctly @@ -22,7 +22,7 @@ and configured for your system. If you want to use the host as a secondary MCU the klipper_mcu process must run before the klippy process. -After installing Klipper, install the script. run: +After installing Kalico, install the script. run: ``` cd ~/klipper/ sudo cp ./scripts/klipper-mcu.service /etc/systemd/system/ @@ -31,7 +31,7 @@ sudo systemctl enable klipper-mcu.service ## Building the micro-controller code -To compile the Klipper micro-controller code, start by configuring it +To compile the Kalico micro-controller code, start by configuring it for the "Linux process": ``` cd ~/klipper/ @@ -58,7 +58,7 @@ sudo usermod -a -G tty pi ## Remaining configuration -Complete the installation by configuring Klipper secondary MCU +Complete the installation by configuring Kalico secondary MCU following the instructions in [RaspberryPi sample config](../config/sample-raspberry-pi.cfg) and [Multi MCU sample config](../config/sample-multi-mcu.cfg). @@ -81,7 +81,7 @@ to set the baud rate to 400000 by: adding/uncommenting ## Optional: Identify the correct gpiochip On Raspberry Pi and on many clones the pins exposed on the GPIO belong -to the first gpiochip. They can therefore be used on klipper simply by +to the first gpiochip. They can therefore be used on Kalico simply by referring them with the name `gpio0..n`. However, there are cases in which the exposed pins belong to gpiochips other than the first. For example in the case of some OrangePi models or if a Port Expander is @@ -112,7 +112,7 @@ gpioinfo` command. ***Warning:*** only gpio marked as `unused` can be used. It is not possible for a _line_ to be used by multiple processes simultaneously. -For example on a RPi 3B+ where klipper use the GPIO20 for a switch: +For example on a RPi 3B+ where Kalico use the GPIO20 for a switch: ``` $ gpiodetect gpiochip0 [pinctrl-bcm2835] (54 lines) diff --git a/docs/Releases.md b/docs/Releases.md deleted file mode 100644 index 3e9dd9391..000000000 --- a/docs/Releases.md +++ /dev/null @@ -1,291 +0,0 @@ -# Releases - -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: -* Support for "Multi-MCU Homing". It is now possible for a stepper - motor and its endstop to be wired to separate micro-controllers. - This simplifies wiring of Z probes on "toolhead boards". -* Klipper now has a - [Community Discord Server](https://discord.klipper3d.org) - and a [Community Discourse Server](https://community.klipper3d.org). -* The [Klipper website](https://DangerKlippers.github.io/danger-klipper) now uses the - "mkdocs" infrastructure. There is also a - [Klipper Translations](https://github.com/DangerKlippers/danger-klipper-translations) - project. -* Automated support for flashing firmware via sdcard on many boards. -* New kinematic support for "Hybrid CoreXY" and "Hybrid CoreXZ" - printers. -* Klipper now uses `rotation_distance` to configure stepper motor - travel distances. -* The main Klipper host code can now directly communicate with - micro-controllers using CAN bus. -* New "motion analysis" system. Klipper's internal motion updates and - sensor results can be tracked and logged for analysis. -* Trinamic stepper motor drivers are now continuously monitored for - error conditions. -* Support for the rp2040 micro-controller (Raspberry Pi Pico boards). -* The "make menuconfig" system now utilizes kconfiglib. -* Many additional modules added: ds18b20, duplicate_pin_override, - filament_motion_sensor, palette2, motion_report, pca9533, - pulse_counter, save_variables, sdcard_loop, temperature_host, - temperature_mcu -* Several bug fixes and code cleanups. - -## Klipper 0.9.0 - -Available on 20201020. Major changes in this release: -* Support for "Input Shaping" - a mechanism to counteract printer - resonance. It can reduce or eliminate "ringing" in prints. -* New "Smooth Pressure Advance" system. This implements "Pressure - Advance" without introducing instantaneous velocity changes. It is - also now possible to tune pressure advance using a "Tuning Tower" - method. -* New "webhooks" API server. This provides a programmable JSON - interface to Klipper. -* The LCD display and menu are now configurable using the Jinja2 - template language. -* The TMC2208 stepper motor drivers can now be used in "standalone" - mode with Klipper. -* Improved BL-Touch v3 support. -* Improved USB identification. Klipper now has its own USB - identification code and micro-controllers can now report their - unique serial numbers during USB identification. -* New kinematic support for "Rotary Delta" and "CoreXZ" printers. -* Micro-controller improvements: support for stm32f070, support for - stm32f207, support for GPIO pins on "Linux MCU", stm32 "HID - bootloader" support, Chitu bootloader support, MKS Robin bootloader - support. -* Improved handling of Python "garbage collection" events. -* Many additional modules added: adc_scaled, adxl345, bme280, - display_status, extruder_stepper, fan_generic, - hall_filament_width_sensor, htu21d, homing_heaters, input_shaper, - lm75, print_stats, resonance_tester, shaper_calibrate, query_adc, - graph_accelerometer, graph_extruder, graph_motion, graph_shaper, - graph_temp_sensor, whconsole -* Several bug fixes and code cleanups. - -### Klipper 0.9.1 - -Available on 20201028. Release containing only bug fixes. - -## Klipper 0.8.0 - -Available on 20191021. Major changes in this release: -* New G-Code command template support. G-Code in the config file is - now evaluated with the Jinja2 template language. -* Improvements to Trinamic stepper drivers: - * New support for TMC2209 and TMC5160 drivers. - * Improved DUMP_TMC, SET_TMC_CURRENT, and INIT_TMC G-Code commands. - * Improved support for TMC UART handling with an analog mux. -* Improved homing, probing, and bed leveling support: - * New manual_probe, bed_screws, screws_tilt_adjust, skew_correction, - safe_z_home modules added. - * Enhanced multi-sample probing with median, average, and retry - logic. - * Improved documentation for BL-Touch, probe calibration, endstop - calibration, delta calibration, sensorless homing, and endstop - phase calibration. - * Improved homing support on a large Z axis. -* Many Klipper micro-controller improvements: - * Klipper ported to: SAM3X8C, SAM4S8C, SAMD51, STM32F042, STM32F4 - * New USB CDC driver implementations on SAM3X, SAM4, STM32F4. - * Enhanced support for flashing Klipper over USB. - * Software SPI support. - * Greatly improved temperature filtering on the LPC176x. - * Early output pin settings can be configured in the - micro-controller. -* New website with the Klipper documentation: http://klipper3d.org/ - * Klipper now has a logo. -* Experimental support for polar and "cable winch" kinematics. -* The config file can now include other config files. -* Many additional modules added: board_pins, controller_fan, - delayed_gcode, dotstar, filament_switch_sensor, firmware_retraction, - gcode_arcs, gcode_button, heater_generic, manual_stepper, mcp4018, - mcp4728, neopixel, pause_resume, respond, temperature_sensor - tsl1401cl_filament_width_sensor, tuning_tower -* Many additional commands added: RESTORE_GCODE_STATE, - SAVE_GCODE_STATE, SET_GCODE_VARIABLE, SET_HEATER_TEMPERATURE, - SET_IDLE_TIMEOUT, SET_TEMPERATURE_FAN_TARGET -* Several bug fixes and code cleanups. - -## Klipper 0.7.0 - -Available on 20181220. Major changes in this release: -* Klipper now supports "mesh" bed leveling -* New support for "enhanced" delta calibration (calibrates print x/y - dimensions on delta printers) -* Support for run-time configuration of Trinamic stepper motor drivers - (tmc2130, tmc2208, tmc2660) -* Improved temperature sensor support: MAX6675, MAX31855, MAX31856, - MAX31865, custom thermistors, common pt100 style sensors -* Several new modules: temperature_fan, sx1509, force_move, mcp4451, - z_tilt, quad_gantry_level, endstop_phase, bltouch -* Several new commands added: SAVE_CONFIG, SET_PRESSURE_ADVANCE, - SET_GCODE_OFFSET, SET_VELOCITY_LIMIT, STEPPER_BUZZ, TURN_OFF_HEATERS, - M204, custom g-code macros -* Expanded LCD display support: - * Support for run-time menus - * New display icons - * Support for "uc1701" and "ssd1306" displays -* Additional micro-controller support: - * Klipper ported to: LPC176x (Smoothieboards), SAM4E8E (Duet2), - SAMD21 (Arduino Zero), STM32F103 ("Blue pill" devices), atmega32u4 - * New Generic USB CDC driver implemented on AVR, LPC176x, SAMD21, and - STM32F103 - * Performance improvements on ARM processors -* The kinematics code was rewritten to use an "iterative solver" -* New automatic test cases for the Klipper host software -* Many new example config files for common off-the-shelf printers -* Documentation updates for bootloaders, benchmarking, - micro-controller porting, config checks, pin mapping, slicer - settings, packaging, and more -* Several bug fixes and code cleanups - -## Klipper 0.6.0 - -Available on 20180331. Major changes in this release: -* Enhanced heater and thermistor hardware failure checks -* Support for Z probes -* Initial support for automatic parameter calibration on deltas (via a - new delta_calibrate command) -* Initial support for bed tilt compensation (via bed_tilt_calibrate - command) -* Initial support for "safe homing" and homing overrides -* Initial support for displaying status on RepRapDiscount style 2004 - and 12864 displays -* New multi-extruder improvements: - * Support for shared heaters - * Initial support for dual carriages -* Support for configuring multiple steppers per axis (eg, dual Z) -* Support for custom digital and pwm output pins (with a new SET_PIN command) -* Initial support for a "virtual sdcard" that allows printing directly - from Klipper (helps on machines too slow to run OctoPrint well) -* Support for setting different arm lengths on each tower of a delta -* Support for G-Code M220/M221 commands (speed factor override / - extrude factor override) -* Several documentation updates: - * Many new example config files for common off-the-shelf printers - * New multiple MCU config example - * New bltouch sensor config example - * New FAQ, config check, and G-Code documents -* Initial support for continuous integration testing on all github commits -* Several bug fixes and code cleanups - -## Klipper 0.5.0 - -Available on 20171025. Major changes in this release: - -* Support for printers with multiple extruders. -* Initial support for running on the Beaglebone PRU. Initial support - for the Replicape board. -* Initial support for running the micro-controller code in a real-time - Linux process. -* Support for multiple micro-controllers. (For example, one could - control an extruder with one micro-controller and the rest of the - printer with another.) Software clock synchronization is implemented - to coordinate actions between micro-controllers. -* Stepper performance improvements (20Mhz AVRs up to 189K steps per - second). -* Support for controlling servos and support for defining nozzle - cooling fans. -* Several bug fixes and code cleanups - -## Klipper 0.4.0 - -Available on 20170503. Major changes in this release: - -* Improved installation on Raspberry Pi machines. Most of the install - is now scripted. -* Support for corexy kinematics -* Documentation updates: New Kinematics document, new Pressure Advance - tuning guide, new example config files, and more -* Stepper performance improvements (20Mhz AVRs over 175K steps per - second, Arduino Due over 460K) -* Support for automatic micro-controller resets. Support for resets - via toggling USB power on Raspberry Pi. -* The pressure advance algorithm now works with look-ahead to reduce - pressure changes during cornering. -* Support for limiting the top speed of short zigzag moves -* Support for AD595 sensors -* Several bug fixes and code cleanups - -## Klipper 0.3.0 - -Available on 20161223. Major changes in this release: - -* Improved documentation -* Support for robots with delta kinematics -* Support for Arduino Due micro-controller (ARM cortex-M3) -* Support for USB based AVR micro-controllers -* Support for "pressure advance" algorithm - it reduces ooze during - prints. -* New "stepper phased based endstop" feature - enables higher - precision on endstop homing. -* Support for "extended g-code" commands such as "help", "restart", - and "status". -* Support for reloading the Klipper config and restarting the host - software by issuing a "restart" command from the terminal. -* Stepper performance improvements (20Mhz AVRs up to 158K steps per - second). -* Improved error reporting. Most errors now shown via the terminal - along with help on how to resolve. -* Several bug fixes and code cleanups - -## Klipper 0.2.0 - -Initial release of Klipper. Available on 20160525. Major features -available in the initial release include: - -* Basic support for cartesian printers (steppers, extruder, heated - bed, cooling fan). -* Support for common g-code commands. Support for interfacing with - OctoPrint. -* Acceleration and lookahead handling -* Support for AVR micro-controllers via standard serial ports diff --git a/docs/Resonance_Compensation.md b/docs/Resonance_Compensation.md index 8f2d2b643..a17b2c6ff 100644 --- a/docs/Resonance_Compensation.md +++ b/docs/Resonance_Compensation.md @@ -1,6 +1,6 @@ # Resonance Compensation -Klipper supports Input Shaping - a technique that can be used to reduce ringing +Kalico 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 printing defect when, typically, elements like edges repeat themselves on a printed surface as a subtle 'echo': @@ -136,7 +136,7 @@ For the example above, we get shaper_freq_x/y = 49.4. ### Choosing input shaper -Klipper supports several input shapers. They differ in their sensitivity to +Kalico supports several input shapers. They differ in their sensitivity to errors determining the resonance frequency and how much smoothing they cause in the printed parts. Also, some of the shapers like 2HUMP_EI and 3HUMP_EI should usually not be used with shaper_freq = resonance frequency - they are @@ -311,7 +311,7 @@ new `shaper_freq_x` and `shaper_freq_y` values. If you use Pressure Advance, it may need to be re-tuned. Follow the [instructions](Pressure_Advance.md#tuning-pressure-advance) to find the new value, if it differs from the previous one. Make sure to -restart Klipper before tuning Pressure Advance. +restart Kalico before tuning Pressure Advance. ### Unreliable measurements of ringing frequencies @@ -457,7 +457,7 @@ parameter described in [this section](#selecting-max_accel)). ### Input shapers -Input shapers used in Klipper are rather standard, and one can find more +Input shapers used in Kalico are rather standard, and one can find more in-depth overview in the articles describing the corresponding shapers. This section contains a brief overview of some technical aspects of the supported input shapers. The table below shows some (usually approximate) @@ -476,7 +476,7 @@ A note on vibration reduction: the values in the table above are approximate. If the damping ratio of the printer is known for each axis, the shaper can be configured more precisely and it will then reduce the resonances in a bit wider range of frequencies. However, the damping ratio is usually unknown and is hard -to estimate without a special equipment, so Klipper uses 0.1 value by default, +to estimate without a special equipment, so Kalico uses 0.1 value by default, which is a good all-round value. The frequency ranges in the table cover a number of different possible damping ratios around that value (approx. from 0.05 to 0.2). diff --git a/docs/Rotation_Distance.md b/docs/Rotation_Distance.md index 142fe250c..83d270448 100644 --- a/docs/Rotation_Distance.md +++ b/docs/Rotation_Distance.md @@ -1,6 +1,6 @@ # Rotation distance -Stepper motor drivers on Klipper require a `rotation_distance` +Stepper motor drivers on Kalico require a `rotation_distance` parameter in each [stepper config section](Config_Reference.md#stepper). The `rotation_distance` is the amount of distance that the axis moves with @@ -17,7 +17,7 @@ distance: rotation_distance = * / ``` -Or, if you have an older Klipper configuration and know the +Or, if you have an older Kalico configuration and know the `step_distance` parameter you can use this formula: ``` rotation_distance = * * diff --git a/docs/SDCard_Updates.md b/docs/SDCard_Updates.md index 432446de7..8579fbdb3 100644 --- a/docs/SDCard_Updates.md +++ b/docs/SDCard_Updates.md @@ -5,7 +5,7 @@ updating firmware via SD Card. While this is convenient in many circumstances, these bootloaders typically provide no other way to update firmware. This can be a nuisance if your board is mounted in a location that is difficult to access or if you need to update firmware often. -After Klipper has been initially flashed to a controller it is possible to +After Kalico has been initially flashed to a controller it is possible to transfer new firmware to the SD Card and initiate the flashing procedure via ssh. @@ -46,7 +46,7 @@ of 250000 and the firmware is located at `~/klipper/out/klipper.bin`. The All options can be viewed by the help screen: ``` ./scripts/flash-sdcard.sh -h -SD Card upload utility for Klipper +SD Card upload utility for Kalico usage: flash_sdcard.sh [-h] [-l] [-c] [-b ] [-f ] @@ -69,7 +69,7 @@ rate it is possible to upgrade by specifying the `-b` option: ./scripts/flash-sdcard.sh -b 115200 /dev/ttyAMA0 btt-skr-v1.3 ``` -If you wish to flash a build of Klipper located somewhere other than +If you wish to flash a build of Kalico located somewhere other than the default location it can be done by specifying the `-f` option: ``` ./scripts/flash-sdcard.sh -f ~/downloads/klipper.bin /dev/ttyAMA0 btt-skr-v1.3 @@ -170,7 +170,7 @@ 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 Discord](Contact.md). +the Kalico [Discord server](Contact.md#discord). ## Flashing Boards that use SDIO diff --git a/docs/Slicers.md b/docs/Slicers.md index afffe7499..ca396dd3c 100644 --- a/docs/Slicers.md +++ b/docs/Slicers.md @@ -1,23 +1,25 @@ # Slicers This document provides some tips for configuring a "slicer" -application for use with Klipper. Common slicers used with Klipper are +application for use with Kalico. Common slicers used with Kalico are Slic3r, Cura, Simplify3D, etc. ## Set the G-Code flavor to Marlin -Many slicers have an option to configure the "G-Code flavor". The -default is frequently "Marlin" and that works well with Klipper. The -"Smoothieware" setting also works well with Klipper. +Many slicers have an option to configure the "G-Code flavor". +Most modern slicers nowadays have a "Klipper" G-Code flavor that works best +for Kalico. +"Marlin" also should work well with Kalico if the "Klipper" flavor is not +available. The "Smoothieware" setting also works well with Kalico. -## Klipper gcode_macro +## Kalico gcode_macro Slicers will often allow one to configure "Start G-Code" and "End G-Code" sequences. It is often convenient to define custom macros in -the Klipper config file instead - such as: `[gcode_macro START_PRINT]` +the Kalico config file instead - such as: `[gcode_macro START_PRINT]` and `[gcode_macro END_PRINT]`. Then one can just run START_PRINT and END_PRINT in the slicer's configuration. Defining these actions in the -Klipper configuration may make it easier to tweak the printer's start +Kalico configuration may make it easier to tweak the printer's start and end steps as changes do not require re-slicing. See [sample-macros.cfg](../config/sample-macros.cfg) for example @@ -26,29 +28,29 @@ START_PRINT and END_PRINT macros. See the [config reference](Config_Reference.md#gcode_macro) for details on defining a gcode_macro. -## Large retraction settings may require tuning Klipper +## Large retraction settings may require tuning Kalico The maximum speed and acceleration of retraction moves are controlled -in Klipper by the `max_extrude_only_velocity` and +in Kalico by the `max_extrude_only_velocity` and `max_extrude_only_accel` config settings. These settings have a default value that should work well on many printers. However, if one has configured a large retraction in the slicer (eg, 5mm or greater) then one may find they limit the desired speed of retractions. -If using a large retraction, consider tuning Klipper's +If using a large retraction, consider tuning Kalico's [pressure advance](Pressure_Advance.md) instead. Otherwise, if one finds the toolhead seems to "pause" during retraction and priming, then consider explicitly defining `max_extrude_only_velocity` and -`max_extrude_only_accel` in the Klipper config file. +`max_extrude_only_accel` in the Kalico config file. ## Do not enable "coasting" The "coasting" feature is likely to result in poor quality prints with -Klipper. Consider using Klipper's +Kalico. Consider using Kalico's [pressure advance](Pressure_Advance.md) instead. Specifically, if the slicer dramatically changes the extrusion rate -between moves then Klipper will perform deceleration and acceleration +between moves then Kalico will perform deceleration and acceleration between moves. This is likely to make blobbing worse, not better. In contrast, it is okay (and often helpful) to use a slicer's @@ -57,33 +59,33 @@ In contrast, it is okay (and often helpful) to use a slicer's ## Do not use "extra restart distance" on Simplify3d This setting can cause dramatic changes to extrusion rates which can -trigger Klipper's maximum extrusion cross-section check. Consider -using Klipper's [pressure advance](Pressure_Advance.md) or the regular +trigger Kalico's maximum extrusion cross-section check. Consider +using Kalico's [pressure advance](Pressure_Advance.md) or the regular Simplify3d retract setting instead. ## Disable "PreloadVE" on KISSlicer If using KISSlicer slicing software then set "PreloadVE" to -zero. Consider using Klipper's [pressure advance](Pressure_Advance.md) +zero. Consider using Kalico's [pressure advance](Pressure_Advance.md) instead. ## Disable any "advanced extruder pressure" settings Some slicers advertise an "advanced extruder pressure" capability. It -is recommended to keep these options disabled when using Klipper as +is recommended to keep these options disabled when using Kalico as they are likely to result in poor quality prints. Consider using -Klipper's [pressure advance](Pressure_Advance.md) instead. +Kalico's [pressure advance](Pressure_Advance.md) instead. Specifically, these slicer settings can instruct the firmware to make wild changes to the extrusion rate in the hope that the firmware will approximate those requests and the printer will roughly obtain a -desirable extruder pressure. Klipper, however, utilizes precise -kinematic calculations and timing. When Klipper is commanded to make +desirable extruder pressure. Kalico, however, utilizes precise +kinematic calculations and timing. When Kalico is commanded to make significant changes to the extrusion rate it will plan out the corresponding changes to velocity, acceleration, and extruder movement - which is not the slicer's intent. The slicer may even command excessive extrusion rates to the point that it triggers -Klipper's maximum extrusion cross-section check. +Kalico'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. diff --git a/docs/Sponsors.md b/docs/Sponsors.md index a226bb57b..de6b1e5ee 100644 --- a/docs/Sponsors.md +++ b/docs/Sponsors.md @@ -1,25 +1,32 @@ # Sponsors -Klipper is Free Software. We depend on the generous support from -sponsors. Please consider sponsoring Klipper or supporting our +Kalico is Free Software. We depend on the generous support from +sponsors. Please consider sponsoring Kalico or supporting our sponsors. -## BIGTREETECH +## Kalico Developers -[](https://bigtree-tech.com/collections/all-products) +### Rogerio Goncalves (@rogerlz) -BIGTREETECH is the official mainboard sponsor of Klipper. BIGTREETECH -is committed to developing innovative and competitive products to -serve the 3D printing community better. Follow them on -[Facebook](https://www.facebook.com/BIGTREETECH) or -[Twitter](https://twitter.com/BigTreeTech). +Rogerio initiated the Kalico project, forking the awesome Klipper firmware originally as "Danger-Klipper" to add some bleeding edge spice to it. -## Sponsors +Contact: [rogerlz@gmail.com](mailto:rogerlz@gmail.com) -[](https://obico.io/klipper.html?source=klipper_sponsor) -[](https://peopoly.net) +### Lasse Dalegaard (@dalegaard) -## Klipper Developers + + +Contact: [dalegaard@gmail.com](mailto:dalegaard@gmail.com) + +### Bea Nance (@bwnance) + + + +Contact: [bwnance@gmail.com](mailto:bwnance@gmail.com) + +## Original Klipper Developers + +See [https://www.klipper3d.org/Sponsors.html](https://www.klipper3d.org/Sponsors.html) for further information. ### Kevin O'Connor @@ -33,9 +40,9 @@ Eric is the author of bed_mesh, spi_flash, and several other Klipper modules. Eric has a donations page at: [https://ko-fi.com/arksine](https://ko-fi.com/arksine) -## Related Klipper Projects +## Related Kalico Projects -Klipper is frequently used with other Free Software. Consider using or +Kalico is frequently used with other Free Software. Consider using or supporting these projects. * [Moonraker](https://github.com/Arksine/moonraker) diff --git a/docs/Status_Reference.md b/docs/Status_Reference.md index fe8c5e504..f6b2e64f0 100644 --- a/docs/Status_Reference.md +++ b/docs/Status_Reference.md @@ -1,14 +1,14 @@ # Status reference This document is a reference of printer status information available -in Klipper [macros](Command_Templates.md), +in Kalico [macros](Command_Templates.md), [display fields](Config_Reference.md#display), and via the [API Server](API_Server.md). The fields in this document are subject to change - if using an attribute be sure to review the [Config Changes document](Config_Changes.md) when upgrading the -Klipper software. +Kalico software. ## angle @@ -56,7 +56,7 @@ The following information is available in the `configfile` object (or default value) during the last software start or restart. (Any settings changed at run-time will not be reflected here.) - `config.
.