Shutdown mid print - "MCU shutdown: Move queue overflow"

Sovol SV06 ACE
1

Print was sliced in Orca, and was printing along just fine. I’ve printed this particular gcode file twice before with no problems, but this time it made it about 15 layers in or so and I heard the fan shut off. Walked into the room to see that error on the screen and the printer stopped and demanding I reboot it.

Is this something that’s going to keep happening? Is it something wrong with the printer, or something I can fix on my end?

2

Were you printing a round object…??

This post is from FlashForge but it’s still Klipper Based.

https://www.reddit.com/r/FlashForge/comments/1agosli/move_queue_overflow_error_on_5m_pro/?rdt=37581

3

I get that same error sometimes and would like to know how to fix it. Most of the times I see it, is after I’ve used the “exclude object” feature, but not always.

4

Ive been having the same issue intermittently.

I think you are correct with the exclude object behavior, ill have to track it more closely but that follows with what i remember.

5

I also got the error after pausing the printer, excluding an object, then trying to resume. Been meaning to ask the correct procedure for how to exclude an object without this happening

6

Sorry to necro this, but I’ve also been dealing with this problem on specific models, particularly ones with smaller circular features, or using tree supports/Arachne wall generation on round-ish models.

I did try the Reddit link Lion posted, but since the ACE doesn’t have a power recovery feature, klipper did not recognize the command and threw an error.

I don’t use the exclude object feature very often at all, and I haven’t seen this error happen during that. Mainly on models with circular/round/concentric features. Sometimes fiddling with the slicer settings, particularly changing infill or wall generation, can help, but it’s not consistent. Has anyone here had any success mitigating it?

7

Are you using arc fitting? I also found that if my resolution was too low it caused errors on circular/jagged solid infill. I had issues at 0.1 but haven’t had any at 0.15

8

Hello!

No, I have arc fitting disabled.

The problem has been very inconsistent lately. Today it happened when I was printing a model at 0.28mm layer height which I had already printed successfully on this machine with the same infill/other settings, but at a 0.2mm layer height. Oddly in this case, the error happened once all but the tallest objects (one cylindrical and one torus-shaped) had been completed, so each layer should have had fewer instructions than the previous layer. And the “circularity” of the previous layers would be the same.

I’m not sure how to narrow down what is causing it, as I’ve seen the error at a variety of model scales, layer heights, etc.

I had a different model where it printed fine at a small size, got the MCU overflow if I scaled it up by 50%, then printed fine again if I scaled it up further to 100% total.

¯\(ツ)/¯

Edit: Looking closely at the slicer settings, it may be related to layer time, as that’s the only parameter which I can see changing once the other objects have finished.

9

This is about the K1, but it talks about round objects & Arc.

10

I have an SV08, not an SV06 ACE but I was having the move queue overflow problem a lot. I figured out how to fix it, it’s probably similar for the SV06.

For anybody else who gets stuck with this error I found the root cause and 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.

At least for the SV08 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 on SV08 (other Sovol printers probably have similar code), 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.

1 Like