Fill out above information andin all cases attach yourklippy.logfile (use zip to compress it, if too big). Pasting yourprinter.cfgis 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
…
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.
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
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.
FYI, bad CANbus wiring is highly unlikely to cause bytes_invalid to increase. An increasing bytes_invalid indicates an issue in the host Linux Kernel or a firmware issue in the USB to CAN adapter. CANBUS Troubleshooting - Klipper documentation
An increasing bytes_retransmit (and similar “Timer too close” errors) can be the result of bad wiring. However, with the combination of bytes_invalid it is likely a symptom of Kernel/adapter issues. I’d recommend addressing the Kernel/adapter issue first.