MCU shutdown due to move queue overflow

Basic Information:

Printer Model: Custom E3NG (cr10 version)
MCU / Printerboard: btt Octo (as CAN interface)/ ebb36
Host / SBC PI 3B+

klippy-6-8-24.zip (1.2 MB)
klippy-6-7-24.zip (839.2 KB)

Fill out above information and in all cases attach your klippy.log file (use zip to compress it, if too big). Pasting your printer.cfg is not needed
Be sure to check our “Knowledge Base” Category first. Most relevant items, e.g. error messages, are covered there

Describe your issue:

keep having different mcu shutdowns i have tried a few different things and have had no success, example 32 micro stepping to 16 , added step pulse duration, lowest settings on webcam. but i just keep having these issues mcu shutdown all data issues. maybe i need to change to a U2C instead of using the octo as the can bridge? thanks for any incite that am not seeing

i did uses graph klipper stats and do see when these happen my MCU frequencys are all over the place

Move Queue overflow error is generated by MCU when it don’t have enough memory to store future move, this is very strange …

What exact CPU you have on your BTT Octo board ?
by the log it’s stm32f446xx.

@Dutchmonkey - just to reiterate what @gaolst is saying.

BTT built Octopus boards with different MCUs. You didn’t specify whether or not it is an Octopus V1.0, V1.1 or Pro.

Along with not specifying which Octopus board, the Pro uses the STM32F429 and the Octopus V1.0/V1.1 normally have the STM32F446 but some were built with the STM32F407 while others were reportedly built with the STM32F429.

Could you physically look at your board and read the part number off the MCU chip (it’s the biggest one of the board)?

This may not be your problem but the different MCU Part Numbers will provide the same functionality but need to have their firmware built for the actual MCU for everything to work perfectly.

Octopus v1.1 STM32F446ZET6

1 Like

Can you explain how you wired your CAN bus?

When I look at your klippy.log, you’re getting an awful lot of bytes_retransmit and bytes_invalid which is what I believe is an indicator of a CAN bus wiring problem. I wonder if you have an intermittent break in your CAN cable which is causing the communications problems but isn’t bad enough to cause failures at the start of the print.

I have a twisted pair of wires coming from the rj11 jack on the octopus to the ebb36 connector on the top, the 24v pair come from the octo to the ebb36. I will check both crimps and see if that makes a difference. Thank you for giving me some idea of what might be going on

1 Like

klippy6-10-24.zip (704.3 KB)
I rebuilt the CanBus cable last night, the RJ11 connector is loose in the socket on the octopus but i did run the same gcode, i started the print after the first layer i cranked the speed to 200% at the 75% completion i turned it up to 250%. it managed to get to the 99.95% then crashed i forgot to write the exact fail it was something about mcu temp. it might have been the fact i was pushing it but thought i would see if anything looks suspisous to you. the mcu frequency had one bad spot i think thats where i hit the 250%. thank you again for any insite on this.

Maybe somebody more adept at reading klippy.log files can comment further but based on what I see, the CAN interface is pretty rock solid and the system was shut down when you got a “Timer Too Close” with the rPi 3B+ to Octopus communications.

The basic SBC to Octopus communications seems to have some minor issues right from the start but things really start to fall apart at 7378 seconds (Two Hours, Three Minutes into things) - Does this correspond to when you cranked up the speed?

If it does, then my recommendation is don’t do that.

Thank you for checking it out, ya that sounds about right on the timing, I don’t make it a practice of speeding up prints but it does help stress the system.

1 Like