CR10 - BTT SKR Mini E3 V3 - BTT Pi
My printhead has a delay between movements. The results are significant increases in print times and quality issues. What could be causing this?
klippy.log (7.3 MB)
Full klippy zip
klippy.zip (1.3 MB)
Your [printer] section is completely off.
Compare against a working example for your printer: klipper/config/printer-creality-cr10-2017.cfg at master · Klipper3d/klipper · GitHub
Judging from the log there is at least another issue with your Neopixel setup, but I will leave this exercise to you since I do not feel going through hundreds of config lines that are not printing relevant.
I’m not using a default CR10 printer config. The only thing CR10 about this machine anymore is the frame and motors.
The default config I started with is for the SKR Mini E3 V3. I’ve re-arranged some of the sections, and added features (such as the neopixels), but all of the pin locations and relevant board control information has remained default.
I cannot asses what you have done. In any case the entire [printer] section is crap.
For a bed slinger (in fact for probably all 3D printers) really all values in there are wrong, with the exception of kinematics and maybe max_velocity. Start with the section as per the link above and try to optimize from there
I’m not changing to a CR10 config. I can comment out the added features for the SKR mini config, but changing to a CR10 config would completely throw off the pin mapping.
What values are you talking about? The voltages and etc were updated on the config I am using to suggested ranges for the motors I have on the machine.
I’d rather you find someone else to call crap. Thanks for nothing.
It would help to read what I have written. It would further help to understand what these settings mean. You will find an explanation in the documentation.
[printer]
kinematics = cartesian
max_velocity = 250
square_corner_velocity = 1.0
max_accel = 1600
max_accel_to_decel = 7000
max_z_velocity = 50
max_z_accel = 100
Except the first two settings all other settings are simply wrong by any definition or wrong for this type of printer.
Take the settings for exactly this section from the above link and try again. Or leave it like it is and find someone who hopefully has more clue than I do.
max_accel of 1600 is reasonable but somewhat conservative for a bedslinger. If you slicer accel values are significantly higher than this would account for some of the discrepancy between the slicer’s time estimate and the actual print time.
max_accel_to_decel of 7000 makes no sense. This is typically half the max_accel value, but you probably don’t even need it with your max_accel value.
square_corner_velocity of 1 is also pretty low (the default is 5). This means your printer will come to nearly a complete stop when executing a 90 degree corner. Depending on the geometry you’re printing, this is probably why you’re seeing the behavior you’re seeing.
1 Like
The problem is your square corner velocity. The default is 5 for a reason and it’s not something you should change unless you know what you’re doing. Even then the you would never want to decrease that value (other than for pressure advance tuning), and instead increase it. On my corexy printer I’ve tuned it for scv of 7, and my bedslinger uses the default 5.
These settings are pulled from the default CR10 V3 config. I made them active.
The default accel_to_ decel setting of 1500 was automatically reinstated when I deleted that line from the config. I returned the sq_corner_velo back to 5mm (default), and removed all ancillary add-on features except print_area_bed_mesh and screw_tilt_adjust.
I confirmed that Arcs is inactive in the slicer as well as deactivated any slicer setting I could find that would cause a slow down in the print speed (IE: layer time cooling and etc.)
I ran a test with these changes and I am still getting a short delay between print moves.
Could this be a RAM issue with the BTT-Pi? It seems like buffering.
Doubtful. The BTT Pi has the same amount of RAM as the RPi 3B+ (but faster) and the RPi 3B+ runs Klipper just fine. The next thing I’d look at are slicer settings. It might help to upload a gcode file on which you experience the issue. EDIT: …and a new klippy.log
Thanks to all. I just figured it out.
I had started using firmware_retraction to control oozing while the printhead was parked during timelapses because I could not get that under control with the slicer retraction settings.
Timelapse is not as important as print time to me, so I just now disabled the firmware_retraction in the printer.cfg and went back to slicer retraction settings. BOOM, no delays between print moves.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.