On every print I do the first (slow) layers are pretty nice but then, most of the time when the printer is doing infill, the nozzle starts grinding and scraping at every layer change on it’s way back right through the infill with horribly noises. Even at the normal speed ( 50mm/sec).
When using higher speeds (80mm/sec and above) it gets so aggressive that the infill gets torn.
At some point it actually ripped the print right of the bed.
However the finished print looks ok. Top and Bottom Surfaces are good and the walls look nice.
I’m using a BL-Touch. I also have better bed-springs installed.
I use 3D-Lac adhesive.
I calibrated my e-steps multiple times… It’s spot on….
I played with the z-offset.
I even bought a dual z-axis kit to prevent gantry sagging, but no change.
I played with the temperature (just using PLA).
I bought a new glass bed.
I changed the Bowden tube.
I tried a lot of different PLA filaments.
The only way to print “normal” without scraping and grinding noises is to use z-hop.
When reverting back to the Marlin firmware it prints the exact same g-code perfectly fine…
I would hate to leave Klipper behind and go back to Marlin just to get the normal print operation back, but as of now I’m totally lost.
I’m looking to upgrade to klipper when I figure out this current issue. Here is a link to the GitHub these people are really good. https://github.com/Jyers/Marlin/issues/1838
hey have you figured out the issues? I just started using klipper for few week noticed the same issues with my ender3v2, first level is perfect but scraping on infill I try to adjust the z offset during print it kinda fixed it but if I use the same offset for new print the 1st layer is way of the bed
The only workaround is to print with a high z-hop.
But then the duration of the print increases wich in one way defeats the purpose of Klipper on this machine for me…
With your printer I now know of a total of 4 Ender 3v2s with Klipper having that behavior.
The big advantage of Klipper is not only the achievable speed but also precision. As the path planning etc is done in advance on the RPi (or similar SBC) it can be done with a lot higher precision than firmwares that need to do it on the MCU.
In the end the firmware has one big task: Translate Gcode into physical movement at the highest possible speed and precision. So if your Gcode commands the printer to move Z up by 0.1mm, the steppers are expected to do exactly this - not more not less. The firmware does not do any black-box Gcode interpretation / manipulation / “improvements”.
So if this system would have bugs each and every printer running Klipper would be affected and GitHub and here would be full of such issues. As this is not the case, my reasoning would search the issue on side of the Ender and especially mechanical precision / stability:
Does the issue appear at every speed (as defined in the printer cfg and defined in the slicer)? What happens if you half the speed?
Does the issue appear at every acceleration (as defined in the printer cfg and defined in the slicer)? What happens if you half the acceleration?
Does it appear when sliced with Prusa Slicer and also with Cura (just to name two popular slicers)?
Edit: To add a few more check-points:
Is the bed badly warped?
Are the offsets for the probe / BLtouch highly precise? If not the z-correction will happen at the wrong place
Do you have unusual square_corner_velocity, i.e. significantly under or over 5?
Do you use a clone BLtouch and have activated some fancy probing that may only be working on genuine BLtouch v3 and above?
Have you verified the probe accuracy?
Does the issue happen as well without bed_mesh / probing?
Do you use some Gcode post processing, e.g. arcs or similar that might significantly reduce precision? (anyway not needed / recommended with Klipper)
I used to have exactly the same issue on my E3V2, and it turned out to be binding on the Z-Axis. The Z-Axis is the biggest weakness of the E3 printers IMHO, the single-leadscrew setup will bind easily if everything else is not setup perfectly. There are lots of things to check on the hardware. First of all, check that the Z-motor is sitting square to the chassis (very common problem, there are motormounts on Thingiverse for this), Next check that the extruder mount (which also houses the leadscrew nut) is perfectly square to the chassis. On mine, it was bent upwards by about 5 degrees, and that meant that the leadscrew would not pass through the nut smoothly. I ended up converting to a dual-motor setup and that eliminated all Z-axis issues for me.
