Fill out above information and in all cases attach yourklippy.logfile. Pasting yourprinter.cfgis not needed
Describe your issue:
Hi All,
I’m new here. I hope I’ve found the right place. I’ve managed to get Klipper running on the CXY-V6-191121 Board which is the latest revision from Tronxy. When it works, it works great. But it crashes a lot.
The Klippy log was too big to attach, but the moonraker log seems to be the one reporting the problem. It looks like a thermal shutdown, so overheating? But my knowledge is pretty limited, so I apologise in advance. I don’t know what’s overheating, so if anyone with more experience could advise then I will upgrade the needed part.
I really want to put an Octopus Pro board on this machine, but because of the breakout board to 30 pin serial connection on the Tronxy boards breaking the connections up might well be beyond my current ability.
Any help / advice / troubleshooting would be massively appreciated. I just had a print stop with the firmware shutting down about 10 mins before the end of the print. So it’s ruined…not the end of the world, but would love to find out why and fix it.
Thanks for the reply. The klippy.log is too large to post. I did try and attach it. I’ve zipped it and tried again. Any help would be much appreciated! Klipper Log.zip (1.2 MB)
It seems Klipper on the Pi loses connection to the MCU on the printer board.
You may check the USB cable for proper connection.
Also check if there are maybe some cold solder joints with the USB connector on the printer board (one never knows). When the board warms up, those bad joints can lose contact. Also the connector may has to bear some mechanical stress.
This is what makes me think overheat? A temperature reading, then a throttle flag with a shutdown?
This causes the MCU to disconnect from the Pi it looks like?
Guess he followed the guide on the TronXY fandom wiki for the STM32F446, same as I did, no issues whatsoever. Just download the Marlin firmware from Tronxy3D Github instead of the one that’s no longer available from their website and follow the Github instructions, compile it (mine failed because of a precompiled library duplicated interrupt declaration but still created the .bin files ??), replace the fmw_tronxy.bin file with klipper.bin (rename to fmw_tronxy.bin and overwrite) and once flashed you can ignore the display (only useful for checking that the bootloader hasn’t died).
Regarding the OP, I’ve read somewhere that some OSs (I guess vanilla Raspbian) do something funny with the ports and don’t allocate them exclusively to a running program.
@shadyshaun Are you still experiencing these issues? What RPi are you using? Do you have a heatsink on the CPU? What OS are you running? I’m using Mainsail that’s not meant to have the issue with the exclusive port use. Have you tried compiling klipper with a different baudrate? Default is 250000 as per the fandom guide but from my (very limited) experience compiling STM32 programs, you can go as high as 12M (yep, that’s 12 000 000) and use the full USB 2.0 bandwidth even if Klipper is only communicating once in a while. I don’t think it’s a CPU temperature issue because 43.8 Celsius is on the cold side of a running Pi 4 without heatsink.
I’m still waiting for a few parts like GT2 z-axis timing belt and corner brackets before putting mine to the test.
Just download his klippy.log file, and extract configuration from there.
P.S. there could be multiple instances of it, klipper on each firmware start is putting current configuration to klippy.log file