Hi. Since two days ago, I had Klipper working very nicely on my Anycubic 4Max Pro 2.0. I did a few prints, and everything was working perfectly. Yesterday though, I installed a BLTouch probe. Everything went fine with that as well, and it probes correctly. The probe accuracy seems to be very consistent, and the mesh makes sense. Today, however, I did my first test prints after setting up the BLTouch. For some reason, the purge line is not extruded correctly.
The gcode previews in the slicer and in Mainsail both show the purge line looking correct.
But what actually happens is it seems to move to the end of the line without extruding anything, and then stops at the end of the line and does one massive extrusion in place, very fast:
This can’t be good for the extruder, so it’s no surprise that klipper throws the error message in the title. Although even though it throws that error, it didn’t prevent it from happening… It just did it and then stayed there right up against the bed with the heaters on, which just makes things worse.
Anyway, I’m able to surpress the error and continue the print by increasing max_extrude_cross_section, of course, but that doesn’t fix my problem because my purge line is still messed up either way, and I’m afraid of the extruder being damaged by this.
Not sure what could’ve caused this, because as far as I can remember I haven’t intentionally changed anything in particular except for setting up the BLTouch. I don’t get why that would mess this up though. Maybe the virtual z endstop probe procedure messes with the positioning mode or something? I don’t know. Would really appreciate any help in figuring this out.
Logs attached below.
klippy.log (39.8 KB)
And here is the screenshot of the gcode preview in PrusaSlicer. Tried to include in the original post but apparently new users are only allowed one embed per post…
It is very unlikely that it is due to your BLTouch. Most likely you (or your slicer) have modified the start gcode. See [H] Move exceeds maximum extrusion - #2 by Sineos
I have read most of these other posts/issues and I can’t find any evidence of these same causes. I hadn’t messed with my start gcode at all since installing Klipper. It’s done through the slicer same as always.
I tried to upload the sliced gcode file my initial post but this website wouldn’t let me. I have zipped up the gcode and attached it because at least that seems to work:
Bed_Levelling.zip (52.9 KB)
Actually after observing it more closely at the start of the print, I think I see the problem. It isn’t even starting the purge line from the origin corner. It’s because of the safe_z_home which moves it to the center of the bed for the Z home. My start gcode assumes that after homing it will already be at the origin, and it doesn’t set all 3 coordinates when it positions for heatup and purge line. So I should simply be able to add G1 X0 Y0 Z0 after homing and that should fix it. So… as I suspected, it was an interaction with the new BLTouch Z home and my start gcode. I haven’t tested this yet, but I’m pretty confident we should be able to say case closed on this.
Hurrah, that’s worked! Another weird interaction with the BLTouch Z homing I’ve noticed is that it moves the bed down twice before homing Z. That’s probably because I have G28 X0 Y0 on one line which triggers the Z hop once, and then the next line is G28 Z0 which must trigger it again. I’ll just replace both with a simple G28.
