Getting "MCU 'mcu' shutdown: Move queue overflow" error mid print for a certain file?

General Discussion
1

Basic Information:

Printer Model: Custom 550x550x550mm based on Voron Trident and VZBot designs
MCU / Printerboard: BTT Manta M8P, with EBB36 over CAN
Host / SBC: CB1
klippy.log: klippy(1).zip (1.8 MB)

Describe your issue:

I have received this error twice now at nearly the same point, but not the exact same point while printing the same file. I have used OrcaSlicer to slice it and used the Classic wall generator from the start which is what was discussed to be a solution here: MCU 'mcu' shutdown: Move queue overflow · Issue #8739 · OrcaSlicer/OrcaSlicer · GitHub

Initially I thought it was a CANBus connector issue, since I have had it in the past, but since it has occurred twice in a row now, once at 5h3m, once at 5h9m, that makes me feel this is not an electrical issue.

I can share the gcode file in question, not posting it here because new users are only allowed 2 links per post

The printer was idle and stored away for around 6 months, before I turned it on last week. I got 6 pcs of 13 hour prints done perfectly. Similar prints in scale and pattern but different design compared to the one I am facing problems with so I don’t understand what’s going wrong.

I noticed a low disk space warning in fluidd, and have only 720MB free, but as much I read the error concerns the MCU memory. However please let me know if this could be the problem, I just don’t want to waste more filament on failed attempts, it’s costing me dearly. Following is the neofetch output from CB1:

image
image728×337 31.8 KB

Thanks in advance

2

Welcome Y97,
yes, please do.

1 Like
3

Shortly, your best bet is to simply update everything.
From the log, even if I see this error, I can’t guess why it happens. Because from a pure host perspective, it does not (all scheduled moves are <1024) (klipper/src/basecmd.c at master · Klipper3d/klipper · GitHub):

Dumping stepper 'stepper_x' (mcu) 35 queue_step:
...
Dumping stepper 'stepper_x1' (mcu) 35 queue_step:
...
Dumping stepper 'stepper_y' (mcu) 43 queue_step:
...
Dumping stepper 'stepper_y1' (mcu) 43 queue_step:
...
Dumping stepper 'stepper_z' (mcu) 6 queue_step:
...
Dumping stepper 'stepper_z1' (mcu) 6 queue_step:
...
Dumping stepper 'stepper_z2' (mcu) 6 queue_step:
...

So, something should go really wrong to hit that limit.
Generally, it is the modified firmware.
In your case, I do not see that it is modified.

But I’m not sure it’s worth investing time to deep dive here:

Loaded MCU 'mcu' 108 commands (v0.12.0-86-gdaf875e6 / gcc: (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] binutils: (2.35.2-2+14+b2) 2.35.2)
...
Loaded MCU 'EBBCan' 108 commands (v0.12.0-86-gdaf875e6 / gcc: (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027] binutils: (2.35.2-2+14+b2) 2.35.2)
...
 >>>> Configured MCU 'mcu' (1024 moves)
Args: ['/home/biqu/klipper/klippy/klippy.py', '/home/biqu/printer_data/config/printer.cfg', '-I', '/home/biqu/printer_data/comms/klippy.serial', '-l', '/home/biqu/printer_data/logs/klippy.log', '-a', '/home/biqu/printer_data/comms/klippy.sock']
Git version: 'v0.13.0-119-g17b8ce4c-dirty'
Untracked files: klippy/extras/z_calibration.py
Branch: master

Hope that helps.

1 Like
4

LAMP_SHADE_399_9h1m.zip (6.4 MB)

The gcode file in question

1 Like
5

I have updated all my files, and fixed warnings related to the mobileraker and z_calibration.py
This is what fluidd shows now (it had warnings earlier but I didn’t ss it):

image
image1072×779 44.4 KB

I have nearly run out of filament for the day, so I’ll be printing a slightly scaled down (90%) version of the model overnight. Also, I am using bambustudio this time to slice… Just trying everything I can at the moment to not fail again. Will update if it fails again in the morning

6

Did you update your MCUs as well?

JFYI: slicers has nothing to do with it.

2 Likes
7

How do I do that? Do I have to rebuild the binary and reflash? I used kiuah last time and that was in 2023 IIRC