MCU 'mcu' shutdown: Move queue overflow

[clutchkick512]

Is there an existing issue for this problem?

• [x] I have searched the existing issues

OrcaSlicer Version

2.3.0-beta2

Operating System (OS)

Windows

OS Version

windows 11

Additional system information

cpu-13700k, 64gb ram,rtx 4080

Printer

k1

How to reproduce

load up any round object, slice with archane walls and print.

Actual results

I have been able to repeate the failure 3 times in a row with cylinders about 65mm wide and 100mm tall. near the 85mm mark the printer has the MCU 'mcu' shutdown: Move queue overflow error and stops klipper.

Expected results

the file should print without issue.

Project file & Debug log uploads

I am unable to provide this as it is a paid file.

Checklist of files to include

• [ ] Log file
• [ ] Project file

Anything else?

I am a support mod for the k1 software SimpleAF and have had at least 1 other user on the beta report the same issue. In my case turning wall generation to classic and disabling arc fitting resolved the issue. I beleive the exported gcode files may be too large for the k1 memory but on the latest stable release it is not an issue at all. I have rolled back to the stable as has the other discord member of SimpleAF and fixed the issue with that.

[igiannakas]

Try adding the below in your start g-code: M413 S0

This disables power loss recovery which places significant compute load on the K1 CPU.

Also you MUST disable arc fitting for the K1 and all klipper machines as they are not using these commands natively - instead they convert them internally back into line segments. This results in both a worse print quality and also increased CPU load.

Also make sure you have verbose g-code output set to disabled in Orca.

Finally do not use the extrusion rate smoothing feature as this generates smaller line segments to enable gradual slow downs and speed ups. While not being able to use this will affect overhang quality, if the printer cannot cope with the gcode load, then it's best disabled. However, optimisations in 2.3 have been also done for this feature: https://github.com/SoftFever/OrcaSlicer/pull/7398

A more drastic way is to also reduce the precision -> resolution setting but again this may affect print quality if you go too high.

The issue stems from the fact that the CPU used by creality is too slow to keep up with the speed the printer is commanding it to go.

There have been several fixes already in 2.2 and 2.3 to reduce gcode size and optimise it, especially for overhangs (eg: https://github.com/SoftFever/OrcaSlicer/pull/6714), but there is only so much that can be done.

[clutchkick512]

Interesting, so just for notes SimpleAF doesn’t have the power loss recovery already because of the CPU load.

Disabling arc fitting- does this also change spiral z hop back to normal or slope? That’s about the only real arc fitting feature I use.

[igiannakas]

There are two places where arcs are used.

1. Arc fitting in the quality tab. This creates arcs for extrusion moves (ie printing). This should be disabled.
2. spiral Z hop: this creates arcs for non printing moves (travel). These can be enabled on a klipper machine (and should be to be honest as the quality benefit is significant).

My recommendation is to leave spiral z on and arc fitting off. However if your printer cannot cope with the spiral z speed you can increase the arc segment in klipper itself (not sure if the creality machine allows you to have access to the printer cfg) or simply use slope z hop.

Hope this helps!

[github-actions[bot]]

Orca bot: this issue is stale because it has been open for 90 days with no activity.

[github-actions[bot]]

Orca bot: This issue was closed because it has been inactive for 7 days since being marked as stale.

[stevenwalton]

I'm facing this issue too. I get it when doing a 2 stack 6x6 multiboard print. It fails exactly when the second one begins printing. (EDIT: printing a single 6x6 the print fails at 94%) I'm always left with just a little glob. I am unable to recover the print, but at least it doesn't leave me with a ruined print.

I've tried adding M413 S0 under my Filament settings and this had no effect. I never had Arc fitting enabled (Quality > Precision), so that doesn't seem to be the issue either.

Through some reading Redditors are suggesting this is due to a buffering issue? I find that interesting as when stack printing there is an ironing layer so it is going pretty slow. Is my intuition wrong in that this should also be giving more time to clear out the buffer? FlashForge doesn't have the best code so I wouldn't be surprised if this is part of it but if anyone has some insights to help me debug I would appreciate it.

Given that this happens during stacked printing and it fails at the second stack, I'm wondering if there is something OrcaSlicer can do here. FWIW, I've successfully printed a 2x2x2 version no problem, only facing the issue when doing a 6x6x2.

Facing on FlashForge Adventure 5M OrcaSlicer 2.3.0 Machine: Macbook Air (M2) Sequoia 15.5 failing gcode: 6x6x2.gcode.zip

[dingausmwald]

Same here, Creality k1.

M413 S0 has no effect.

Does seem to happen in areas with alot of tree support/spirale z hop.

Like this:

option to use spirale only on print, not on supports would help i think arcs disabled, resolution at 0,036, about 60.000 polygons. Still, mcu at 2.0 all the time, crashing at around 2 hours in print. Sculpture with alot of round shapes

[Brakisshuro]

Having the same issue, have a 3mf that fails almost exactly at same point everytime (line 211 or so) with a MCU overflow. Tested 10 times and 10 out of 10 it fails. Arc is not enabled, resolution is .012 (which is fine except for this) verbose is disabled and I am using classic walls as a try with not difference. It is failing when building supports on base for stomach of model.

[bpengu1n]

I'm having this come up as well on a print with many circles. If I reduce the number of those objects (from 18 to 9 oval pieces with approx 6 circles each), I don't get the failure. I thought it might be an issue with my printer (Sovol SV08), but after following their procedure to fix I still have this issue.

Not seeing any resource constraints on printer around time of crash. Arcs disabled, resolution .012, but increasing doesn't seem to resolve the issue, nor does disabling verbose gcode

[evelant]

@bpengu1n I'm having the same issue on an SV08. Did you ever get it figured out?

[igiannakas]

Depending on which version of orca you’re using, you should reduce arc fitting resolution (increase the number in the printer cfg.).

If that doesn’t work, you’ll need to reduce print & travel speeds.

[bpengu1n]

There are a number of things that could cause this, but the fix in my case was to modify one of the Klipper core files, mcu.py, and change the MCU comm timeout from 0.025 to 0.05. I haven’t seen the issue a single time since making this change (I also since went to mainline Klipper and installed Kalico which supports changing this timeout in the user config).

I don’t remember the guide I followed, but this page gives an easy one-line command to make the change when you SSH into your printer: https://mellow.klipper.cn/en/docs/DebugDoc/faq/hometimeout/

(Edit: the post I found with the steps originally was https://forum.sovol3d.com/t/console-error-communication-timeout-during-homing-probe/8276. I highly recommend backing up this file before changing it)

[evelant]

For anybody else who gets stuck with this error I found the root cause and figured out how to fix it at least on my Sovol SV08. The problem may be similar on other printers.

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!

[dingausmwald]

Interesting. I can recall that creality has a similar mechanism on their machines. I thought i disabled it while testing but will have a look again

[clutchkick512]

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!

Yeah not the actual problem though. For creality machines on SimpleAF we found it was a mishandled m106 macro. SimpleAF doesnt hav ethe PLR code anymore and we were still seeing the move queue overflow errors.

[evelant]

Sorry, I edited my post to clarify that at least on my sovol sv08 this was the source of the problem and there may be similar "features" on other printers triggering the same failure. My hope is that it at least gives people a clue to help diagnose the issue.

[bpengu1n]

Yeah, this can be caused by many different things ranging from host resource constraints to wiring issues. I’ve found the 25ms increase in MCU timeout to solve it completely for me, and have had no issues over hundreds of hours of print time. That timeout increase can help independent of the root cause.

[drewslarsen-hash]

i have an ender 3v3 plus and ive connected to the printer with ssh but it seems mcu.py is read only and im unable to modify it in any way. anyone got any ideas?

[dingausmwald]

its not rly written down but the way to go is to copy it and rename the link in printer.cfg to the new file. 2026 ...