[4.7.0] Glitch Causing Slowdowns in Circular Perimeters

[CCS86]

4.7.0
Win 10

The slicing engine seems to be struggling with circular perimeters. 99% of the code is fine, but there are random slowdowns during printing at 70 mm/s on a Duet Maestro, which should have plenty of horsepower.

I first noticed these random artifacts (typical slow down bulges) in a print. So, I ran the gcode through gcodeanalyzer and it is actually showing these areas:

I saved the project file: Slowdown.3mf.txt

Then I loaded that project into 4.6.2, saved the gcode, and ran through the analyzer. It also shows some of these slowdown areas (and some oddly long ones), but scanning through all the code, there are FAR fewer of them. Here is the same layer in 4.6.2:

I tried many combinations of 'maximum resolution' and 'maximum deviation', and interestingly with 4.6.2, bringing maximum resolution down to 0.1mm eliminated most of these spots. The behavior in 4.7.0 is not the same, and it saw no improvement.

Here are the gcode files:
4.6.2.gcode.txt
4.7.0.gcode.txt

[CCS86]

[swademc95]

I have this issue as well. Only noticed after upgrading to 4.7.0. Even in places where the curve appears smooth, the printer jitters around the contours causing a significant reduction in speed and a lot of vibration. Only the inner walls seem to be affected.

[CCS86]

Wow, those are some big discontinuities!

[CCS86]

I know this is off-topic from the original issue here, but if you guys are rewriting this portion of the code, is there anything that can be done about this tendancy?

When the model has small holes, and you use a relatively large number of perimeters, each perimeter becomes progressively lower resolution. I can see that it it simply doing offsets on the inner perimeter, and it may be much more complicated to maintain the same segment length, while moving outwards.

Let me know if I should make this request via a new issue.

[dominik59]

I have got the same problem.
I have reflashed firmware, change junction deviation to jerk and so on and have not noticed improvement. When i tried IdeaMaker problem has dissapeared.

Green tickc are pointing model printed with previous cura version (4.6.2), red arrows are pointing models printed with newest software.

P.S. Cura 4.7.0 stable, Linux Mint 20

[ClockeNessMnstr]

Yep, CURA can't slice curves? I thought I was going crazy.

Here it is at 30mm/s target (print speed = 30, speed setting = 60...)

Here it is at 60mm/s target.

actual print. I forget the settings for this but the speed was at least 60mm/s, possibly set higher.
There could be two issues here. The lines you see running up the bow primarily in the z-axis do not show up based on infill, rather appear differently based on speed? looks like some sort of ghosting of the front of the bow but you can see the printer changing speed and causing the pattern.
The rough texture looks to match the gcode issues in different layers of the shell.

[louisferreira]

So I installed 4.7.0 along side 4.6.2 and set both instances to be exactly the same on all settings using CHEPS 0.2 profile, and I noticed a big difference in the prints. Firstly the GCode for 4.7 was twice the size of 4.6. And the print quality was distinctly different as shown - 4.6 on the left (2hr 2min), 4.7 on the right (2hrs 35min). There was also a noticeable difference in the sound the steppers made... 4.7 seemed to jitter a lot more round curves, whilst 4.6 seemed to be smoother in the same places.
So for now, I'm sticking to 4.6.2 until 4.7.x can do at least the same output as 4.6.2
I'd be interested to see if anyone else can do the same test and get similar results on their printer.
Hardware:
Ender 5+
Stock board + firmware
Capri bowden
metal extruder
Luke's hot end fix
Octoprint
Filament:
YOYI Silk PLA 1.75

[rburema]

Possibly caused by Ultimaker/CuraEngine#1214 and the related #7385

Depending on whether you're using stock profiles or external ones, please try 4.7.0 with the 'Maximum Deviation' set to half that of 4.6.x -- If this happens with stock profiles that come with Cura, there's something quite wrong. Otherwise the setting should be changed.

[swademc95]

Deviation settings was the first place I went after noticing the stuttering and slowdown. Thoroughly testing those settings through a range of values did not improve results once I was looking in the right place (at the plotted g-code)

[jellespijker]

@rburema #7385 is in my mind the likely cull-print compared to the simplify function executed on a circle

[rburema]

@swademc95 Thanks for the reply. This is bad news :-/

@jellespijker Yes, that's the second PR I mention in my comment (because they are related, and from the same JIRA ticket: CURA-7282). So I'm a bit confused: Are you agreeing or did you mean another PR?

[jellespijker]

@rburema I should have done more then hoover over the link. Once again I agree with you completely. I meant an other ticket but I can't remember the number and title anymore. I gonna look into it tomorrow.

Curious why it wasn't caught with the statistics that we run on the build server over certain models, especially the increase in file size as @louisferreira mentioned.

Time to double the effort for in GHermeneus toolbox ;-)