Issue with my nozzle pausing between moves and extrusions

General Discussion
1

Basic Information:

Printer Model: N/A
MCU / Printerboard:BTT SKR 2 stm32f429
klippy.log

Fill out above information and in all cases attach your klippy.log file. Pasting your printer.cfg is not needed

Describe your issue: My nozzle is pausing approximately 8 seconds in between extrusions/moves. More like 16 seconds though. The print head moves waits 8 seconds then prints plastic then waits 8 seconds. I have tried making gcode files with prusa 2.5 and cura 5.21. I have attempted to use buffer_time_high: 10. I have a libre ROC-RK3328-CC 2gb ram sbc running klipper on armbian 22.11. I have a 64 gb silicon power sd card with UHS-I (U3), and V30 ratings. So I don’t think its buffering issues. Im trying to find out if there is a setting I have wrong or something else in my config I don’t know enough about. As far as hardware I couldn’t find any thing stating an issue with the stm32f429 on the main board, or the Rockchip RK3328 SoC in my sbc.

klippy .log (7.6 MB)

2

There are a few things I can think of off the top of my head.

  1. What front end are you using? Fliudd? Mainsail? Octoprint? If it is the latter, I have seen this happen before, suggest trying one of the other front ends to see if that fixes things
  2. Do you have timelapse turned on? Depending on the settings you are using, that will pause the nozzle at set intervals, worth checking
  3. Does the model you are printing have lots of arcs? Does the pause happen if you just print a plain cube? Arcs are converted to a series of small straight lines by the slicer. If the resolution of the stl file is very fine, you get truck loads of small lines for a single arc, and that can cause buffering issues. This can be fixed by either using Arc Welder, or by reducing the resolution of the STL file

That’s all I got.

3

If you use OctoPrint, please share the systeminfo bundle.

4

Sorry, I have tried all three front ends multiple times. I still get this same behavior. I orignally had a raspberry pi zero w with mainsail os installed. I figured it wasnt keeping up due to the processor and switched to the above mentioned libre sbc. I personally didn’t like OctoPrint as a klipper interface so I don’t have the systeminfo bundle. I erased the sd card for each individual front end. I’m currently printing a simple 20 mm cube with fluidd.The cube has no arcs or circles. Infill is set to cubic. I’m still seeing the pauses. I haven’t set up any time lapse stuff. I am however still checking to see if i have anything is set to pause for a time lapse. Arc welder sounds awesome so I will be getting it set up. Including enabling it in my klipper config.

5

Does the version of Armbian you are running have a desktop environment? Have you monitored RAM usage? Is it running a swapfile? The specs of the board should be more than enough to run klipper. I’m running klipper on much slower hardware, so all I can think of is that it is being throttled due to limited RAM

6

Arc welder is not needed for Klipper. On the contrary it might rather introduce unwanted effects due to precision loss and bugs in arc-welder.

What kind of printer is this? Your acceleration of 750 seems terrible low even for some Chinesium printer.

Edit:

nozzle_diameter = 0.04
filament_diameter = 1.750
max_extrude_cross_section = 30
max_extrude_only_distance = 200

nozzle_diameter seems a little off and the max_extrude_* should not be needed on a properly configured printer.

7

Can you elaborate on this please? I’ve certainly experienced buffering with klipper when printing arcs on high-res STL files before, and Arc Welder fixed it, which it is what it is supposed to do.

8

Ok, I sincerly hope that this does not end in a discussion about the sense (or rather the lack thereof) of high resolution STL or even what “resolution” actually means

Chordal Deviation

Chordal Deviation is the difference between a CAD file and its STL representation. For typical pinter application you aim for a value < 0.1mm for a high quality print.
Typically this is also the default in various CAD applications

  • SolidWorks → Deviation 0.1mm
  • Fusion360 → Surface Deviation 0.1 mm
  • Creo → Chord Height 0.1 mm

Default Slicer Settings

Commonly, the slicer even goes more coarse. For example Cura defines a minimum segment length of 0.25mm but at a maximum deviation from the STL of 0.025mm

CAD → STL → GCODE

As you can see, you already have two conversion steps: One from the CAD file to the STL and one from the STL to your GCODE.
Both are typically working with different “resolutions”.

Arc-Welder Process

  1. Take a polygon and approximate to an arc → First lossy operation
  2. Klipper to take the arc and approximate it back to a segment → Second lossy operation

My Conclusion

  • Klipper uses the virtual_sdcard to prevent stuttering, which would typically occur when you directly transfer via a serial connection (e.g. Marlin)
  • I have yet to see Klipper stuttering when using virtual_sdcard AND having a sensible resolution
  • Yes, you can make Klipper stutter by creating GCODE files over and beyond every sane resolution (which btw. will not offer any benefit in accuracy or quality since it cannot be resolved by the stepper movement and even less by a FDM extrusion system)
  • Arc welding and high resolution is a contradiction in itself, since you introduce another two lossy transformations
2 Likes
9

Thanks very much for the very comprehensive reply!

So, without getting into a discussion, but just for clarity, when I talk about the resolution of STL files, I mean the size of the polygons (triangles) used to create the mesh. High resolution means smaller polygons which equates to many more polygons.

I’ve only run into this situation and handful of times (the last time was probably over 18 months ago), but I have downloaded STLs that were created at high resolution, and have had buffing issues, which Arc Welder fixed. However it is entirely possible that I did not have a virtual-sdcard defined back then, it’s too long ago now that I just don’t remember.

Anyway, thanks again for the informative reply, and apologies to OP for hi-jacking the thread, but I hope that you got something out of the discussion too :slight_smile:

10

In my defense that tiny little bead of plastic looks a lot closer to .04 inches than it does .4 inches. That being said I edited my printer config to reflect the .4 mm nozzle size I currently have installed on my printer. I lowered the acceleration so I could trouble shoot failed prints. I don’t know if i was fallowing a youtube tutorial on initial steup or problem fixing but at some pint I added the max_extrude_* entries. I commented them out and my printer has stopped misbehaving.
Thank you very much Sineos.
My printer started life as a tronxy xy2. The bed heater eventually died in a way that also took out the main board. At that point I decided to change a couple of things like a skr2 main board, second lead screw, a 381mm x381mm bed, and silicone heater. It is very much non standard size, and currently still a work in progress.
Just in case any one still wanted to know how my libre board runs during a print.
Ok in linux according to top It’s cofigured with a 960mb swap partition of which its using 0%. Total reported ram is 1980.6mb of which only 327mb are used during printing. Cpu usage maxed out at 3% during printing. According to fluidd klipper load mostly stays under 10%. Moonraker load is usually under 7%. Mcu usage is pretty consistent at about 1%.

I defiantly learned a little more about the arc functions and resolution.

Thank you every one for the help.

11

Glad, that it worked out for you.

Yes, unfortunately some folks out there produce these files. One very nice example is Skull Candy Dish by lostinlmbo - Thingiverse that I printed this Halloween for our kids.

In fact, only the ornament is a 54 MB STL and would surely cause stuttering. As a matter of fact NetFabb (luckily I have access to the Ultimate edition via my workplace) turned it into a 4MB file without any loss in details or precision. Max deviation after the conversion was 0.01mm from the original file.