Printer Model: Voron 2.4
MCU / Printerboard: Octopus, HUVUD, PI w/ RS485
klippy.log klippy.zip (1.6 MB)
Describe your issue:
After running my heatsoak I run into times where I will get a timeout during homing or during probing. I’ve looked at clipper logs and it seems like retransmission isn’t happening from what I can tell. Attached is a log with a firmware restart hit right after it failed. I’m using a HUVUD with a waveshare on my pi. They are setup with 500 Mhz for bitrate and txqueuelen of 256. I know CANBUS Communication timeout while homing Z talks about bytes invalid increasing but I’m not seeing that so hoping you guys can maybe point me in the right direction.
Please provide a full and unmodified
Did you get a chance to look at the un modified klipper log?
Can you point to the error in the log. With a first check I did not see anything that would point to a problem, maybe except some:
Transition to shutdown state: Shutdown due to webhooks request
Dumping gcode input 0 blocks
Dumping 20 requests for client 4064206888
But this typically is a Level 8 thing: MCU 'mcu' shutdown: Command request / Shutdown due to webhooks request
If you are referring to:
Communication timeout during homing x
This means that your MCU is not sending new status information every 25ms. This is often due to improper CAN setups, but I’m not an expert on these.
Or it may be due to having loaded unofficial Klipper modifications:
Git version: 'v0.11.0-275-g8ef0f7d7-dirty'
Untracked files: klippy/extras/z_calibration.py
Tracked URL: https://github.com/Klipper3d/klipper.git
I am referring to the timeout during homing. When you say incorrect configuration of CAN can you clarify? In terms of the unofficial klipper modification that is the z autocalibration modification GitHub - protoloft/klipper_z_calibration: Klipper plugin for self-calibrating z-offset. After a moonraker update I think I started seeing a similar message in mainsail.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.