[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

[dpreed]

Indeed, Fedora 32 has already distributed the update to all Fedora users who track Cura via the standard package system. However, it would be nice to make 4.6.3 available and suggest that anyone having problems try 4.6.3 reversion rather than trying to fix their printer.

[kiss81]

Indeed, Fedora 32 has already distributed the update to all Fedora users who track Cura via the standard package system. However, it would be nice to make 4.6.3 available and suggest that anyone having problems try 4.6.3 reversion rather than trying to fix their printer.

I agree with this...

[dpreed]

This "issue" is hard for most ordinary printer users to understand from its title or from the posts. I've shared it with others in a printer user group and they react with confusion. So my advice has turned to "Don't use 4.7.1 at all until a fix is released". And that's simple enough. I am not trying to say Cura is "crap", and they should switch to Slic3r or Simplify3D or Kisslicer. No, Cura 4.7 has great stuff in it. But a huge problem that wastes users' time.

[mattaw]

[I hesitate to lengthen a technical bug with non-technical "political" matters, please delete if off-topic. In addition, I am unsure how many folks are being affected.] Can we tastefully escalate guidance like this: https://www.helpscout.com/helpu/outage-status-update/ to the Ultimaker / Cura management and have them do some structured communications around it? I feel Cura would be stronger for clear communications and suggestions like @dpreed . We are 26 days into this bug report, and I imagine the number of affected individuals will only grow and will not have had @dpreed 's positive experience to support them while this issue is being addressed. If we have no communications, how will individuals know to upgrade when the fix is merged short of release notes which I suspect most don't read.

[msteele999]

I have to agree with this suggestion. Currently the lack of communication has created a vacuum in the social media platforms and that vacuum is being filled with helpful (just downgrade to 6.4.1 for now, they are working on it) and deragatory (Ultimaker scks, Cura scks, go use one of the other slicers, etc.) comments.

Use this as an opportunity to connect with your user base and build confidence and loyalty.

Best regards,

Mark Steele

On Wed, Sep 30, 2020, 17:22 Dr. Matthew Swabey notifications@github.com wrote:

[I hesitate to lengthen a technical bug with non-technical "political" matters, please delete if off-topic. In addition, I am unsure how many folks are being affected.] Can we tastefully escalate guidance like this: https://www.helpscout.com/helpu/outage-status-update/ to the Ultimaker / Cura management and have them do some structured communications around it? I feel Cura would be stronger for clear communications and suggestions like @dpreed https://github.com/dpreed . We are 26 days into this bug report, and I imagine the number of affected individuals will only grow and will not have had @dpreed https://github.com/dpreed 's positive experience to support them while this issue is being addressed. If we have no communications, how will individuals know to upgrade when the fix is merged short of release notes which I suspect most don't read.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/8321#issuecomment-701653825, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRMUYM7FHTLCZO7BGVCVT3SIOOS7ANCNFSM4QYPYE7A .

[nallath]

Those derogatory comments will happen regardless. If we release a patch version the same comments happen.

Anyhow, this is also the reason that we are looking for a dedicated (technical) community manager (https://www.linkedin.com/jobs/view/technical-community-manager-at-ultimaker-2021321718).

Last but not least; I don't mind mixing up technical & political matters. They are almost always intertwined, especially in cases like this.

[msteele999]

Those derogatory comments will happen regardless. If we release a patch version the same comments happen.

Anyhow, this is also the reason that we are looking for a dedicated (technical) community manager (https://www.linkedin.com/jobs/view/technical-community-manager-at-ultimaker-2021321718).

Last but not least; I don't mind mixing up technical & political matters. They are almost always intertwined, especially in cases like this.

Understood - so, how can we help?

[KimmoHop]

It would be nice to have nightly or unofficial builds to test how the fix works. I spent ~3 evenings with cura-build-environment, maybe making through it, but then cura-build said "no" ;)

[dpreed]

I'm a beta-test kind of guy. But man, building Cura isn't simple. And figuring out how to attribute bugs on Linux isn't simple, either.

I just found (experimenting) that I can't load 3DBenchy.stl into 4.7.1 - it segfaults reading the mesh somewhere.. Other STL models load fine. The same file loads in the Appimage version of 4..6.2, and used to load fine in the Fedora32 version of 4.6.2.

I'm not sure it is Cura that is hitting this - Fedora32 just updated a bunch of python 3 packages, too. So maybe Cura is fine, but something broke underneath it. So before I do a bug report, I'm experimenting some more.

Being a beta-test kind of guy, I'm used to collaborating with software developers, rather than trashing them.

So this is a complicated way to say I agree with the idea of "unofficial test builds" or "nightlies" as ways I can and would "help".

[konskarm]

Hello everyone. We just merged PR https://github.com/Ultimaker/CuraEngine/pull/1336 into master. Can you check whether it fixes the issue (if you are running Cura from source)?

[nallath]

You just need to build the engine (which is much easier) and ensure that Cura uses that version of the engine (which is a matter of replacing the executable).

I will also check to see what the best way is to expose some nightly builds to you guys (since that is way easier). Do note that these builds will not be signed, as that is a manual and bit of a tedious process.

[nallath]

@dpreed @KimmoHop @msteele999

The nightlies can be found here: https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014539-Darwin.dmg https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014541.AppImage https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002022935.exe

Do note; This is the nightly build from last night. Since our master is considered unstable, it could be that there are other issues with it. As always; it should be possible to install things side by side, but do make a backup of your config folder before using this just to be on the safe side.

[bill-orange]

This isn't authoritative.

I made other changes, such as baking my filament roll, before trying the beta posted by @nallath. That being said, the voids resembling the post by @CCS86 were greatly reduced in the test print made with the beta. I could attribute the very few remaining defects to other causes.

[Skaifer]

Have not tried to print a model sliced with nightly build, cuz, lack of time. But sliced the last problematic model and put in gcode analyzer. I still notice abnormal speed decreases in places it should not happen.

[KimmoHop]

@nallath I sliced benchy (bottommost 10 mm of it) with 4.7.1 and nightly, varying settings. Recently I have used Ender 3 profile, which has low acceleration, modest speeds and very high resolution 0.05mm. Anycubic Mega has higher acceleration and much lower resolution 0.5mm. I printed 3 pairs of benchys based on AC settings with resolutions 0.05mm, 0.1mm and 0.5mm.

In the following I use "high resolution" to short max resolution / more detail / lots of segments and "low resolution" to long max resolution / less detail / less segments, not to confuse, but to make it analogous to e.g. image resolution.

What I found, was that

• getting PS out of the way, it has user definable resolution for island polygons and fixed simplification for print paths so it prints clean. D-P simplification is used in both phases
• 4.4.1 doesn't seem to care much about resolution. It gives small g-code every time, even with 0.001mm resolution, and number of segments does not rise. I guess it's not working correctly, though it prints clean
• 4.7.1 produces files, where size correlates with resolution. High resolutions stutter and blob when printed. 0.5mm printed fine without blobs.
• nightly produces smaller files and less segments for all resolutions. High resolutions stutter and blob when printed. 0.5mm printed fine without blobs, maybe slightly cleaner in some areas, but hard to say with sample size of 1 ;)

The printed parts are not very interesting, so this is how they look in g-code viewer, 2 layers showing at the same time, composition of 3 resolutions for both:

Both versions do some non-printing movements in infill with high resolutions (arrows) that maybe shouldn't be there?

The main finding for me was that max resolution can be fairly long - if we can say so for a length slightly more than nozzle opening. Max deviation keeps contours where they are needed while also keeping SD command buffer fed. I'm not sure if max resolution "started to work" in some Cura version, or is my 4.4.1 just an oddball. Also I'm not sure if 0.05mm really is default max resolution for Ender 3, and if it deals with it without stuttering. Also I didn't check what value other printers use. Maybe that might be something to go through and evaluate at least for 8-bit printers?

[nallath]

• 4.4.1 doesn't seem to care much about resolution. It gives small g-code every time, even with 0.001mm resolution, and number of segments does not rise. I guess it's not working correctly, though it prints clean

That sounds about right. We've had some issues with the simplify not really doing it's job at all (that's how we even got to this situation)

Both versions do some non-printing movements in infill with high resolutions (arrows) that maybe shouldn't be there?

That is always a hard issue. I think this is another issue (but as always, they could be related).

The main finding for me was that max resolution can be fairly long - if we can say so for a length slightly more than nozzle opening. Max deviation keeps contours where they are needed while also keeping SD command buffer fed.

For Ultimaker printers the max resolution is 0.5mm with a max deviation of 0.025mm

[eoyilmaz]

I had the same problems with 4.7.1. Fixed it by the following settings:

Compensate Wall Overlaps: Off Maximum Resolution: 0.5 mm Maximum Travel Resolution: 0.05 mm Maximum Deviation: 0.05 mm

And these helped a little bit too:

Z Seam Alignment: Shortest Print Speed: 75 mm/s Infill Speed: 75 mm/s Outer Wall Speed: 12.5 mm/s Inner Wall Speed: 25 mm/s Top/Bottom Speed: 37.5 mm/s Travel Speed: 187.5 mm/s Initial Layer Speed: 20 mm/s

[msteele999]

I am running a test print now with these settings to see if there is any difference on my printer / setup.

On Fri, Oct 9, 2020 at 4:28 AM Erkan Ozgur Yilmaz notifications@github.com wrote:

I had the same problems with 4.7.1. Fixed it by the following settings:

Compensate Wall Overlaps: Off Maximum Resolution: 0.5 mm Maximum Travel Resolution: 0.05 mm Maximum Deviation: 0.05 mm

And these helped a little bit too:

Z Seam Alignment: Shortest Print Speed: 75 mm/s Infill Speed: 75 mm/s Outer Wall Speed: 12.5 mm/s Inner Wall Speed: 25 mm/s Top/Bottom Speed: 37.5 mm/s Travel Speed: 187.5 mm/s Initial Layer Speed: 20 mm/s

[image: Before] https://camo.githubusercontent.com/6d3feddd7fd1836e694f2e4b393a70ae53a88fc8/68747470733a2f2f6c68332e676f6f676c6575736572636f6e74656e742e636f6d2f61447064527864527a354b7a3646696550395969344c4668585654684a75316b525a7556766d4d485f50425732536d37754e68713569495f43475353594c766f5577496b4c2d34376b506678705a714245746b326444587237583475762d373051723358494e5236797275574467474850734d32576547514c4e4f45334e4a55634e55594b584a5a7a513d7732343030

[image: After] https://camo.githubusercontent.com/fa4e51f9dc3a8f87f1c0913b570159f9d88e15c2/68747470733a2f2f6c68332e676f6f676c6575736572636f6e74656e742e636f6d2f5775712d31305f46647273633765564b64376542485f4474704d505271634a444551794b41337648353274345a35753067535f77394e5f6661567a315130717a4b44376b686858354164345249716f61576f556d3758765879396a77726277333333556a636f2d326e75514c447965685276664b6d58462d63664f346439713550595134384e51386e413d7732343030

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/8321#issuecomment-706046715, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRMUYONEC6J3SP6BG2JY3DSJ3CTVANCNFSM4QYPYE7A .

[CCS86]

Those settings will just hide the issue. Outer walls at 12.5 mm/s is so incredibly slow, that the printer can deal with the discontinuities without significant slow down, because it is already slowed wayyyy down.

[msteele999]

Yeah, I'm finding that it is unacceptably slow - my test print usually takes about 2 hours to print - with these settings it's over 5 hours.

Back to 4.6.1 :-)

On Fri, Oct 9, 2020 at 8:51 AM CCS86 notifications@github.com wrote:

Those settings will just hide the issue. Outer walls at 12.5 mm/s is so incredibly slow, that the printer can deal with the discontinuities without significant slow down, because it is already slowed wayyyy down.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Ultimaker/Cura/issues/8321#issuecomment-706162038, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRMUYPWP6O4SPJUERI7GODSJ4BMBANCNFSM4QYPYE7A .

[nallath]

@eoyilmaz Did you also try to print it with the nightly build i posted?

[eoyilmaz]

Guys, those speed settings are not necessary and it is not slow as stated by @CCS86 as I increase the "Print Speed" to 75 mm/s. It prints around them same 2 hours that I normally print a 3DBenchy (by the way Slic3r's G-Code takes like 1.5 hours). Also I printed at normal speed of 50 mm/s and the main settings that mitigates this problem are those:

Compensate Wall Overlaps: Off Maximum Resolution: 0.5 mm Maximum Travel Resolution: 0.05 mm Maximum Deviation: 0.05 mm

So as I learned, the Compensate Wall Overlaps setting when enabled will disable the Maximum Resolution setting which is the main mitigation for this problem. Doesn't seem to be true. So I checked witth 4.6.2, even with the "Compensate Wall Overlaps" setting is turned on increasing the Maximum Resolution will lower the file size, thus it is working.

@eoyilmaz Did you also try to print it with the nightly build i posted?

@nallath I'll do it so tonight. I'll let you guys now my result.

aand those are the prints that I did while searching for a solution for this problem:

[colatuttorf]

@eoyilmaz Did you also try to print it with the nightly build i posted?

I downloaded and started using the nightly posted above. The issues have been largely cleared. I did run some code through the visualizer, and 4.7.0 definitely shows the slow downs illustrated above, and the code generated with the exact same slicer settings with the nightly build do not show the random wall slow downs.

Is there a date where we expect a 4.7.2 or 4.8.0 to be released including the fix? I really don't want to be doing customer work on a nightly, but 4.6.x and 4.5.x both included show-stopper issues throughout, so I'd have to go pretty far back to find something workable.

[eoyilmaz]

@dpreed @KimmoHop @msteele999

The nightlies can be found here: https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014539-Darwin.dmg https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002014541.AppImage https://software.ultimaker.com/cura/nightly/Ultimaker_Cura-master.20201002022935.exe

Do note; This is the nightly build from last night. Since our master is considered unstable, it could be that there are other issues with it. As always; it should be possible to install things side by side, but do make a backup of your config folder before using this just to be on the safe side.

Oh snap I should have read your post earlier. I spent like 1 hour to make the master work and then I was trying to figure out why the slicer is not working. It is time to print the 3DBenchy. Will let you know in the morning.

[hrafnkelle]

Just printed a Benchy sliced with the Cura_SteamEngine 4.8.99-master.20201002014518 and Cura_SteamEngine 4.6.2 The front of the hull still shows issues with nightly build that are not visible in the 4.6.2 sliced print.

Attached image shows 3 Benchy, 1st (from left) is sliced with 4.7.1, middle is sliced with the nightly build and the last (on the right) is sliced with 4.6.2. The 4.6.2 and the nigtly build based prints were done just now.

Printed on a Ender 3 in PLA.

Filesize with 4.6.2 is 3945KB, with the nightly build 8902KB.

[eoyilmaz]

I would like to say that, comparing 4.6.2, 4.7.1 and the nightly build, when I use the simulation, on the curvy side of the 3DBenchy model, I still can see the slowing down issue with the nightly and with 4.7.1 where as on 4.6.2 the nozzle flies through those lines, without any hesitation. Now, just because I saw @hrafnkelle 's result. I think I don't want to waste any filaments and any of my time to get the same result.

[smartavionics]

Hello @hrafnkelle , Please try the build at https://github.com/smartavionics/Cura/releases/tag/20200922 and see if it exhibits the same issues. Thanks.

[hrafnkelle]

Here is print using your build @smartavionics The order from left is 4.8.99-master.20201002014518 mb-master-20200922 (@smartavionics build) 4.6.2

Gcode filesize with your build is 6082KB

There is definetly improvement but still showing issues on the curved front hull. However, the definition of the #3DBenchy on the back is great, probably best I've had from my printer.

[Skaifer]

I'm getting approximately same results as Hrafnkelle 3-rd benchy with nightly build. Used settings eoyilmaz recommended. Much fewer zits, but they are still there. With 4.7.1 I got completely fuzzy skin, could not even call them zits. Still not smooth. BUT! Can someone tell me, are those zits random on every print? Cuz, my are random and I'm starting to think I have other issue. But at the same time all good in other slicer. That can not be wet filament or retraction settings.

[chendo]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

[hrafnkelle]

I'm printing over USB from octoprint.

[eoyilmaz]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

I thought the same. I'm printing over OctoPrint with USB. But, in Marlin Firmware, I increased the buffer (from 16KB to 32KB) and the baud rate (from 115.2K to 250K) over the default values. It didn't help. The result I shown on my previous post was already with those settings.

[chendo]

My investigation into this issue indicates that the print quality issue is more significant when printing over USB with something like Octoprint vs printing directly off SD card. Can we clarify if prints are done over USB or SD card cause I think that's a fairly critical distinction.

I thought the same. I'm printing over OctoPrint with USB. But, in Marlin Firmware, I increased the buffer (from 16KB to 32KB) and the baud rate (from 115.2K to 250K) over the default values. It didn't help. The result I shown on my previous post was already with those settings.

My understanding of the interaction between Marlin and Octoprint shows that by default, Octoprint waits for an ok from Marlin before sending the next line, which means Marlin's buffers generally remain empty, so this doesn't help. You can verify this by enabling ADVANCED_OK and seeing if the available command buffer indicated by ok P<planner buffer availability> B<command buffer availability> goes to 0.

My experiments show that printing with Octoprint reliably shows B3 for my printer, which has BUFSIZE set to 4.

So currently, increasing buffers and baudrate doesn't address the issue if Octoprint doesn't fill those buffers, however it can help if you're still seeing print quality issues when printing from SD card.

I've done a more detailed write up on my investigation on my blog post, and another one which measures planner buffer underruns (which causes zits) between gcode generated by Cura 4.6.2 and 4.7.1.

Cura 4.6.2:

Cura 4.7.1:

[hrafnkelle]

Just printed a Benchy from SD card, same Gcode file as before sliced with 4.8.99-master.20201002014518 Results are similar as before so I would not say printing over USB is causing this. Both prints used the same GCode file, gray printed over USB from OctoPrint, orange printed from SD card.

(Filament is same brand, just different color)

[Liger0]

Are you people using stock profiles? No wonders results can be so off if you import the same edited profile with personal resolution and deviation settings on different builds. Stock profiles would be more useful

[hrafnkelle]

My profile is mostly stock but yes I'm using the same profile on all builds. I'm willing to tweak for each build and print if someone wants to guide me what tweaks would make a difference.

[bill-orange]

I am having a odd outer wall problem that may possibly be a symptom of this problem. I am having outer wall defects that change with percent extrusion, layer height and possible wall shape. If I print with a layer height of 0.06mm, find that I get symptoms of over extrusion. The problem resolves if I decrease the percent extrusion to 85%, VERY low. If I print with a layer height of 0.20mm at anything less that 105% extrusion rate, I get symptoms of what appears to be under extrusion (photo attached).

The problem also seem to change with linear vs rounded walls. A very low extrusion rate for highly rounded walls and a much higher extrusion rate for straight walls. It is as if the printing travel speed is not staying well synchronized to the extrusion rate, layer heights and wall shapes. ( in my humble opinion).

Thoughts? Could my issue be an odd consequence of this problem or do I have an issue that I am not analyzing correctly? I have not done regression testing with versions below 4.7.1. I have wasted a lot of filament as it is!

EDIT: I download the latest PrusaSlicer and ran my "straight wall" 0.2mm layer height model. There were no signs of the skipping shown in the photo. One cavate, going from Cura to PrusaSlicer entailed countless other settings changed. Thus, this was clearly a apples-to-oranges test.

Photo of flat 0.20mm layer height flat wall.

[chendo]

As an experiment, I increased BUFSIZE on my printer to 32, and printed a 50% scale Benchy sliced with 4.7.1 from SD card while monitoring buffer underruns. Printing from SD resulted in no planner underruns, however still resulted in overextrusion in the same places around curves. The instructions per second can spike to 200 per second, and considering a print with 4.7.1 is noticeably longer than 4.6.2 as well as the file size being significantly bigger, there are too many instructions for most printers to be able to process.

[gluap]

Independently from any buffer underruns: In the beginning of this issue people were analyzing the g-code and were seeing slowdonws in the g-code that seemed to correspond to the blobs/zits. If the slowdowns are in the g-code they should be independent from any printer buffers. One example where this was shown: https://github.com/Ultimaker/Cura/issues/8321#issuecomment-687835204

Of course the gravity of the zit issue may still depend on printer types, for instance (uneducated guess) bowden printers may produce more zits for the same g-code because they have more lag in slowing extrusion.

Or did I miss something re-reading the thread and the issues with the g-code are already solved?

[nallath]

Bowden style printer actually have this issue less (or well, Ultimaker printers didn't really suffer from it, which is why we didn't see it). I think (but i'm very far from sure) that it has something to do with linear advance on the firmware.

Anyhow, as far as I can see, most, if not all, of the zits in the g-code are gone with the nightly builds I posted.

[hrafnkelle]

I think the prints I posted pictures of show that some of the zits are gone in the nightly build but far from all. Am I misunderstanding your comment @nallath? I have a bowden style printer and I am not using linear advance.

[nallath]

Hmm. That is odd then. Ultimaker printers are bowden style printers and aren't using linear advance.

What settings do you have for the max resolution?

[hrafnkelle]

I have not touched that setting since I'm not familiar with it I had

• max resolution 0.05mm
• max travel resolution 0.05mm
• max deviation 0.025mm in the profile that was used on the 4.8nightly build

I am willing to print more with changed settings if you suggest other values for this or other parameters.

[nallath]

For the UM3 the settings are: Maximum resolution: 0.5 Max travel resolution: 0.7 Max deviation: 0.025

Since that's a pretty big difference, I think it might be a good idea to test the max resolution at 0.25 or 0.5 and see what happens.

[ClockeNessMnstr]

The settings were irrelevant weren't they? The g-code was causing slowdowns that shouldn't have been there regardless of the settings? Is that already fixed and people are still having issues?

A separate note to bring back up. I had gone back to Cura 4.3 I think with the version that came with the ender 3 V2. There were still random slowdowns around the forward hull perimeter of a benchy. They were very few and far between but I was hoping when this issue was fixed that we would also see what was causing them before.

[CCS86]

I think the issue has at least two causes:

1. There are actual discontinuities in the curve paths, with segments that should be tangent but angularly separated, also having a translation. These can be seen in gcode visualizers as slow downs because the printer needs almost stop "forward" momentum, to make the sideways shift. I would imagine this is more printer agnostic, since it is a pure motion kinematics issue.

2. The increase in tiny print segments causing motion planner slowdowns. This would vary a bit between controllers because it is more of a calculation bottleneck.

For the record, I am running an Ultimaker Original with a Duet Maestro board; no linear/pressure advance. Fast controller, with a bowden printer.

[nallath]

The settings were irrelevant weren't they? The g-code was causing slowdowns that shouldn't have been there regardless of the settings? Is that already fixed and people are still having issues?

Well, it's a bit more complicated than that. There were very teeny tiny segments that should have been deleted that were not deleted. That issue has been fixed.

That obviously doesn't mean that all issues regarding line segments per second are fixed. It's a complex problem that we've been fighting for a long time. Not every machine has the same number that it can handle and it can result in multiple symptoms that need to be fixed all over the place (Hardware, Firmware, Slicer)

A separate note to bring back up. I had gone back to Cura 4.3 I think with the version that came with the ender 3 V2. There were still random slowdowns around the forward hull perimeter of a benchy. They were very few and far between but I was hoping when this issue was fixed that we would also see what was causing them before.

That's kinda the problem with complicated systems in general. There is no such thing as "changing just one thing". Almost eveyrthing can theoretically impact everything else (this is also why we didn't spot it upon first release, why it's taking so long to really fix it and why we depend on people testing it; We need as much different configurations as possible).

[hrafnkelle]

Here is a picture of two benchys sliced with the 4.8.99-master.20201002014518 build The one on the left is sliced with max resolution set to 0.05 and the one of the right is sliced with max resolution set to 0.5 The "fuzzyness" and zits are gone on the curved front of the hull when setting max resolution to 0.5. Great!

There is however a discontinuity in the layers where each layer starts/ends (the seam). It is very easy to feel by finger and visual as you can see on the photo.

[rburema]

@hrafnkelle The wrong seam placement is (probably) caused by another bug we're still working on. We hope/'expect' to get that in before 4.8 final as well. (Maybe even before beta?)

(To other devs: Ticket for the misplaced seam is known in our internal system as CURA-7769)

Edit: It is probably related to the initial 'fix' though.

[hrafnkelle]

How should the maximum resolution parameter be tuned? It seems neccecary to adjust it for 4.7 and eventually 4.8. New defaults need to be created for at least ender 3 for this value.