I have been running my Voron Trident with minimal issues for quite a while, just recently was starting a longer print, and after a few hours I received MCU ‘mcu’ shutdown: move queue overflow. I’ve checked all connections and cables and all appears well (no different than the past 6-8 months). Error is mentioned in line 17212 of attached Klippy log file. Any input is greatly appreciated.
Host: v0.11.0-169-g83308a10,
MCU: v0.11.0-5-ga42f6158 klippy (1).log (6.5 MB)
I have checked that out yes. My takeaway was that manifestation was a fluky error. I’m wondering if there is a definitive explanation for mine, as I’ll have a lot of longer prints coming down the pipe and want be as confident as possible in my machine.
After replacing the octopus mainboard with a brand new board and updated firmware, using RPi 3B+, I am now getting an ‘MCU shutdown Timer Too Close’ error. I’ve never had anything like this happen before, could it be anything to do with my recent switch to PrusaSlicer from SuperSlicer? Updated log attached. Timer Too Close.zip (2.5 MB)
EDIT FOR CLARITY: I was running a different file this time, with fewer parts to avoid wasting filament. I sliced using PrusaSlicer 2.6-alpha-6. As I think about it more, I lean towards it being a slicer artifact, but any input is appreciated.
I did check that out, I am running a webcam, but have been since I built the printer, so I wouldn’t have expected that to become an issue. It’s possible I could be getting interference on the Pi-MCU cable, but again I’ve never had that issue until now, I’ll try rerouting that tonight.
I’m wondering though if this is an artifact of PrusaSlicers newly introduced Klipper GCode flavor? I am running some in depth controls like adaptive fan and speed based on layer times, maybe there’s something in there that crops up and bogs Klipper down unexpectedly?
At least MCU Bandwidth is pretty high. Does no necessarily mean it is an issue, since it is scaled to 250 kBaud and USB can go faster. System Load and other indicators seem fine.
Thanks for the input. Just an update, I ran another print successfully with only the following changes made: changed G-Code flavor from Klipper to Marlin (Legacy) and changed the travel_speed_z from its default value (my travel speed of 150 mm/s) to 20 mm/s to avoid overloading the leadscrew steppers, though this had never been an issue before for me. I had been using the Klipper G-Code flavor in PrusaSlicer 2.6-a6, maybe my errors were a result of the new integration of Klipper in PS? Webcam was still connected and running. Successful Print.zip (1.3 MB)
