├── .github ├── dependabot.yml └── workflows │ ├── ci.yml.old │ ├── jekyll.yml │ └── pages.yml.old ├── .gitignore ├── 404.html ├── Dedicated_USB_Can_Device.md ├── Final_Steps.md ├── Gemfile ├── Getting_Started.md ├── LICENSE ├── README.md ├── USB_CAN_Bridge_Mainboard.md ├── Updating.md ├── _config.yml ├── _includes └── nav_footer_custom.html ├── _sass └── color_schemes │ └── eso-dark.scss ├── assets ├── esoterical-canbus-green.png ├── esoterical-image.png ├── esoterical-logo.png └── favicon.ico ├── can_adapter ├── BigTreeTech U2C v2.1 │ ├── G0B1_U2C_V2.bin │ └── README.md ├── Makerbase UTC 1.0 │ └── README.md ├── Mellow Fly UTOC-1 and UTOC-3 │ └── README.md └── common_can_adapters.md ├── index.md ├── katapult_updating.md ├── mainboard_flashing.md ├── mainboard_flashing ├── common_hardware.md └── common_hardware │ ├── BigTreeTech Kraken │ └── README.md │ ├── BigTreeTech Manta E3EZ │ └── README.md │ ├── BigTreeTech Manta M5P V1.0 │ └── README.md │ ├── BigTreeTech Manta M8P v1.1 │ └── README.md │ ├── BigTreeTech Manta M8P v2.0 │ └── README.md │ ├── BigTreeTech Octopus Max EZ │ └── README.md │ ├── BigTreeTech Octopus Pro v1.0 │ ├── BigTreeTech Octopus Pro v1.1 │ └── README.md │ ├── BigTreeTech Octopus X7 │ └── README.md │ ├── BigTreeTech Octopus │ └── README.md │ ├── BigTreeTech SKR Pico │ └── README.md │ ├── BigTreeTech SKR-3 EZ │ └── README.md │ ├── BigTreeTech SKR-3 │ └── README.md │ ├── BigTreeTech SKRat v1.0 │ └── README.md │ ├── Fysetc Spider Pro │ └── README.md │ ├── Fysetc Spider v1.0 │ └── README.md │ ├── Fysetc Spider v2.2 │ └── README.md │ ├── Fysetc Spider v2.3 │ └── README.md │ ├── Fysetc Spider v3.0 H7 │ └── README.md │ ├── Fysetc Spider v3.0 │ └── README.md │ ├── LDO Leviathan v1.2 │ └── README.md │ ├── MKS Monster8 v2 │ └── README.md │ ├── Mellow Fly-D5P │ └── README.md │ ├── Mellow Fly-Super8 Pro H723 │ └── README.md │ └── Mellow Fly-Super8 │ └── README.md ├── mainboard_klipper_updating.md ├── toolhead_flashing.md ├── toolhead_flashing ├── common_hardware.md └── common_hardware │ ├── AFC-Lite │ └── README.md │ ├── BigTreeTech EBB36 V1.2 │ └── README.md │ ├── BigTreeTech EBB42 V1.2 │ └── README.md │ ├── BigTreeTech Eddy Duo │ └── README.md │ ├── BigTreeTech MMB CAN V1.0 │ └── README.md │ ├── BigTreeTech MMB CAN v2.0 │ └── README.md │ ├── BigTreeTech SB2209 (RP2040) │ └── README.md │ ├── BigTreeTech SB2209 and SB2240 │ ├── README.md │ └── SB2240 Stepper Configuration and Undervoltage.md │ ├── DragonDinghy │ ├── DragonDinghyDFU.jpg │ ├── DragonDinghyKatapult.jpg │ ├── DragonDinghyKlipper.jpg │ ├── DragonDinghyKlipperBridge.jpg │ ├── DragonDinghyTerminator.jpg │ └── README.md │ ├── Fysetc H36 │ └── README.md │ ├── Fysetc PITB V1.0 │ └── README.md │ ├── Fysetc PITB V2.0 │ └── README.md │ ├── Fysetc SB Combo V2 │ └── README.md │ ├── Fysetc SB-CAN-TH │ └── README.md │ ├── MKS THR36 V1.0 │ └── README.md │ ├── Mellow Fly ERCF │ ├── README.md │ └── img │ │ ├── canboot.png │ │ ├── dfu-mode.png │ │ ├── klipper-canboot.png │ │ └── klipper-only.png │ ├── Mellow Fly SB2040 │ └── README.md │ ├── Mellow Fly SB2040v3 │ └── README.md │ ├── Mellow Fly SHT36 and SHT42 │ └── README.md │ ├── Mellow Fly SHT36v2 │ └── README.md │ ├── Mellow Fly SHT36v3 │ └── README.md │ └── README.md ├── toolhead_klipper_updating.md ├── troubleshooting.md ├── troubleshooting ├── debugging │ ├── README.md │ └── can_debug.sh ├── klipper_fail_to_start.md ├── lost_communication_to_mcu.md ├── multiple_can_networks.md ├── no_can0.md ├── no_uuid.md ├── other_errors.md ├── termination_resistor_info.md ├── timeout_during_homing_probing.md ├── timer_too_close.md └── tmc_reset_undervoltage.md └── updating_can_speed.md /.github/dependabot.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | updates: 3 | - package-ecosystem: bundler 4 | directory: / 5 | schedule: 6 | interval: daily 7 | allow: 8 | - dependency-type: direct 9 | -------------------------------------------------------------------------------- /.github/workflows/ci.yml.old: -------------------------------------------------------------------------------- 1 | name: CI 2 | 3 | on: 4 | push: 5 | branches: ["main"] 6 | pull_request: 7 | 8 | jobs: 9 | # Build job 10 | build: 11 | runs-on: ubuntu-latest 12 | steps: 13 | - name: Checkout 14 | # uses: actions/checkout@v3 15 | uses: actions/checkout@v4 16 | - name: Setup Ruby 17 | # uses: ruby/setup-ruby@v1 18 | # with: 19 | # ruby-version: '3.1' # Not needed with a .ruby-version file 20 | # bundler-cache: true # runs 'bundle install' and caches installed gems automatically 21 | # cache-version: 0 # Increment this number if you need to re-download cached gems 22 | uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1.195.0 23 | with: 24 | ruby-version: '3.1' # Not needed with a .ruby-version file 25 | bundler-cache: true # runs 'bundle install' and caches installed gems automatically 26 | cache-version: 0 # Increment this number if you need to re-download cached gems 27 | - name: Build with Jekyll 28 | run: bundle exec jekyll build 29 | -------------------------------------------------------------------------------- /.github/workflows/jekyll.yml: -------------------------------------------------------------------------------- 1 | # This workflow uses actions that are not certified by GitHub. 2 | # They are provided by a third-party and are governed by 3 | # separate terms of service, privacy policy, and support 4 | # documentation. 5 | 6 | # Sample workflow for building and deploying a Jekyll site to GitHub Pages 7 | name: Deploy Jekyll site to Pages 8 | 9 | on: 10 | # Runs on pushes targeting the default branch 11 | push: 12 | branches: ["main"] 13 | 14 | # Allows you to run this workflow manually from the Actions tab 15 | workflow_dispatch: 16 | 17 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 18 | permissions: 19 | contents: read 20 | pages: write 21 | id-token: write 22 | 23 | # Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued. 24 | # However, do NOT cancel in-progress runs as we want to allow these production deployments to complete. 25 | concurrency: 26 | group: "pages" 27 | cancel-in-progress: false 28 | 29 | jobs: 30 | # Build job 31 | build: 32 | runs-on: ubuntu-latest 33 | steps: 34 | - name: Checkout 35 | uses: actions/checkout@v4 36 | - name: Setup Ruby 37 | # uses: ruby/setup-ruby@8575951200e472d5f2d95c625da0c7bec8217c42 # v1.161.0 38 | uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1.195.0 39 | with: 40 | ruby-version: '3.1' # Not needed with a .ruby-version file 41 | bundler-cache: true # runs 'bundle install' and caches installed gems automatically 42 | cache-version: 0 # Increment this number if you need to re-download cached gems 43 | - name: Setup Pages 44 | id: pages 45 | uses: actions/configure-pages@v5 46 | - name: Build with Jekyll 47 | # Outputs to the './_site' directory by default 48 | run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}" 49 | env: 50 | JEKYLL_ENV: production 51 | - name: Upload artifact 52 | # Automatically uploads an artifact from the './_site' directory by default 53 | uses: actions/upload-pages-artifact@v3 54 | 55 | # Deployment job 56 | deploy: 57 | environment: 58 | name: github-pages 59 | url: ${{ steps.deployment.outputs.page_url }} 60 | runs-on: ubuntu-latest 61 | needs: build 62 | steps: 63 | - name: Deploy to GitHub Pages 64 | id: deployment 65 | uses: actions/deploy-pages@v4 66 | -------------------------------------------------------------------------------- /.github/workflows/pages.yml.old: -------------------------------------------------------------------------------- 1 | # This workflow uses actions that are not certified by GitHub. 2 | # They are provided by a third-party and are governed by 3 | # separate terms of service, privacy policy, and support 4 | # documentation. 5 | 6 | # Sample workflow for building and deploying a Jekyll site to GitHub Pages 7 | name: Deploy Jekyll site to Pages 8 | 9 | on: 10 | push: 11 | branches: ["main"] 12 | 13 | # Allows you to run this workflow manually from the Actions tab 14 | workflow_dispatch: 15 | 16 | # Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages 17 | permissions: 18 | contents: read 19 | pages: write 20 | id-token: write 21 | 22 | # Allow one concurrent deployment 23 | concurrency: 24 | group: "pages" 25 | cancel-in-progress: true 26 | 27 | jobs: 28 | # Build job 29 | build: 30 | runs-on: ubuntu-latest 31 | steps: 32 | - name: Checkout 33 | uses: actions/checkout@v3 34 | - name: Setup Ruby 35 | # uses: ruby/setup-ruby@v1 36 | # with: 37 | # ruby-version: '3.1' # Not needed with a .ruby-version file 38 | # bundler-cache: true # runs 'bundle install' and caches installed gems automatically 39 | # cache-version: 0 # Increment this number if you need to re-download cached gems 40 | uses: ruby/setup-ruby@086ffb1a2090c870a3f881cc91ea83aa4243d408 # v1.195.0 41 | with: 42 | ruby-version: '3.1' # Not needed with a .ruby-version file 43 | bundler-cache: true # runs 'bundle install' and caches installed gems automatically 44 | cache-version: 0 # Increment this number if you need to re-download cached gems 45 | - name: Setup Pages 46 | id: pages 47 | uses: actions/configure-pages@v3 48 | - name: Build with Jekyll 49 | # Outputs to the './_site' directory by default 50 | run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}" 51 | env: 52 | JEKYLL_ENV: production 53 | - name: Upload artifact 54 | # Automatically uploads an artifact from the './_site' directory by default 55 | # uses: actions/upload-pages-artifact@v1 56 | uses: actions/upload-pages-artifact@v3 57 | 58 | # Deployment job 59 | deploy: 60 | environment: 61 | name: github-pages 62 | url: ${{ steps.deployment.outputs.page_url }} 63 | runs-on: ubuntu-latest 64 | needs: build 65 | steps: 66 | - name: Deploy to GitHub Pages 67 | id: deployment 68 | uses: actions/deploy-pages@v2 69 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Not sure what a .gitignore is? 2 | # See: https://git-scm.com/docs/gitignore 3 | 4 | # These are directly copied from Jekyll's first-party docs on `.gitignore` files: 5 | # https://jekyllrb.com/tutorials/using-jekyll-with-bundler/#commit-to-source-control 6 | 7 | # Ignore the default location of the built site, and caches and metadata generated by Jekyll 8 | _site/ 9 | .sass-cache/ 10 | .jekyll-cache/ 11 | .jekyll-metadata 12 | 13 | # Ignore folders generated by Bundler 14 | .bundle/ 15 | vendor/ 16 | -------------------------------------------------------------------------------- /404.html: -------------------------------------------------------------------------------- 1 | --- 2 | permalink: /404.html 3 | layout: default 4 | --- 5 | 6 | 19 | 20 |
21 | 22 |

404

23 | 24 |

The requested page could not be found

25 |
26 | -------------------------------------------------------------------------------- /Dedicated_USB_Can_Device.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Dedicated USB CAN Device 4 | has_children: true 5 | has_toc: false 6 | nav_order: 30 7 | --- 8 | 9 | # Dedicated USB CAN device 10 | 11 | If you want to use a dedicated USB CAN devcice, then it should be as simple as plugging it in to your Pi via USB. ***You shouldn't have to flash anything to this U2C/UTOC/etc device first, they are meant to come pre-installed with the necessary firmware. They do NOT run Klipper***. You can test if it is working by running an `lsusb` command (from an SSH terminal to your pi). Most common USB CAN devices will show up as a "Geschwister Schneider CAN adapter" when they are working properly (though some may simply show as an "OpenMoko, Inc" device): 12 | ```bash 13 | lsusb 14 | ``` 15 | 16 | ![image](https://user-images.githubusercontent.com/124253477/221329262-d8758abd-62cb-4bb6-9b4f-7bc0f615b5de.png) 17 | 18 | ![image](https://user-images.githubusercontent.com/124253477/222042688-10fa6fdb-8c0a-4142-8c40-0d93ef4fc4bd.png) 19 | 20 | 21 | A better check is by running `ip -s -d link show can0` . If everything is correct you will see something like this: 22 | ```bash 23 | ip -s -d link show can0 24 | ``` 25 | 26 | ![image](https://github.com/user-attachments/assets/f9366698-d1f8-44ed-8f8b-33c5b924dc37) 27 | 28 | 29 | You see a can0 interface, the "qlen" will be 128, and the bitrate will be 1000000 30 | 31 | 32 | {: .stop } 33 | > 34 | >

35 | > 36 | >

37 | > 38 | >If the `ip -s -d link show can0` command returns an error then go back to ths top of this page and check that your USB CAN adapter is properly showing up to an `lsusb` command. 39 | > 40 | >If the can0 network shows up, but the qlen *isn't* 128 or the bitrate *isn't* 1000000 then go back to [Getting_Started](./Getting_Started.md) and check the can0 file settigns in both the ifupdown section and the netplan section. 41 | 42 | 43 | 44 | **A note on edge cases** 45 | 46 | If you plug in your USB CAN adapter and you *don't* see the expected results from an `lsusb`, then the firmware on your device may have issues. If this is the case then it's worth going to the Github page of your device as they usually have the stock firmware and flashing instructions there. 47 | 48 | **A note on the note** 49 | 50 | The BTT U2C V2.1 was released with bad firmware which although would show up to the above tests it would make issues show up down the line. If you have a v2.1 of the U2C then please follow [these instructions](./can_adapter/BigTreeTech%20U2C%20v2.1/README.md) to update it. 51 | 52 | 53 | # Next Step 54 | 55 | Once you have confirmed you can see your can0 interface, continue [here](./toolhead_flashing) for instructions on flashing your toolhead for use with Canbus. 56 | -------------------------------------------------------------------------------- /Final_Steps.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Final Steps 4 | nav_order: 60 5 | --- 6 | 7 | # Final Steps 8 | 9 | So your CAN network is now running and you can see the CAN boards on it, everything is coming up Milhouse. 10 | 11 | There are some last things you need to complete before your Klipper (on pi) will talk to the boards though. 12 | 13 | # Update Config 14 | 15 | You will need to add some settings to your printer.cfg in order for Klipper (on the Pi) to actually talk to your new CAN nodes. 16 | 17 | ## Dedicated CAN adapter 18 | 19 | If you are running a dedicated USB Can adapter (like a U2C) then you don't need to do anything for this device, it won't be used/seen in the printer.cfg, Just skip to the [Toolhead section](#toolhead). 20 | 21 | ## USB-CAN-Bridge Mainboard 22 | 23 | If you are running a USB-CAN-Bridge Mainboard, then you will need to now set your main [mcu] section to use the UUID of your mainboard (that you found in [this step](./mainboard_flashing#klipper-is-now-installed)) 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/11040725-aa0f-4f98-bb8d-df4420320096) 26 | 27 | 28 | Note that the mainboard **must** be simply called [mcu]. And also note that there is no `restart_method` or anything else in this section, just the `canbus_uuid`. 29 | 30 | ## Toolhead 31 | 32 | For your toolhead, the best first step is to look for a sample config from your manufacturer (links in the [Toolhead Common Hardware](./toolhead_flashing/common_hardware) section). You can simply copy this sample file to the config folder on your Pi, then in your printer.cfg add a line [include samplefilename.cfg] so klipper loads in any settings from this additional file as well as the settings in the main printer.cfg file. 33 | 34 | ![image](https://github.com/user-attachments/assets/6f322043-b750-48d2-a4fb-25c6e2bed6ee) 35 | 36 | You will need to add (or modify) the new mcu section but as this is a ["extra" mcu](https://www.klipper3d.org/Config_Reference.html#mcu-my_extra_mcu) you need to give it a name. The name is arbitrary, but keeping it similar to what the manufacturer uses in their sample config files makes it easier later. 37 | 38 | eg. if I called my board "EBBCan", then I would have the [mcu EBBCan] section with the UUID of my toolhead (that you found in [this step](./toolhead_flashing#klipper-is-now-installed)) 39 | 40 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/4f3d2478-490b-41d9-8ee1-322d4a7f8117) 41 | 42 | You will need to adjust a few things from the sample config file. Make sure to change any temperature sensor types so it matches what your *actual* temperature sensor in your printer. Also adjust any motor and extruder specific settings (motor run current, extruder rotation_distance, etc.) as the default values in the sample config may not match what is in your printer. 43 | 44 | Once the sample config file matches your *actual* hardware, you need to go back to your printer.cfg and delete or comment out any section that is now in your sample config file. Things like the [extruder] section (including the [tmc2209 extruder] motor section), Fans, Probe, endstops, etc. 45 | 46 | If you have the same section ative in both your printer.cfg and the sample config file, then Klipper will only "read" it once which means it may start looking at the wrong pins for your hardware. Having the hotend temperature sensor still set to the old mainboard pin is a common mistake, and this manifests as an "ADC out of range" error when Klipper tries to start (because it is looking at a pin on the mainboard that no longer has the temperature sensor plugged in to it). 47 | 48 | 49 | 50 | -------------------------------------------------------------------------------- /Gemfile: -------------------------------------------------------------------------------- 1 | source 'https://rubygems.org' 2 | 3 | gem "jekyll", "~> 4.3.3" # installed by `gem jekyll` 4 | # gem "webrick" # required when using Ruby >= 3 and Jekyll <= 4.2.2 5 | gem 'jekyll-relative-links' 6 | 7 | gem "just-the-docs", "0.7.0" # pinned to the current release 8 | # gem "just-the-docs" # always download the latest release 9 | -------------------------------------------------------------------------------- /Getting_Started.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Getting Started 4 | nav_order: 20 5 | --- 6 | 7 | # Getting Started 8 | 9 | # Raspberry Pi Operating System 10 | 11 | As stated on the "Home" page of this guide, it is assumed that you are running a Raspberry Pi as your main computer for your printer. If you are not then this information may be worth reading, but also may not be directly relavent. 12 | 13 | There is a known issue with Raspberry Pi operating systems where "Bullseye" based distros (version 6.1.something) and 64bit can cause very strange timing issues which can then lead to Timer Too Close, Missed Scheduling, or other errors. A simple way to check what version operating system you have is to SSH in and then run: 14 | 15 | ```bash 16 | uname -a 17 | ``` 18 | 19 | This will give you information about your OS. You are looking for the version number and the architecture. 20 | 21 | ![image](https://github.com/user-attachments/assets/e631ffca-ea4a-4bca-8b27-c5d9f76168da) 22 | 23 | If you have 6.1.something as the version and aarch64 as the architecture, then it would be best to backup any existing Klipper data (config files and maybe moonraker history if you want to keep that) and then reflashing the SD card with the latest Raspberry Pi OS. Eric Zimmerman has fantastic instructions for doing both of those steps [here.](https://github.com/EricZimmerman/VoronTools/blob/main/OSUpgrade.md) 24 | 25 | If you find your version is 6.6.something, or 5.something, then it is fine. Also, if your architecture is `armv7l` then it means you are running a 32bit OS and this is also unaffected. 26 | 27 | # Network Service, CAN Speeds, and Transmit Queue Length 28 | 29 | In order to dictate the speed at which your CAN network runs at you will need make sure there is a service on the Pi that can configure a CANBus interface, and also the necessary information in configuration files so this service knows what settings you want to use. 30 | 31 | To set everything up, SSH into your pi and run the commands needed for your network setup: 32 | 33 | {: .highlight } 34 | >**Wait, wasn't this section different before?** 35 | > 36 | >Yes, originally the "default" method of configuring the CAN network was using a can0 file and the ifupdown network service. However, ifupdown is being phased out by newer 37 | >linux distributions. The more universal option seems to be using the systemd-networkd service instead. The good news is that this seems to be installed (if not enabled) 38 | >on most linux distros we'd see on 3d printers. So streamlining the process down should make it better for everyone. 39 | 40 | Make sure the systemd-networkd service is enabled by running 41 | 42 | ```bash 43 | sudo systemctl enable systemd-networkd 44 | ``` 45 | 46 | then start the service with: 47 | 48 | ```bash 49 | sudo systemctl start systemd-networkd 50 | ``` 51 | 52 | {: .note } 53 | > If you get a `Failed to start systemd-networkd.service: Unit systemd-networkd.service is masked` error (or similar), run 54 | > `sudo systemctl unmask systemd-networkd` first to unmask it, then run `sudo systemctl start systemd-networkd` again 55 | 56 | 57 | then check it is running properly with: 58 | 59 | ```bash 60 | systemctl | grep systemd-networkd 61 | ``` 62 | 63 | and make sure it shows as "loaded active running" 64 | 65 | ![image](https://github.com/user-attachments/assets/901096ef-29c8-4abc-8191-8d6c6aec9010) 66 | 67 | Unfortunately, this also enables the systemd-networkd-wait-online service which can cause your system to be "frozen" for around 2 minutes on boot as it waits for 68 | network interfaces to be online. If the problem was only the CAN interface there would be ways around this but as there are edge cases where the wait would still happen 69 | I've found it's best to just disable the wait-online servce entirely by running: 70 | 71 | ```bash 72 | sudo systemctl disable systemd-networkd-wait-online.service 73 | ``` 74 | 75 | If disabling this service results in any negative impact on certain linux distros or setups please let me know via an [issue ticket](https://github.com/Esoterical/voron_canbus/issues). 76 | 77 | Then configure the txqueuelen for the interface by running the following command (copy the line entirely and paste it into your SSH session) 78 | 79 | ```bash 80 | echo -e 'SUBSYSTEM=="net", ACTION=="change|add", KERNEL=="can*" ATTR{tx_queue_len}="128"' | sudo tee /etc/udev/rules.d/10-can.rules > /dev/null 81 | ``` 82 | 83 | To confirm it has applied correctly, run 84 | 85 | ```bash 86 | cat /etc/udev/rules.d/10-can.rules 87 | ``` 88 | 89 | and it should look like this: 90 | 91 | ![image](https://github.com/user-attachments/assets/da566d41-8737-4847-8b63-9b4ce2821b53) 92 | 93 | {: .note } 94 | > **Didn't this use to be a txqueuelen of 1024?** 95 | > 96 | > Yes, for a long time it was recommended to use 1024 for the transmit queue length, and if that is working for you then power on. But 97 | > it is recommended directly from Kevin O'Connor (of Klipper fame) to use a lower queue length of 128 and in my testing I've found no 98 | > issues doing so. Also it should *theoretically* help with some timeout issues using a smaller queue though I haven't seen real evidence 99 | > one way or another. Still, seems good to align with the recommended Klipper docs on the matter. 100 | 101 | Now finally, to enable the can0 interface and set the speed run the following command: 102 | 103 | ```bash 104 | echo -e "[Match]\nName=can*\n\n[CAN]\nBitRate=1M\nRestartSec=0.1s\n\n[Link]\nRequiredForOnline=no" | sudo tee /etc/systemd/network/25-can.network > /dev/null 105 | ``` 106 | 107 | To confirm it has applied correctly, run 108 | 109 | ```bash 110 | cat /etc/systemd/network/25-can.network 111 | ``` 112 | 113 | and it should look like this: 114 | 115 | ![image](https://github.com/user-attachments/assets/e17218fa-103c-4cc6-a769-2b58cff0e026) 116 | 117 | Then finally reboot the Pi (so the systemd-networkd service has started properly reading from the config files) with a: 118 | 119 | ```bash 120 | sudo reboot now 121 | ``` 122 | 123 | 124 | 125 | # 120R Termination Resistors 126 | 127 | A CANBus expects both ends of the CanH/CanL wire run to be terminated with a 120 ohm resistor bridging the High and Low wires. Your CAN board will almost certainly have provisions for this somewhere. 128 | 129 | You want to have **two** of these termination resistors in your CANBus circuit. **No more, No less**. Running with too many connected can be just as bad as running with none. 130 | 131 | Put these at the physical "end" of the CAN wires. 132 | 133 | If you want a more in depth breakdown of the termination resistors, or you have a CAN setup that seems more complicated than what is outlined above, have a read of the [termination resistors](./troubleshooting/termination_resistor_info.md) page. 134 | 135 | 136 | ## CAN Adapter/Mainboard 137 | 138 | Some boards (Like the BTT Octopus) have the 120 ohm resistor permenantly connceted across the CanH/L wires, so nothing you need to do there. Others will have a two-pin header (sometimes labelled "120R") that you can put a jumper on and this will bring the termination resistor into the circuit. 139 | 140 | The same can be said for dedicated USB CAN adapters (like the U2C). Most will have a a header that you can put a jumper on to enable the resistor. 141 | 142 | You can find information and diagrams on the 120 ohm termination resistor placement for boards in the *mainboard common hardware* section. 143 | 144 | ## Toolhead 145 | 146 | Nearly all Toolheads will have a two-pin header (sometimes labelled 120R) that you can put a jumper on to bring the 120 ohm resistor into the circuit. 147 | 148 | You can find information and diagrams on the 120 ohm termination resistor placement for boards in the *toolhead common hardware* section. 149 | 150 | # Cabling 151 | 152 | There is a high likelyhood that with your changeover to canbus you will also change to some sort of umbilical system for your toolhead. This isn't absolutely necessary, but extremely common. Some boards even come with a premade cable which may or may not work well in cable chains anyway. 153 | 154 | Before getting too swept up in what the absolute best gold plated gucci cabling would be for your system, keep the following things in mind. They are the most 155 | important factors when it comes to canbus toolhead board cabling. Nearly every single time someone has issues (after the initial install) it is because a wire has 156 | cracked or connector crimp is failing or similar, so take extra careful to follow these steps: 157 | 158 | 1. **Good Crimps** 159 | 160 | If you are making your own cable then be extra sure your wire crimps are properly done. A loose crimp can fall off, a bent crimp can crack. And make sure the 161 | pins are fully seated into the connector housing. Do a pull test to be sure, it's very easy for a pin to look inserted but not actually clicked in and they can 162 | get pushed out the back during use. 163 | 164 | This also applies to premade cables. I've seen some where the H/L connectors get pushed back slightly in the housing, enough that it causes intermittent connection 165 | issues. 166 | 167 | 2. **Strain Relief** 168 | 169 | No matter what you do **not** want the cable having any sort of movement at/near the connector to the toolhead board. If the wires at those crimp points start 170 | moving then it's only a matter of time before they'll crack. 171 | 172 | Have the cable run away from the toolhead for a short distance and then secure it down so no matter what the rest of the umbilical is doing there is no movement 173 | transmitted directly to the connector. 174 | 175 | 3. **Flexible Cable** 176 | 177 | I know I said not to get worked up about über cables, and that's still true, but also don't go using old solid core mains wiring you ripped from the walls. 178 | You want the cable/wires to be flexible enough to withstand the constant movement of a printer. That means don't go *too* thick on the wire gauge, and also make 179 | sure it is decently stranded wire (not 7-strand high current wire). 180 | 181 | 22AWG or thicker (smaller number is thicker wire) is usually fine for the power wires. The CAN H/L can be thinner, 24 or 26AWG is common, but you can also just 182 | do four 22AWG wires or something without trouble as well. 183 | 184 | A common method of supporting and strain relieving the umbilcal is to use PG7 glands, and although these work really well they also tend to mean people have to cut 185 | or repin the premade cables that come with some boards. Because of this I prefer using the printable [P.U.G](https://www.printables.com/model/378567-pug-parametric-umbilical-gland) umbilical gland. It does the same job as a PG7 but comes in two halves so you can clamp it over any cable without needing to cut/depin anything. 186 | 187 | I've got a public Printables "collection" of various PUG mounts for different extruders [here](https://www.printables.com/@Esoterical_306854/collections/2039742) and will hopefully grow 188 | it over time, so be sure to check there to see if one of them fits your toolboard/extruder. 189 | 190 | 191 | # Next Step 192 | 193 | Now that the can0 interface files are set up, you need to choose how you are going to connect your Pi to the CANBus network. 194 | 195 | To actually create a CAN network in your system, your Pi needs some sort of device to act as a CAN adapter (think of it like a USB network card, or USB wifi dongle). 196 | 197 | The simplest plug-and-play option is to use a dedicated USB to Can device such as the BigTreeTech U2C, Mellow Fly UTOC, Fysetc UCAN, etc. (other devices exist as well). [Click here if you have a Dedicated USB-CAN Adapter](./Dedicated_USB_Can_Device.md) to continue the guide. 198 | 199 | The second "cheaper" option is to actually utilise your printer mainboard (ie. Octopus, Manta, Spider, etc.) to function as a usb-can bridge for klipper. [Click here if you have are using your mainboard as the CAN interface](./USB_CAN_Bridge_Mainboard.md) to continue the guide. 200 | 201 | 202 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: README 4 | nav_exclude: true 5 | --- 6 | The CANBus guide is now an actual website, find it at https://canbus.esoterical.online 7 | -------------------------------------------------------------------------------- /USB_CAN_Bridge_Mainboard.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: USB CAN Bridge Mainboard 4 | nav_order: 40 5 | --- 6 | 7 | # Klipper USB to CAN bus bridge 8 | 9 | The second way of setting up a CAN network is to use the printer mainboard itself as a CAN adapter. 10 | 11 | **If you are using a dedicated CAN adapter as outlined [here](./Dedicated_USB_Can_Device.md) then you don't need this step. Your mainboard will be flashed the same as any other "normal" klipper install** 12 | 13 | This is acheived through Klippers "USB-CAN-Bridge mode". In order for this to work you need to have a compatible MCU on the mainboard (A lot of the popular STM32 chips works, as well as the RP2040), and either a dedicated "CAN" port on the motherboard or at least a way of accessing the CAN pins that you configure for klipper. 14 | 15 | Some mainboards (like the BTT Octopus) have a CAN Transceiver built in so they will output CAN signals directly from a dedicated port (the Octopus has an RJ11 port for this purpose). Other compatible boards may have a port on their board labelled as CAN but only output serial (Tx Rx) signals. These boards can still be run as USB-CAN-Bridge mode but will require an additional CAN Transceiver module (such as the SN65HVD230). These can be cheaply purchased from Amazon or eBay or AliExpress. Other boards may yet not have any dedicated CAN port, but still have a compatible MCU and have compatible CAN pins that you can access (the SKR Mini E3 V3 can be run in USB-CAN-Bridge mode if you use the PB8/PB9 pins on the EXP1 header that is normally used for an LCD screen). 16 | 17 | [Click here to start flashing your mainboard to USB-CAN-Bridge Klipper](./mainboard_flashing) 18 | -------------------------------------------------------------------------------- /Updating.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Updating 4 | has_children: true 5 | nav_order: 70 6 | has_toc: false 7 | --- 8 | 9 | # Updating 10 | 11 | ![captain_update](https://github.com/Esoterical/voron_canbus/assets/124253477/2b35e7a5-d2b7-4f50-9db7-5e4202ad85ed) 12 | 13 | 14 | Did you update the Klipper on your Pi, and now it is yelling at you about MCU version being out of date? Or maybe you just want to update the firmware on your boards for the latest features (or fixes). Either way, just follow these steps and it should be pretty painless. 15 | 16 | Before doing anything, you need to pull the latest Katapult down from Git so just so all the following tools are *definitely* available. You may already have the latest Katapult stuff, but running the Git commands again won't hurt. 17 | 18 | ```bash 19 | test -e ~/katapult && (cd ~/katapult && git pull) || (cd ~ && git clone https://github.com/Arksine/katapult) ; cd ~ 20 | ``` 21 | 22 | This command will download Katapult from github if you don't already have it, or it will update it to the latest if you do already have it. 23 | 24 | If during the following steps you see "Application:CanBoot" instead of "Application:Katapult" then don't worry, Canboot was just renamed to Katapult but all the Katapult tools/queries will still "talk" to Canboot perfectly fine. You don't need to update a working CanBoot bootloader. 25 | 26 | If you want to update your CAN Toolhead, go to [here](./toolhead_klipper_updating.md). 27 | 28 | If you want to update a mainboard running USB-CAN-Bridge mode klipper, go to [here](./mainboard_klipper_updating.md) 29 | -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | title: Esoterical's CANBus Guide 2 | description: A guide for setting up CANBus hardware on 3D printers 3 | theme: just-the-docs 4 | color_scheme: eso-dark 5 | markdown: kramdown 6 | url: https://canbus.esoterical.online 7 | logo: "/assets/esoterical-canbus-green.png" 8 | favicon_ico: "/assets/favicon.ico" 9 | 10 | callouts: 11 | warning: 12 | title: Warning 13 | color: red 14 | stop: 15 | color: red 16 | highlight: 17 | color: yellow 18 | note: 19 | color: blue 20 | 21 | plugins: 22 | - jekyll-relative-links 23 | 24 | aux_links: 25 | CANBus Guide on Github: https://github.com/Esoterical/voron_canbus 26 | -------------------------------------------------------------------------------- /_includes/nav_footer_custom.html: -------------------------------------------------------------------------------- 1 | 5 | -------------------------------------------------------------------------------- /_sass/color_schemes/eso-dark.scss: -------------------------------------------------------------------------------- 1 | // 2 | // Eso Customizations (based on Voron customizations 3 | // 4 | 5 | // 6 | // Color Definitions 7 | // 8 | $grey-dk-400: #2c2f33; 9 | $grey-dk-500: #23272a; 10 | $red-400: #bd0f0f; 11 | $red-500: #760a0a; 12 | $voron-red-30: #dd6670; 13 | $voron-red-40: #ff3341; 14 | $voron-red-50: #ff0213; 15 | $voron-red-60: #cc000e; 16 | $voron-red-70: #99000a; 17 | $voron-red-80: #dd0007; 18 | $voron-link-purple: #661aff; 19 | $eso-green-dark: #3b8d66; 20 | $eso-green-light: #6cc299; 21 | 22 | // 23 | // Body Elements 24 | // 25 | $body-background-color: $grey-dk-400; 26 | $body-heading-color: $eso-green-dark; 27 | $btn-primary-color: $eso-green-light; 28 | $link-color: $eso-green-light; 29 | 30 | // Copied from JTD dark theme 31 | $sidebar-color: $grey-dk-500; 32 | $border-color: $grey-dk-200; 33 | 34 | $body-text-color: $grey-lt-300; 35 | $nav-child-link-color: $grey-dk-000; 36 | $search-result-preview-color: $grey-dk-000; 37 | $base-button-color: $grey-dk-250; 38 | 39 | 40 | $code-background-color: #302d36; 41 | $code-linenumber-color: #dee2f7; // OneDarkJekyll .nf for syntax-one-dark-vivid 42 | $search-background-color: $grey-dk-250; 43 | $table-background-color: $grey-dk-250; 44 | $feedback-color: darken($sidebar-color, 3%); 45 | 46 | .highlight .c { 47 | color: #586e75; 48 | } // comment // 49 | .highlight .err { 50 | color: #93a1a1; 51 | } // error // 52 | .highlight .g { 53 | color: #93a1a1; 54 | } // generic // 55 | .highlight .k { 56 | color: #859900; 57 | } // keyword // 58 | .highlight .l { 59 | color: #93a1a1; 60 | } // literal // 61 | .highlight .n { 62 | color: #93a1a1; 63 | } // name // 64 | .highlight .o { 65 | color: #859900; 66 | } // operator // 67 | .highlight .x { 68 | color: #cb4b16; 69 | } // other // 70 | .highlight .p { 71 | color: #93a1a1; 72 | } // punctuation // 73 | .highlight .cm { 74 | color: #586e75; 75 | } // comment.multiline // 76 | .highlight .cp { 77 | color: #859900; 78 | } // comment.preproc // 79 | .highlight .c1 { 80 | color: #586e75; 81 | } // comment.single // 82 | .highlight .cs { 83 | color: #859900; 84 | } // comment.special // 85 | .highlight .gd { 86 | color: #2aa198; 87 | } // generic.deleted // 88 | .highlight .ge { 89 | font-style: italic; 90 | color: #93a1a1; 91 | } // generic.emph // 92 | .highlight .gr { 93 | color: #dc322f; 94 | } // generic.error // 95 | .highlight .gh { 96 | color: #cb4b16; 97 | } // generic.heading // 98 | .highlight .gi { 99 | color: #859900; 100 | } // generic.inserted // 101 | .highlight .go { 102 | color: #93a1a1; 103 | } // generic.output // 104 | .highlight .gp { 105 | color: #93a1a1; 106 | } // generic.prompt // 107 | .highlight .gs { 108 | font-weight: bold; 109 | color: #93a1a1; 110 | } // generic.strong // 111 | .highlight .gu { 112 | color: #cb4b16; 113 | } // generic.subheading // 114 | .highlight .gt { 115 | color: #93a1a1; 116 | } // generic.traceback // 117 | .highlight .kc { 118 | color: #cb4b16; 119 | } // keyword.constant // 120 | .highlight .kd { 121 | color: #268bd2; 122 | } // keyword.declaration // 123 | .highlight .kn { 124 | color: #859900; 125 | } // keyword.namespace // 126 | .highlight .kp { 127 | color: #859900; 128 | } // keyword.pseudo // 129 | .highlight .kr { 130 | color: #268bd2; 131 | } // keyword.reserved // 132 | .highlight .kt { 133 | color: #dc322f; 134 | } // keyword.type // 135 | .highlight .ld { 136 | color: #93a1a1; 137 | } // literal.date // 138 | .highlight .m { 139 | color: #2aa198; 140 | } // literal.number // 141 | .highlight .s { 142 | color: #2aa198; 143 | } // literal.string // 144 | .highlight .na { 145 | color: #555; 146 | } // name.attribute // 147 | .highlight .nb { 148 | color: #b58900; 149 | } // name.builtin // 150 | .highlight .nc { 151 | color: #268bd2; 152 | } // name.class // 153 | .highlight .no { 154 | color: #cb4b16; 155 | } // name.constant // 156 | .highlight .nd { 157 | color: #268bd2; 158 | } // name.decorator // 159 | .highlight .ni { 160 | color: #cb4b16; 161 | } // name.entity // 162 | .highlight .ne { 163 | color: #cb4b16; 164 | } // name.exception // 165 | .highlight .nf { 166 | color: #268bd2; 167 | } // name.function // 168 | .highlight .nl { 169 | color: #555; 170 | } // name.label // 171 | .highlight .nn { 172 | color: #93a1a1; 173 | } // name.namespace // 174 | .highlight .nx { 175 | color: #555; 176 | } // name.other // 177 | .highlight .py { 178 | color: #93a1a1; 179 | } // name.property // 180 | .highlight .nt { 181 | color: #268bd2; 182 | } // name.tag // 183 | .highlight .nv { 184 | color: #268bd2; 185 | } // name.variable // 186 | .highlight .ow { 187 | color: #859900; 188 | } // operator.word // 189 | .highlight .w { 190 | color: #93a1a1; 191 | } // text.whitespace // 192 | .highlight .mf { 193 | color: #2aa198; 194 | } // literal.number.float // 195 | .highlight .mh { 196 | color: #2aa198; 197 | } // literal.number.hex // 198 | .highlight .mi { 199 | color: #2aa198; 200 | } // literal.number.integer // 201 | .highlight .mo { 202 | color: #2aa198; 203 | } // literal.number.oct // 204 | .highlight .sb { 205 | color: #586e75; 206 | } // literal.string.backtick // 207 | .highlight .sc { 208 | color: #2aa198; 209 | } // literal.string.char // 210 | .highlight .sd { 211 | color: #93a1a1; 212 | } // literal.string.doc // 213 | .highlight .s2 { 214 | color: #2aa198; 215 | } // literal.string.double // 216 | .highlight .se { 217 | color: #cb4b16; 218 | } // literal.string.escape // 219 | .highlight .sh { 220 | color: #93a1a1; 221 | } // literal.string.heredoc // 222 | .highlight .si { 223 | color: #2aa198; 224 | } // literal.string.interpol // 225 | .highlight .sx { 226 | color: #2aa198; 227 | } // literal.string.other // 228 | .highlight .sr { 229 | color: #dc322f; 230 | } // literal.string.regex // 231 | .highlight .s1 { 232 | color: #2aa198; 233 | } // literal.string.single // 234 | .highlight .ss { 235 | color: #2aa198; 236 | } // literal.string.symbol // 237 | .highlight .bp { 238 | color: #268bd2; 239 | } // name.builtin.pseudo // 240 | .highlight .vc { 241 | color: #268bd2; 242 | } // name.variable.class // 243 | .highlight .vg { 244 | color: #268bd2; 245 | } // name.variable.global // 246 | .highlight .vi { 247 | color: #268bd2; 248 | } // name.variable.instance // 249 | .highlight .il { 250 | color: #2aa198; 251 | } // literal.number.integer.long // 252 | -------------------------------------------------------------------------------- /assets/esoterical-canbus-green.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/assets/esoterical-canbus-green.png -------------------------------------------------------------------------------- /assets/esoterical-image.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/assets/esoterical-image.png -------------------------------------------------------------------------------- /assets/esoterical-logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/assets/esoterical-logo.png -------------------------------------------------------------------------------- /assets/favicon.ico: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/assets/favicon.ico -------------------------------------------------------------------------------- /can_adapter/BigTreeTech U2C v2.1/G0B1_U2C_V2.bin: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/can_adapter/BigTreeTech U2C v2.1/G0B1_U2C_V2.bin -------------------------------------------------------------------------------- /can_adapter/BigTreeTech U2C v2.1/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech U2C v2.1 4 | parent: Common CAN Adapters 5 | grand_parent: Dedicated USB CAN Device 6 | --- 7 | 8 | 9 | # 120 ohm Termination Resistor 10 | 11 | The header for the 120R termination resistor is circled in purple 12 | 13 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/c7044a7f-db00-42a1-b75f-c449c44a13ca) 14 | 15 | # Wiring 16 | 17 | Connect a USB cable from our Pi to the usb-c port of the U2C. This provides the data connection and power to the U2C. 18 | 19 | Do *not* connect your mainboard (Octopus, etc.) to the USB-A ports on the U2C. They are not a simple USB hub, they are canbus ports using a USB-A connector. 20 | You want to connect your mainboard directly to your Pi via USB. 21 | 22 | Connect the CanH and CanL from your canbus boards to any of the H/L connections on the U2C. All of these connections are tied together so it doesn't matter 23 | which ones you choose. 24 | 25 | If you *also* run the 24v and GND wires from your canbus board to the U2C then you have to connect the 24v and GND pins (usually the screw terminals) to the V+ and V- of your PSU. This doesn't power the U2C at all, it's just pass through to your canbus board for ease of wiring. 26 | 27 | ![image](https://github.com/user-attachments/assets/f3e6e632-7456-4825-afbf-fe0f6d0f37e6) 28 | 29 | 30 | ![CANbus_U2C_Pinout_on_Power_Connector](https://github.com/Esoterical/voron_canbus/assets/124253477/57a4a525-31ea-4565-ad69-6bb50510c090) 31 | 32 | 33 | # Bad Firmware 34 | 35 | The U2C came stock with bad firmware that would cause flashing problems down the line. This was mainly back in early 2023 so if you have purchased a board *recently* this may not be an issue, but flashing this firmware can't hurt anyway and is very simple to do. 36 | 37 | I have copied a fixed version of the firmware here, you can download it to your pi by running: 38 | ```bash 39 | cd ~/ 40 | wget https://github.com/Esoterical/voron_canbus/raw/main/can_adapter/BigTreeTech%20U2C%20v2.1/G0B1_U2C_V2.bin 41 | ``` 42 | 43 | (you can read about the error at https://github.com/Arksine/katapult/issues/44) 44 | 45 | If you used the wget link the firmware should now be in your home directory. Press the boot button on the U2C while plugging it in to your Pi to put it into DFU mode. 46 | 47 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ad3a5d48-fc30-4dea-9b9e-96fb1eec37e3) 48 | 49 | Confirm it is connected in DFU mode by running `sudo dfu-util -l`. You should see the devive: 50 | 51 | ![image](https://user-images.githubusercontent.com/124253477/221551890-3205eafb-9f16-41b5-8020-ebb1ebbf5ded.png) 52 | 53 | If you can see it there then just run this command to flash the fixed firmware to the U2C: 54 | 55 | ```bash 56 | sudo dfu-util -D ~/G0B1_U2C_V2.bin -a 0 -s 0x08000000:leave 57 | ``` 58 | 59 | ![image](https://user-images.githubusercontent.com/124253477/221552152-89f14967-b807-4e54-9159-003b19eed784.png) 60 | 61 | You may see an "error during download get-status" down the bottom. You can ignore that as long as everything else is successful. 62 | 63 | Once flashed, unplug the U2C from the Pi then plug it back in. Run an `ifconfig` and you should see a "can0" interface (assuming you have already set the /etc/network/interfaces.d/can0 file). If so, then congratulations your U2C is succesfully flashed with the fixed firmware. 64 | -------------------------------------------------------------------------------- /can_adapter/Makerbase UTC 1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Makerbase UTC 1.0 4 | parent: Common CAN Adapters 5 | grand_parent: Dedicated USB CAN Device 6 | --- 7 | 8 | **Big thanks to @terranx#9681 on the Voron Discord for investigating this issue and writing up these instructions** 9 | 10 | # Fixing the Makerbase UTC 1.0 11 | 12 | *Background:* 13 | 14 | Makerbase recently released a STM32G0B1 based USB can device. It comes factory flashed with 15 | klipper in USB CanBridge mode at a default bitrate of 250k. With the way klipper’s USB Can 16 | Bridge mode works, you can’t change the bitrate without reflashing the device, no matter what 17 | your Can0 file shows. Unfortunately makerbase set the CPU configuration of the STM32g0b1 18 | such that you can’t actually enter bootmode to do a USB reflash. However if you grab an STLink 19 | you can reflash it. This guide assumes you have an stlink device and updated. A clone or 20 | legitimate st-link is acceptable. 21 | 22 | 23 | Identify the SWD header on your board, highlighted below: 24 | 25 | ![image](https://user-images.githubusercontent.com/124253477/221704780-4e5a6603-b258-4876-9fb6-516029574300.png) 26 | 27 | Note that Pin 1 is on the top right. 28 | You want to connect to your STLink it like such: 29 | Pin 1: SWDIO 30 | Pin 2: +3.3V 31 | Pin 3: SWCLK 32 | Pin 4: Ground 33 | Pin 5: Reset 34 | Once that is all connected. Connect your STLink device to your USB port and open up 35 | STM32CubeProgrammer. Set the interface to ST-Link, setup the configuration like 36 | below, and hit connect. If you’ve never connected this STLink before, reset mode is the 37 | only option that is changed from default. 38 | 39 | ![image](https://user-images.githubusercontent.com/124253477/221705555-494ff0a7-22db-4fef-b391-5c34c99d0809.png) 40 | 41 | Your board should be connected now. Your window should look something like this 42 | (don’t worry about the exact values within Device Memory) 43 | 44 | ![image](https://user-images.githubusercontent.com/124253477/221705667-d373c26d-cbb9-41d0-8435-924a181ee096.png) 45 | 46 | Now you need to click on the “OB” button on the left. Expand the User Configuration 47 | setting and scroll down until you find the nBOOT_SEL option. You will need to uncheck 48 | that, and then hit Apply 49 | 50 | ![image](https://user-images.githubusercontent.com/124253477/221705775-6e8ba9e9-f2d5-447f-b9a6-e1eb7a3f61c2.png) 51 | 52 | If all goes well, you should get a message the option bytes were successfully 53 | programmed. Now your boot button should work as expected. 54 | 55 | From here you can flash whatever you want to the device. Your choices are to either use 56 | klipper’s USB Can Bridge mode or flash a CandleLight variant. I personally think 57 | CandleLight is better for this sort of thing. We will be using marckleinebudde’s 58 | multichannel fork – note that it is still a WIP fork, so there may be bugs, but it seems to 59 | work well enough for our purposes 60 | 61 | cd ~ 62 | sudo apt-get install gcc-arm-none-eabi 63 | git clone https://github.com/marckleinebudde/candleLight_fw 64 | cd ~/candleLight_fw 65 | git checkout multichannel 66 | mkdir build 67 | cd build 68 | cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc-arm-none-eabi-8-2019-q3-update.cmake 69 | make budgetcan_fw 70 | 71 | now plugin your UTC in boot mode and type: 72 | make flash-budgetcan_fw 73 | 74 | After that you can reset your UTC and you can setup your can-bus similarly to a U2C or 75 | UTOC setup. 76 | If you do wish to use klipper instead of CandelLight, you can use the following settings 77 | for katapult and klipper respectively 78 | 79 | ![image](https://user-images.githubusercontent.com/124253477/221706131-6c538194-5a92-42e4-8078-e6ae88f78028.png) 80 | 81 | ![image](https://user-images.githubusercontent.com/124253477/221706218-a8f03655-0ce1-4008-874b-3466cb90f9c1.png) 82 | -------------------------------------------------------------------------------- /can_adapter/Mellow Fly UTOC-1 and UTOC-3/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly UTOC 4 | parent: Common CAN Adapters 5 | grand_parent: Dedicated USB CAN Device 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # Flashing UTOC Firmware 13 | 14 | This information is from https://mellow-3d.github.io/fly-utoc_firmware.html#flashing-utoc-firmware 15 | 16 | **Note: The UTOC firmware is intalled at the manufacturer. This procedure is only needed to restore the OEM firmware.** 17 | 18 | Download the stock firmware from https://mellow-3d.github.io/files/utoc_firmware.bin and copy it to the user folder on your Pi. 19 | 20 | 21 | Install the DFU mode Jumper 22 | 23 | ![image](https://user-images.githubusercontent.com/124253477/222069095-ae8c486e-5818-4925-927b-4099d517bf1c.png) 24 | 25 | ![image](https://user-images.githubusercontent.com/124253477/222069120-9a27bcf5-2513-4728-b19f-2925287e1442.png) 26 | 27 | 28 | Connect the UTOC to your Pi by the USB C port 29 | 30 | 31 | On your Pi run the command: 32 | 33 | `lsusb` 34 | 35 | If it shows something like: 36 | 37 | `Bus 001 Device 004: ID 0483:df11 STMicroelectronics STM Device in DFU Mode` 38 | 39 | With the ID of the DFU device as 0483:df11, then run the following command to flash the UTOC. 40 | 41 | `sudo dfu-util -d 0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D ~/utoc_firmware.bin` 42 | 43 | Otherwise if it shows something like: 44 | 45 | `Bus 001 Device 004: ID 314b:0106 Geehy APM32 DFU ISP Mode` 46 | 47 | With the DFU device ID as 314b:0106, run this command instead: 48 | 49 | `sudo dfu-util -d 314b:0106 -c 1 -i 0 -a 0 -s 0x08000000 -D ~/utoc_firmware.bin` 50 | 51 | -------------------------------------------------------------------------------- /can_adapter/common_can_adapters.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Common CAN Adapters 4 | parent: Dedicated USB CAN Device 5 | has_children: true 6 | --- 7 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | --- 2 | title: Home 3 | layout: home 4 | nav_order: 1 5 | --- 6 | 7 | 8 | Before we start a big thanks has to go to the #can-and-usb_toolhead_boards thread on the Voron discord. A wealth of information from some very clever people. 9 | Plus a specific thanks to @MastahFR and @eschlenz for their [early](https://github.com/akhamar/voron_canbus_octopus_sb2040) [canbus](https://github.com/eschlenz/3D-Printing-Public/blob/main/skr_pico_canboot_canbus.md) guides, and @EricZimmerman for his still-very-relevant [BTT U2C and EBB36](https://github.com/EricZimmerman/VoronTools/blob/main/EBB_CAN.md) guide. 10 | 11 | And a huge thanks to @dormausian who was instrumental in lifting this just-a-github page into an actual website. 12 | 13 | ## Generalised CANBus guide 14 | 15 | So you want to use Canbus on your printer? There are plenty of guides around but usually they are guides on a specific hardware configuration. This guide hopes to generalise some of the steps to help anyone get started on their CAN journey with a printer. 16 | 17 | Note: This will be generally structured around Voron printers and common hardware for a Voron printer, but you can take the information to any Klipper-based printer as long as you either use the same electronics (mainboard/canboard) or use this guide to adapt to your specific electronics (if they are supported). 18 | 19 | So let's get started. 20 | 21 | 22 | # Basic Structure of a 3d Printer CANBus 23 | 24 | In all likelyhood you are looking to hook up a single CAN toolhead board to your printer to minimise wiring from mainboard to toolhead, so that is the setup we'll be focusing on. 25 | In order to achieve a functioning CAN network on your printer you need 3 things: A computer running the main Klipper software (usually a Raspberry Pi, but anything with a USB port will work for this guide), a CAN network adapter (either a standalone USB device or running a compatible mainboard in klipper's usb-can bridge mode) and a CAN node (the toolhead device). This is also the order in which you need to set things up. No point setting everything up on the toolhead CAN board if you don't have a way for the Pi to talk to it. 26 | We are going to assume you have a functioning Pi (or equivalant) running linux and already have Klippper, Moonraker, some sort of GUI (Fluidd/Mainsail/Octoprint), and you have the ability to SSH into it. 27 | 28 | Please note that whenever you see "Pi" or "RPi" in this guide you should substitute it for whatever computer you are running Klipper on (Raspberry Pi, Orange Pi, CB1, BTT Pi, old laptop etc). For example, if the guide says "plug the USB into the Pi", and you have an old laptop doing this job, then plug the USB into your old laptop. 29 | Also note that integrated boards like the BTT Manta series that have a CM4/CB1/CB2 module *on* the mainboard itself, then any Pi connections (usb, etc) would actuallly be on the Manta/Mainboard, and not the Pi/Computer board. 30 | 31 | # Regarding Katapult (formerly known as CanBoot) 32 | 33 | You may have seen other guides have installing Katapult/CanBOOT onto devices as a first step. Katapult is a custom firmware and allows flashing of Klipper to the devices via the CAN network so you don't have to plug a USB cable in each time to flash/update klipper. Katapult is really handy but it is ***NOT*** mandatory. This will be discussed later, but Klipper will happily run over a CAN network with or without Katapult. 34 | 35 | 36 | # Your main CAN network adapter 37 | 38 | To actually create a CAN network in your system, your Pi needs some sort of device to act as a CAN adapter (think of it like a USB network card, or USB wifi dongle). The simplest plug-and-play option is to use a dedicated USB to Can device such as the BigTreeTech U2C, Mellow Fly UTOC, Fysetc UCAN, etc. (other devices exist as well). The second "cheaper" option is to actually utilise your printer mainboard (ie. Octopus or Spider board) to function as a usb-can bridge for klipper. We'll cover both options, but you only need to choose one. 39 | 40 | 41 | # Checkpoints 42 | 43 | Throughout this guide you will notice stop signs: 44 | 45 |

46 | 47 |

48 | 49 | These denote sections where you need to do a final check before proceeding. If you do not get the same results as outlined in these STOP sections, *do not* go further. Continuing on to subsequent sections when the section you are on isn't set up correctly will just either not work or cause confusing issues. 50 | 51 | 52 | # New build 53 | 54 | If this is a fresh build click [here](./Getting_Started.md) to start your journey. 55 | 56 | # Updating 57 | 58 | If you are just updating an existing already-working CANBus system, click [here](./Updating.md) for steps on how to update the firmware on your boards. 59 | 60 | # HELP! 61 | 62 | If you are just getting stuck, or you had a working CANBus system that is now not working, have a look at the [troubleshooting section](./troubleshooting.md) for information that may help. 63 | 64 | 65 | 66 | 67 | -------------------------------------------------------------------------------- /katapult_updating.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Updating Katapult 4 | parent: Updating 5 | nav_order: 30 6 | --- 7 | # Updating Katapult 8 | 9 | Updating Katapult isn't something you should need to do regularly, if at all. If Katapult is currently working on your board (toolhead or mainboard or other) then just leave it as is. 10 | 11 | The only time you should really need to update Katapult is if you are changing CAN speeds, and even then that's only on the toolhead. If you need to do this please refer to [Updating CAN Speed](./updating_can_speed.md) 12 | 13 | You should never really have to update your Katapult on the mainboard. Even if you wish to change your CanBUS speeds you don't need to change Katapult **On the Mainboard** as it only communicates via USB and not via CAN. 14 | 15 | ## Updating Toolhead Katapult 16 | 17 | This is only if you need to update katapult as well. If you are just doing a Klipper firmware update (because you updated Klipper on your Pi and now it is yelling at you or something) then skip to [here](#updating-toolhead-klipper) 18 | 19 | **Step 1** 20 | 21 | Change to your Katapult directory, then go into the Katapult firmware config menu by running:: 22 | ```bash 23 | cd ~/katapult 24 | make menuconfig 25 | ``` 26 | 27 | This time **make sure "Build Katapult deployment application" is configured** with the properly bootloader offset (same as the "Application start offset" that is relevant for your toolhead). Make sure all the rest of your settings are correct for your toolhead. 28 | 29 | You can find screenshots of settings for common toolheads in the [Common Toolhead Hardware](./toolhead_flashing/common_hardware) section, but once again, **make sure "Build Katapult deployment application" is set** 30 | 31 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e0482b4c-7a6b-4b6d-94bd-76e50a917f66) 32 | 33 | 34 | This time when you run `make`, along with the normal katapult.bin file it will also generate a deployer.bin file. This deployer.bin is a fancy little tool that uses the existing bootloader (Katapult, or stock, or whatever) to "update" itself into the Katapult you just compiled. 35 | ```bash 36 | make clean 37 | make 38 | ``` 39 | 40 | So to update your Katapult, you just need to flash this deployer.bin file via your existing Katapult (in a very similar way you would flash klipper via Katapult). 41 | 42 | **Step 2** 43 | 44 | If you already have a functioning CAN setup, and your [mcu toolhead] canbus_uuid is in your printer.cfg, then you can force Katapult to reboot into Katapult mode by running: 45 | 46 | ```bash 47 | python3 ~/katapult/scripts/flashtool.py -i can0 -r -u yourtoolheaduuid 48 | ``` 49 | 50 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/eda51419-6ab4-49c5-9c33-a581b08d085c) 51 | 52 | If will probably say "Flash success" 53 | **THIS IS NOT ACTUALLY FLASHING ANYTHING, YOU NEED TO CONTINUE WITH THE STEPS BELOW** 54 | 55 | **Step 3** 56 | 57 | If you don't have the UUID (or something has gone wrong with the klipper firmware and your toolboard is hung) then you can also double-press the RESET button on your toolhead to force Katapult to reboot into Katapult mode. 58 | 59 | You can verify it is in the proper mode by running `python3 ~/katapult/scripts/flashtool.py -q`. If you see a "Detected UUID: xxxxxxxxx, Application: Katapult" device then it is good to go. 60 | ```bash 61 | python3 ~/katapult/scripts/flashtool.py -q 62 | ``` 63 | 64 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ff9dcbb3-0456-4d87-8091-41d5d6050c02) 65 | 66 | **Step4** 67 | 68 | Once you are at this stage you can flash the deployer.bin by running: 69 | 70 | ```bash 71 | python3 ~/katapult/scripts/flashtool.py -i can0 -u yourtoolheaduuid -f ~/katapult/out/deployer.bin 72 | ``` 73 | 74 | and your Katapult should update. 75 | 76 | ## Updating Mainboard Katapult 77 | 78 | Again, it is very rare to ever need to update a working Katapult firmware on a USB-CAN-Bridge mainboard, because even if you are changing CAN speeds this won't affect the Katapult on a mainboard as it communicates over USB and doesn't actually care about the CANBus. 79 | 80 | However, **if** you need to update katapult for whatever reason then follow the steps below. 81 | 82 | **Step 1** 83 | 84 | Change to your Katapult directory: 85 | ```bash 86 | cd ~/katapult 87 | ``` 88 | then go into the Katapult firmware config menu by running: 89 | ```bash 90 | make menuconfig 91 | ``` 92 | 93 | This time **make sure "Build Katapult deployment application" is configured** with the properly bootloader offset (same as the "Application start offset" that is relevant for your mainboard). Make sure all the rest of your settings are correct for your mainboard. 94 | 95 | You can find screenshots of settings for common mainboards in the [Common Mainboard Hardware](./mainboard_flashing/common_hardware) section, but once again, **make sure "Build Katapult deployment application" is set** 96 | 97 | If your board doesn't exist in the common_hardware folder already, then you want the Processor, Clock Reference, and Application Start offset to be set as per whatever board you are running. Set the "Build Katapult deployment application", and make sure "Communication Interface" is set to USB. Also make sure the "Support bootloader entry on rapid double click of reset button" is marked. It makes it so a double press of the reset button will force the board into Katapult mode. Makes re-flashing after a mistake a lot easier. 98 | 99 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/7726b137-0079-4191-bd22-1b084345809f) 100 | 101 | This time when you run `make`, along with the normal katapult.bin file it will also generate a deployer.bin file. This deployer.bin is a fancy little tool that uses the existing bootloader (Katapult, or stock, or whatever) to "update" itself into the Katapult you just compiled. 102 | ```bash 103 | make clean 104 | make 105 | ``` 106 | So to update your Katapult, you just need to flash this deployer.bin file via your existing Katapult (in a very similar way you would flash klipper via Katapult). 107 | 108 | **Step 2** 109 | 110 | If you already have a functioning CAN setup, and your [mcu] canbus_uuid is in your printer.cfg, then you can force Katapult to reboot into Katapult mode by running: 111 | 112 | ```bash 113 | python3 ~/katapult/scripts/flashtool.py -i can0 -r -u yourmainboarduuid 114 | ``` 115 | 116 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/eda51419-6ab4-49c5-9c33-a581b08d085c) 117 | 118 | If will probably say "Flash success" **THIS IS NOT ACTUALLY FLASHING ANYTHING, YOU NEED TO CONTINUE WITH THE STEPS BELOW** 119 | 120 | **Step 3** 121 | 122 | If you don't have the UUID (or something has gone wrong with the klipper firmware and your mainboard is hung) then you can also double-press the RESET button on your mainboard to force Katapult to reboot into Katapult mode. 123 | 124 | You can verify it is in the proper mode by running `ls /dev/serial/by-id`. If you see a "usb-katapult-......" device then it is good to go. 125 | ```bash 126 | ls /dev/serial/by-id 127 | ``` 128 | 129 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1e9f0f7c-ada3-490b-bd62-bde25b67c362) 130 | 131 | **Step4** 132 | 133 | Once you are at this stage you can flash the deployer.bin by running: 134 | 135 | ```bash 136 | python3 ~/katapult/scripts/flashtool.py -f ~/katapult/out/deployer.bin -d /dev/serial/by-id/usb-katapult_your_mainboard_usb_id 137 | ``` 138 | 139 | and your Katapult should update. 140 | 141 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/aa644018-861e-473c-83f9-4f2a423aa44b) 142 | 143 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Common Mainboard Hardware 4 | parent: Mainboard Flashing 5 | has_children: true 6 | nav_order: 410 7 | --- 8 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Kraken/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Kraken 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/915d6855-088a-4137-896c-78737cb08925) 13 | 14 | # DFU Mode 15 | 16 | To put the Kraken into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/60c2859e-1c49-45be-b47c-d1642743ff9a) 19 | 20 | 21 | # Katapult Config 22 | 23 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/42a4f43f-5f52-468b-a8dc-1a8dce937ea7) 24 | 25 | # Klipper USB-CAN-Bridge Config 26 | 27 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ac4cbd8f-cfd9-4def-89ae-bf1c6a31c488) 28 | 29 | 30 | 31 | 32 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Manta E3EZ/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Manta E3EZ 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e7aa0564-4d75-4c4d-82a2-cfcb8bf6f92f) 13 | 14 | # DFU Mode 15 | 16 | To put the Manta E3EZ into DFU mode, hold the BOOT button and while still holding press and release the RST button. Then count to 5 and release the BOOT button. 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/f6e00688-6805-4433-b38c-fec34042e418) 19 | 20 | 21 | # Katapult Config 22 | 23 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/074383e9-fd53-4672-ae33-c9fd9d37e513) 24 | 25 | # Klipper USB-CAN-Bridge Config 26 | 27 | ![image](https://user-images.githubusercontent.com/124253477/235831140-66b78a6f-5f3b-403b-9383-037caf9b1eee.png) 28 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Manta M5P V1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Manta M5P V1.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/d6c1aec5-ec9d-4fab-8e01-40a233039aa4) 13 | 14 | 15 | # DFU Mode 16 | 17 | To put the Manta M5P V1.0 into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 18 | 19 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/0acf8512-8d60-40b3-8b92-384b29a916d0) 20 | 21 | 22 | 23 | # Katapult Config 24 | 25 | ![image](https://user-images.githubusercontent.com/124253477/235831073-92c31a1a-d252-4deb-9f94-e4f2e755881d.png) 26 | 27 | # Klipper USB-CAN-Bridge Config 28 | 29 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/39486ecf-b895-47c5-8a2f-c707fa29e180) 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Manta M8P v1.1/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Manta M8P V1.1 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/de9c07e8-5349-4348-a10a-c20bd2585bad) 13 | 14 | # DFU Mode 15 | 16 | To put the M8P V1.1 into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e1d46e49-776d-442b-9cd1-eca262e04265) 19 | 20 | 21 | # Katapult Config 22 | ![image](https://user-images.githubusercontent.com/14154875/225157525-d1b8f813-ab11-4f59-87fa-45f8a3ee2a6a.png) 23 | 24 | 25 | # Klipper USB-CAN-Bridge Config 26 | ![image](https://user-images.githubusercontent.com/14154875/225156775-2fc1d727-0aa8-4d1c-abb3-1a832fab2187.png) 27 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Manta M8P v2.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Manta M8P V2.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/aa44e56e-bb80-4b38-9dbc-5d17fffe5903) 13 | 14 | # CAN Port 15 | 16 | the CAN port is a JST-XH header located here: 17 | 18 | ![image](https://github.com/user-attachments/assets/0cc73ca8-94d9-4ee9-92ed-a29683f61ab5) 19 | 20 | 21 | # DFU Mode 22 | 23 | To put the M8P V2 into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/be5a7f3e-98e7-491c-8f00-beb343e82cad) 26 | 27 | 28 | # Katapult Config 29 | 30 | ![image](https://github.com/user-attachments/assets/0fe71954-ab42-4b78-bbb9-0f380ab1e0ed) 31 | 32 | 33 | # Klipper USB-CAN-Bridge Config 34 | 35 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/eddbf66e-e417-4e9a-b31d-4df7a1e4e8c4) 36 | 37 | 38 | 39 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Octopus Max EZ/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Octopus Max EZ 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/b9199bf6-b27a-4d84-8c14-4b167c941fab) 13 | 14 | # DFU Mode 15 | 16 | To put the Octopus Max EZ into DFU mode, hold the BOOT0 button (Blue) and while still holding press and release the RESET button (Green). Then count to 5 and release the BOOT0 button. 17 | ![image](https://github.com/user-attachments/assets/7a7b15bf-38ed-47de-9cdb-1de54b06b803) 18 | 19 | # Katapult Config 20 | 21 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ce6782aa-aaa7-4e95-a664-cf490f82f535) 22 | 23 | # Klipper USB-CAN-Bridge Config 24 | 25 | ![image](https://user-images.githubusercontent.com/124253477/221387725-5b28da97-6f3b-4e48-86db-46811023a2b7.png) 26 | 27 | 28 | 29 | 30 | 31 | 32 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Octopus Pro v1.0: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Octopus Pro v1.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | 13 | 14 | # DFU Mode 15 | 16 | To put the octopus into DFU mode you need to put in the boot jumper (purple) and press the reset button (green). 17 | 18 | ![image](https://github.com/user-attachments/assets/553abdd1-b43d-4e33-bdcb-7da923e1bfed) 19 | 20 | 21 | 22 | 23 | ## Katapult Config 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/673ce3c6-5bd7-48a8-bcd4-99aeefb0f0a2) 26 | 27 | ## Klipper USB-CAN-Bridge Config 28 | 29 | ![image](https://user-images.githubusercontent.com/124253477/221378034-ac82a51e-6ba7-4288-8186-91a6733dbd2f.png) 30 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Octopus Pro v1.1/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Octopus Pro v1.1 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is located next to the CAN port. 11 | 12 | ![image](https://github.com/user-attachments/assets/74ddb87b-1cda-4837-9d18-136b77ee165c) 13 | 14 | # CAN port 15 | 16 | The Octopus Pro v1.1 CAN port is a JST-XH connector located at the bottom-right corner of the board. 17 | 18 | ![image](https://github.com/user-attachments/assets/3b378dcb-4727-464c-9b76-c1e67632a513) 19 | 20 | 21 | # DFU Mode 22 | 23 | To put the octopus into DFU mode you need to put in the boot jumper and press the reset button . 24 | 25 | ![image](https://github.com/user-attachments/assets/9e87b908-2cf2-428b-b1c6-d4b3aecfe4b4) 26 | 27 | 28 | 29 | 30 | ## Katapult Config 31 | 32 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e9850f4a-d4d9-438b-8b95-3fd21cd790d8) 33 | 34 | ## Klipper USB-CAN-Bridge Config 35 | 36 | ![image](https://user-images.githubusercontent.com/124253477/221378502-d3aee8c7-c4ba-42da-838b-3e64cfc6262d.png) 37 | 38 | 39 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Octopus X7/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Octopus X7 (Troodon) 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # DFU Mode 13 | 14 | To put the Octopus X7 into DFU mode, hold the BOOT button and while still holding press and release the RESET button. Then count to 5 and release the BOOT button. 15 | 16 | ![image](https://github.com/user-attachments/assets/dbcd62fe-7180-49d3-b2ef-c61ef9639c96) 17 | 18 | 19 | 20 | ## Katapult Config 21 | 22 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ec17d20a-2aba-4cc5-809f-aa1748a76a63) 23 | 24 | ## Klipper USB-CAN-Bridge Config 25 | 26 | ![image](https://user-images.githubusercontent.com/124253477/221378459-561064a6-deaa-4590-85b9-058f480871e2.png) 27 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech Octopus/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Octopus 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # CAN port 13 | 14 | The Octopus v1/v1.1 and the Octopus Pro v1 all use an RJ12 port for their CANBUS connection. It only uses the middle two pins, the rest are unused. 15 | 16 | The "bottom" middle pin is CAN-H, the "top" middle pin is CAN-L. 17 | 18 | ![image](https://github.com/user-attachments/assets/d03e250a-7c06-437c-aa29-36bf6a5d7020) 19 | 20 | 21 | # DFU Mode 22 | 23 | To put the octopus into DFU mode you need to put in the boot jumper (purple) and press the reset button (green). The blue is for the "power over USB" jumper and isn't needed if you already have 24v hooked up to the octopus. 24 | 25 | ![image](https://user-images.githubusercontent.com/124253477/229234235-345ff23e-cc9e-4d61-ab7e-3df27dda1eb5.png) 26 | 27 | 28 | **The BTT Octopus comes in many variations of MCU chip. Make sure you pick the correct config for the MCU chip you have** 29 | 30 | # STM32F446 31 | ## Katapult Config 32 | 33 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/673ce3c6-5bd7-48a8-bcd4-99aeefb0f0a2) 34 | 35 | ## Klipper USB-CAN-Bridge Config 36 | 37 | ![image](https://user-images.githubusercontent.com/124253477/221378034-ac82a51e-6ba7-4288-8186-91a6733dbd2f.png) 38 | 39 | 40 | # STM32F429 41 | ## Katapult Config 42 | 43 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/41d4bfe5-ed20-4956-93fd-cb3b99250aae) 44 | 45 | ## Klipper USB-CAN-Bridge Config 46 | 47 | ![image](https://user-images.githubusercontent.com/124253477/221378352-e22e8719-6a26-499a-9f9f-375c0baa1cd6.png) 48 | 49 | 50 | # STM32F407 51 | ## Katapult Config 52 | 53 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ec17d20a-2aba-4cc5-809f-aa1748a76a63) 54 | 55 | ## Klipper USB-CAN-Bridge Config 56 | 57 | ![image](https://user-images.githubusercontent.com/124253477/221378459-561064a6-deaa-4590-85b9-058f480871e2.png) 58 | 59 | 60 | # STM32H723 61 | ## Katapult Config 62 | 63 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e9850f4a-d4d9-438b-8b95-3fd21cd790d8) 64 | 65 | ## Klipper USB-CAN-Bridge Config 66 | 67 | ![image](https://user-images.githubusercontent.com/124253477/221378502-d3aee8c7-c4ba-42da-838b-3e64cfc6262d.png) 68 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech SKR Pico/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SKR Pico 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | As the SKR Pico requires an [external CAN transciever](#transceiver) there is no built in 120ohm resistor on the Pico itself. The transceiver you use will likely have the 120r resistor hard soldered already, but some may have jumpers or solder pads to add/remove it from the circuit. 11 | 12 | 13 | # Katapult Config 14 | 15 | ![image](https://user-images.githubusercontent.com/124253477/221390508-c6fdd63a-f4af-46e1-b100-ee90dd723bf8.png) 16 | 17 | # Klipper USB-CAN-Bridge Config 18 | 19 | ![image](https://user-images.githubusercontent.com/124253477/221390518-b7f15c58-6beb-43bd-a47b-d6823956e997.png) 20 | 21 | # Transceiver 22 | You will need a seperate CAN Transceiver board, such as the TJA1050: 23 | 24 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2df10f80-8239-4368-9aa4-e1abe9ded541) 25 | 26 | 27 | The Can Tx and Can Rx will be connected to the IO0 and IO1 port which is commonly used for the UART Pi connection. You can also hook up the Gnd and 5v from this port to the transceiver board. 28 | 29 | ![image](https://user-images.githubusercontent.com/124253477/221390636-6342067f-1a2a-4b18-99a4-d33441dab933.png) 30 | 31 | 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech SKR-3 EZ/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SKR-3 EZ 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is *meant* to be a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | However, it seems some recent boards have been made without this resitor and instead including a standalone resitor with the connector packet which you can crimp on if required. 13 | 14 | # STM32H723 15 | 16 | ## Katapult Config 17 | 18 | ![image](https://github.com/user-attachments/assets/d6bc279a-ca5c-48a0-b881-64c52359b66b) 19 | 20 | 21 | ## Klipper USB-CAN-Bridge Config 22 | 23 | ![image](https://github.com/user-attachments/assets/be1a0c88-bb9c-4d9a-9f86-1ae873a88365) 24 | 25 | 26 | # STM32H743 27 | 28 | ## Katapult Config 29 | 30 | ![image](https://github.com/user-attachments/assets/e847ca07-2619-48ad-a5c1-781c2ec96264) 31 | 32 | 33 | ## Klipper USB-CAN-Bridge Config 34 | 35 | ![image](https://github.com/user-attachments/assets/64f4d744-6a82-43c0-a5f4-bcca7a4fadc9) 36 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech SKR-3/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SKR-3 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # Katapult Config 13 | 14 | ![image](https://user-images.githubusercontent.com/124253477/236376883-34ae7805-365a-40ad-a5fc-f613e9d1fc4d.png) 15 | 16 | # Klipper USB-CAN-Bridge Config 17 | 18 | ![image](https://user-images.githubusercontent.com/124253477/236376937-172778da-ba61-45af-b64e-ed1b2d79f51b.png) 19 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/BigTreeTech SKRat v1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SKRat v1.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1d053118-e901-4b82-91b8-ba6cbf985895) 13 | 14 | # DFU Mode 15 | 16 | To put the SKRat into DFU mode, hold the BOOT button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/3e24de91-d5d1-476f-b3e9-d05ab3bbb7df) 19 | 20 | 21 | 22 | # Katapult Config 23 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/76cb21f2-5059-49df-83df-d9fc02992894) 24 | 25 | 26 | # Klipper USB-CAN-Bridge Config 27 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/76114c58-679c-4e0c-a832-ff20b5007d22) 28 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider Pro/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider Pro 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/user-attachments/assets/21465227-8b31-4e2b-b725-2178dbba128c) 13 | 14 | # CAN Port 15 | 16 | the CAN port is a JST-XH header located here: 17 | 18 | ![image](https://github.com/user-attachments/assets/91bbfc79-ce77-44ec-bea8-8fa8868a6e6d) 19 | 20 | # DFU Mode 21 | 22 | To put the Spider Pro into DFU mode, hold the BOOT0 button and while still holding press and release the RST button. Then count to 5 and release the BOOT0 button. 23 | 24 | ![image](https://github.com/user-attachments/assets/6809e97d-a9df-46d6-bf25-2177aa1715fc) 25 | 26 | 27 | # Katapult Config 28 | 29 | ![image](https://github.com/user-attachments/assets/b72c48d7-dea6-4483-a20c-b7f3b9fa0bf8) 30 | 31 | 32 | # Klipper USB-CAN-Bridge Config 33 | 34 | ![image](https://github.com/user-attachments/assets/b6185a32-e808-4903-9073-efdc528023d3) 35 | 36 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider v1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider V1.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | As the Spider v1.0 requires an [external CAN transciever](#transceiver) there is no built in 120ohm resistor on the Spider itself. The transceiver you use will likely have the 120r resistor hard soldered already, but some may have jumpers or solder pads to add/remove it from the circuit. 11 | 12 | # Katapult Config 13 | 14 | ![image](https://github.com/user-attachments/assets/3d8e589e-feaa-4695-9328-539dc8ac21c9) 15 | 16 | 17 | # Klipper USB-CAN-Bridge Config 18 | 19 | ![image](https://user-images.githubusercontent.com/124253477/221349817-d7381c21-fecc-4111-a34b-bf0522cd456e.png) 20 | 21 | 22 | # Transceiver 23 | You will need a seperate CAN Transceiver board, such as the TJA1050: 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2df10f80-8239-4368-9aa4-e1abe9ded541) 26 | 27 | 28 | The Can Rx and Can Tx will be connected to the PD0 and PD1 port (which is labelled as the CAN port). You can also hook up the Gnd and 5v from this port to the transceiver board. 29 | 30 | ![image](https://user-images.githubusercontent.com/124253477/221392367-bc3c2d55-2869-4d79-9610-3f2bb0bf41dc.png) 31 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider v2.2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider v2.2 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | As the Spider v2.2 requires an [external CAN transciever](#transceiver) there is no built in 120ohm resistor on the Spider itself. The transceiver you use will likely have the 120r resistor hard soldered already, but some may have jumpers or solder pads to add/remove it from the circuit. 11 | 12 | # Katapult Config 13 | 14 | ![image](https://github.com/user-attachments/assets/d42513b0-d9ab-4bae-ae64-2b0253759c18) 15 | 16 | 17 | # Klipper USB-CAN-Bridge Config 18 | 19 | ![image](https://user-images.githubusercontent.com/124253477/221349817-d7381c21-fecc-4111-a34b-bf0522cd456e.png) 20 | 21 | 22 | # Transceiver 23 | You will need a seperate CAN Transceiver board, such as the TJA1050: 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2df10f80-8239-4368-9aa4-e1abe9ded541) 26 | 27 | The Can Rx and Can Tx will be connected to the PD0 and PD1 port (which is labelled as the CAN port). You can also hook up the Gnd and 5v from this port to the transceiver board. 28 | 29 | ![image](https://user-images.githubusercontent.com/124253477/221390921-e1fa8675-347a-4fda-8217-95b9f872acc7.png) 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider v2.3/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider v2.3 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | As the Spider v2.3 requires an [external CAN transciever](#transceiver) there is no built in 120ohm resistor on the Spider itself. The transceiver you use will likely have the 120r resistor hard soldered already, but some may have jumpers or solder pads to add/remove it from the circuit. 11 | 12 | # DFU mode 13 | 14 | To put the Spider v2.3 into DFU mode, connect the Spider to the Pi with a USB cable, then place a jumper on the `3.3v` and `BT0` pins: 15 | 16 | ![image](https://github.com/user-attachments/assets/491e2e1c-7b56-419b-a0ec-e08707820030) 17 | 18 | 19 | 20 | Then press the RST button on the side of the board: 21 | 22 | ![image](https://github.com/user-attachments/assets/05a5354b-e578-4655-b0db-fd5021f3efbb) 23 | 24 | 25 | # Katapult Config 26 | 27 | ![image](https://github.com/user-attachments/assets/b99edc19-008a-43fa-be5a-21434b081185) 28 | 29 | # Klipper USB-CAN-Bridge Config 30 | 31 | ![image](https://user-images.githubusercontent.com/124253477/221349817-d7381c21-fecc-4111-a34b-bf0522cd456e.png) 32 | 33 | 34 | # Transceiver 35 | You will need a seperate CAN Transceiver board, such as the TJA1050: 36 | 37 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2df10f80-8239-4368-9aa4-e1abe9ded541) 38 | 39 | The Can Rx and Can Tx will be connected to the PD0 and PD1 port (which is labelled as the CAN port). You can also hook up the Gnd and 5v from this port to the transceiver board. 40 | 41 | ![image](https://user-images.githubusercontent.com/124253477/221392424-3454c8da-a7b5-48a7-add6-9e9b751fc3b4.png) 42 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider v3.0 H7/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider v3.0 H7 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | # 120 ohm Termination Resistor 8 | 9 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 10 | 11 | # CAN Port 12 | 13 | The CAN port is a JST-XH header located here: 14 | 15 | ![image](https://github.com/user-attachments/assets/d676c2ab-0f04-4a0d-8881-1ef1e9b91680) 16 | 17 | 18 | # DFU Mode 19 | 20 | To put the Spider 3.0 H7 into DFU mode, hold the BT0 button and while still holding press and release the RST button. Then count to 5 and release the BT0 button. 21 | 22 | ![image](https://github.com/user-attachments/assets/64f05c3f-660e-43da-812f-05d6177baeb3) 23 | 24 | 25 | # Katapult Config 26 | 27 | ![image](https://github.com/user-attachments/assets/a95ecd50-7d4c-4edb-b2b3-9a7cc6f056a9) 28 | 29 | 30 | 31 | # Klipper USB-CAN-Bridge Config 32 | 33 | ![image](https://github.com/user-attachments/assets/1a83b0cd-73aa-4245-b0bd-980fdc7f86ed) 34 | 35 | 36 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Fysetc Spider v3.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc Spider v3.0 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # CAN Port 13 | 14 | The CAN port is a JST-XH header located here: 15 | 16 | ![image](https://github.com/user-attachments/assets/89058e8c-9576-428a-bb84-7fc21fce313f) 17 | 18 | 19 | # DFU Mode 20 | 21 | To put the Spider 3.0 into DFU mode, hold the BT0 button and while still holding press and release the RST button. Then count to 5 and release the BT0 button. 22 | 23 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/f3901e72-4066-4125-885d-d78205e9f1ae) 24 | 25 | # Katapult Config 26 | 27 | ![image](https://github.com/user-attachments/assets/0e6b577f-34c3-4ceb-ac66-e024fad64d54) 28 | 29 | # Klipper USB-CAN-Bridge Config 30 | 31 | ![image](https://user-images.githubusercontent.com/124253477/221349817-d7381c21-fecc-4111-a34b-bf0522cd456e.png) 32 | 33 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/LDO Leviathan v1.2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: LDO Leviathan v1.2 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/0429410e-0fd0-4d65-bbf6-b5ffb6e06c76) 13 | 14 | 15 | # DFU Mode 16 | 17 | To put the Leviathan into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 18 | 19 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/09a84d17-c6be-4d75-86d6-f14e21991c61) 20 | 21 | 22 | 23 | # Katapult Config 24 | 25 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/272721d7-6bbd-44bc-a977-ccfc6917f0b1) 26 | 27 | 28 | # Klipper USB-CAN-Bridge Config 29 | 30 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/5eae405b-0c87-49ba-9c64-77c533e03e77) 31 | 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/MKS Monster8 v2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: MKS Monster8 v2 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | 9 | 10 | 11 | # 120 ohm Termination Resistor 12 | 13 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 14 | 15 | # DFU Mode 16 | 17 | {: .stop } 18 | >**UNPLUG HEATERS BEFORE USING DFU MODE** 19 | > 20 | >There may be a chance that the heater pins will pull "High" during DFU mode, which would turn the attached heater on without any temperature regulation. 21 | > 22 | >To be safe just unplug any heaters before using DFU mode. 23 | 24 | To put the Monster8 into DFU mode, hold the BOOT0 button and while still holding press and release the RESET button. Then count to 5 and release the BOOT0 button. 25 | 26 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/0682086b-f507-430b-96fc-dfbe1812bef9) 27 | 28 | # Katapult Config 29 | 30 | ![image](https://user-images.githubusercontent.com/124253477/221387924-afb1784e-823b-48b4-a5d4-3ea08cd09071.png) 31 | 32 | # Klipper USB-CAN-Bridge Config 33 | 34 | ![image](https://user-images.githubusercontent.com/124253477/221387939-22b5a327-af94-4337-b952-849758bec999.png) 35 | 36 | 37 | # NOTE ON ENABLING CAN 38 | Make sure to have the CAN select jumper installed. The two jumpers should be on the LEFT and MIDDLE pins. 39 | 40 | ![image](https://user-images.githubusercontent.com/124253477/221388006-b58054f2-649b-44f0-a997-6d9423928736.png) 41 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Mellow Fly-D5P/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow FLY-D5P 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/9f1bdf13-b8f5-4ab2-b661-7ada729f2ad0) 13 | 14 | 15 | # DFU Mode 16 | 17 | To put the FLY-D5P into DFU mode, hold the BOOT button and while still holding press and release the RESET button. Then count to 5 and release the BOOT button. 18 | 19 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/be5ae84e-41ce-43bb-94d2-79e6fbc6a82a) 20 | 21 | 22 | 23 | 24 | # Katapult Config 25 | 26 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ee04bdb5-164d-4475-83a0-e675626c7a0a) 27 | 28 | 29 | # Klipper USB-CAN-Bridge Config 30 | 31 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/d1dfe729-eba7-457b-8c3f-4a0c3b80aec0) 32 | 33 | 34 | 35 | 36 | 37 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Mellow Fly-Super8 Pro H723/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly-Super8 Pro H723 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # DFU Mode 13 | 14 | To put the Fly-Super8 Pro H723 into DFU mode you need to put in the boot jumper at BT0 and press the reset button. 15 | 16 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/10a4fc29-b546-498e-b819-dd47370b151f) 17 | 18 | 19 | # Katapult Config 20 | 21 | ![image](https://github.com/user-attachments/assets/3f9fb477-3c7e-40a5-9d4f-05a7d0730f28) 22 | 23 | 24 | 25 | # Klipper USB-CAN-Bridge Config 26 | 27 | ![image](https://github.com/user-attachments/assets/dc9356fa-332d-43c1-b1a8-057707471610) 28 | -------------------------------------------------------------------------------- /mainboard_flashing/common_hardware/Mellow Fly-Super8/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly-Super8 4 | parent: Common Mainboard Hardware 5 | grand_parent: Mainboard Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # DFU Mode 13 | 14 | To put the Fly-Super8 into DFU mode you need to put in the boot jumper at BT0 and press the reset button. 15 | 16 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/10a4fc29-b546-498e-b819-dd47370b151f) 17 | 18 | 19 | # Katapult Config 20 | 21 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/10c95ae6-123b-4b90-a242-db9926e7cd12) 22 | 23 | 24 | # Klipper USB-CAN-Bridge Config 25 | 26 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/470a0d03-8c88-4460-ad19-e7233362b50a) 27 | 28 | -------------------------------------------------------------------------------- /mainboard_klipper_updating.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: CAN-Bridge Mainboard Updating 4 | parent: Updating 5 | nav_order: 20 6 | --- 7 | 8 | # Updating Mainboard Klipper 9 | 10 | **Step 1** 11 | 12 | To update Klipper, you first need to compile a new klipper.bin with the correct settings. 13 | 14 | Move into the klipper directory on the Pi, then go into the klipper configuration menu by running: 15 | ```bash 16 | cd ~/klipper 17 | make menuconfig 18 | ``` 19 | 20 | You can find screenshots of settings for common mainboards in the [Common Mainboard Hardware](./mainboard_flashing/common_hardware) section. 21 | 22 | Otherwise, you want the Processor and Clock Reference to be set as per whatever board you are running. Set Communication interface to 'USB to CAN bus bridge' then set the CAN Bus interface to use the pins that are specific to your mainboard. Also set the CAN bus speed to the same as the speed in your can0 file. In this guide it is set to 1000000. 23 | 24 | Once you have the firmware configured, hit Q to save and quit from the makemenu screen, then run a `make clean` to make sure there are no old files hanging around, then `make` to compile the firmware. It will save the firmware to ~/klipper/out/klipper.bin 25 | 26 | **Step 2** 27 | 28 | First, stop the Klipper service on the Pi by running: 29 | 30 | ```bash 31 | sudo service klipper stop 32 | ``` 33 | 34 | If you already have a functioning CAN setup, and your [mcu] canbus_uuid is in your printer.cfg, then you can force Katapult to reboot into Katapult mode by running: 35 | 36 | ```bash 37 | python3 ~/katapult/scripts/flashtool.py -i can0 -r -u yourmainboarduuid 38 | ``` 39 | 40 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/eda51419-6ab4-49c5-9c33-a581b08d085c) 41 | 42 | It will probably say "Flash success" **THIS IS NOT ACTUALLY FLASHING ANYTHING, YOU NEED TO CONTINUE WITH THE STEPS BELOW** 43 | 44 | {: .highlight } 45 | >If you don't have the UUID (or something has gone wrong with the klipper firmware and your mainboard is hung) then you can also double-press the RESET button on your mainboard to force Katapult to reboot into Katapult mode. 46 | 47 | 48 | **Step 3** 49 | 50 | You can verify it is in the proper mode by running `ls /dev/serial/by-id/*`. If you see a "usb-katapult-......" device then it is good to go. 51 | ```bash 52 | ls /dev/serial/by-id/* 53 | ``` 54 | 55 | ![image](https://github.com/user-attachments/assets/2ed240e4-1347-403f-be18-d55327049708) 56 | 57 | 58 | **Step4** 59 | 60 | Then you can run the same command you used to initially flash Klipper, using the out from the `ls /dev/serial/by-id/*` command you ran above: 61 | 62 | ```bash 63 | python3 ~/katapult/scripts/flashtool.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-katapult_yourmainboardusbid 64 | ``` 65 | 66 | ![image](https://github.com/user-attachments/assets/8fb111ae-2b52-4d75-b7bf-0e565c239ed2) 67 | 68 | 69 | **If** an `lsusb` doesn't show up your mainboard as a CAN adapter (or if `ip a` doesn't show your can0 network), or if the can0 network shows fine but you can't connect to your tooolhead that was previously working (and that you haven't flashed anything new to yet) then there is a good chance your klipper.bin settings were incorrect. Go back to Step 1 and check *all* the settings in the `make menuconfig` screen then recompile with `make clean` and `make`, and hen double-click the reset button on your toolhead to kick it back to katapult mode then go from Step 3. 70 | 71 | However, **if** the `lsusb` and `ip a` show the correct things then your mainboard is now updated, run `sudo service klipper start` to start the klipper service on your Pi again. 72 | ```bash 73 | sudo service klipper start 74 | ``` 75 | 76 | -------------------------------------------------------------------------------- /toolhead_flashing.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Toolhead Flashing 4 | has_children: true 5 | nav_order: 51 6 | has_toc: false 7 | --- 8 | 9 | # General Info 10 | 11 | The following should be taken as an overall guide on what you are going to be achieving. 12 | 13 | **PLEASE DO NOT TAKE THE SCREENSHOTS/CONFIGURATIONS ON THIS PAGE EXACTLY AS WRTTEN AS THEY MAY NOT BE COMPATIBLE WITH YOUR PARTICULAR MAINBOARD** 14 | 15 | Before doing anything it is good to have some dependencies installed. Do this by running these on your Pi: 16 | 17 | ```bash 18 | sudo apt update 19 | sudo apt upgrade 20 | sudo apt install python3 python3-serial 21 | ``` 22 | 23 | {: .note } 24 | > If you get an error along the lines of "unable to locate package python3-serial" then you may be on an older version of linux. 25 | > 26 | > In that case, run: 27 | > 28 | > `sudo apt install python3-pip` 29 | > 30 | > then 31 | > 32 | > `pip3 install pyserial` 33 | 34 | # Installing Katapult 35 | 36 | First you need to clone the Katapult repo onto your pi. Run the following commands to clone (or update) the repo: 37 | 38 | ```bash 39 | test -e ~/katapult && (cd ~/katapult && git pull) || (cd ~ && git clone https://github.com/Arksine/katapult) ; cd ~ 40 | ``` 41 | 42 | This will clone the Katapult repo into a new folder in your home directory called "katapult" if you don't already have it, or it will update your Katapult folder to the latest version if you did already have it. 43 | 44 | To configure the Katapult firmware, run these commands to change into the katapult directory and then modify the firmware menu: 45 | 46 | ```bash 47 | cd ~/katapult 48 | make menuconfig 49 | ``` 50 | 51 | You will need to adapt the below instructions so they cover _your_ board's specicific configuration. You can find screenshots of settings for common toolheads in the [Common Toolhead Hardware](./toolhead_flashing/common_hardware) section. 52 | 53 | If your board doesn't exist in the common_hardware folder already, then you want the Processor, Clock Reference, and Application Start offset to be set as per whatever board you are running. You can leave the "Build Katapult deployment application" set or not set (it makes not difference at this flashing stage, it's only for updating), and make sure "Communication Interface" is set to "CAN Bus" with the correct pins for your toolhead board. Also make sure the "Support bootloader entry on rapid double click of reset button" is marked. It makes it so a double press of the reset button will force the board into Katapult mode. Makes re-flashing after a mistake a lot easier. Lastly, setting the Status LED GPIO Pin won't affect how katapult functions, but it will give a nice visual indicator (of an LED flashing on and off once a second) on the toolhead to show the board is sitting in Katapult mode. 54 | 55 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/4f56422c-c451-4036-afc1-c67475ecd380) 56 | 57 | 58 | 59 | Compile the firmware with `make`. You will now have a katapult.bin (or katapult.uf2) in your ~/katapult/out/ directory. 60 | ```bash 61 | make 62 | ``` 63 | 64 | To flash, connect your toolhead board to the Pi via USB then put the toolhead board into DFU/BOOT mode (your toolhead board user manual should have instructions on doing this). 65 | 66 | If your toolhead board uses an STM32 based MCU use [these flashing steps](#stm32-based-boards) 67 | 68 | If your toolhead board uses an RP2040 MCU, use [these flashing steps](#rp2040-based-boards) 69 | 70 | ## STM32 based boards 71 | 72 | To confirm it’s in DFU mode you can run the command lsusb and look for an entry of “STMicroelectronics STM Device in DFU mode” 73 | ```bash 74 | lsusb 75 | ``` 76 | 77 | ![image](https://github.com/user-attachments/assets/0c63ba83-08fa-4a59-9a49-5d2cca97eddd) 78 | 79 | You can then flash the Katapult firmware to your toolhead board by running 80 | 81 | ```bash 82 | sudo dfu-util -R -a 0 -s 0x08000000:leave -D ~/katapult/out/katapult.bin -d 0483:df11 83 | ``` 84 | 85 | If the result shows an "Error during download get_status" or something, but above it it still has "File downloaded successfullY" then it still flashed OK and you can ignore that error. 86 | 87 | ![image](https://user-images.githubusercontent.com/124253477/225469341-46f3478a-aa96-4378-8d73-96faa90d561c.png) 88 | 89 | Katapult is now installed, [click here](#katapult-is-now-installed) for the next steps. 90 | 91 | 92 | ## RP2040 based boards 93 | 94 | To confirm it's in BOOT mode, run an `lsusb` command and you should see the device as a "Raspberry Pi boot" device (or similar) 95 | ```bash 96 | lsusb 97 | ``` 98 | 99 | ![image](https://user-images.githubusercontent.com/124253477/221344712-500b3c36-8e96-4f23-88ed-5e13ee79535f.png) 100 | 101 | > Note the address of the usb device => 2e8a:0003 102 | 103 | You can then flash the Katapult firmware to your toolhead board by running 104 | 105 | ```bash 106 | cd ~/katapult 107 | make flash FLASH_DEVICE=2e8a:0003 108 | ``` 109 | 110 | where the FLASH_DEVICE ID is what you noted down from the `lsusb` command. 111 | 112 | It should look something like this if the download was successfull 113 | 114 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/34c4ca36-d03d-4eb3-a426-8be7751602fc) 115 | 116 | Katapult is now installed, [click here](#katapult-is-now-installed) for the next steps. 117 | 118 | ## Katapult is now installed 119 | 120 | Katapult should now be successfully flashed. 121 | 122 | Shut down your Pi (`sudo shutdown now`) and then power off your entire printer. 123 | ```bash 124 | sudo shutdown now 125 | ``` 126 | Take out any DFU jumpers on your toolhead (if it needed them) and then wire up your toolhead power (24v and gnd) and CAN (CANH/CANL) wires, then power your printer back up. 127 | 128 | Run the following command to see if the toolhead board is on the CAN network and waiting in Katapult mode 129 | 130 | ```bash 131 | python3 ~/katapult/scripts/flashtool.py -i can0 -q 132 | ``` 133 | 134 | You should see a "Found UUID" with "Application: Katapult" 135 | 136 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ff9dcbb3-0456-4d87-8091-41d5d6050c02) 137 | 138 | If you see the above, take note of the UUID and move on to flashing Klipper to the toolhead board. 139 | 140 | {: .stop } 141 | > 142 | >

143 | > 144 | >

145 | > 146 | >If you do *not* see a UUID here with "Application: Katapult" (if you are using usb-can-bridge mainboard then you may see your Mainboard UUID with "application:klipper", **this is different and not what we are looking for**) then go back to the [Installing Katapult](#installing-katapult) section and try again, making sure the Katapult `make menuconfig` settings are *absolutely* correct for your toolhead board. 147 | > 148 | >If you still don't see the "Application:Katapult" after going through the Katapult flashing steps again, check the [no_uuid troubleshooting](./troubleshooting/no_uuid.md) page for things to try. 149 | > 150 | >**DO NOT CONTINUE** until you can see your toolhead UUID with "application:katapult" when running `python3 ~/katapult/scripts/flashtool.py -i can0 -q` 151 | 152 | 153 | # Installing Klipper 154 | 155 | Move into the klipper directory on the Pi by running: 156 | ```bash 157 | cd ~/klipper 158 | ``` 159 | Then go into the klipper configuration menu by running: 160 | ```bash 161 | make menuconfig 162 | ``` 163 | 164 | Again, if your toolhead is already in [Common Toolhead Hardware](./toolhead_flashing/common_hardware) then you can copy the Klipper settings from there. 165 | 166 | 167 | Otherwise, you want the Processor and Clock Reference to be set as per whatever board you are running. Set Communication interface to"CAN Bus" with the correct pins for your toolhead board. Also set the CAN bus speed to the same as the speed in your can0 file. In this guide it is set to 1000000. 168 | 169 | 170 | Once you have the firmware configured, run a 171 | ```bash 172 | make clean 173 | ``` 174 | to make sure there are no old files hanging around, then 175 | ```bash 176 | make 177 | ``` 178 | to compile the firmware. It will save the firmware to ~/klipper/out/klipper.bin 179 | 180 | ## Using Katapult to flash Klipper 181 | 182 | Stop the Klipper service on the Pi by running: 183 | 184 | ```bash 185 | sudo service klipper stop 186 | ``` 187 | 188 | Run the following query command and take note of the Katapult device that it shows: 189 | ```bash 190 | python3 ~/katapult/scripts/flashtool.py -i can0 -q 191 | ``` 192 | 193 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ff9dcbb3-0456-4d87-8091-41d5d6050c02) 194 | 195 | Then run the following command to install klipper firmware via Katapult. Use the UUID you just retrieved in the above query. 196 | 197 | ```bash 198 | python3 ~/katapult/scripts/flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u youruuid 199 | ``` 200 | 201 | where the "-u" ID is what you found from the "flashtool.py -i can0 -q" query. 202 | 203 | Once the flash has been completed you can run the 204 | ```bash 205 | python3 ~/katapult/scripts/flashtool.py -i can0 -q 206 | ``` 207 | command again. This time you should see the same UUID but with "Application: Klipper" instead of "Application: Katapult" 208 | 209 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1e01f858-71f3-45b4-a69f-1f704dce80d4) 210 | 211 | {: .stop } 212 | > 213 | >

214 | > 215 | >

216 | > 217 | >If you do *not* see "Application:Klipper" for the **same** UUID that was previously showing as "Application:Katapult" then the Klipper didn't flash properly or you had the wrong settings for the Klipper firmware. 218 | > 219 | >Double-click the RESET button on your toolhead to force it back into DFU mode then go back to [Installing Klipper](#installing-klipper) section and try again, making sure the Klipper `make menuconfig` settings are *absolutely* correct for your toolhead board. 220 | > 221 | >If your toolhead board doesn't *have* a RESET button then you'll have to go all the way back to the [Installing Katapult](#installing-katapult) sections and reflash Katapult via USB again, then try the [Installing Klipper](#installing-klipper) steps. 222 | 223 | 224 | 225 | # Klipper is now installed 226 | 227 | You can now run the Klipper canbus query to retrieve the canbus_uuid of your toolhead board: 228 | 229 | ```bash 230 | ~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0 231 | ``` 232 | 233 | ![image](https://user-images.githubusercontent.com/124253477/221332914-c612d996-f9c3-444d-aa41-22b8eda96eba.png) 234 | 235 | Use this UUID in the [mcu] section of your printer.cfg in order for Klipper (on Pi) to connect to the toolhead board. 236 | 237 | Start the Klipper service on the Pi again by running: 238 | 239 | ```bash 240 | sudo service klipper start 241 | ``` 242 | 243 | # Next Step 244 | 245 | Congratulations! Everything is now flashed. Time to move on to the [final steps](./Final_Steps.md). 246 | 247 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Common Toolhead Hardware 4 | parent: Toolhead Flashing 5 | has_children: true 6 | nav_order: 410 7 | --- 8 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/AFC-Lite/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: AFC-Lite for Boxturtle 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/user-attachments/assets/a953667b-bd29-4915-b9d8-d558713afba3) 13 | 14 | 15 | 16 | # DFU mode 17 | 18 | To put the AFC-Lite into DFU mode, connect it via USB to the Pi using the USB-C port then hold the BOOT button, press and release the RESET button, then count to 5 and release the BOOT button. 19 | 20 | ![image](https://github.com/user-attachments/assets/d4b863d0-07cf-4862-98c0-fe2a7a408c3a) 21 | 22 | 23 | # Katapult Config 24 | 25 | ![image](https://github.com/user-attachments/assets/b48ca731-ad33-4eaf-b87a-2869557836c5) 26 | 27 | 28 | 29 | # Klipper Config 30 | 31 | ![image](https://github.com/user-attachments/assets/a4fee86d-34aa-49e5-86a2-11d98f595efc) 32 | 33 | 34 | # Additional Info 35 | 36 | Manual and schematic and other info can be found at [https://github.com/xbst/AFC-Lite/tree/master 37 | ](https://github.com/xbst/AFC-Lite/tree/master 38 | ) 39 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech EBB36 V1.2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech EBB36 V1.2 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/64dc58a0-bd77-4da2-bd55-a58bd25dfacf) 13 | 14 | 15 | # CAN port wiring 16 | 17 | ![EBB36_PowerConnector2](https://github.com/Esoterical/voron_canbus/assets/124253477/5d915c3b-ce41-417a-bf05-887c1da230cd) 18 | 19 | 20 | # DFU Mode 21 | 1. Add a jumper as shown in the image below so the board can be powered via a USB connection 22 | ![image](https://user-images.githubusercontent.com/124253477/226155159-06afd94e-01fb-4256-89ec-10e59d236eac.png) 23 | 24 | 2. Connect your device to your Pi via USB 25 | 3. Press and hold the `RESET` and `BOOT` buttons down (button locations shown in step 1) 26 | 1. Release `RESET` button 27 | 2. Release `BOOT` button 28 | 4. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 29 | ``` 30 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 31 | ``` 32 | 33 | # Katapult Config 34 | 35 | ![image](https://user-images.githubusercontent.com/124253477/228764838-d75c7bc4-a27f-4c3a-b6c8-ef0e78f49f4f.png) 36 | 37 | 38 | # Klipper Config 39 | 40 | ![image](https://user-images.githubusercontent.com/124253477/221349102-cd2f4060-9c29-44aa-b722-9883262b2fc3.png) 41 | 42 | 43 | # Sample Configuration 44 | 45 | A sample configuration file can be found at [https://github.com/bigtreetech/EBB/tree/master/EBB%20CAN%20V1.1%20and%20V1.2%20(STM32G0B1)](https://github.com/bigtreetech/EBB/tree/master/EBB%20CAN%20V1.1%20and%20V1.2%20(STM32G0B1)) 46 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech EBB42 V1.2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech EBB42 V1.2 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/5d13b4cd-9a86-4b96-bff0-23ffad50acaa) 13 | 14 | 15 | # DFU Mode 16 | 1. Add a jumper as shown in the image below so the board can be powered via a USB connection 17 | ![image](https://user-images.githubusercontent.com/124253477/229331918-4239d5dc-b64e-46c9-acd7-b1464d5567d7.png) 18 | 19 | 2. Connect your device to your Pi via USB 20 | 3. Press and hold the `RESET` and `BOOT` buttons down (button locations shown in step 1) 21 | 1. Release `RESET` button 22 | 2. Release `BOOT` button 23 | 4. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 24 | ``` 25 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 26 | ``` 27 | 28 | # Katapult Config 29 | 30 | ![image](https://user-images.githubusercontent.com/124253477/228764838-d75c7bc4-a27f-4c3a-b6c8-ef0e78f49f4f.png) 31 | 32 | 33 | # Klipper Config 34 | 35 | ![image](https://user-images.githubusercontent.com/124253477/221349102-cd2f4060-9c29-44aa-b722-9883262b2fc3.png) 36 | 37 | 38 | # Sample Configuration 39 | 40 | A sample configuration file can be found at [https://github.com/bigtreetech/EBB/tree/master/EBB%20CAN%20V1.1%20and%20V1.2%20(STM32G0B1)](https://github.com/bigtreetech/EBB/tree/master/EBB%20CAN%20V1.1%20and%20V1.2%20(STM32G0B1)) 41 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech Eddy Duo/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech Eddy Duo 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # USB/CAN Mode Switch 9 | 10 | For normal operations connected to your CAN network, make sure the USB/CAN switch is set to CAN. 11 | 12 | ![image](https://github.com/user-attachments/assets/197bde37-ac81-4fec-990e-6a5e6a681da3) 13 | 14 | If you need to flash the Eddy over USB in BOOT mode (for the intial flashing of Katapult or to recover 15 | from a bad firmware flash) set the USB/CAN switch to USB. 16 | 17 | ![image](https://github.com/user-attachments/assets/958fd93d-708b-4625-94b7-1fa0b5bf41cf) 18 | 19 | Just remember to change it *back* to the CAN option before reconnecting it to your CAN network. 20 | 21 | # RP Boot Mode 22 | 23 | Make sure the USB/CAN switch is in the USB position then hold the BOOT button while plugging the USB cable into your Pi. 24 | 25 | The BOOT button is located on the top of the Eddy. 26 | 27 | ![image](https://github.com/user-attachments/assets/ee5b003c-1ddd-4c57-b76a-3c8f4d58dfb5) 28 | 29 | Change the USB/CAN switch back to the CAN position once you are finished using the USB/BOOT mode. 30 | 31 | # Katapult Config 32 | 33 | ![image](https://github.com/user-attachments/assets/4f4add54-70fc-430f-8186-480cca7655fe) 34 | 35 | 36 | # Klipper Config 37 | 38 | ![image](https://github.com/user-attachments/assets/83382734-0ed1-4e6e-b48a-cfe9d895ecd1) 39 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech MMB CAN V1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech MMB v1.0 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | The following settings are valid for the MMB v1.0 and v1.1 9 | 10 | # 120 ohm Termination Resistor 11 | 12 | The header for the 120R termination resistor is circled in purple 13 | 14 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1e359304-b00f-4e93-a877-5b60beaa5249) 15 | 16 | 17 | # DFU Mode 18 | 1. Add a jumper as shown in the image below so the board can be powered via a USB connection 19 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/c5f00b2a-c6dc-4f80-b9aa-4b963d21a580) 20 | 21 | 22 | 2. Connect your device to your Pi via USB 23 | 3. Press and hold the `Reset` and `BOOT` buttons down (button locations shown in step 1) 24 | 1. Release `Reset` button 25 | 2. Release `BOOT` button 26 | 4. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 27 | ``` 28 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 29 | ``` 30 | 31 | # Katapult Config 32 | 33 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/649a5bb8-f35f-42fc-b643-02341e1f4d05) 34 | 35 | 36 | # Klipper Config 37 | 38 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ef7f82f2-b5b9-469d-b1aa-9bad94a4c949) 39 | 40 | 41 | # Sample Configuration 42 | 43 | A sample configuration file can be found at [https://github.com/bigtreetech/MMB/tree/master/Firmware 44 | ](https://github.com/bigtreetech/MMB/tree/master/Firmware 45 | ) 46 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech MMB CAN v2.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech MMB v2.0 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1e359304-b00f-4e93-a877-5b60beaa5249) 13 | 14 | 15 | # DFU Mode 16 | 1. Add a jumper as shown in the image below so the board can be powered via a USB connection 17 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/c5f00b2a-c6dc-4f80-b9aa-4b963d21a580) 18 | 19 | 20 | 2. Connect your device to your Pi via USB 21 | 3. Press and hold the `Reset` and `BOOT` buttons down (button locations shown in step 1) 22 | 1. Release `Reset` button 23 | 2. Release `BOOT` button 24 | 4. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 25 | ``` 26 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 27 | ``` 28 | 29 | # Katapult Config 30 | 31 | ![image](https://github.com/user-attachments/assets/f543775f-5104-486c-ac3f-92e3a38fdbd5) 32 | 33 | 34 | 35 | # Klipper Config 36 | 37 | ![image](https://github.com/user-attachments/assets/663e79e1-35f9-4638-8e37-7adf5feffee1) 38 | 39 | 40 | 41 | # Sample Configuration 42 | 43 | A sample configuration file can be found at [https://github.com/bigtreetech/MMB/tree/master/Firmware 44 | ](https://github.com/bigtreetech/MMB/tree/master/Firmware 45 | ) 46 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech SB2209 (RP2040)/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SB2209 (RP2040) 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/7f9863d3-9593-49d6-bf4c-34ba3d47a687) 13 | 14 | # BOOT Mode 15 | 16 | To put the SB2209 into boot mode (for initial flashing), unplug any USB and CAN cables from the SB2040, then put the 5v jumper in place so the board can receive power over the USB connection: 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/e8daeabf-3c85-45cb-89e3-0735cca961dd) 19 | 20 | Plug a USB cable from the pi to the SB2209 then hold down the BOOT button, breifly press the RST button (while still holding BOOT), wait a few seconds, then release the BOOT button. The SB2209 should now show up to an `lsusb` command as Pi RP2 Boot device: 21 | 22 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/fda3a72c-b255-46fd-ab11-938c92844d42) 23 | 24 | 25 | 26 | # Katapult Config 27 | 28 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/3b1a7a33-48ce-4136-8a0f-0aad49d65f76) 29 | 30 | 31 | # Klipper Config 32 | 33 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/aac98e3a-472f-4934-9000-13de6e66849e) 34 | 35 | # Sample Config 36 | 37 | A sample config file can be found at [https://github.com/bigtreetech/EBB/tree/master/EBB%20SB2209%20CAN%20(RP2040)](https://github.com/bigtreetech/EBB/tree/master/EBB%20SB2209%20CAN%20(RP2040)) 38 | 39 | 40 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/BigTreeTech SB2209 and SB2240/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: BigTreeTech SB2209 and SB2240 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2eddc105-c64f-4d00-9b8d-6f0ba0c23a82) 13 | 14 | 15 | # DFU mode 16 | 1. Add a jumper as shown in the image below so the board can be powered via a USB connection 17 | ![image](https://user-images.githubusercontent.com/124253477/226155311-c90b3571-72db-4f77-8b35-5e825cba9937.png) 18 | 19 | 2. Connect your device to your Pi via USB 20 | 3. Press and hold the `RESET` and `BOOT` buttons down (button locations shown in step 1) 21 | 1. Release `RESET` button 22 | 2. Release `BOOT` button 23 | 4. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 24 | ``` 25 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 26 | ``` 27 | 28 | # Katapult Config 29 | 30 | ![image](https://user-images.githubusercontent.com/124253477/228764307-36da2c3a-393d-43d9-b370-4eb31d231c27.png) 31 | 32 | 33 | # Klipper Config 34 | 35 | ![image](https://user-images.githubusercontent.com/124253477/221349102-cd2f4060-9c29-44aa-b722-9883262b2fc3.png) 36 | 37 | # Sample Configuration 38 | 39 | A sample configuration file can be found at [https://github.com/bigtreetech/EBB/tree/master/EBB%20SB2240_2209%20CAN](https://github.com/bigtreetech/EBB/tree/master/EBB%20SB2240_2209%20CAN) 40 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyDFU.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyDFU.jpg -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKatapult.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKatapult.jpg -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKlipper.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKlipper.jpg -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKlipperBridge.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyKlipperBridge.jpg -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyTerminator.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/DragonDinghy/DragonDinghyTerminator.jpg -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/DragonDinghy/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: DragonDinghy 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in red 11 | 12 | ![image](DragonDinghyTerminator.jpg) 13 | 14 | # DFU mode 15 | 16 | To put the DragonDinghy into DFU mode: 17 | 18 | 1. Apply Power - either via the main 24V input or via USB and the 5V USB jumper, circled in pink 19 | 2. Ensure that the 5V, 5VL and 3.3V LEDs are lit (circled in light blue) 20 | 3. Hold BOOT, tap RESET, release BOOT (circled in red) 21 | 4. DFU mode is indicated via the DFU LED (circled in green) 22 | 23 | 24 | ![image](DragonDinghyDFU.jpg) 25 | 26 | 27 | # Katapult Config 28 | 29 | ![image](DragonDinghyKatapult.jpg) 30 | 31 | # Klipper Config 32 | 33 | ![image](DragonDinghyKlipper.jpg) 34 | 35 | # Klipper as CAN Bridge 36 | 37 | ![image](DragonDinghyKlipperBridge.jpg) 38 | 39 | 40 | # Additional Info 41 | 42 | Manual, schematics and troubleshooting guides can be found at [https://drachenkaetzchen.github.io/DragonDinghy/](https://drachenkaetzchen.github.io/DragonDinghy/) 43 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Fysetc H36/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc H36 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # CANBUS Mode 9 | 10 | To put the H36 board into CAN mode (instead of USB mode) you simply need to make sure the Katapult and Klipper firmware settings (further down below) have the 11 | "GPIO pins to set at micro-controller startup" set correctly. For CAN mode this needs to be `!PA2` 12 | 13 | 14 | # 120 ohm Termination Resistor 15 | 16 | The H36 board has a 120 ohm termination resistor enabled by default. If you need to disable this you need to cut between these two solder pads to sever the trace between them. 17 | 18 | ![image](https://github.com/user-attachments/assets/8c8848e7-527a-43ef-9403-e13547804793) 19 | 20 | If you need to reenable the 120 ohm resistor again after cutting simply solder the two pads together. 21 | 22 | 23 | {: .note } 24 | > Please note, due to the USB/CAN switching ability of the H36, when it is unpowered you are unable to measure the 120 ohm termination resistor if you just measure across the H and L wires. 25 | > This has no effect in use, but can make troubleshooting a broken wire a little more difficult. Something to keep in mind. 26 | 27 | 28 | # DFU Mode 29 | 30 | To put the H36 into DFU mode, connect it via USB to the Pi using the USB-C port then hold the BOOT0 button, press and release the RESET button, then count to 5 and release the BOOT0 button. 31 | 32 | ![image](https://github.com/user-attachments/assets/cdc62cf8-e926-4f4d-9c99-6f8d047b4db3) 33 | 34 | 35 | 36 | 37 | # Katapult Config 38 | 39 | ![image](https://github.com/user-attachments/assets/b52db77f-6cc2-4866-a600-ef67f8ae250e) 40 | 41 | 42 | 43 | # Klipper Config 44 | 45 | ![image](https://github.com/user-attachments/assets/0ee6c2c9-90ba-4ab6-a108-068d3660130e) 46 | 47 | 48 | 49 | 50 | # Sample Config 51 | 52 | A sample config file can be found at [https://github.com/FYSETC/H36_Combo/tree/main 53 | ](https://github.com/FYSETC/H36_Combo/tree/main) 54 | 55 | # More Info 56 | 57 | More information can be found at the [H36 wiki](https://wiki.fysetc.com/docs/H36-Combo) 58 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Fysetc PITB V1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc PITB V1.0 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | 13 | # BOOT Mode 14 | 15 | To put the PITB V1.0 into BOOT mode for initial flashing, unplug the main CAN cable then connect a USB cable from your Pi to the USB-C port of the PITB V1.0. 16 | 17 | Then hold the BOOT SEL button, press and release the RST button, count to five then release the BOOT SEL button. 18 | 19 | ![image](https://github.com/user-attachments/assets/2338aaf5-2891-4ff2-988f-7329fe6e907d) 20 | 21 | 22 | # Katapult Config 23 | 24 | ![image](https://github.com/user-attachments/assets/80176c27-3310-4827-b0aa-01469ddc1d2a) 25 | 26 | 27 | 28 | # Klipper Config 29 | 30 | ![image](https://github.com/user-attachments/assets/adc4420c-4183-4620-b816-086a8b0de25e) 31 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Fysetc PITB V2.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc PITB V2.0 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # CAN mode 13 | 14 | To enable CAN mode you must add a jumper between these two pins. 15 | 16 | ![image](https://github.com/user-attachments/assets/6f6b9e51-c025-4b34-8537-5449ee7f5833) 17 | 18 | If you don't have a jumper in place then the board will default to CAN-FD mode which Klipper does not support. 19 | 20 | # BOOT Mode 21 | 22 | To put the PITB V2.0 into BOOT mode for initial flashing, unplug the main CAN cable then connect a USB cable from your Pi to the USB-C port of the PITB V2.0. 23 | 24 | Then hold the BT0 button, press and release the RST button, count to five then release the BT0 button. 25 | 26 | ![image](https://github.com/user-attachments/assets/0a0f4cd2-68ce-4eb5-a412-7444df0cff82) 27 | 28 | # Katapult Config 29 | 30 | ![image](https://github.com/user-attachments/assets/6720f402-2459-491a-9a59-1621ab4daf52) 31 | 32 | 33 | # Klipper Config 34 | 35 | ![image](https://github.com/user-attachments/assets/1b2ca665-530b-4fe2-af33-27c62d4ca86e) 36 | 37 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Fysetc SB Combo V2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc SB Combo V2 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # Safety 9 | 10 | Do not use SB1.3 cable directly with V2, their positive and negative positions are reversed and will lead to damage. 11 | The H and L wires are also swapped, but this won't damage anything (it just wouldn't work). 12 | 13 | Just use the new cable that comes with the SB Combo V2 board. 14 | 15 | 16 | # CANBUS Mode 17 | 18 | To put the SB Combo V2 board into CAN mode (instead of USB mode) make sure the two switches are in the "up" position. 19 | 20 | ![image](https://github.com/user-attachments/assets/a5be3ceb-fa40-41a5-a245-058a7c04f866) 21 | 22 | # 120 ohm Termination Resistor 23 | 24 | The SB Combo V2 board has a 120 ohm termination resistor enabled by default. If you need to disable this you need to cut the trace between these two solder pads. 25 | 26 | ![image](https://github.com/user-attachments/assets/fc060894-251a-4fd5-8dbb-4dd5854c5019) 27 | 28 | {: .note } 29 | > Please note, due to the USB/CAN switching ability of the Combo V2, when it is unpowered you are unable to measure the 120 ohm termination resistor if you just measure across the H and L wires. 30 | > This has no effect in use, but can make troubleshooting a broken wire a little more difficult. Something to keep in mind. 31 | 32 | 33 | 34 | # DFU Mode 35 | 36 | To put the SB Combo V2 into DFU mode, connect it via USB to the Pi using the USB-C port then hold the BOOT0 button, press and release the RESET button, then count to 5 and release the BOOT0 button. 37 | 38 | ![image](https://github.com/user-attachments/assets/922c0f4f-9b4a-44d5-b636-77b9678f62f1) 39 | 40 | 41 | 42 | # Katapult Config 43 | 44 | ![image](https://github.com/user-attachments/assets/5225459f-11ff-4f76-9fb3-f3524aec2272) 45 | 46 | 47 | 48 | # Klipper Config 49 | 50 | ![image](https://github.com/user-attachments/assets/46e29e52-36ae-4390-965e-ef4caf0cb00d) 51 | 52 | 53 | 54 | # Sample Config 55 | 56 | A sample config file can be found at https://github.com/FYSETC/SB_Combo_V2/tree/main/Config 57 | 58 | # More Info 59 | 60 | More information can be found at the [SB Combo V2 wiki](https://wiki.fysetc.com/docs/SBComboV2) 61 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Fysetc SB-CAN-TH/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Fysetc SB-CAN-TH 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The Fysetc SB-CAN-TH v1.1 has no resistor nor any provisions for adding one. 11 | 12 | The Fysetc SB-Can-TH v1.3B has header for the 120R termination resistor which is circled in purple 13 | 14 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/592d4dd6-429b-4833-b3f7-2b78d34fa2be) 15 | 16 | 17 | # DFU Mode 18 | 19 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/dda93dd3-bdc8-4d8f-be9b-45658668bfe1) 20 | 21 | ## For V1.1 22 | 23 | 1. Power *off* your whole printer (at the wall) 24 | 2. Connect SB-CAN-TH Micro-USB to Pi USB-A 25 | 3. Power on your printer 26 | 4. Run `lsusb` to check if the SB-CAN-TH shows in DFU mode. If not, go back to step 1. 27 | 5. If it shows as a DFU device in `lsusb` you can continue with the flashing steps 28 | 6. After flashing, power down the whole printer, remove the USB cable, connect all the CAN cables, then power on the printer. 29 | 30 | 31 | ## For V1.3 32 | 33 | 1. Power *off* your whole printer (at the wall) 34 | 2. Connect SB-CAN-TH Micro-USB to Pi USB-A 35 | 3. Power on your printer, wait for the Pi to be fully booted 36 | 4. Hold the reset button on the SB-CAN-TH for 2 seconds then release it. 37 | 5. Run `lsusb` to check if the SB-CAN-TH shows in DFU mode. If not, go back to step 1. 38 | 6. If it shows as a DFU device in `lsusb` you can continue with the flashing steps 39 | 7. After flashing, power down the whole printer, remove the USB cable, connect all the CAN cables, then power on the printer. 40 | 41 | 42 | 43 | # Katapult Config 44 | 45 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ece9bd34-5165-4864-ba95-73e8b1846f94) 46 | 47 | 48 | # Klipper Config 49 | 50 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/b38f1af9-cf9b-4173-9e30-06e0e0aa1d76) 51 | 52 | # Sample Configuration 53 | 54 | A sample configuration file can be found at [https://github.com/FYSETC/FYSETC_SB_CAN_TOOLHEAD](https://github.com/FYSETC/FYSETC_SB_CAN_TOOLHEAD) 55 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/MKS THR36 V1.0/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: MKS THR36 V1.0 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # BOOT Mode 13 | 14 | To put the THR36 into boot mode (for initial flashing), unplug any USB and CAN cables from the THR36, then put the 5v jumper in the middle and "on" position so the board can receive power over the USB connection: 15 | 16 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/f8d98041-e9da-4c99-87bf-d25b899e71c4) 17 | 18 | 19 | Plug a USB cable from the pi to the THR36 then hold down the BOOT button, breifly press the RESET button (while still holding BOOT), wait a few seconds, then release the BOOT button. The THR36 should now show up to an `lsusb` command as Pi RP2 Boot device: 20 | 21 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/81d28d7c-a273-47d7-a57b-a34c84ccf279) 22 | 23 | 24 | 25 | 26 | # Katapult Config 27 | 28 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/a7638805-f9f0-475a-abbb-1ce4f3d239aa) 29 | 30 | 31 | 32 | # Klipper Config 33 | 34 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/9cd3358d-8c9f-4462-9521-9ed2f1ac15d7) 35 | 36 | 37 | # Sample Config 38 | 39 | A sample config file can be found at [https://github.com/makerbase-mks/MKS-THR36-THR42-UTC/tree/main](https://github.com/makerbase-mks/MKS-THR36-THR42-UTC/tree/main) 40 | 41 | 42 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly ERCF/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly ERCF 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | There is a permanent 120 ohm termination resistor soldered to the board, no need to add a jumper to enable it and also no ability to disable it. 11 | 12 | # BOOT Mode 13 | 14 | To put the ERCF into boot mode (for initial flashing), unplug any USB and CAN cables from the ERCF, then hold the BOOT button. While continuing to hold the BOOT button plug in the USB cable from the Pi to the ERCF. Keep holding the BOOT button for a few more second, then release. 15 | 16 | ![image](img/dfu-mode.png) 17 | 18 | The ERCF should now show up to an `lsusb` command as Pi RP2 Boot device: 19 | 20 | ![image](https://user-images.githubusercontent.com/124253477/226155004-2cc63e48-4545-46c0-92ed-b09cd26c8e80.png) 21 | 22 | 23 | # Katapult Config 24 | 25 | ![image](./img/canboot.png) 26 | 27 | # Klipper Config 28 | 29 | ![image](./img/klipper-canboot.png) 30 | 31 | # Sample Config 32 | 33 | A sample config file can be found at [https://mellow.klipper.cn/#/board/fly_ercf/cfg](https://mellow.klipper.cn/#/board/fly_ercf/cfg) 34 | 35 | # More Info 36 | 37 | [https://mellow.klipper.cn/#/board/fly_ercf/ 38 | ](https://mellow.klipper.cn/#/board/fly_ercf/ 39 | ) 40 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly ERCF/img/canboot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/Mellow Fly ERCF/img/canboot.png -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly ERCF/img/dfu-mode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/Mellow Fly ERCF/img/dfu-mode.png -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly ERCF/img/klipper-canboot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/Mellow Fly ERCF/img/klipper-canboot.png -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly ERCF/img/klipper-only.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/Esoterical/voron_canbus/ca2ff883c2fd7b0c6dd63ecd9b2992288c5281e4/toolhead_flashing/common_hardware/Mellow Fly ERCF/img/klipper-only.png -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly SB2040/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly SB2040v1/v2 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the 120R termination resistor is circled in purple 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/87099ccc-7012-4d90-9147-eec3207b29ff) 13 | 14 | 15 | # BOOT Mode 16 | 17 | To put the SB2040 into boot mode (for initial flashing), unplug any USB and CAN cables from the SB2040, then hold the BOOT button. While continuing to hold the BOOT button plug in the USB cable from the Pi to the SB2040. Keep holding the BOOT button for a few more second, then release. The SB2040 should now show up to an `lsusb` command as Pi RP2 Boot device: 18 | 19 | ![image](https://user-images.githubusercontent.com/124253477/226155004-2cc63e48-4545-46c0-92ed-b09cd26c8e80.png) 20 | 21 | 22 | # Katapult Config 23 | 24 | ![image](https://user-images.githubusercontent.com/124253477/228765757-5a8bab71-6f57-4467-8400-4bbb9d37e2f6.png) 25 | 26 | # Klipper Config 27 | 28 | ![image](https://user-images.githubusercontent.com/124253477/221348650-b9f2749e-0f3b-44b4-b34a-a57bd8beb706.png) 29 | 30 | # Sample Config 31 | 32 | A sample config file can be found at [https://mellow-3d.github.io/fly_sb2040_v1_klipper_config.html](https://mellow-3d.github.io/fly_sb2040_v1_klipper_config.html) 33 | 34 | 35 | # More Info 36 | 37 | [https://mellow-3d.github.io/fly_sb2040_v1_general.html](https://mellow-3d.github.io/fly_sb2040_v1_general.html) 38 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly SB2040v3/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly SB2040v3 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # Enable Klipper CAN Mode 9 | 10 | Have both single switches in the "down" position to enable the board for Klipper CANBUS 11 | 12 | ![image](https://github.com/user-attachments/assets/d17ff68e-b297-4bb1-923a-298afce42bfa) 13 | 14 | 15 | # 120 ohm Termination Resistor 16 | 17 | The 120 ohm resistor is enabled by switch 1 on the eight switch block 18 | 19 | ![image](https://github.com/user-attachments/assets/2c6b3c23-ec21-4fcb-91f9-9c379591c527) 20 | 21 | 22 | 23 | # BOOT Mode 24 | 25 | Plug a USB cable from the pi to the SB2040v3 then hold down the BOOT button, breifly press the RST button (while still holding BOOT), wait a few seconds, then release the BOOT button. The SB2040v3 should now show up to an lsusb command as Pi RP2 Boot device: 26 | 27 | ![image](https://github.com/user-attachments/assets/5cc1bef8-329a-4259-9756-c8a14c23af18) 28 | 29 | 30 | 31 | # Katapult Config 32 | 33 | ![image](https://github.com/user-attachments/assets/9e9d2524-cf91-4b63-82b0-ac0d89e59bfd) 34 | 35 | # Klipper Config 36 | 37 | ![image](https://github.com/user-attachments/assets/39847f63-bbd8-4f8b-8503-32e0981df504) 38 | 39 | 40 | # Sample Config 41 | 42 | A sample config file can be found at [https://mellow.klipper.cn/#/board/fly_sb2040_v3_pro/cfg](https://mellow.klipper.cn/#/board/fly_sb2040_v3_pro/cfg) 43 | 44 | 45 | # More Info 46 | 47 | [https://mellow.klipper.cn/#/board/fly_sb2040_v3_pro/README 48 | ](https://mellow.klipper.cn/#/board/fly_sb2040_v3_pro/README 49 | ) 50 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly SHT36 and SHT42/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly SHT36 and SHT42 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # 120 ohm Termination Resistor 9 | 10 | The header for the termination resistor is circled in purple. You need to jumper *both* the header pairs 11 | 12 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/b546bbc3-60c3-459e-b309-4e2d007bfbc7) 13 | 14 | 15 | # DFU Mode 16 | 1. Add a jumper as shown in the image below to enable DFU mode 17 | 18 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/0420edcd-512f-4f11-9353-5d8f3fc90e1f) 19 | 20 | 2. Connect your device to your Pi via USB 21 | 3. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 22 | ``` 23 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 24 | ``` 25 | 26 | # Katapult Config 27 | 28 | ![image](https://user-images.githubusercontent.com/124253477/228767194-0ee2d789-13b2-44f4-99aa-f0a7f750c99c.png) 29 | 30 | # Klipper Config 31 | 32 | ![image](https://user-images.githubusercontent.com/124253477/221396323-83dd84e5-b661-4472-8074-ea45aa19dced.png) 33 | 34 | 35 | # Sample Configuration 36 | 37 | A sample config file can be found at [https://mellow-3d.github.io/fly-sht36_klipper_config.html](https://mellow-3d.github.io/fly-sht36_klipper_config.html) 38 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly SHT36v2/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly SHT36v2 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | *Note, SHT-36 V2 units shipped before 2022-10-18 will use the GD32F103 CPU, later shipments will use the APM32F072 CPU. The settings are exactly the same except for the processor model. Make sure the chosen processor model STM32F072 or STM32F103 matches with your board* 9 | 10 | # 120 ohm Termination Resistor 11 | 12 | The header for the 120R termination resistor is circled in purple 13 | 14 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/18e2c705-41be-4d99-a1c3-7ebcc2c76751) 15 | 16 | 17 | # DFU Mode 18 | 1. Add a jumper as shown in the image below to enable DFU mode 19 | 20 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/d5e77aa8-8cbd-4766-b21f-52053d1bc16a) 21 | 22 | 2. Connect your device to your Pi via USB 23 | 3. The device should now be in DFU mode. Verify this via the `lsusb` command, which should look something like this: 24 | ``` 25 | Bus 001 Device 005: ID 0483:df11 STMicroelectronics STM Device in DFU Mode 26 | ``` 27 | **The SHT36v2 comes with two different versions of STM32 MCU chips. Make sure you pick the correct config for the MCU chip you have** 28 | 29 | # STM32F103 (GD32F103) 30 | 31 | ## Katapult Config 32 | 33 | ![image](https://user-images.githubusercontent.com/124253477/228767706-e14d572a-b0de-4445-9c7c-11276fc8c4a7.png) 34 | 35 | ## Klipper Config 36 | 37 | ![image](https://user-images.githubusercontent.com/124253477/221396540-52695957-90f7-4f01-9d7d-130a76a81ee8.png) 38 | 39 | # STM32F072 (APM32F072) 40 | 41 | ## Katapult Config 42 | 43 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/63ca392a-16b8-4516-8fa8-bb22b6c9f7a0) 44 | 45 | ## Klipper Config 46 | 47 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/21f25ff7-a775-4081-a4b0-47e42076f969) 48 | 49 | 50 | # Sample Configuration 51 | 52 | A sample config file can be found at [https://mellow-3d.github.io/fly-sht36_v2_klipper_config.html](https://mellow-3d.github.io/fly-sht36_v2_klipper_config.html) 53 | 54 | # More Info 55 | 56 | [https://mellow-3d.github.io/fly-sht36_v2_general.html](https://mellow-3d.github.io/fly-sht36_v2_general.html) 57 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/Mellow Fly SHT36v3/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Mellow Fly SHT36v3 4 | parent: Common Toolhead Hardware 5 | grand_parent: Toolhead Flashing 6 | --- 7 | 8 | # Enable Klipper CAN mode 9 | 10 | Have the top switch in the "down" position, and the bottom switch in the "right" position to enable CAN mode. 11 | 12 | ![image](https://github.com/user-attachments/assets/c212b6f4-ec8a-4808-bbe2-1fd94c744f8f) 13 | 14 | # 120 ohm Termination Resistor 15 | 16 | Set the DIP switch to the ON (Up) position to enable the 120 ohm termination resistor 17 | 18 | ![image](https://github.com/user-attachments/assets/2ee3fdc2-b117-4fb4-9dcc-0ff356946ad2) 19 | 20 | 21 | 22 | # BOOT Mode 23 | 24 | To enter BOOT mode, unplug USB and XT30 cables from the SHT36v3, then hold the BOOT button while plugging in the USB-C cable 25 | 26 | ![image](https://github.com/user-attachments/assets/17ff78ca-f8e2-4c95-a7f3-c9dee549679e) 27 | 28 | 29 | # Katapult Config 30 | 31 | ![image](https://github.com/user-attachments/assets/f5bb4e0c-cac2-4e88-8f73-463e69e6379c) 32 | 33 | 34 | # Klipper Config 35 | 36 | ![image](https://github.com/user-attachments/assets/3ef27412-a078-4695-99c6-c6154c49e9c0) 37 | 38 | 39 | 40 | # Sample Configuration 41 | 42 | A sample config file can be found at [https://mellow.klipper.cn/en/docs/ProductDoc/ToolBoard/fly-sht36/sht36_v3/cfg](https://mellow.klipper.cn/en/docs/ProductDoc/ToolBoard/fly-sht36/sht36_v3/cfg) 43 | 44 | # More Info 45 | 46 | [https://mellow.klipper.cn/en/docs/category/fly-sht36-v3](https://mellow.klipper.cn/en/docs/category/fly-sht36-v3) 47 | -------------------------------------------------------------------------------- /toolhead_flashing/common_hardware/README.md: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /toolhead_klipper_updating.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Toolhead Updating 4 | parent: Updating 5 | nav_order: 10 6 | --- 7 | 8 | # Updating Toolhead Klipper 9 | 10 | **Step 1** 11 | 12 | To update Klipper, you first need to compile a new klipper.bin with the correct settings. 13 | 14 | Move into the klipper directory on the Pi by running: 15 | ```bash 16 | cd ~/klipper 17 | ``` 18 | Then go into the klipper configuration menu by running: 19 | ```bash 20 | make menuconfig 21 | ``` 22 | 23 | You can find screenshots of settings for common toolheads in the [Common Toolhead Hardware](./toolhead_flashing/common_hardware) section. 24 | 25 | You want the Processor and Clock Reference to be set as per whatever board you are running. Set Communication interface to 'CAN bus' with the pins that are specific to your toolhead board. Also set the CAN bus speed to the same as the speed in your can0 file. In this guide it is set to 1000000. 26 | 27 | Once you have the firmware configured, hit Q to save and quit from the makemenu screen, then run a `make clean` to make sure there are no old files hanging around, then `make` to compile the firmware. It will save the firmware to ~/klipper/out/klipper.bin 28 | ```bash 29 | make clean 30 | make 31 | ``` 32 | 33 | **Step 2** 34 | 35 | First, stop the Klipper service on the Pi by running: 36 | 37 | ```bash 38 | sudo service klipper stop 39 | ``` 40 | 41 | If you already have a functioning CAN setup, and your [mcu toolhead] canbus_uuid is in your printer.cfg, then you can force Katapult to reboot into Katapult mode by running: 42 | 43 | ```bash 44 | python3 ~/katapult/scripts/flashtool.py -i can0 -r -u yourtoolheaduuid 45 | ``` 46 | 47 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/eda51419-6ab4-49c5-9c33-a581b08d085c) 48 | 49 | If will probably say "Flash success" 50 | **THIS IS NOT ACTUALLY FLASHING ANYTHING, YOU NEED TO CONTINUE WITH THE STEPS BELOW** 51 | 52 | **Step 3** 53 | 54 | If you don't have the UUID (or something has gone wrong with the klipper firmware and your toolboard is hung) then you can also double-press the RESET button on your toolhead to force Katapult to reboot into Katapult mode. 55 | 56 | You can verify it is in the proper mode by running `python3 ~/katapult/scripts/flashtool.py -q`. If you see a "Detected UUID: xxxxxxxxx, Application: Katapult" device then it is good to go. 57 | ```bash 58 | python3 ~/katapult/scripts/flashtool.py -q 59 | ``` 60 | 61 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/ff9dcbb3-0456-4d87-8091-41d5d6050c02) 62 | 63 | **Step4** 64 | 65 | Then you can run the same command you used to initially flash Klipper: 66 | 67 | ```bash 68 | python3 ~/katapult/scripts/flashtool.py -i can0 -f ~/klipper/out/klipper.bin -u yourtooolheaduuid 69 | ``` 70 | 71 | Once the flash has been completed you can run the `python3 ~/katapult/scripts/flashtool.py -i can0 -q` command again. This time you should see the same UUID but with "Application: Klipper" instead of "Application: Katapult" 72 | ```bash 73 | python3 ~/katapult/scripts/flashtool.py -i can0 -q 74 | ``` 75 | 76 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/1e01f858-71f3-45b4-a69f-1f704dce80d4) 77 | 78 | 79 | **If** you can't connect to your tooolhead after these steps (assuming all the ouputs look similar in success to the screenshots) then there is a good chance your klipper.bin settings were incorrect. Go back to Step 1 and check *all* the settings in the `make menuconfig` screen then recompile with `make clean` and `make`, and then double-click the reset button on your toolhead to kick it back to katapult mode then go from Step 3. 80 | 81 | However, **if** the CAN query *does* return your UUID with "Application: Klipper" then start the Klipper service on the Pi again with `sudo service klipper start` and then do a firmware_restart and confirm that Klipper starts without errors. 82 | ```bash 83 | sudo service klipper start 84 | ``` 85 | -------------------------------------------------------------------------------- /troubleshooting.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Troubleshooting 4 | nav_order: 80 5 | has_children: true 6 | has_toc: false 7 | --- 8 | 9 | # Troubleshooting 10 | 11 | So, you've followed the instructions but things just aren't working they way they should. Hopefully there will be some nuggets of wisdom here that help out with your build. Note that this page is still very much a work in progress and I will be treating it as a living document. Expect it to be less structured than the rest of the guide, just look around for something that sounds like your problem and see what is there. 12 | 13 | There won't be any particular order to the sections. Maybe I'll make it flow better in the future, maybe not. 14 | 15 | ### No can0 network when flashing 16 | 17 | If you see something like "unable to bind socket to can0" when attempting to flash, read [here](./troubleshooting/no_can0.md) 18 | 19 | 20 | ### No UUIDs show up to a query 21 | 22 | So you're can0 interface is online, but a query returns no UUIDs? read [here](./troubleshooting/no_uuid.md) 23 | 24 | 25 | ### Klipper won't start 26 | 27 | You have everything flashed fine, and the UUID's all showed up, but klipper refuses to start, read [here](./troubleshooting/klipper_fail_to_start.md) 28 | 29 | 30 | ### Timeout during homing/probing 31 | 32 | Klipper starts, but sometimes during a homing command or levelling/bed mesh Klipper will halt with "Timeout during homing/probing", read [here](./troubleshooting/timeout_during_homing_probing.md) 33 | 34 | ### Lost connection to MCU 35 | 36 | Klipper was running, maybe even printing for a while, but all of a sudden it failed mid print with "Lost connection to MCU" error, read [here](./troubleshooting/lost_communication_to_mcu.md) 37 | 38 | 39 | ### Timer too close 40 | 41 | Sometimes it prints fine, sometimes it fails with "Timer too close" error, read [here](./troubleshooting/timer_too_close.md) 42 | 43 | 44 | ### TMC Driver reset/undervoltage 45 | 46 | If your extruder TMC driver is reporting "reset" or undervoltage errors, read [here](./troubleshooting/tmc_reset_undervoltage.md) 47 | 48 | ## Other Errors and Reading the Log 49 | 50 | If you have errors not previously mentioned then it is worth learning to check your klippy.log file [here](./troubleshooting/other_errors.md) 51 | -------------------------------------------------------------------------------- /troubleshooting/debugging/README.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Debug Script 4 | nav_order: 100 5 | parent: Troubleshooting 6 | --- 7 | 8 | # Debug Script 9 | 10 | If you are still running into trouble you can run this can_debug.sh script on your Pi. It will pull a bunch of config and diagnostic data which can give whomever is helping you a lot of info for diagnosing your issue. 11 | 12 | To use the script on your Pi simply run: 13 | 14 | ```bash 15 | wget -qO - debug.esoterical.online | sh 16 | ``` 17 | 18 | It will generate a termbin.com link which will have all the info in it. Just share this link with the person helping you and they will be able to see the info. 19 | -------------------------------------------------------------------------------- /troubleshooting/debugging/can_debug.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | 3 | #Credit to @bolliostu for the original idea and script 4 | #Credit to @dormouse for a whole lot, including making the script not look like hot garbage 5 | 6 | # Directories and files 7 | KATAPULTDIR="$HOME/katapult" 8 | CANBOOTDIR="$HOME/CanBoot" 9 | KLIPPERDIR="$HOME/klipper" 10 | KLIPPYLOG="$HOME/printer_data/logs/klippy.log" 11 | 12 | # Default responses 13 | MODEL="Unknown" 14 | DISTRO="Unknown" 15 | KERNEL="Unknown" 16 | UPTIME="Unknown" 17 | 18 | IFACESERVICE="Directory Not Found" 19 | SYSTEMD="Directory Not Found" 20 | IPA="Interfaces Not Found" 21 | 22 | CAN0STATUS="Unknown" 23 | CAN0IFACE="/etc/network/interfaces.d/can0 Not Found" 24 | CAN0STATS="No can0 interface" 25 | CAN0QUERY="No can0 interface" 26 | 27 | RCLOCAL="/etc/rc.local Not Found" 28 | BYID="/dev/serial/by-id Not Found" 29 | 30 | BOOTLOADERDIRFND="Not Found" 31 | BOOTLOADERFND="Not Found" 32 | BOOTLOADERVER="Unknown" 33 | KLIPPERDIRFND="Not Found" 34 | KLIPPERFND="Not Found" 35 | KLIPPERVER="Unknown" 36 | 37 | KLIPPERCFG="Not Found" 38 | KLIPPYMSGS="Not Found" 39 | MCUCONFIGS="Not Found" 40 | ADC="Klipper Log Not Found" 41 | 42 | disclaimer() { 43 | echo "*************" 44 | echo "* Attention *" 45 | echo "*************" 46 | echo 47 | echo "This script will run a series of diagnostic commands to gather configuration" 48 | echo "information about this host and upload it to a public site where it may be" 49 | echo "viewed by others. It will contain no personal information." 50 | echo "It may also be necessary to install an additional package to help facilitate" 51 | echo "this task. This script is available for review at: " 52 | echo "https://github.com/Esoterical/voron_canbus/blob/main/troubleshooting/debugging/can_debug.sh" 53 | echo 54 | 55 | while true; do 56 | read -p "Do you wish to run this program? (yes/no) " yn < /dev/tty 57 | case $yn in 58 | [Yy]* ) break;; 59 | [Nn]* ) exit;; 60 | * ) echo "Please answer yes or no.";; 61 | esac 62 | done 63 | } 64 | 65 | checknc() { 66 | # Checks for nc command and installs modern version of netcat on Debian based systems if not found. 67 | if ! command -v nc > /dev/null 2>&1 ; then 68 | echo "NetCat not found on system" 69 | echo "Installing Netcat with 'sudo apt-get install netcat-openbsd -qq > /dev/null'" 70 | sudo apt-get install netcat-openbsd -qq > /dev/null 71 | fi 72 | } 73 | 74 | 75 | # Formatting function for output sections 76 | # Usage: prepout
[SUBSECTION...] 77 | 78 | prepout() { 79 | echo 80 | echo "================================================================"; 81 | echo $1; 82 | echo "================================================================\n"; 83 | # shift the first array entry $1 (Header) and iterate through remaining 84 | shift 85 | for var in "$@"; do echo "$var\n"; done 86 | } 87 | 88 | ####################################### 89 | 90 | disclaimer; 91 | checknc; 92 | 93 | echo "\nGathering Data...\n" 94 | 95 | # Definition of commands to be be run to obtain relevant information regarding CAN bus configuration. 96 | 97 | if [ -f /sys/firmware/devicetree/base/model ]; then 98 | MODEL="$(cat /sys/firmware/devicetree/base/model)" 99 | fi 100 | 101 | if [ ! -z "$(ls /etc/*-release)" ]; then 102 | DISTRO="$(cat /etc/*-release)" 103 | fi 104 | 105 | KERNEL="$(uname -a)" 106 | UPTIME="$(uptime)" 107 | 108 | if [ -d /etc/network ]; then 109 | IFACESERVICE="$(ls /etc/network)" 110 | fi 111 | 112 | if [ -d /etc/systemd/network ]; then 113 | if [ ! -z "$(ls /etc/systemd/network)" ]; then 114 | SYSTEMD="$(ls /etc/systemd/network)" 115 | else 116 | SYSTEMD="Empty Directory" 117 | fi 118 | fi 119 | 120 | IPA="$(ip a)" 121 | 122 | # Checking can0 interface configuration. 123 | if [ -f /etc/network/interfaces.d/can0 ]; then 124 | CAN0IFACE=$(cat /etc/network/interfaces.d/can0) 125 | fi 126 | 127 | if ip l l can0 > /dev/null 2>&1; then 128 | CAN0STATS="$(ip -d -s l l can0)" 129 | CAN0UPDOWN="$(echo "$CAN0STATS" | grep -m 1 -o 'state [A-Z]*')" 130 | CAN0STATE="$(echo "$CAN0STATS" | grep -m 1 -o 'can state [A-Z-]*')" 131 | CAN0BITRATE="$(echo "$CAN0STATS" | grep -m 1 -o 'bitrate [0-9]*')" 132 | CAN0QLEN="$(echo "$CAN0STATS" | grep -m 1 -o 'qlen [0-9]*')" 133 | CAN0STATUS="$(echo " $CAN0UPDOWN"; echo " $CAN0STATE"; echo " $CAN0BITRATE"; echo " $CAN0QLEN";)" 134 | 135 | if [ "$CAN0UPDOWN" = "state UP" ]; then 136 | CAN0QUERY="$(~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0)" 137 | else 138 | CAN0QUERY="Unable to query can0 - DOWN" 139 | fi 140 | fi 141 | 142 | # Contents of rc.local 143 | if [ -f /etc/rc.local ]; then 144 | RCLOCAL="$(cat /etc/rc.local)" 145 | fi 146 | 147 | LSUSB="$(lsusb)" 148 | 149 | if [ -d /dev/serial/by-id ]; then 150 | BYID="$(ls -l /dev/serial/by-id | tail -n +2 | awk '{print $9,$10,$11}')" 151 | fi 152 | 153 | # Retrieving katapult bootloader compilation configuration. 154 | if [ -d ${KATAPULTDIR} ]; then 155 | BOOTLOADERDIRFND="${KATAPULTDIR}"; 156 | if [ -f ${KATAPULTDIR}/.config ]; then 157 | BOOTLOADERFND="\n$(cat ${KATAPULTDIR}/.config)" 158 | cd ${KATAPULTDIR} 159 | BOOTLOADERVER="$(git describe --tags)" 160 | fi 161 | 162 | # Retrieving CanBoot bootloader compilation configuration if katapult not there. 163 | elif [ -d ${CANBOOTDIR} ]; then 164 | BOOTLOADERDIRFND="${CANBOOTDIR}" 165 | if [ -f ${CANBOOTDIR}/.config ]; then 166 | BOOTLOADERFND="\n$(cat ${CANBOOTDIR}/.config)" 167 | cd ${CANBOOTDIR} 168 | BOOTLOADERVER="$(git describe --tags)" 169 | fi 170 | fi; 171 | 172 | # Retrieving klipper firmware compilation configuration. 173 | if [ -d ${KLIPPERDIR} ]; then 174 | KLIPPERDIRFND="${KLIPPERDIR}"; 175 | if [ -f ${KLIPPERDIR}/.config ]; then 176 | KLIPPERFND="\n$(cat ${KLIPPERDIR}/.config)" 177 | if command -v git > /dev/null 2>&1; then 178 | cd ${KLIPPERDIR} 179 | KLIPPERVER="$(git describe --tags)" 180 | fi 181 | fi 182 | fi 183 | 184 | # Retrieving info from klippy.log 185 | if [ -f $KLIPPYLOG ]; then 186 | SESSIONLOG=$(tac $KLIPPYLOG | sed '/Start printer at /q' | tac) 187 | KLIPPERCFG=$(echo "$SESSIONLOG" | awk '/^===== Config file/{m=1;next}/^[=]+$/{m=0}m') 188 | KLIPPYMSGS=$(echo "$SESSIONLOG" | awk '/^[=]+$/,EOF' | tail +2) 189 | MCUCONFIGS=$(echo "$SESSIONLOG" | awk '/^Loaded MCU/,/^MCU/') 190 | STARTUPMSGS=$(echo "$KLIPPYMSGS" | grep -E -v '^MCU|^Loaded MCU|^Stats' | head -100) 191 | 192 | # ADC temp check 193 | MIN_TEMP=-10 194 | MAX_TEMP=400 195 | ADC=$(echo "$SESSIONLOG" | tac | grep -m 1 "^Stats" | sed 's/\([a-zA-Z0-9_.]*\)\:/\n\1:/g' | 196 | awk -v mintemp="$MIN_TEMP" -v maxtemp="$MAX_TEMP" '/temp=/ { 197 | printf "%18s ", $1; 198 | j=0; 199 | for (i=2; i<=split($0, stat, " "); i++) { 200 | if (sub(/^.*temp=/, "", stat[i])) { 201 | printf "%6s", stat[i]; 202 | if (stat[i] + 0 < mintemp ) { 203 | printf "%s", " *** Check Sensor ***"; 204 | } else if (stat[i] + 0 > maxtemp) { 205 | printf "%s", " *** Check Sensor ***"; 206 | } 207 | j++; 208 | break; 209 | } 210 | } 211 | printf "\n"; 212 | } END { if (j == 0) { printf "No Temperature Data Available\n"; } }' 213 | ) 214 | fi 215 | 216 | LOG="$(prepout "Klippy Messages" "$KLIPPYMSGS")\n$(prepout "Klipper Config" "$KLIPPERCFG")" 217 | 218 | DEBUG="$(prepout "OS" "Model:\n${MODEL}" "Distro:\n${DISTRO}" "Kernel:\n${KERNEL}" "Uptime:\n${UPTIME}") 219 | $(prepout "Network" "Interface Services:\n${IFACESERVICE}" "Systemd Network Files:\n${SYSTEMD}" "ip a:\n${IPA}") 220 | $(prepout "can0" "status:\n${CAN0STATUS}" "file:\n${CAN0IFACE}" "ifstats:\n${CAN0STATS}" "Query:\n${CAN0QUERY}") 221 | $(prepout "rc.local contents" "${RCLOCAL}") 222 | $(prepout "USB / Serial" "lsusb:\n${LSUSB}" "/dev/serial/by-id:\n${BYID}") 223 | $(prepout "MCU Configs" "${MCUCONFIGS}") 224 | $(prepout "Temperature Check" "${ADC}") 225 | $(prepout "Startup Messages" "${STARTUPMSGS}") 226 | $(prepout "Bootloader" "Directory: ${BOOTLOADERDIRFND}" "Version: ${BOOTLOADERVER}" "Make Config: ${BOOTLOADERFND}") 227 | $(prepout "Klipper" "Directory: ${KLIPPERDIRFND}" "Version: ${KLIPPERVER}" "Make Config: $KLIPPERFND")" 228 | 229 | if nc -z -w 3 termbin.com 9999; then 230 | echo "Uploading...\n" 231 | LOGURL=$(echo "$LOG" | nc termbin.com 9999) 232 | sleep 1 233 | DEBUGURL=$(echo "$DEBUG\n$(prepout "Klippy Log Details" "$LOGURL")" | nc termbin.com 9999) 234 | echo "Information available at the following URL:" 235 | echo "$DEBUGURL" 236 | else 237 | if [ -d $HOME/printer_data/logs ]; then 238 | LOGPATH=$HOME/printer_data/logs 239 | else 240 | LOGPATH=/tmp 241 | fi 242 | TIMESTAMP=$(date "+%Y%m%d-%H%M%S") 243 | DEBUGFILE="$LOGPATH/esodebug-$TIMESTAMP.txt" 244 | LOGFILE="$LOGPATH/esolog-$TIMESTAMP.txt" 245 | echo "Unable to connect to termbin.com. Outputting to local file instead..." 246 | echo "$DEBUG" > $DEBUGFILE 247 | echo "$LOG" > $LOGFILE 248 | echo "debug: $DEBUGFILE" 249 | echo "log: $LOGFILE" 250 | fi 251 | -------------------------------------------------------------------------------- /troubleshooting/klipper_fail_to_start.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Klipper Fails to Start 4 | nav_order: 30 5 | parent: Troubleshooting 6 | --- 7 | 8 | # Klipper fails to start 9 | 10 | You have everything flashed up, you were able to get the UUID's of all your devices, you thought it was smooth sailing from this point. Then you booted the printer only go find the big red warning box of Klipper failing to start. 11 | 12 | Really, this isn't a bad situation to be in. At this point it is all just configuration in the printer.cfg file to get everything up and running. 13 | 14 | This is the best time to have a look at your manufacture sample configurations for your device. I've linked to a few (not all) in the [mainboard common_hardware](../mainboard_flashing/common_hardware) and [toolhead common_hardware](../toolhead_flashing/common_hardware) folders. These sample configs will have all the pin numberings for the different headers (heater, thermistor, fans, etc.) that you will need to replicate into your main printer config folder. 15 | 16 | ### MCU 17 | 18 | First thing, you need to make sure you have the UUID of each CAN device set against their corresponding MCU in your config file. 19 | The mainboard of your printer is always just called `[mcu]`, and any subsequent boards (ie. CAN toolheads in this case) have their own name and are labelled `[mcu toolheadname]` with the "toolheadname" being what you want to call it. Some sample configs call it `[mcu can0]`, BigTreeTech like to call theirs `[mcu EBBCan]`, but at the end of the day it's an arbitrary label. You can call it `[mcu whoopy]` if you want to, as long as you consistently use that name for all your pin assignments down the line (we'll get to that later). 20 | 21 | If you are using a standalone CAN adapter (eg. a U2C or UTOC or similar) then it is likely that your mainboard should be left completely alone and still be set as per manufacturer instructions. Probably something like: 22 | 23 | ```bash 24 | [mcu] 25 | serial: /dev/serial/by-id/usb-Klipper_stm32f446xx_37001A001851303439363932-if00 26 | ``` 27 | However, if you are using USB-CAN-Bridge mode on your mainboard then you need to make sure this has now been changed to show your **mainboard's** canbus UUID. Something like: 28 | ```bash 29 | [mcu] 30 | canbus_uuid: a396d68a95a3 31 | ``` 32 | In either case, you will need to set a secondary MCU for your toolhead board. This will *always* be a canbus_uuid as that is the whole point of this guide. 33 | Again, the name you give it is arbitrary, but it's probably easier to stick to whatever the manufacturer sample config has set. 34 | eg: 35 | ```bash 36 | [mcu EBBCan] 37 | canbus_uuid: ec60cf516124 38 | ``` 39 | 40 | ### Pins 41 | 42 | The next step is to set all the correct pins for all of hte functions that are now on your toolhead instead of your mainboard. Usually this is the `[extruder]` section (along with the `[tmcxxxx extruder]` TMC section), any `[fan]` and `[heater_fan hotend_fan]` sections that are for your hotend/part cooling fans, your `[probe]` section, maybe the `endstop_pin:` in your `[stepper_x]` section if you now have the x-endstop switch plugged in to your toolhead, and anything else that is plugged in to your toolhead. 43 | 44 | What I do is I have my printer.cfg open in one window, and the sample config for my toolhead open in a seperate window next to it. Then I go to each section (eg. the `[extruder]` section) and change any of my old pin values for the corresponding ones in the sample config. Take note that **any** pin that is now being used on your toolhead needs to have the MCU name as a prefix. For example, if your toolhead mcu is called `[mcu EBBCan]`, and the step_pin on your toolhead is `PD0`, then in your config you have to call the pin `EBBCan:PD0` and these names **are case sensitive**. So any toolhead pins will look something like: 45 | 46 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/f4864243-5f7e-47ee-82b2-fc0f1d9df8e5) 47 | 48 | Go through your printer.cfg until all "things" that are connected to your toolhead have had their pins changed. 49 | 50 | ### "ADC out of range" error 51 | 52 | So you've set the MCU sections correctly, and gone through and changed all the pins that need changing, but Klipper still won't start and you get this strange "ADC out of range" error. This is a pretty good error to have all things considered. It just means that one of your temperature sensors is reading way too hot or way too cold for it to be normal. 53 | 54 | As the whole point of this guide is getting a CAN toolhead running, there is a very high chance that the temperature sensor in question will be your hotend sensor. If you have it unplugged, you'll get this ADC error so check that first. 55 | 56 | If it's definitely plugged in to the toolhead, double check that you set the pin in the printer.cfg correctly. If it's still "looking" at the old mainboard temperature sensor pin location then it will also act the same as if it was unplugged. 57 | 58 | If you have a PT100 or PT1000 sensor and a board with the MAX31865 chip make sure the DIP switches are set correctly for your type of sensor and that the printer.cfg is correct. Most sample configs leave this section commented out so you will need to add it to your config (and make sure to remove the old `sensor_type:` and `sensor_pin:` options as the MAX31865 section will handle it instead). 59 | 60 | If none of these options helped then make sure your thermistor hasn't broken a wire or crimp, and also have a look at your klippy.log and it'll tell you exactly what temperature sensor is the one with issues. Maybe it's not even your hotend thermistor, and maybe you've bumped loose your bed thermsitor or something. 61 | 62 | ### "MCU: Unable to connect" 63 | 64 | Klipper won't start, and you get the error "MCU'yourMCUname': Unable to connect" 65 | 66 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/491e4654-981b-4a8b-be36-6d65c907fa95) 67 | 68 | I'm going to assume you have looked at the above steps and your config file has all the correct UUID values against the correct MCU section. If that is the case then we need to check a few things. 69 | 70 | First: run an `ip a` on your Pi and make sure it shows a can0 interface. If you don't see a can0 interface listed then check through the [can0 troubleshooting steps](./no_can0.md) 71 | 72 | If the can0 network shows up fine, then we need to see if your device is actually online proplerly. We don't want Klipper actually attempting to start at this point, so the easiest way is to rename your `printer.cfg` to `printer.old` or something, then shudown your pi with `sudo shutdown now` then turn off **all** the power to your printer. Wait 30 seconds or so then turn it back on. After a minute or two your Pi should be online again so SSH back in and run `~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0` to do a query of all canbus devices. 73 | 74 | If no UUIDs show up (or you get only the mainboard UUID and not your toolhead) then check the [no UUID troubleshooting steps](./no_uuid.md). 75 | 76 | If your toolhead UUID shows up but it says `Application: Katapult` (or `Application: Canboot`) then your toolhead is on the CAN network but is in bootloader mode. Continue flashing with the toolhead flashing guide, starting at the ["Installing Klipper" section](../toolhead_flashing#installing-klipper). 77 | 78 | If all your devices show up fine, and show `Application: Klipper` as they should, then rename your `printer.old` file back to `printer.cfg` and do a firmware restart. It might be that it all just works now and it needed a power cycle. If it still doesn't work then you may have an error in your printer.cfg (the mainboard UUID and toolhead UUID being swapped around is a common one). Go back to the **MCU** section above. 79 | 80 | 81 | [Return to Troubleshooting](./) 82 | -------------------------------------------------------------------------------- /troubleshooting/lost_communication_to_mcu.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Lost Communications to mcu 4 | nav_order: 50 5 | parent: Troubleshooting 6 | --- 7 | 8 | # Lost Communication to mcu 9 | 10 | So you're happily printing, everythings great, you're thinking "oh, this whole CANbus thing is easy" when all of a sudden your print stops with an error `Lost communication with MCU 'EBBCan'` or similar (whatever your CAN toolhead name is). You restart, it works fine again but sooner or later it happens again. Or maybe after the first time you can't even get klipper to start again as it just can't connect to your toolhead UUID. 11 | 12 | This is almost always a wiring loss problems. A way to confirm is to check your logs. Download your klippy.log from when the error happened, then do a "Ctrl F" search for "lost communication" and find the one that is closes to the bottom of your log file (ie. the latest one that occurred). 13 | 14 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/b0f887be-dc0a-4a2a-858f-c30d96fd00bd) 15 | 16 | Once you've found it, look just above it at the `Stats:` lines. Scroll across until you find the `bytes_retransmit` entries. There will be one of these for each MCU in your system, so the first one is your mainboard (octpus or whatever) which *probably* is fine, then further along you will find the entries for your CAN toolhead. 17 | 18 | What you are looking for is a sudden jump in the retransmits. Maybe it was at 0 for ages, or maybe it would have small jumps but sit at that for long periods of time. Either way what you are looking for is if there was a sudden jump right before the "lost communication" error: 19 | 20 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/2daa62db-9c94-4ddc-8794-f8f1d5b74376) 21 | 22 | This is a pretty solid indication of the toolhead losing communcation with the pi from a wiring problem. Could be a broken wire, could be a crimp in a connector going bad. It may be on the 24v or Ground wire or, or it may be the CanH or CanL communcation wires. Either way, your Pi has lost the signal to your toolhead. 23 | 24 | The only way around it is to go through and check all your wires. This is sometimes obvious (a broken wire in a cable chain) othertimes not (a "partially" broken crimp inside a molex connector) but it'll likely be somewhere. Just keep digging around. 25 | 26 | Before you say "I've checked and it all looks good, it must be something else" just remember that it doesn't take much of a break for the connection to drop out: 27 | 28 | ![broken_wire](https://github.com/Esoterical/voron_canbus/assets/124253477/d5d466cf-27af-48b7-93f0-62a8991b784a) 29 | 30 | 31 | [Return to Troubleshooting](./) 32 | 33 | -------------------------------------------------------------------------------- /troubleshooting/multiple_can_networks.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Multiple CAN Networks 4 | parent: Troubleshooting 5 | --- 6 | 7 | Credit to Fragmon (find them on youtube at [https://youtube.com/@crydteamprinting](https://youtube.com/@crydteamprinting)) for their help with the following instructions. 8 | 9 | # Multiple CAN Networks 10 | 11 | Generally there is *no* reason you would need mutiple CAN networks on a single printer. If you have a bunch of different 12 | CAN devices you can just hook them up along the same pair of H/L wires on a single CAN network. 13 | 14 | However, if your printer needs to run multiple CAN networks for some reason (maybe you run multiple printers/klipper installs 15 | on the same PC) then it is simple enough to do. 16 | 17 | All that is really needed to get a second CAN network is to just connect a second CAN adapter. Usually this would be a USB CAN 18 | adapter like a BigTreeTech U2C, but it doesn't have to be. Anything that would act as a CAN adapter will work, but in the following 19 | instructions I will assume your adapter is connected via USB as it is the most common way and simplifies things. 20 | 21 | The next important thing we need to do is make sure that each CAN interface *always* gets applied to the same CAN adapter. If 22 | you don't specify this then Linux may change which adapter is running which network and that will give you klipper errors. 23 | 24 | ## Finding the Hardware Serial of your CAN Adapter 25 | 26 | Connect your first CAN adapter to your printer 27 | 28 | We want only **one** connected at this time so it's easier to get the correct hardware IDs and not to get confused. 29 | 30 | Run `lsusb` and note down the Bus and Device ID. For example, if your device is on `Bus 001 Device ID 010` then note down the values 31 | 001 and 010 32 | 33 | ![image](https://github.com/user-attachments/assets/979ce265-cedb-48ab-aa13-5c20f61a5f5a) 34 | 35 | 36 | Then we'll use "udevadm info -a -n /dev/bus/usb/BUS/DEVICE_ID" using the Bus and Device ID you just found, then pipe it 37 | to GREP to find the hardware serial of the device. 38 | 39 | ```bash 40 | udevadm info -a -n /dev/bus/usb/001/010 | grep ATTR{serial} 41 | ``` 42 | 43 | ![image](https://github.com/user-attachments/assets/07fed863-dd8a-4097-9c68-36e1c27e496d) 44 | 45 | {: .note } 46 | >If you aren't seeing any serial number using the above command, you can try searching by ATTRS{serial} instead of ATTR{serial} 47 | > 48 | > `udevadm info -a -n /dev/bus/usb/001/010 | grep ATTRS{serial}` 49 | > 50 | >The difference: 51 | > 52 | >ATTR{serial} checks only the current device level. 53 | > 54 | >ATTRS{serial} searches higher levels in the device hierarchy (e.g., USB hubs or controllers). 55 | > 56 | >If your adapter is part of a multi-interface device or connected via a hub, the serial might be stored on a higher level, requiring ATTRS{serial}. 57 | 58 | ## Create UDEV rule to link hardware ID to CAN interface 59 | 60 | Now that we have the hardware serial ID we will use a udev rule to link this hardware to the can0 interface. 61 | 62 | Run: 63 | 64 | ```bash 65 | sudo nano /etc/udev/rules.d/99-can.rules 66 | ``` 67 | 68 | To create a new udev rules file and add: 69 | 70 | SUBSYSTEM=="net", ACTION=="add", ATTR{serial}=="YOUR_SERIAL", NAME="can0" 71 | 72 | to the top line (making sure to put in the serial ID you just found) 73 | 74 | ![image](https://github.com/user-attachments/assets/4e78045a-1667-42d5-b842-35d3f2bef8e9) 75 | 76 | Press Ctrl X to save and exit, Then Y when it asks to save modified buffer, then press enter when it asks for the filename to use 77 | (it will already have the correct name). 78 | 79 | 80 | ## Repeat steps for second CAN adapter 81 | 82 | Now connect the second CAN adapter to your Pi and we'll go through a very similar set of steps. 83 | 84 | Run `lsusb` and note down the Bus and Device ID (in the following example it is `Bus 001 Device ID 012`) 85 | 86 | ![image](https://github.com/user-attachments/assets/aec211b4-6850-4dbc-8353-631f90bd1861) 87 | 88 | Run udevadmin info with the Bus and Device ID to find the serial ID 89 | 90 | ```bash 91 | udevadm info -a -n /dev/bus/usb/001/012 | grep ATTR{serial} 92 | ``` 93 | 94 | ![image](https://github.com/user-attachments/assets/c32129b7-ab27-45ba-8421-432050aa6ce5) 95 | 96 | We will now add this second ID to the same 99-can.rules file you created earlier. 97 | 98 | Run: 99 | 100 | ```bash 101 | sudo nano /etc/udev/rules.d/99-can.rules 102 | ``` 103 | 104 | and add a second line the same as the first line but with your new serial ID and with `NAME="can1"` to link this hardware to the 105 | can1 interface. 106 | 107 | SUBSYSTEM=="net", ACTION=="add", ATTR{serial}=="YOUR_SERIAL", NAME="can1" 108 | 109 | ![image](https://github.com/user-attachments/assets/cdbd87ab-2f2c-4eb9-acbb-eebe42b8abb8) 110 | 111 | Press Ctrl X to save and exit, Then Y when it asks to save modified buffer, then press enter when it asks for the filename to use 112 | (it will already have the correct name). 113 | 114 | Now just reboot your pi with: 115 | 116 | ```bash 117 | sudo reboot now 118 | ``` 119 | 120 | and we have now made it so your Pi will *always* link that your can0/can1 interfaces to those specific adapters. 121 | 122 | Note, you can just go through these steps again for any number of CAN interfaces if you like, but again the use case for multiple CAN networks is 123 | very niche. 124 | 125 | ## Change Klipper config 126 | 127 | The last thing you need to do is modify your printer.cfg so that Klipper knows which boards 128 | are on the new can1 network instead of the default can0. 129 | 130 | Simply edit your printer.cfg (or whatever .cfg has the required settings) where the MCU section is for your board that is on the second CAN network. 131 | 132 | Add `canbus_interface: can1` underneath the canbus_uuid:. This lets Klipper know that this device is on the can1 interface instead of can0. 133 | 134 | 135 | ![image](https://github.com/user-attachments/assets/59afac6b-ef4e-4ad9-a9aa-6eee7023000f) 136 | 137 | {: .note } 138 | >Also take note that any time you need to run the katapult flashtool.py tool you will need to include the parameter `-i can1` 139 | >in your command string for any device that is on the can1 network. 140 | > 141 | >eg. `~/katapult/scripts/flsahtool.py -u a145c2b0d6d7 -r -i can1` 142 | -------------------------------------------------------------------------------- /troubleshooting/no_can0.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: No can0 Interface 4 | nav_order: 10 5 | parent: Troubleshooting 6 | --- 7 | 8 | ## No CAN network when running a query or flash attempt 9 | 10 | If you run a `python3 ~/katapult/scripts/flashtool.py -i can0 -q` or `~/klippy-env/bin/python ~/klipper/scripts/canbus_query.py can0` or are trying to flash a device with a command like `python3 ~/katapult/scripts/flashtool.py -i can0 -u b6d9de35f24f -f ~/klipper/out/klipper.bin` but you are seeing an error along the lines of "unable to bind socket to can0" or "failed to transmit, network is down" then your can0 "interface" on your Pi isn't running. 11 | 12 | ![image](https://user-images.githubusercontent.com/124253477/235117239-009ab013-d9ba-4524-81d4-a73c8990c2a7.png) 13 | 14 | First thing to check is your `/etc/systemd/network/25-can.network` file. Make sure it exists and you have no typos in it. 15 | 16 | ### Seperate USB-CAN adapter (U2C/UTOC/etc.) 17 | 18 | If you are using a seprate USB to CAN adapter (U2C/UTOC/etc.) then double check that the USB cable connecting the devices is plugged in and not loose. If you _never_ get a response to a query (ie. the can0 interface has never shown at all) then you may have a dodgy USB cable. I have personally seen a handful of usb-c cables that don't actually have the data pins hooked up (they are power only). If the adapter doesn't show to an `lsusb` then your cable is probably dodgy. 19 | 20 | If it shows up to an `lsusb` but an `ip link show can0` shows "Device can0 does not exist" then you might have a bad firmware or something on your device. Reflash it with the appropriate firmware either from a manufacturer github repository or other source (like candlelight). If there are instructions back on the voron_canbus/can_adapter folder then follow those. 21 | 22 | ### USB-CAN-Bridge mode mainboard 23 | 24 | Check that the Pi-to-mainboard USB cable hasn't come loose or anything, and that the mainboard is actually powered up. An `lsusb` should show the mainboard up as a can adapter device. If it's not showing as a can adapter device then do an `ls /dev/serial/by-id`. If you see your mainboard there then either it's still in Katapult mode, or you haven't flashed usb-can-bridge klipper to it (or the flash didn't take). If that is the case then reflash your mainboard as per the voron_canbus/mainboard_flashing instructions and take extra care that the klipper `make menuconfig` settings are 100% correct for your board. 25 | 26 | [Return to Troubleshooting](./) 27 | 28 | 29 | -------------------------------------------------------------------------------- /troubleshooting/no_uuid.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: No UUID 4 | nav_order: 20 5 | parent: Troubleshooting 6 | --- 7 | 8 | 9 | So you're can0 interface is online, but a query returns nothing: 10 | 11 | ![image](https://user-images.githubusercontent.com/124253477/235122048-e39c4fb0-6163-4469-b1fa-aa9dddfe69b2.png) 12 | 13 | First up, if you previously _could_ see UUID's returned, and then put them into your printer.cfg file, but now you can't see anything from a canbus query **don't panic**. Once a UUID has been "grabbed" by klipper-on-pi then it won't show up to a query. This is normal. 14 | 15 | {: .highlight } 16 | > Note: If your board is meant to be in Katapult mode, and you have a blinking LED on the toolhead indicating the board *is* in katapult mode (if the status LED is supported) 17 | > then the Klipper service on the pi *won't* be grabbing the UUID. It will only grab `application: klipper` UUID's. 18 | 19 | 20 | 21 | ### Firmware 22 | 23 | If you haven't put the UUID into your printer.cfg then this means that your method of CAN adapting (standalone adapter or usb-can-bridge mainboard) is running OK but can't see anything on the network. Starting at the adapter end, if you are using a usb-can-bridge mainboard then **double check** that the klipper firmware you flashed had the correct pins set for the CAN network. If you used the wrong pins then the mainboard will boot fine, and even show the can0 interface fine, but will be looking on the wrong pins for CAN traffic and so will never find any other nodes. Note that you should never be able to get into a situation with a usb-can-bridge mainboard where it shows the can0 interface fine but can't find at least its own UUID to a query. 24 | 25 | Next, check the firmware of your toolhead. If you never saw the toolhead Katapult or klipper as a UUID at all then **double check** the Katapult/klipper firmware for incorrect settings. This could be any setting as even a single incorrect setting on this firmware will either stop the toolhead from booting at all (in which case you won't see it on the network) or it boots but is looking at the wrong CAN pins/has the wrong CAN speed (in which case you also won't see it on the network). 26 | 27 | I'm going to assume you are using Katapult from this point on. If this had the correct settings (which you have double checked) and it flashed OK then we can assume it has booted into Katapult. I would recommend setting a status_led pin in the config (I have outlined the correct pins to use for this in the toolhead_flashing/common_hardware entries) as it will be flashing an LED if it is sitting in Katapult mode. 28 | 29 | 30 | 31 | 32 | ### Wiring 33 | 34 | If it's sitting in Katapult but you still can't see a UUID then your problem is likely down to wiring. (Thanks to @drachenkaetzchen for the much better writeup than my original one) 35 | 36 | - First thing **Shut down the Pi with `sudo shutdown now` and then power off the whole printer. There needs to be no power before testing further.** 37 | 38 | - Each side of the CAN Bus needs the 120 Ohm resistor in place. Ensure you got the appropriate jumpers set. The Octopus is an exception, it has no jumper, the 120 Ohm resistor is always present. 39 | 40 | - For all following measurements, your printer must be powered off. 41 | 42 | - Ensure using a multimeter in continuity mode that CAN_L from one side actually ends up on CAN_L on the other side. Same for CAN_H. Remove all termination resistors for that. If one of your boards has a fixed 120 Ohm resistor, remove the jumper on the other board. Then use your multimeter in Ohms mode to measure from one side to the other, you should read close to 0 ohms. If you read 120 Ohms, you probably have swapped CAN_L and CAN_H 43 | 44 | - With everything connected, measure resistance between CAN_L and CAN_H. You should read 60 Ohms (2x 120 Ohm in parallel = 60 Ohms). If you get 120 Ohm, then there might be a break in the wire or you forgot to set the jumper 45 | 46 | - If you suspect that CAN_L or CAN_H might be broken, measure in resistance mode (not continuity!) between CAN_L on one board with CAN_L on the other board. If you get 240 Ohms, then there's a break in CAN_L. Repeat the measurement for CAN_H 47 | 48 | 49 | ### can0 Interface 50 | 51 | There are guides floating around on the internet (I can't find them now but I swear I've seen them in the past) that instruct users to add post-boot tasks to modify the CAN speed or txqueuelen to something different than is stated in the `/etc/systemd/network/25-can.network` file. If your firmware/wiring/everything looks fine yet you still can't get a UUID then this is a good thing to check. 52 | 53 | To test this hypothesis, make sure you are **absolutely sure** of the CAN speed you set when compiling the katapult/klipper firmware for your device (if you are using this guide then that will be one million, 1000000) then run the following commands to manually take down the can0 interface then bring it back up with the "known correct" speed 54 | 55 | To **stop** the can0 interface: 56 | 57 | `sudo ip link set can0 down type can` 58 | 59 | To **start** the can0 interface (replace the bitrate to whatever you are using if it isn't 1000000) 60 | 61 | `sudo ip link set can0 up type can bitrate 1000000` 62 | 63 | To confirm the network is back up and running at the correct speeds run `ip -details -statistics link show can0` and look for the following: 64 | 65 | ![image](https://github.com/user-attachments/assets/c211da71-a0e3-4c47-b4a2-fdef3b717999) 66 | 67 | If it looks good then re-run a canbus query to see if the UUID shows up now. 68 | 69 | If your UUIDs show up then reboot the printer and check again. If they now *don't* show up then you probably have one of these post-boot script things interfering. 70 | Usually it is in the rc.local file. Run: 71 | 72 | `sudo nano /etc/rc.local` 73 | 74 | and if you see any lines referecing "can0" then put a # at the start of the line to comment it out (or delete the whole line), then reboot and canbus query once again. Hopefully it's all good at this point. 75 | 76 | If the rc.local file *isn't* the problem, but you still get post-boot no UUIDs but you *do* get UUIDs after manually setting the can0 speed with the commands, then the overriding "script" is somewhere else. As linux has a bunch of different ways to change settings after a boot it is hard to cover all of them here. Just take the information you have now figured out (something is changing my can0 speed afterboot, it isn't the rc.local file) and ask your favourite helpers/discord channels/forums/wherever. 77 | 78 | ### BUS-OFF 79 | 80 | There are rare cases where certain circumstances lead to the CAN interface on your Pi going into a BUS-OFF state. You can see this when you run: 81 | 82 | ```bash 83 | ip -s -d link show can0 84 | ``` 85 | 86 | ![image](https://github.com/user-attachments/assets/2e07dd50-da8d-4f2b-96cb-b563c3be19a7) 87 | 88 | 89 | This means your can0 interface on your Pi is no longer listening for CAN traffic, even if you have a node (like a toolhead) that you "fix" and it should be detectable. 90 | 91 | For example, the wrong Klipper firmware on a toolhead can possibly make the toolhead innaccessible over CAN (no UUID to a query, won't connect in Klipper) but also causes the CAN adapter to 92 | freak out and go into a BUS-OFF state. Even if you then double-click the reset button on the toolhead and you *know* the Katapult firmware on it is fine so you *should* now see the UUID, you 93 | won't while the can0 interface itself stays BUS-OFF. 94 | 95 | One way to kick the can0 interface out of BUS-OFF is to manually turn the interface off and on again by running: 96 | 97 | `sudo ip link set can0 down type can` 98 | 99 | then: 100 | 101 | `sudo ip link set can0 up type can bitrate 1000000` 102 | 103 | It is probably a good idea to have your toolhead/node/whatever in a "It should be working" state before you do this (ie. double-click reset to put the node into Katapult mode). If there is 104 | an active node already when you do the above off/on of the interface then you should be able to now do a 105 | 106 | `~/katapult/scripts/flashtool.py -q` 107 | 108 | and see your node UUID again, and be able to reflash Klipper to it (if needed). 109 | 110 | 111 | [Return to Troubleshooting](./) 112 | -------------------------------------------------------------------------------- /troubleshooting/other_errors.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Other Errors 4 | parent: Troubleshooting 5 | --- 6 | 7 | # Reading your klippy.log 8 | 9 | If you happen to be having errors such as "Timer Too Close" or "Missed Scheduling of next digital out event" or something like that (ie. something that isn't giving a direct cause like an ADC error or a Lost Comms error) 10 | then it is always worth having a look into your klippy.log file to see what it says. 11 | 12 | Simply download the klippy.log file from your printer (you can do this via the Mainsail or Fluidd GUI, or copy it directly from `~/printer_data/logs`), scroll down to the very bottom, then start scrolling "up" until you 13 | run into the error you just had (you can also use the "find" function in a lot of text editors to search for your error). 14 | 15 | Once you have found where the error in the logs, scroll up a bit further until you start seeing lines that start with `Stats:` 16 | 17 | ![image](https://github.com/user-attachments/assets/c0ca73e4-0b5b-46b5-aea6-d3f08959a63d) 18 | 19 | These lines are incredibly helpful when diagnosing issues. 20 | 21 | Each line goes in sections according to the MCU. The first section will be your mainboard MCU as it is simply called `MCU` 22 | 23 | ![image](https://github.com/user-attachments/assets/23c8dcf7-c87a-48c6-8d0c-3130a7293b10) 24 | 25 | So if you find the `mcu:` part, anything to the right of this on that line will be the stats for the mainboard at that time. So any bytes_retransmit or bytes_invalid or whatever will be associated with your mainboard. 26 | 27 | If you keep scrolling to the right you will find another mcu entry with the name of one of your other boards 28 | 29 | ![image](https://github.com/user-attachments/assets/4b0c49eb-60ae-443d-9ade-d5eb9c63b1a3) 30 | 31 | So same thing again. Anything after *this* entry will be related to *this* particular MCU (in this case, the EBBCan is the toolhead of this user, so the stats are related to the toolhead board). 32 | 33 | The most common things to look at to help diagnose issues are the `bytes_retransmit` and `bytes_invalid` counters. Make sure to check the entries for *each* mcu entry (ie. the just `mcu`, a toolhead that may be `EBBCan` or whatever, etc.) 34 | 35 | # bytes_retransmit 36 | 37 | The `bytes_retransmit:` field indicates how many data packets have had to be resent to that MCU. This can be because the packet was malformed or had errors or otherwise isn't getting through from the Pi to the MCU properly. 38 | 39 | If you are seeing bytes_retransmit after investigating a "Lost communication" error then it is highly likely your problem is a physical issue, usually an issue with the CAN cable or other connector (see [here](./lost_communication_to_mcu.md)) 40 | But retransmits aren't *only* caused by a bad cable. They can be caused by many other issues as well, but if you see it *in conjunction with* a "Lost communication with mcu" error then there is a good chance it's cabling. 41 | 42 | bytes_retransmit is the most common "bad" thing you'll see in the logs, but make sure to check *each* mcu section along the Stats: line. Just because the mainboard MCU has no bytes_retransmits doesn't mean your toolhead doesn't. 43 | 44 | If you see anything higher than 9 then you should keep an eye on it. Generally it should be 0 but I've seen USB boards sometimes cause it to get to 9 and stay there (probably something to do with first startup). 45 | 46 | # bytes_invalid 47 | 48 | the `bytes_invalid:` entry is another helpful one to check but it's far less common for this to be anything other than 0. 49 | 50 | Invalid bytes are data packets that arrived to the mcu perfectly fine, no errors or anything, but they came in the wrong order. So if your Pi was sending packets 101, 102, 103, then the MCU may have received them in order 101, 103, 102. 51 | 52 | This is **not** something that is caused by a bad cable/wire/other physical thing. This is a software issue. 53 | 54 | There have been instances where bad firmware on a CAN adapter (the only one I really know of is the BTT U2C but it could happen to others) and the fix for that is simply to flash the correct firmware on it (see [here](../can_adapter/BigTreeTech%20U2C%20v2.1/README.md#bad-firmware) 55 | for the BTT U2C fix specifically). 56 | 57 | The other more common cause is the operating system of the Pi itself. It may be getting overloaded or have some rogue process (in which case the [timer_too_close](./timer_too_close.md) page may help) or you may have a bad version of 58 | the operating system (see the [Pi operating system](../Getting_Started.md#raspberry-pi-operating-system) section of the Getting Started page) 59 | 60 | # Live Tracking 61 | 62 | If you have found one of these stats incrementing in the logs but you can't seem to find the cause, then it may help to watch the stats "live". You can do this in the Mainsail GUI (may be possible in Fluidd or others in a similar way) 63 | by going to the "MACHINE" tab, then clicking on the mcu name of the board you want to monitor in the "System Loads" section. This will open a new window where you can scroll down and find bytes_retransmit and bytes_invalid (as well 64 | as every other stat) and this will be showing a live update of the stats. 65 | 66 | ![image](https://github.com/user-attachments/assets/3df25c42-b7b1-4e57-842c-a2a7968c43d0) 67 | 68 | Simply keep this open in another browser window while you are doing a print or test or whatever. It may help you line up a specific action of the printer with a jump in errors. 69 | -------------------------------------------------------------------------------- /troubleshooting/termination_resistor_info.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Termination Resistor Info 4 | parent: Troubleshooting 5 | --- 6 | 7 | # Termination Resistor Info 8 | 9 | The 120 ohm termination resistors facilitate two different jobs in a CANBus system. 10 | 11 | The first is that they provide the proper resistance for the CAN Transceivers to be able to pull the signal high/low. 12 | 13 | The second is that they mitigate reflections when the signal hits the "end" of the wire. 14 | 15 | Ideally, the 120ohm resistors will be at the physical "ends" of the CAN cable, and each node will be on this main cable in a nice straight line. This thinking has caused much confusion for users, especially as their CAN setups get more complicated than a single toolhead. 16 | 17 | Imagine a system that has a U2C CAN adapter in the electronics bay, a CAN toolhead board on the toolhead, and a CAN control board on a ERCF situated outside of the printer. 18 | In this case, it is simple enough to have a CAN cable going from U2C to toolhead, and another going from U2C to ERCF, and have the 120r resistor/jumper in place on the toolhead 19 | and on the ERCF board, but *not* on the U2C. This gives a nice standard "resistor on each end" setup. 20 | 21 | But what about a system with more boards like a toolchanger setup? Or what if instead of a U2C you are using an Octopus mainboard as the CAN adapter, and the Octo has a hardwired 120 22 | ohm resistor that *can't* be removed. 23 | 24 | This is where reality hits. 25 | 26 | At the end of the day, our printers are *tiny* compared to what a CANBus system is usually used for. This means we have a lot of wiggle room when it comes to things like termination 27 | resistor placement and wiring quality and component choices etc. 28 | 29 | ## Transceiver fuctionality 30 | 31 | For a printer, the biggest impact of an incorrect amount of termination resistors is actually around the ability of the CAN transceviers to generate a signal. These transceivers are 32 | "expecting" the circuit to have around 60 ohms of impedence (which two 120ohm resistors in parallel ends up being). 33 | 34 | If you have **no** resistors at all, then the transceivers can't really pull the signal high or low and in all likelyhood nothing will work. 35 | 36 | If you have **one** resistor in the circuit, you *may* find that the system works simply because of the small scale we are on. It's not ideal, but there have been plenty of instances 37 | of a printer functioning even though the user has forgotten one of the termination resistor jumpers. 38 | 39 | If you have **two** resistors in the circuit, gold star, this is what we want. 40 | 41 | If you have **more than** two resistors things start going bad again. Each additional resistor is lowering the overall impedance (the more resistors in parallel, the lower the effective resistance) 42 | so from the transceivers point of view it's looking more and more like a short circuit, and they won't function like this. You *might* get away with 3 resistors, but that's not guaranteed. 43 | Definitely won't work with 4+. 44 | 45 | ## Signal Reflections 46 | 47 | As stated before, the main factor with the use of 120ohm resistors **in the context of a 3d printer** is how it affects the CAN Transceivers, but the other side is mitigating signal reflections 48 | in the wire. This is what most people think of when talking about these termination resistors, and in a long CAN cable (like in a car or heavy machinery) it is indeed the primary concern. But 49 | for the small maybe-3-meters runs of a printer it's almost negligable. 50 | 51 | So if you have a printer with a "complicated" topography, like a 5 toolhead toolchanger setup, simply aim for "good enough" in where you put your resistors/jumpers. 52 | For a toolchanger setup, I'd tie all the tools back to a common spot (like on the gantry or frame) and put a 120ohm jumper/resistor here, then run a single cable back to the electronics bay and put 53 | the other resistor on the CAN adapter/mainboard. 54 | 55 | Or for a setup where there are hardwired resistors in "not optimal" locations, like an Octopus mainboard with a hard wired resistor in the middle of both a toolhead and an ERCF board, simply 56 | put one other termination resistor/jumper on one of the other devices (usually the toolhead, but might also be worth picking the one that has the longest physcial CAN cable run). 57 | 58 | -------------------------------------------------------------------------------- /troubleshooting/timeout_during_homing_probing.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Timeout During Homing/Probing 4 | nav_order: 40 5 | parent: Troubleshooting 6 | --- 7 | 8 | # Timeout during homing and/or probing 9 | 10 | I'm going to make a couple of assumptions right at the start for this section as this 'symptom' could be from different causes. So to narrow it down this section is if: 11 | 12 | - Your printer gets an error along the lines of `Timeout during homing` or `Timeout during probe` or `Timeout during homing probe` 13 | - This error doesn't *always* happen. Sometimes it'll home fine or probe fine and start printing. 14 | - Once your printer is printing it doesn't error out, it only happens during axis homing or a bed mesh. 15 | 16 | If your symptoms match the above read on. If you can't even finish a homing or probing actuion error, or you sometimes can but you frequently get ["lost communication to mcu"](./lost_communication_to_mcu.md) or ["timer too close"](./timer_too_close.md) errors please read those relevant sections first then return here if your symptoms more align with the above. 17 | 18 | With that out of the way, this kind of problem is usually the cause of your Pi not keeping up with klipper during a homing or probing operation. These operations require very tight timings and an underpowered board or a board with a lot of background processes going on can somtimes miss a timing window and cause this error. Or sometimes a board that "should" work fine still does it, which I suspect is something lower level in the linux kernel, but that's not a discussion for here. 19 | 20 | ## CPU Affinity 21 | 22 | Something I've had success with lately is assigning CPU cores to processes. The following steps will force everything *except* klipper to run on the first 3 cores (cores 0, 1, 2) of a quad-core CPU (any Pi newer than a Pi2) and then force Klipper to run by itself on the fourth core. This *may* help with timing issues or scheduling conflicts or whatever could be interrupting Klipper from hitting the proper timing windows. 23 | 24 | Create the system.conf.d folder with: 25 | ```bash 26 | sudo mkdir -p /etc/systemd/system.conf.d/ 27 | ``` 28 | 29 | then edit (or create) the cpuaffinity.conf file by running: 30 | ```bash 31 | sudo nano /etc/systemd/system.conf.d/cpuaffinity.conf 32 | ``` 33 | and putting in: 34 | ```bash 35 | [Manager] 36 | CPUAffinity=0-2 37 | ``` 38 | then press ctrl+X to save and quit. This will force everything to run on the first three cpu cores only. 39 | 40 | To make Klipper run on the now-unused fourth core, create the klipper.service.d folder with: 41 | ```bash 42 | sudo mkdir -p /etc/systemd/system/klipper.service.d 43 | ``` 44 | 45 | then edit (or create) the override.conf file by running: 46 | ```bash 47 | sudo nano /etc/systemd/system/klipper.service.d/override.conf 48 | ``` 49 | and putting in: 50 | ```bash 51 | [Service] 52 | CPUAffinity=3 53 | ``` 54 | then press ctrl+X to save and quit, and run `sudo reboot now` to reboot the Pi. 55 | 56 | Once it starts again it should have the Klipper service running by itself on the fourth core of the CPU and hopefully let it not get interrupted by other non-Klipper processes. 57 | 58 | ## Config Tweaks 59 | 60 | If the CPU Affinity doesn't work (or your computer board doesn't have multiple cores),then we can try minimising CAN traffic by lowering stepper motor microsteps and the homing speed. 61 | 62 | - Set **all** microstep settings in your printer.cfg to 16. This value is found in the `[stepper_ ]` sections for X/Y/Z (probably multiple Z motors, you need to change each one) and also your `[extruder]` section. 63 | 64 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/12fe8458-664c-4a50-86e7-b20845e9a579) 65 | 66 | - Set the homing speeds to fairly low. 20mm/s for X/Y, 10mm/s for Z. Yes this may be painful but it's just testing at the moment. Once you've "fixed" the problem feel free to adjust these back up. 67 | - Make sure your CAN speed is set to 1M and txqueuelen is set to 128 (see the [Getting_Started](../Getting_Started.md) page on how to set this) 68 | - Unplug any extra USB devices from your pi. Maybe LEDs, maybe cameras. Anything USB can be drawing power and using processing time so lets remove it all for testing 69 | - If using crowsnest for your camera, stop the crowsnest service completely. Easy to do in mainsail, just press the button: 70 | 71 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/c0555deb-9cb9-44b5-9679-43500659b2d6) 72 | 73 | or you can run `sudo service crowsnest stop` on the Pi and this will also stop the crowsnest service 74 | 75 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/08d74420-1ef5-4223-9e4e-1c735ee70574) 76 | 77 | 78 | Now do some more homing and probing. If it's rock solid now, great! Go through the steps in reverse order (re-enable crowsnest, plug in USB one at a time, change microsteps, etc) until you start seeing it time out again. This way you should be able to either track down the single culprit or at least find the limits of what your Pi can handle. 79 | 80 | ## TRSYNC_TIMEOUT 81 | 82 | If the above still doesn't fix it (and by "fix it" I mean "never happens" not just making it happen less) then the next thing I would do is to actually change the klipper homing timeing threshold. This is a bit "hacky", but I've found it necessary on certain boards (I had to do it on my pi3b, nothing else would solve the problem). 83 | 84 | By default, Klipper uses a 25ms window for homing actions. This is set by the `TRSYNC_TIMEOUT` entry in the klipper `mcu.py` file. To check if yours is still the default run: 85 | 86 | ```bash 87 | cat klipper/klippy/mcu.py | grep "TRSYNC_TIMEOUT =" 88 | ``` 89 | 90 | if it shows TRSYNC_TIMEOUT=0.025 then it is still the default setting. 91 | 92 | ![image](https://github.com/Esoterical/voron_canbus/assets/124253477/8ae18275-a606-47e1-86c1-f2b53d54e9a9) 93 | 94 | To change this to 50ms run the command: 95 | 96 | ```bash 97 | sed -i 's\TRSYNC_TIMEOUT = 0.025\TRSYNC_TIMEOUT = 0.05\g' ~/klipper/klippy/mcu.py 98 | ``` 99 | 100 | Then confirm it by running `cat klipper/klippy/mcu.py | grep "TRSYNC_TIMEOUT ="` again. If the change has been set reboot the Pi with `sudo reboot`. 101 | 102 | I've found a 50ms timeout window got rid of all my "timeout during homing probe" errors with seemingly no loss in probing or homing accuracy. 103 | 104 | **Note** as I said this is still a bit of a hacky workaround. Doing this will mark your klipper install as "dirty" in your mainsail update manager (all it means is there is a file that is different to what is in github, which is true because we just changed it) and whenever you update klipper it will overwrite this to default. So if you update klipper and find the timeouts returning just run `sed -i 's\TRSYNC_TIMEOUT = 0.025\TRSYNC_TIMEOUT = 0.05\g' ~/klipper/klippy/mcu.py` and reboot. 105 | 106 | 107 | 108 | 109 | [Return to Troubleshooting](./) 110 | -------------------------------------------------------------------------------- /troubleshooting/timer_too_close.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Timer Too Close 4 | nav_order: 60 5 | parent: Troubleshooting 6 | --- 7 | 8 | # Timer Too Close 9 | 10 | This error tends to be a "catch all" for a bunch of different causes. It can often be caused by the Pi itself getting overloaded (or overheating and throttling), or the mcu in question (toolhead/mainboard/whatever) also getting overloaded. Or a different thing entirely. 11 | 12 | Some things to check: 13 | 14 | ## Pi CPU load 15 | 16 | There's always the possibility of a rogue process on your Pi hogging the CPU cycles and not leaving much space left for klipper tasks. This is something that is generally hard to spot unless it is *really* obvious 17 | (like a bad klipperscreen process stuck at 90% CPU or whatever), but something I like to do is use `htop` to get a view of the currently running processes and just seeing if anything looks particularly wrong. Pressing 18 | `F6` then choosing the PERCENT_CPU option in the "Sort By" sidebard helps sort the list from highest CPU usage to lowest. 19 | 20 | ![image](https://github.com/user-attachments/assets/cc61761f-2e5b-4adc-a9f3-9744af4a8b87) 21 | 22 | ## LED Effects 23 | 24 | Another common resource hog that can use up cycles on both the Pi *and* the MCU is the LED Effects plugin. The one that lets your neopixels do the funky breathing/pulsing effects. Because Klipper uses bit-banging in 25 | order to send neopixel commands once you start trying to send animation effects at 12fps or whatever the load on the MCU really adds up. So if you are getting TTC errors and have the LED Effects plugin installed it's 26 | best to just [uninstall it](https://github.com/julianschill/klipper-led_effect?tab=readme-ov-file#uninstall) to see if it helps with the error. 27 | 28 | ## Anecdata 29 | 30 | Because the problems are so many I'm just going to start cataloguing real-world examples of where users have had TTC errors and what the cause ended up being. 31 | 32 | This section will be expanded as I add more examples. 33 | 34 | 35 | `User had no retransmits/invalids, failed at same point in same gcode when sliced in orca. Worked fine in SS. Ended up being gcode_arc set too low (0.01 vs 0.1)` 36 | 37 | `User had no retrasmits/invalids, using CB1, they determined it'd TTC when CB1 got above 70 degrees. Worked fine under 70.` 38 | 39 | `User had no retrasmits/invalids, would get TTC *sometimes* after print finished. They had 256 usteps on all motors, and in the end_print macro had a move in all X/y/Z planes at F20000. This would overload the system. ` 40 | 41 | 42 | `KAMP running at the printer.cfg max velocity (which it does by default) caused TTCs when user had max velocity set quite high (1k mm/s). Issue didn't show up when running Ellis test_speed macro though even at >1k mm/s. MAybe a combo of X,Y, and Z movement, or maybe extruder movement as well. Fixed by lowering printer.cfg max velocity, or changing the KAMP settings to use a lower travel_speed. 43 | They also observed this problem was more likely on short distances (IE smaller print). "I believe the acceleration to quick deceleration or transition from KAMP to actual print can cause this when moving at very very high speeds."` 44 | 45 | `I can't remember the specifics on this one, but a bad/dying SD card can definitely cause TTC errors as well as the base linux system starts freaking out/having errors and this extra load transferrs into messing with klipper` 46 | 47 | `Seemingly random TTC's, SD card was full` 48 | 49 | `TTC when Exclude Object was used on a large/complex model. Possibly the host overloaded trying to skip the bazillion lines of gcode` 50 | 51 | [Return to Troubleshooting](./) 52 | -------------------------------------------------------------------------------- /troubleshooting/tmc_reset_undervoltage.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: TMC Reset or Undervoltage 4 | parent: Troubleshooting 5 | --- 6 | 7 | # TMC reset or undervoltage error 8 | 9 | Rarely there can be errors coming from the TMC driver, along the lines of: 10 | 11 | `TMC 'extruder' reports GSTAT: 00000001 reset=1(Reset)` 12 | 13 | WHile this can be caused by a brief power interruption, it may *also* be caused by static discharge that has been accumulated on the filament feed and arcing in the motor coils which transfers to the TMC stepper driver. 14 | 15 | This can also manifest on the TMC2240 driver (as used on the BTT SB2240 toolhead board) as an `uv_cp=1(Undervoltage!)` error. 16 | 17 | Something easy to try to stop this static charge from building up and causing issues is to connect the extruder motor to a free GND pin on the toolhead board to help shunt any accumulated charge to the negative power rail. 18 | 19 | A simple ring terminal and nut on the motor mounting screw which then goes to any free ground pin is sufficient. 20 | 21 | ![image](https://github.com/user-attachments/assets/e48e5ad3-4ea5-4518-b424-d51a377c5729) 22 | 23 | **Please Note** this may not be the silver bullet to solve all your issues, but *if* the reset/undervoltage error is due to static buildup then this workaround has had good results. 24 | -------------------------------------------------------------------------------- /updating_can_speed.md: -------------------------------------------------------------------------------- 1 | --- 2 | layout: default 3 | title: Updating your CANBUS speed 4 | parent: Updating 5 | nav_order: 40 6 | --- 7 | 8 | # Updating your CANBUS Speed 9 | 10 | If you are trying to modify the speed of your existing CAN network then there is an order of operations to make it as seamless as possible. If you don't use this order then you can get in to a state where you need to hook things up with USB cables and flash them as if it was the first time again. 11 | 12 | **UNLESS YOU ARE CHANGING YOUR CANBUS SPEED YOU DON'T NEED TO USE THESE STEPS. FOR NORMAL UPDATING GO TO [TOOLHEAD UPDATING](./toolhead_klipper_updating.md) OR [MAINBOARD UPDATING](./mainboard_klipper_updating.md)** 13 | 14 | I am going to use the scenario of changing from a speed of 500K to a speed of 1M. The steps are slightly different depending on if you are using a dedicated CAN adapter (U2C/UTOC/etc) or if you are using a USB-CAN-BRIDGE Mainboard. Make sure to choose the proper steps for your setup. 15 | 16 | I'm also not going to go into each command to run, you can find the specific commmands in the main updating pages. 17 | 18 | # If you are running a dedicated CAN adapter (U2C/UTOC/etc) 19 | 20 | 1. Put your toolhead into katapult mode 21 | 2. Compile new katapult firmware (`make menuconfig` and `make`) with the new speed and make sure the "Build Katapult deployment application" option is enabled 22 | 3. Flash the katapult deployer.bin to your toolhead 23 | 24 | Once flashed we will no longer have access to your toolhead in Katapult mode. If your toolhead stays in katapult mode after flashing the deployer.bin just reboot the toolhead with the reset button (if it has one) or power cycle the printer. 25 | 26 | 4. Your toolhead should still boot into Klipper firmware fine at this stage(still with the old firmware) 27 | 5. Force the toolhead back into Katapult mode, either with a double-click of the reset button or with `python3 ~/katapult/scripts/flashtool.py -i can0 -u yourtoolheaduuid -r` 28 | 6. Temporarily change your CAN network speed by running `sudo ip link set can0 down type can` to drop the network and then `sudo ip link set can0 up type can bitrate 1000000` to bring it back up with your new desired speed. 29 | 7. Now with the CAN network temporarily at your new speed you should be able to see your toolhead again in katapult mode with a `python3 ~/katapult/scripts/flashtool.py -i can0 -q` If you can't see your toolhead with `application: katapult` then double-click the reset button on the toolhead until you can, or if your toolhead doesn't have that option you need to power cycle your whole printer then go back to step 5 30 | 8. If you can see your toolhead in katapult mode, you can `cd ~/klipper` and `make menuconfig` a new klipper firmware with your new speed, then Q to save and quit and `make` to compile, then flash this klipper.bin to your toolhead via katapult. 31 | 9. With both Katapult and Klipper flashed to your toolhead with your new speed, and your CAN interface still temporarily running at your new speed, you should be able to see your toolhead as normal in Klipper mode (either via a query or in your Mainsail/whatever GUI) 32 | 10. To permanently change your can0 network speed, go through the [Getting Started](./Getting_Started.md) instructions but using your new desired speed. 33 | 34 | 35 | # If you are running a USB-CAN-BRIDGE Mainboard 36 | 37 | 1. Put your toolhead into katapult mode 38 | 2. Compile new katapult firmware (`make menuconfig` and `make`) with the new speed and make sure the "Build Katapult deployment application" option is enabled 39 | 3. Flash the katapult deployer.bin to your toolhead 40 | 41 | Once flashed we will no longer have access to your toolhead in Katapult mode. If your toolhead stays in katapult mode after flashing the deployer.bin just reboot the toolhead with the reset button (if it has one) or power cycle the printer. 42 | 43 | 4. Your toolhead should still boot into Klipper firmware fine at this stage(still with the old firmware) 44 | 5. Force the toolhead back into Katapult mode, either with a double-click of the reset button or with `python3 ~/katapult/scripts/flashtool.py -i can0 -u yourtoolheaduuid -r` 45 | 46 | We are now going to update your usb-can-bridge mainboard. Note that you **do not** need to reflash the katapult on your mainboard as this Katapult talks to the Pi over USB and so doesn't care what the CANBUS speed is set to. 47 | 48 | 6. Put your Mainboard into katapult mode `python3 ~/katapult/scripts/flashtool.py -i can0 -u yourmainboarduuid -r` and confirm you can see it in katapult mode with `ls /dev/serial/by-id` 49 | 7. `cd ~/klipper` and `make menuconfig` and put the settings for your mainboard usb-can-bridge mode with the new speed selected. Q to save and quit, then `make` to compile 50 | 8. Flash the new klipper.bin to your mainboard with `python3 ~/katapult/scripts/flashtool.py -f ~/klipper/out/klipper.bin -d /dev/serial/by-id/usb-katapult_your_mainboard_usb_id` 51 | 9. Temporarily change your CAN network speed by running `sudo ip link set can0 down type can` to drop the network and then `sudo ip link set can0 up type can bitrate 1000000` to bring it back up with your new desired speed. 52 | 10. Run `python3 ~/katapult/scripts/flashtool.py -i can0 -q` and you should see your toolhead in katapult mode as your CAN network is now running on the new speed. 53 | 11. If you can see your toolhead in katapult mode, you can `cd ~/klipper` and `make menuconfig` a new klipper firmware with your new speed, then Q to save and quit and `make` to compile, then flash this klipper.bin to your toolhead via katapult. 54 | 12. To permanently change your can0 network speed, go through the [Getting Started](./Getting_Started.md) instructions but using your new desired speed. 55 | 56 | 57 | --------------------------------------------------------------------------------