We purchased this printer a little over a month or so and I’ve gotten only one full print from it. After that it has been one error after another. I’m not sure what’s going on and I could use some guidence. From homing x error, unable to obtain probe eddy current sensor readings, gcode macro, but the main one that seems to pop up is MCU or extra MCU communication failure between micro controller and host. I added ferrite beads to the usb cable and that seemed to help a little and get it going, but about 80 to 90% into the print it will error out. Any help is appreciated.
First off welcome to the user forum.
Second. this is not Sovol support. If you don’t have an open support ticket then email info@sovol3d.com and get one started. Be sure to include your order number and a picture of your serial number sticker.
Now for your errors. You seem to be having intermittent communication issues with the toolhead control board. Locate the CANL and CANH wires at the toolhead and mainboard. Inspect for bad crimps, terminals not properly inserted into connector body and connector not fully seated.
Mainboard
Toolhead
Nothing obvious. The crimps are not as clean as they could be, The "upper crimp should be tight against the insulation with the points driven into the insulation. It is almost as if the terminals are for larger wire. @sovol3d
If I was you I’d unplug the wires, dig out the glue, release the terminals from the connector and inspect the “lower” crimp where the conductor is actually crimped.
The other thing you could do is SSH in to the host computer (imbedded in the main board) and examine the error logs. The CAN bus is actually managed by Linux at the OS level. I don’t know the exact path/filename. Google is your friend here.
@lion has a good point. The toolhead will loose connection without a stable 24v supply.
I was able to get the wires out and most of the glue with a little work. The wires and connections didn’t look bad, if any the black one inbetween the white and green looked a little suspect. After plugging everything back in and starting it up I went to calibrate and immediately had an internal error pop up. Then the words disappeared and it just has a box that says “sure”.
Do you have access to the web UI on the [Device] tab in Orca? The console there is should have more information than the knobscreen. Download klipper.log to your PC and upload (zipped) here.
klippy.zip (783.4 KB)
I have an internal error code of “G0”
G0 is a core g-code command. That it flags an error (along with machine history) indicates major corruption of the file system on the EMMC.
The correct path forward is to re-image the EMMC from the recovery file. Requires use of a USB dongle.
If you want to “repair” in place via SSH terminal session click below and “talk” to Claud.
Ok I reflashed the EMMC with the latest firmware and I’m still getting the internal error “G0” no matter what I try to do.
Check the wiring to the buffer, Especially the power side.
Your G0 based error is a result of Sovol’s code not handling a buffer MCU reset correctly.
Your buffer_MCU is resetting constantly, probably every time it tries to power up the motor.
Sorry for the miss direction. @sovol3d The error you flagged (G0) has nothing to do with the buffer except a MCU reset causes a illegal call in gcode_move.py. The correct error in the log would make the fix much easier.
Here are the Klippy log and console files.
Klippy_Log_7_28_26.zip (942.5 KB)
Console_7_28_26.zip (895 Bytes)
Ok so I just reflashed again to make sure and this time the g0 error went away. Now a homing x error is showing.
Klippy_and_Console.zip (1013.2 KB)
It sounds as if your EMMC has bad sectors. The image write puts every file in the exact same location. Your old log and new log both point to gcode_move.py. That the same file gets corrupted over and over is suspicious.
Ask Sovol for a new EMMC OR upgrade to a 32.GB one from Amazon. If you upgrade you’ll have to expand the file system in a ssh terminal as the image will copy the partition table for the 16 GB
Things you can try while waiting on the EMMC.
Step 1: Check the filesystem for errors (read-only, safe)
Open an SSH session (PuTTY, or WinSCP’s built-in terminal if you have that enabled) and log in the same way you do for WinSCP.
Find which partition the root filesystem lives on:
mount | grep " / "
That’ll show something like /dev/mmcblk0p2 on / type ext4 (rw,...). Note that device name (mmcblk0p2 or whatever it says).
Since the filesystem is mounted and in active use, we can’t do a full fsck safely without rebooting to a rescue environment — but a read-only pass is still informative and won’t make anything worse:
sudo fsck -n /dev/mmcblk0p2
(swap in whatever device name you found above)
What to look for: Any lines mentioning “bad blocks,” “inode,” “UNATTACHED,” or errors it wants to fix. If it comes back clean with no complaints, that’s a good sign but not 100% conclusive since the filesystem is live/mounted during the check. If it flags problems, stop here and let me know — that alone may be enough to justify an RMA without going further.
Step 2: File swap test (only if Step 1 comes back clean)
This tests whether a freshly written copy of the broken file corrupts again, which tells us whether the problem is specific to how the recovery image gets flashed, or something wrong with the storage chip itself no matter how the file gets there.
- I’ll send you a known-good
gcode_move.py— save it somewhere on your PC you’ll remember (e.g. Desktop). - Open WinSCP and connect to the printer like normal.
- Navigate to:
/home/sovol/klipper/klippy/extras/ - Right-click
gcode_move.py→ Rename → change it togcode_move.py.old(this keeps the broken original around in case we need to compare it later — don’t delete it). - Drag the fresh
gcode_move.pyI sent you from your PC into that sameextrasfolder. - Back in your SSH terminal, run this to get a fingerprint of the file right after copying it:
md5sum /home/sovol/klipper/klippy/extras/gcode_move.py
Save that output somewhere (screenshot or copy/paste it).
7. Restart Klipper — either through Mainsail/Fluidd’s restart button, or:
sudo systemctl restart klipper
- Try homing (
G28) and jogging (anyG0move) from the web interface. If it crashes with the same"G0"internal error, screenshot it. - Don’t power cycle the printer yet. Leave it running for a while — an hour or more if you can — then run the same
md5sumcommand again:
md5sum /home/sovol/klipper/klippy/extras/gcode_move.py
If the two md5sum outputs from steps 6 and 9 don’t match, the file changed on its own with no reflash involved — that’s a strong hardware signal on its own.
What the results mean:
- Fresh file works, checksums match, no crash → the eMMC itself is probably fine; something specific to the image-flashing process is the culprit. Worth reporting to Sovol as a flashing/recovery-image issue.
gcode_move.py (15.9 KB)
Ok. Step 1 came back clean.
Step 2 the file swap matched.
I’m not getting the “g0” error anymore. I am getting “error during homing x; Communication timeout during homing”.
Please upload a current log file.
klippy_7_29_26.zip (65.0 KB)
Good news/ Bad news.
Good news is that gcode_move.py is no longer involved in the errors you are getting. That (more or less) confirms that your EMMC has bad sectors. Forcing gcode_move.py to a different sector on the EMMC seems to have overcome the corruption of that file.
Bad news - New error is CAN communication issue with the “extra_MCU” (toolhead). Inspect both ends of the umbilical going to the toolhead for connection issues. If you have a miltimeter unplug the printer from the wall and measure resistance from CANh to CANl. That’s the 2 ends of the 3 pin connector circled below. Measure with the wires plugged in. Should be 59-61 Ohms.
I’d still replace the EMMC. There is no remotely easy way to know what other files may be written to suspect areas on the EMMC. There could be other files corrupted that haven’t been read yet. More cryptic errors are likely to pop up later.
Well I checked the wires the best I know how. I checked them individually and to each board. This is what I measured, if I’m not checking what you asked let me know.
I unplugged the wires at the back and checked separatly at first.
Main board wire: G - .2, B - .2, W -.4
Tool head wire: G - 1.8, B - .4, W - 12.3
Both wires connected plugged into the tool head: W&G - 170
Both wires connected plugged into the main board: W&G - 178