PLR customization to Klipper causes move queue overflow error, shutdown, and print failure on small moves like organic supports and spiral z-hop

[evelant]

This is a critical bug in the stock firmware. Using spiral z-hop or printing some models with round shapes or organic supports is impossible as it will cause the SV08 to shutdown with "error 14 move queue overflow".

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!