I’ve had my SV08 for about a month now and this issue keeps cropping up, and its cost me several KG’s of filament at this point. Initially I thought I was just a problem with fuzzy skin in OrcaSlicer, or exclude object, and no matter which configuration I used it always failed mid-print, so I’ve abandoned these options completely. More recently I am now getting this same issue with concentric top layer fill pattern - but the issue is inconsistent, the same gcode may or may not finish successfully
I’m printing with a 0.6mm Nozzle at 0.2mm layer heights, 3500mm/s^2 accelerations, 100mm/s print speeds; all in an effort to reduce the number of times I get the MCU shutdown, which has helped in general, but still not with the issues mentioned above.
I’ve seen a few other posts about this issue, but without any solid fixes other than avoiding exclude object/fuzzy skin. I’m just wondering if anybody else has experienced this issue here, and any advice?
I’m not quite sure what would count as extra code, but I have made a couple of changes to the printer.cfg and macro.cfg, mainly for some neopixels attached to the toolhead.
pin: extra_mcu:PA10 # replace with the actual pin for your UART TX
chain_count: 3 # number of LEDs in your strip
color_order: GRBW # most Neopixels are GRB, check yours
initial_RED: 0.3
initial_GREEN: 0.3
initial_BLUE: 0.3
initial_WHITE: 1.0
I’ll give it a go see if it fixes the issues, and update here with any progress - for some reason it seems the problem is manifesting and now I can’t complete a single print without shutdown, no matter my slicer settings.
These generate a HUGE number of very small moves that have to be Queued and transmitted very quickly. Is your slicer sending “arcs” (G2-G3 - Arc or Circle Move) which Klipper has to split and calculate?
The queue overflow is a problem with the HOST computer. Set your runtime speed modifier to 50%. Does the error continue to happen?
There are Linux tools to monitor Processor and memory loads. I’ve never had to use them but they might identify the process that is using too many resources.
If I had the issues you are experiencing I would reflash the OS on the mainboard.
If I reduce the speed it’ll definitely get further into the print, and may complete some models not possible otherwise. If I’m desperate for something, I’ll print at 40 - 50mm/s, but not guaranteed to complete.
For anything with fuzzy skin, it’s a crash on the first layer no matter what speed.
For anybody else who gets stuck with this error I found the root cause and figured out how to fix it. The problem is Sovol’s PLR (power loss recovery) customization to Klipper. This is why moving to mainline Klipper fixes it, because that removes Sovol’s PLR customization. It’s pretty easy to fix on the Sovol firmware now that we know what’s causing it.
The problem is in ~/klipper/klippy/extras/gcode_move.py Lines 123-133. These lines write information to a file on the sd card synchronously on every single move command. That’s too slow, especially for python on a relatively constrained host. It causes moves to be processed too slowly when there’s a lot of short moves, the host fails to communicate with the mcu fast enough resulting in the move queue overflow error.
To fix it, ssh into the printer and simply comment out these lines in ~/klipper/klippy/extras/gcode_move.py
if 'G' in params and 'Z' in params and 'X' in params and 'Y' in params and 'F' in params:
if self.v_sd.cmd_from_sd:
#commandline = gcmd.get_commandline()
content = {
'commandline': gcmd.get_commandline(),
'Z': params['Z'],
'extrude_type': 'M82' if self.absolute_extrude else 'M83',
'e_extrude_abs': 0 #self.Coord(*self.move_position)[3]
}
with open("/home/sovol/sovol_plr_height", 'w') as height:
json.dump(content, height)
PLR will obviously no longer work, but it never worked well to begin with and failed every single time when the move queue overflow happened since it was the writing of plr info causing the failure. Hopefully Sovol fixes this in an official firmware update. It was hard to track down but in hindsight it’s a pretty obvious huge flaw in the PLR design – there’s no way that writing to a file synchronously with every move command is going to work reliably.
Now I can print as fast as I want with spiral z-hop and organic supports, no more problems!
No. Commenting out the plr include in printer.cfg will not stop the python code from writing to the sd card on every move command. In fact that was one of the first things I tried – it only removes some macros but doesn’t affect the actual cause of the problem. The only way to fix it is to comment out those ~10 lines in gcode_move.py.
The code in my gcode_move.py is a little different. I commented out the lines of code that were similar. It worked! I had a print that failed at least half a dozen times with this error. I just had a successful print with the code change.
Glad it helped! It’s quite a bad bug in the firmware. I emailed Sovol about it and they said they’d “pass it on to their engineering team” so who knows if we’ll ever get a firmware with PLR that doesn’t cause prints to fail.
