Desperation. Klipper updates mayhem.

[Maurici]

So... today I've done a massive NOob mistake.

Had all my printers running, most of them asking for package updates. they have not been updated for a while.

My OCD forced me to click the update all button and now all my ptinters are out of comission

 

I'm reciving the following error in all of them:

 

I've managed to update the MCU in most of them... make menuconfig... and make flash or put SD. But I'm unable to update the MCU software in the RPI

The usual pull in putty and so are not working

I'm pretty sure If I build Klippers from scratch, it will all work. But I can't afford to do that. There is hours and hours of setting up printers CF, macros and all that I can't afford to lose. Also... I'm not sure I can be arsed to redo all my 4 klippers. Is there something I've missed? how do I update Klipper in the MCU?

 

 

Edit. Updated all boards and dissabled all RPI mcu in  RPI and now printers are working, but resonances and accelerometre can't work. So... same problem still. How do I update Klipper MCU in RPI...

Edit2:

Make menuconfig...

Linux process in the menu

 

Klipper stop

Make flash

Klipper start.

 

Yes, I'm dumb. Forgot I had a second MCU and this was basically a klipper flash running into linux.

 

Friday morning eh?

 

Well. lets leave it live, so someone dumb as me can find the answer without having a mini stroke...

 

 

Edited January 26 by Maurici

[claudermilk]

I'm currently avoiding updating my Trident for now because I am certain I'll run into this myself & finally have to update the Octopus.

You should be able to access your config files directly by SSH into the Pi and just copying the files. That will preserve all the hours invested in setting up macros. FYI, that's a big part of why I have my printers back up to GitHub.

[Maurici]

2 hours ago, claudermilk said:

I'm currently avoiding updating my Trident for now because I am certain I'll run into this myself & finally have to update the Octopus.

You should be able to access your config files directly by SSH into the Pi and just copying the files. That will preserve all the hours invested in setting up macros. FYI, that's a big part of why I have my printers back up to GitHub.

well now that you know that is as simple as a makemenuconfig... you are golden!

[Penatr8tor]

9 hours ago, Maurici said:

Edit2:

Make menuconfig...

Linux process in the menu

Klipper stop

Make flash

Klipper start.

Yes, I'm dumb. Forgot I had a second MCU and this was basically a klipper flash running into linux.

Friday morning eh?

Well. lets leave it live, so someone dumb as me can find the answer without having a mini stroke...

Just curious and it may also help dumb people like myself...

Which of the items above are commands and which of them are comments from you?

For example... Is "Klipper Stop" a command? Is "Linux process in the menu" a comment? Etc.

maybe make the commands italic so we know which is which.

Just a suggestion really.

[cjkennedy72]

To Update RPi MCU:
first SSH into your RPi. The following should be copy/paste...

 

sudo systemctl stop klipper

This will stop the klipper service on your RPi.
 

cd ~/klipper
make clean
make menuconfig

Select Q and Save changes.
 

make flash

sudo systemctl daemon-reload
sudo systemctl restart klipper

 

Hopefully someone finds this helpful.... 

I know I am not the author, but was bored @Penatr8tor so I thought I would take care of your suggestions.  Really not meant as snarky or mean-spirited (disclaimer due to nature of text based comms).

 

[Penatr8tor]

1 minute ago, cjkennedy72 said:

I know I am not the author, but was bored @Penatr8tor so I thought I would take care of your suggestions.  Really not meant as snarky or mean-spirited (disclaimer due to nature of text based comms).

@cjkennedy72 Thank you.

I'm not familiar enough to just figure out the pi command line so, what you posted is exactly what I would need (and others at my level) to fix this error. No offense taken at all... Only gratitude. 

[Maurici]

11 hours ago, cjkennedy72 said:

To Update RPi MCU:
first SSH into your RPi. The following should be copy/paste...

 

sudo systemctl stop klipper

This will stop the klipper service on your RPi.
 

cd ~/klipper
make clean
make menuconfig

Select Q and Save changes.
 

make flash

sudo systemctl daemon-reload
sudo systemctl restart klipper

Hopefully someone finds this helpful.... 

I know I am not the author, but was bored @Penatr8tor so I thought I would take care of your suggestions.  Really not meant as snarky or mean-spirited (disclaimer due to nature of text based comms).

My command line is by no means that long nor complicated... But I'm pretty sure that works too!

[cjkennedy72]

All good...

The only thing I have in there that you do not do is to clean up the build environment with 'make clean' and the command to have services re-read their config files with 'sudo systemctl daemon-reload'. 

I don't see how any other steps could be removed... any other solution could fall under the usual linux debates like... should the 'root' user be used instead of sudo, systemctl versus service or init.d, and other semantics. Regardless, glad you got yours flashed and everything is working for you.

[Maurici]

Yeah. Those.

Im nobody to discuss about linux command line... In unable to do anything if is not with a tutorial by my side.

Left MSDOS when i still was a kid, a never enjoyed command line. I love clicking on buttons and icons

Edited January 27 by Maurici

[cjkennedy72]

Just shows the diversity of the people who find 3d Printing and building 3d Printers interesting and I welcome it. I think it is great that something that is deeply tied to software, and hardware, and is very complex can be accessible to people who don't have deep backgrounds in those areas. Great Stuff!!!

I am always happy to help with technical questions here, but ironically I refuse to fix friends' and family's computers or internet, printers, you name it... 
It just happens that my chosen profession requires me to have a good handle on CLI and Linux. 

[Maurici]

44 minutes ago, cjkennedy72 said:

Just shows the diversity of the people who find 3d Printing and building 3d Printers interesting and I welcome it. I think it is great that something that is deeply tied to software, and hardware, and is very complex can be accessible to people who don't have deep backgrounds in those areas. Great Stuff!!!

I am always happy to help with technical questions here, but ironically I refuse to fix friends' and family's computers or internet, printers, you name it... 
It just happens that my chosen profession requires me to have a good handle on CLI and Linux. 

Don't get me wrong, im an automotive engineer, mechanical stuff is my thing, and lately due my line of work, flashing ecus, eproms, modifying attribute lables and so is in my toolbox. However ones brain has limited capacity(mines does) i may have flashed klipper 15 or 20 times. And while im able to navigate in the printer config file practially on my onw, the linux bit is the stuff i just need help with. Same with arduino... That i use very often for work to test controle modules without spending millions in unlocked ECUS... I would be nothing without the basic tutorials available in the net... Between 1 project to the other i manage to completely forget how to compile a simple signal input in arduino. I guess software is definitely not my thing,

[mvdveer]

Just for info:

Updated 10 printers to klipper v.0.12.0-102.  

Seven (7) of those had canbus installed, (5 x SB20240 and 2 x SHT36) All 7 running Octopus v1.1 F446 chips. Got the MCU error as described in this post, but flashing the CanBoards and Octopus boards went without a hitch - and I did not have to touch the electronics bay at all. Flashed the canbus boards via their UUID's with the python script and the Octopus boards over USB. (Used kiauh - just much less effort) All printers except one uses the octopus board as canbus communication bridge. The VZBOT has an Octopus Pro board, where I could not get the canbus bridge to work, so I have the canbus going through a UTOC 1 board. (This had no effect on flashing the Octopus or the SHT36)

Three (3) printers were old school (3 x V0 variants), no canbus and surprisingly - no mcu errors. I decided to flash the boards with the latest firmware none the less (both Octopus F446 boards flashed via USB). However the SKR 1.4 I had in the very first voron I build (V0.1) did not flash over USB - will have to open the electronics bay if I want to do this, but the printer is happily running on V.0.12 of klipper with a flashed mcu of v0.10 without any errors.

Took me about 5 min per printer.

Input shaper still works without any complaints. Did not have to disable anything in the printer.cfg file

So, whilst it may sound daunting upgrading and re-flahing firmware, it really is not. 

 

[claudermilk]

8 hours ago, mvdveer said:

Just for info:

Updated 10 printers to klipper v.0.12.0-102.  

<snip>

Three (3) printers were old school (3 x V0 variants), no canbus and surprisingly - no mcu errors. I decided to flash the boards with the latest firmware none the less (both Octopus F446 boards flashed via USB). However the SKR 1.4 I had in the very first voron I build (V0.1) did not flash over USB - will have to open the electronics bay if I want to do this, but the printer is happily running on V.0.12 of klipper with a flashed mcu of v0.10 without any errors.

Hmm...so the non-CANbus Octopus 446 boards were happy with the latest Klipper update? No flash needed? If so that reduces my reluctance to update. Of course I have some print jobs I want to get cleared off my queue before trying to really break the printer.

[mvdveer]

6 hours ago, claudermilk said:

the non-CANbus Octopus 446 boards were happy with the latest Klipper update?

That was my experience yes.  Those three printed don't have a build in ADXL either but uses an external USB accelerometer that I attach to the rasps when needed. The mcc section of this was commented out on all three prior to updating. (Otherwise if not connected you get the blue Klipper screen)  Just as a control, I uncommented my [adxl mcu] and the error came up on the happily flashed machines. It went away after I did a linux flash. Blue screen appeared but as soon as I connected the accelerometer, Klipper was happy.

So if you have a beacon probe, or accelerometer that is ALWAYS connected, then the error will still present and you need to do a Linux process - make flash, as described earlier.

[NikosSprocket]

I do not know at which stage you are at the moment but if you still have the older version you may able to upgrade it manually from the linux prompt and not the Mainsail GUI.

1. Upgrade the OS as follows:
2. $ sudo su - (be careful from this point as you are root and all safeties are o!)
3. # apt update
4. # apt upgrade
5. # reboot
6. Follow instructions from Manual Update

I hope this will work for you. Remember to run "sudo reboot" every-time you finish an update.

[DennisM]

So I've seen threads like this and have been following some of them. I have a general question here. I have a Voron 2.4 and was in the process of building a 0.2 at the end of last year, and due to health reasons I had to stop all 3D activity for a few months.

Now that I'm about to get back into things I know the printer is going to show me that it needs updates. To be safe, is there a standard procedure that folks have been using to update Klipper and maybe the Octopus and/or Pi firmware? I see cjkennedy72 posted some steps above, and mvdveer mentions it should take 5 minutes.

I was wondering if there's a more appropriate set of instructions we should follow to process the necessary updates?

Thanks in advance!

Dennis

 

[Penatr8tor]

@DennisM I think the standard procedure is to update everything. If everything works you move on. If you get an error message, you then take a valium and start searching the web for a fix. When you eventually find one and get it working again. You move on to stage 2 denial and watch and wait to see if anyone has an issue before upgrading again. 

[claudermilk]

On 1/29/2024 at 1:21 PM, mvdveer said:

That was my experience yes.  Those three printed don't have a build in ADXL either but uses an external USB accelerometer that I attach to the rasps when needed. The mcc section of this was commented out on all three prior to updating. (Otherwise if not connected you get the blue Klipper screen)  Just as a control, I uncommented my [adxl mcu] and the error came up on the happily flashed machines. It went away after I did a linux flash. Blue screen appeared but as soon as I connected the accelerometer, Klipper was happy.

So if you have a beacon probe, or accelerometer that is ALWAYS connected, then the error will still present and you need to do a Linux process - make flash, as described earlier.

Cool, sounds like I'm good to update then. I have an old-school generic ADXL that connects to the Pi via GPIO. Long before any of these fancy-schmancy permanent USB connected ones. I'll remember to comment out the accelerometer mcu section before updating.

[mvdveer]

@DennisM - welcome back and I trust your health has improved. I will try and give a step wise approach. This is for a system with a Raspi Pi, BTT Octopus Pro controller board, SHT36/SB2040 Canbus and beacon probe. It also assumes you have katapult/Canboot installed on the devices.

Process:

1. Update Klipper in mainsail as you would. If you do not get an error then all is well. Happy Printing.

If you get an error (have a canbus board attached, a permanent ADXL attached, a Beacon probe attached, etc) then:

2. ssh into the Raspi pi 

ssh [email protected]

3. change to your Klipper directory

cd ~/klipper

4. Depending on how many devices you need to flash, the following may differ. I will describe my process in having to flash 3 different mcu's (Octopus Pro, Canbus toolhead (sb2040/SHT36) and Linux process).

make menuconfig

5. Enter the parameters for your canbus board you used to initially flashed the board.- be sure to double check because if you don't, you will have to reset the canbus board . 

a. Below is for Mellow Fly SHT36 Canbus boards:

b. Press Q to quit and Y to save configuration.

6. Compile the firmware

make -j4

7. Get the UUID for your canbus board from your printer.cfg file - write it down or as I do copy and paste it into notepad, textedit, etc

8. change into your katapult or Canboot directory

cd ~/katapult

or

cd~/Canboot

9. Flash the SHT36 or whichever canbus board you have:

python3 ~/klipper/lib/canboot/flash_can.py -u {insert your UUID here}

e.g.

python3 ~/klipper/lib/canboot/flash_can.py -u 365f54003b9d

10. Change back to the kiauh directory to compile and flash the firmware for the octopus board

cd ~/kiauh
./kiauh.sh

11. kiauh may want to update itself. Allow this to happen and restart kiauh.

12. Choose the advance option, choose build and flash.

13. compile the firmware for the controller board. In my case - Octopus v1.1 with a F446 chip.

For other Octopus board configurations, see here

14. Press Q and Y. You will be asked how to flash the board. Choose 1 (Regular flashing method)

15. You will be asked again how to flash the mcu - Choose 1 (This should already be selected)

16. Choose the method of connection. Choose the option to show your connection. In my case 1 for USB. kiauh will then search for the mcu's connected.

Make sure you choose the CORRECT MCU. 

kiauh should now flash the controller board with the compiled firmware. You can now exit kiauh.

17. Time to flash the linux kernel, so change back to the Klipper directory

cd ~/klipper

18. Stop Klipper if it is running

sudo systemctl stop klipper

19. Compile the firmware for Linux process

make menuconfig

 

20. Press Q and Y to compile.

21. Make this firmware available to the system

make flash

22. Restart the Klipper service

sudo systemctl daemon-reload
sudo systemctl restart klipper

23. Reboot and restart everything - Away you go printing

Hope this helps

 

[Dirk]

@mvdveer this is a very lengthy(only 5 minutes) taking process.

Because we are using a program(klipper) that was meant to run on the printer computer(RPi). But now we also have this program on every piece of can board we add. Because every such board again has a chip, which needs a different klipper ..

And worse of all is, these can boards are proliferative. Every Chinese company in printers, produces one.

As if all is not enough, we also need to run this klipper on a seperate board or as a bridge.

I really love the idea and practicality of CAN.

But to me it looks as klipper is outdated to run CAN. A new version? That handles all this senseless updating all by itself?

I have bought several can boards to try out. But am very reluctant to do so.

My Voron 2.4, without any can or beacon or idm or anything else yet( stock), also showed these new updates. 

As usual I pushed the update button and everything was updated without problems.

I will continue using 24 cables to the stealthburner, I think .. and wait until there is a major klipper update..

This reminds me of Windows 3.1 on top of DOS... For every piece of hardware we wanted to install, we needed a floppy disk with drivers. Until windows 95 came along...

 

[mvdveer]

18 minutes ago, Dirk said:

this is a very lengthy(only 5 minutes) taking process.

What can I say - I updated 10 printers in less than an hour. Some users may take longer,  I can only give you my experience and this may not be relevant or true for others.

[aju3169]

I had the same problem but my printers are on canboot - octopus MAX EZ and the other octopus PRO 723.  Both have EBB36 MCU on the toolheads.  I backed up my config files first my SSH to the PI (actually I used WINSCP to copy the files to my PC).  I needed to wipe and flash all the MCU's with the new version of canboot which is now called katapult.  Then I re-installed klipper as above.   It was a real pain and took a whole weekend stuffing around.  Apparently the katapult CANBUS improves the communication when using bridge mode on the octopus boards.   Anyway, I will not update the printers now as they are working fine.  I will only update if needed for features, bugs, etc.  and with he expectation (and time) to repeat the above process.

[Maurici]

Eff me. 

Everytime i see 16 wires going to my toolheads... I think i coul do with less faff and move to can. Then i read the above and I'm so happy with my "analog stone aged", printers...

 

Not that long ago i was doing miracles with an ender with bowden tube... Now i want to add canbus to the head? Fxxck that.

Edited January 31 by Maurici

[Penatr8tor]

@Maurici +1, and also why I haven't moved to CAN. Maybe something better comes along, or it becomes more idiot friendly...  IDK but until then, I'll take a pass on the CAN implementation.

[Dirk]

7 minutes ago, Penatr8tor said:

Maybe something better comes along

Klipper '95