5.3.0 Stalling when printing circles with Klipper

[NNMale]

Application Version

5.3.0

Platform

Windows 10

Printer

Flying Bear 5 (Klipper)

Reproduction steps

1. Create any cylinder. The optimal diameter is 40 mm.
2. Make a Cura 5.3.0 slice with normal mode (Not vase mode).
3. Send to the Klipper for printing.

Actual results

Left Cura 5.3.0 (stripes due to printing head stoppage can be seen)
Right Cura 5.2.2 (normal print quality)

Expected results

It was not possible to print on the Klipper without problems. No problems detected on the Marlin.

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

No further information

[tianer2820]

I got a similar issue. Gcodes generated by cura 5.3.0 produce random blobs on the surface when printed with klipper. I checked that the cause is not over-extrusion nor seams. This issue does not exist in 5.2.1.

project files.zip

[darrellenns]

Possible duplicate of #14811

[IamAles]

Hello, I can see the same issue in Cura 5.3 on my modified Anet A8+ with Klipper on it.

It is a top "ring" from this project - https://www.thingiverse.com/thing:45214. I have tried to increase buffer in Klipper (buffer_time_high: 10) with no success.

AA8P_tealight_top_40mm_3fm.zip

[fmonaca]

I have the same issue on my Voron with Klipper and Cura 5.3, heavy stuttering on curves that produces blobs. No issues with Cura 5.2.

[DPe997]

Same issue Windows 11 Cura 5.3.0 FLSUN V400 with Klipper. Perfect prints everytime with 5.2.2.

[Madin5]

Can confirm, had this issue for couple of days, didn't realise that i updated cura.
Left 5.3, right 5.2.2

[Piezoid]

In theory the only thing that could make klipper stutter like this are tiny invisible segments at a sharp angle. This can be verified by checking that lower square_corner_velocity values worsen the issue.

[IamAles]

https://www.gcodeanalyser.com/ shows this for my posted print:

https://gcode.ws/ shows this:

In the gcode there are tiny moves like this:

Mesh settings in Cura 5.3.0 for this print was:
Maximum Resolution: 0.1
Maximum Travel Resolution: 0.1
Maximum Deviation: 0.05

I have also tried:
Maximum Resolution: 0.5
Maximum Travel Resolution: 0.5
Maximum Deviation: 0.1
which unfortunately did not solve the issue.
It seems to me that Cura 5.3.0 did not respect those settings.

[MariMakes]

Hey All! Sorry, it took us a while to get back to you 😰
This looks scary. 😮

It's outside my field of expertise but a klipper bug we introduced in Cura 5.3 is a typo related to ;MESH:NONMESH
It should be resolved in the upcoming service pack.

Can you try the workaround mentioned here and let us know if it works for you? #14679

[IamAles]

Hi MariMakes, thank you for information. I have just tried adding replace script NOMESH -> NONMESH, but the result is unfortunately the same.

[MariMakes]

Hey @IamAles,

Thanks for testing! ❤️
I'll bring it up to the team to see what they can do to improve it.
But I'm not sure what we can do since we don't have access to Klipper printers.

@ckvsoft you know more about Klipper printers than I do, do you perhaps see what might be going on?

[Piezoid]

@MariMakes: @IamAles analysis of the gcode shows small extrusion segments perpendicular to the contour, as I suspected. Klipper constrains the velocity profile in order to follow the extrusion precisely. This cause significant slowdowns on these artifacts.

https://gcode.ws/ shows this:

My guess would be an issue with the path simplification: small segments could be collapsed into longer ones, accumulating the remaining deviation on a short segment whose angle is getting sharper and sharper.
A potential mitigation for this issue is to get less simplification by decreasing maximum resolution and deviation. Most printers running klipper are able to handle high number of segments.

[ckvsoft]

Hallo @MariMakes

Hey @IamAles,

Thanks for testing! heart I'll bring it up to the team to see what they can do to improve it. But I'm not sure what we can do since we don't have access to Klipper printers.

@ckvsoft you know more about Klipper printers than I do, do you perhaps see what might be going on?

This NOMESH/NONMESH typo has nothing to do with this faulty print.
This was about excluding objects during printing. I can't say whether that only makes clippers about this information.

I would not have noticed this printed image, but I rarely print such objects. Has anyone tried whether this is also the case with other firmware? I think it's a slicing error

[IamAles]

Hi @Piezoid

...A potential mitigation for this issue is to get less simplification by decreasing maximum resolution and deviation....

The print was sliced with those parameters:
Maximum Resolution: 0.1
Maximum Travel Resolution: 0.1
Maximum Deviation: 0.05

Do you think it should be decreased even more? What values do you suggest?

[alpytron]

Hi,
I'm having the same issues. Now I switched back to 4.13.1, since 5.3 is creating those artifacts all the time. Below photos show the difference between 5.3 and 4.13.1, both with exactly same settings.

[doubletrouble023]

What interface are you using with Klipper? I remember having these exact issues with earlier versions when I used Octoprint (which was the culprit)

I'm using Fluidd on my voron and haven't noticed these stutters for years now. Not even in 5.3.0

[alpytron]

I use it with Repetier-Server, BTW.

However I believe this issue has nothing to do with Klipper or its interface. The artifact is visible in the GCODE as well, so it's clearly Cura's fault.

[IamAles]

Hi @doubletrouble023

What interface are you using with Klipper? I remember having these exact issues with earlier versions when I used Octoprint (which was the culprit)

I am actually using Octoprint, but as was said the issue is visible in the GCODE. If the Octoprint was the culprit, raising buffer_time_high to 10 should make it "better" or it should be in another place of print at least, which was not the case.

I'm using Fluidd on my voron and haven't noticed these stutters for years now. Not even in 5.3.0

What is your square_corner_velocity? Higher values could probably mitigate the issue as well as higher pressure_advance.

[doubletrouble023]

Yeah I am aware that the issue is with cura. But if that was the entire story, all marlin users would have the same problems? If I haven't misunderstood anything cura outputs gcode with a lot of extremely short moves. That was the same problem with version 4.x.x something and it made klipper stutter a lot. There were some settings you could tweak to make it better but not by a lot. I'm just saying that switching to a moonraker client solved that issue for me. And I haven't noticed anything like this on either of my V2.4s Square_corner_velocity is at 5 and pressure advance : 0.035 and smooth_time : 0.04 So nothing exceptionally high there really.

…

On Wed, 5 Apr 2023 at 21:24, IamAles ***@***.***> wrote: Hi @doubletrouble023 <https://github.com/doubletrouble023> What interface are you using with Klipper? I remember having these exact issues with earlier versions when I used Octoprint (which was the culprit) I am actually using Octoprint, but as was said the issue is visible in the GCODE. If the Octoprint was the culprit, raising *buffer_time_high* to 10 should make it "better" or it should be in another place of print at least, which was not the case. I'm using Fluidd on my voron and haven't noticed these stutters for years now. Not even in 5.3.0 What is your *square_corner_velocity*? Higher values could probably mitigate the issue as well as higher *pressure_advance*. — Reply to this email directly, view it on GitHub <#15001 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQ4EDJLJUEPZK4JNSLRZJZ3W7XBF3ANCNFSM6AAAAAAWEGKBQI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[darrellenns]

@doubletrouble023 I don't see why moonraker vs octoprint would matter at all - it's klipper that processes the gcode, not the frontend. Also, I run moonraker and I'm seeing this same issue.

This is very clearly an issue with Cura. You can actually see the problem directly within Cura's own preview if you look closely. It can be seen by viewing the gcode output in other gcode preview software as well. If it's not showing up (or just less visible) on prints from Marlin machines, then I would guess that's probably down to differences in the Marlin's motion planning algorithms or other configuration/feature differences that mask it (linear advance, accelerations, etc).

The fix needs to be done in Cura, and I'm sure it will happen once the devs track down the root cause. Trying to work around it with printer settings/firmware is likely to be an exercise in frustration, if it's even possible. The only workaround I've found is going back to Cura version 5.2.2, which does not have the issue.

[MariMakes]

Hey All.

Thanks for the reports
I'm going to mark this as a duplicate of #14811
We have a ticket on our backlog with the intent to improve this behavior. For internal reference CURA-10500

I'll be closing this issue as a duplicate but you can follow the progress here: #14811