Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis not needed Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there
Describe your issue:
Alright so I’m gonna try my best to write this in a way that makes any sense because I am very new to 3D printing let alone this entire situation. I have been following a mix of guides to replace the printhead on my SV06 Plus ACE with the print head from the Sovol Zero. I have finally gotten the print.cfg files to stop throwing errors but I have finally ran into an issue that I cannot fumble f**k my way out of and that is the Klipper version mismatch between the printhead and MCU. Sovol has not released a new Klipper version for this MCU in a while and i have noticed that there is not a mainline Klipper for this printer due to the HX711 load sensor and the funky way they went about coding it. I have removed said sensor as part of this upgrade as well as remove the “Smart_effector.py” but I don’t really know what to do from here. Any help would be greatly appreciated.
Wow, you’ve chosen a rough introduction to all this.
The first thing I noticed is you seem to be running (an OLD version) of mainline Klipper. Sovol cripples the log function but your log seems to be intact.
You could “downgrade” the extra_mcu by building new firmware to match your installed version of Klipper. If you wish to use Klipper’s build in eddy tap function you need to update the host to a newer version THEN build.
If I were you I would:
Use WinSCP to make a copy of your entire /home/sovol folder.
SSH into the printer and use KIAUH to uninstall everything it knows about. Obico first from the [Extensions] tab
Use WinSCP to delete everything in /home/sovol EXCEPT the kiauh folder.
SSH in and make sure you are in the right folder cd ~ Then run ./kiauh/kiauh.sh
Install Klipper, Moonraker and any other modules you want.
Now you are ready to build/flash current firmware for BOTH MCUs. You will need MCU models (I think both are STM32f103xx) and bootloader offset to build.
Once both MCU’s are updated you’ll have to debug your printer.cfg to match the mainline klipper functions.
Two quick things. I think it might be the other way around with the Extra_MCU being old and the standard MCU being v12. Would you still recommend wiping and rebuilding everything with that in mind or should I just update the printhead with katapult? Second, in a fun twist the original guide that I was using for this entire project stated that for my printer this upgrade was “Plug and Play” which is why I took it on as someone who was new to all of this. I have since learned that it was not, in fact, plug and play.
The extra_mcu is looking to match a Sovol version number (not aligned with klipper)
The easy route is build/flash the printhead but then you are locked into Sovol’s “eddy tap” or installing eddyNG.
Klipper now supports eddy tap as a probe method allowing you a 100% clean install with support available here. If you go the Sovol route you have a printer not supported by either Sovol or the Klipper community.
For me having a “one of a kind” printer with no OEM support makes a strong case to try and stay mainline.
Alright so quick update. I have finished doing as you recommended and have started going through and trying to fix all of the bugs but I am kinda stumped on this one. I can’t tell if I am missing something here or not but here is my log. Error is “gcode command QUERY_PROBE already registered”
Alright I’ll give that a try as soon as I get home. Another issue I am running into the is semi related is that I am now trying to flash the new clipper to the Extra_MCU using katapult and thus building the original menu config in my Klipper folder. Everything works as expected up until I run the make command where I am confronted with this:
Since this issue I have run ‘sudo apt install binutils-arm-none-eabi’ which it stated was already installed but I so.ehow didn’t have the entire package? I removed and reinstalled the package and somehow had even less even though I did have the storage for the entire package. I don’t know if this an I’m missing something issue or a problem with Debian Bullseye but thought I should ask for help.
Did you sudo apt update before installation? I’ve never seen that error so I can’t be much help. My guess would be a path error. The needed file is probably installed but [make] can’t find it.
I always build on my PC using Windows Subsystem for Linux (WSL). I also always launch makemenu from within KIAUH. AFAIK Your method SHOULD work.
The OP was already running mainline as of their first post. AND they had managed to connect with the Zero toolhead via CAN. The Ace toolhead is USB.
They are in the home stretch but need to combine the Ace and Zero configs then root out all Sovol’s calls to custom modules. Figuring out which macros interact with both MCUs and “fixing” them is no small task either.
The link @Blackstump posted is gold. Halfway through the instructions you’ll find
Sovol has a startup script to automatically remove the libraries libnew-arm-none-eabi and gcc-arm-none-eabi, which we will need later on so disable it:
Open the startup script with nano ~/printer_data/start.sh.
Put a hashtag in front of the two lines starting with nohup.
At the end, these lines should look something like this:
#nohup sudo apt-get remove --purge libnewlib-arm-none-eabi -y &
#nohup sudo apt remove --purge gcc-arm-none-eabi -y &
I don’t know why Sovol removes those packages at boot but it explains your build error.
I just went through and fixed that last night too specifically due to this weird decision by Sovol. I have to assume it’s to make it more difficult to mainline the printer but I don’t even know anymore. They also supposedly have a proprietary .sh file to flash the MCU that I’m going to try using when I get home from work today instead of buying an ST-Link and waiting even longer for the printer to work.
Alright sop quick update to everyone it turns out the only way to flash the MCU is with an ST-Link mini or equivalent. It may be possible to do so with the mcu_update.sh which is stored in the root folder however that program does not put the MCU into flash mode and I was unable to figure out a way to do so with the tools I had available. If someone else figures it out in the future please let me know because that would be a million times easier
After more shenanigans I have an update. I am now stuck here without a full understanding of what is really causing this issue. I can’t seem to figure out what I can remove or read in order to fix this issue and would greatly appreciate any help I can get
I am using the tool that came with the zero. I was able to complete the update using an ST-link v2 Mini which seems to have worked without any issues and then updated the tool with Katapult. now I am flashing the Virtual MCU with the newest klipper version to see if it will fix the probe issue I am having in the above Klippy.log
