That indicates you probably have a mismatch between absolute and relative extrusion mode. Make sure your start gcode explicitly sets the mode that matches your slicer.
Then this would happen at every second print, but in happens randomly.
And yes, start G-Code sets absolute extrusion mode.
These screeches only appear to happen when it is underextruding with small radii, not on long lines
You may check your extruder assembly for an always smooth filament transport. The screeches should not happen.
1 Like
I wrote it ten times here and I’ll write it again.
THIS IS NOT A HARDWARE ISSUE. When I restart Klipper it prints same file flawlessly.
Well, whatever it is:
- If you have to set
baud = 1000000something is wrong - If you have to set
max_extrude_cross_section = 99999something is wrong - If you have to set
microsteps = 4something is wrong
Since
- There is nothing really special about your hardware
- Your settings look OK
- Klipper is running fine on thousands of machines
the conclusion to search the issue somewhere in your hardware is quite obvious.
Otherwise it could be a corrupted Klipper / Linux install
- Take a fresh SD card
- Setup a new Linux
- Follow the Klipper installation steps including building and reflashing your board
I tried to fix this issue with higher baudrate. OK, I’ll change it back to 250000.
What is the correct value for standard V6 then?
Why not? It’s TMC2209, my feeder is ~5:1 geared. But OK, I’ll set it to 16.
Good idea! I’ll reinstall everything but use same printer.cfg, do some tests and post here.
For standard hardware and a properly setup system, this setting is never needed. If you get such an error then you have some issues in your setup and Klipper is warning you about it. See Move exceeds maximum extrusion (AA mm^2 vs BB mm^2)
You can set what you want if you like the results. I’m just pointing out that the NEED to set it to such low values is a strong indication that something is wrong in general.
I made a fresh installation of Linux and Klipper to a new SD card, but issue persists.
I’ll try RaspberryPi 3 and OrangePi 3 LTS instead of RaspberryPi 4, maybe it will help…
Had the same issue(usually high speeds or during homing) Don’t know if related, but I had too high microsteps on the drivers on my delta. TMC2209 without interpolation. Had to settle on 64 per driver to make it work. Now I run an H7 MCU and 256 on all without problems. Previously an F407.
So I have the exact same issue and also tried basically everything to fix it to no avail.
It usually happens every couple of prints.
I start the print (either via mainsail or via superslicer) It heats up and does auto bed leveling (9x9).
And while doing the purge line and starting the skirt, the Extruder makes painful screeching noise and it’s terribly overextruding. Usually it does the skirt for a couple of seconds and then it errors out with mcu timer too close, but sometimes it errors already while doing bed levelling.
I restart, start the exact same print again, and it prints fine now.
I have this issue since the start of my klipper usage (I started using klipper last year).
klippy (1).log (759.8 KB)
Printer Model: HEVO
MCU / Printerboard: MKS Robin (not Robin nano)
Shortly after the bed_mesh something turned off the extruder heater
So at a certain point you get into cold extrusion and Klipper goes into shutdown
You may check your gcode file.
Hello.
Which host do you use? RaspberryPi 4?
Did you try another host? I am going to try OrangePi 3 LTS, I have some self-built printers with same board and OrangePi 3 LTS in my office, and they do not glitch like my Sapphire Plus.
This was my manual intervention and it doesnt have anything to do with the issue. As I said I can print the exact same gcode file fine when I try again.
I started the print and turned off extruder afterwards, I changed filament beforehand and therefore it was hot when starting print and I didn’t like it being hot while idling (waiting on bed heatup).
1 Like
I’m using a Rpi 3B+
Interesting. What else is different in the office? Maybe we can find a common denominator?
My MCU is a STM32F103ZET6, also having 3x TMC2209 via UART connected. Im using a raspi-cam.
My office printers are almost same. Same bed volume, same board, same kinematics, dual-z axis…
I found following differences in the config;
NEMA 17 BMG instead of Sailfin, different gear_ratio
Sensorless homing instead of endstops
Standard 100K thermistor instead of PT1000
No input shaping configured.
Maybe, it’s input shaping… I’ll try enabling it and see if issue pops up here.
I’m using NEMA 17 BMG and 100k as well so it’s not that.
I have input shaping active, this could very well be the culprit. I’ll deactivate it for the next couple of prints and see how it goes.
My settings which I now deactivated:
[input_shaper]
shaper_freq_x: 57.69 # frequency for the X mark of the test model
shaper_freq_y: 57.69 # frequency for the Y mark of the test mode
Im not using senorless homing atm. I have IR-Endstops and BLtouch-Clone (I also used inductive probe in the past)
Edit: corrected my used STM (STM32F103ZET6), found the name in mainsail.
Could you check the OS of your machines? I just realized it could be because I’m still on Debian 10. I am now Upgrading to Debian 11.
I use Raspbian 11 on my glitchy Sapphire.
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian
1 Like
Short Update: It’s not Input Shaper. The issue appeared once again today while printing the skirt and the printer stopped with Error Code:
07:24 Move exceeds maximum extrusion (621.936mm^2 vs 100.000mm^2)
I Printed the same gcode-file yesterday with 100% Success.
Could it be related to auto bed leveling?
[bed_mesh]
speed: 150
mesh_min: 25, 25
mesh_max: 265, 255
probe_count: 6, 6 #10, 10
algorithm: bicubic
Same for me. I enabled Input Shaping on my office printer and it does not glitch. And it has bed leveling and dual-Z tilt leveling too. So it’s not bed leveling.