[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

[hrafnkelle]

@rburema To me the discontinuity isnt just the seam, it seems the whole straight part leading to the seam is higher/further out than the curved part. This doesnt look like a misplaced seam, the whole straight part of the layer is misplaced?

Hope the photo below shows what I mean

[rburema]

@hrafnkelle I think I see what you mean. Odd, as that sort of thing should have been fixed by https://github.com/Ultimaker/CuraEngine/pull/1336 which was merged one or two days before the nightlies you're using. (Though I'm not 100% convinced that it isn't the seam.)

[colatuttorf]

@rburema To me the discontinuity isnt just the seam, it seems the whole straight part leading to the seam is higher/further out than the curved part. This doesnt look like a misplaced seam, the whole straight part of the layer is misplaced?

Hope the photo below shows what I mean

I have this same issue above using in the Nightly posted above. I had thought at first it was a layer shift, but its repeatable across multiple printers and various slicer settings. Going to do a bit more investigating and fiddling with the resolution to resolve, but it appears that the slicer is shifting the model along a boundary of two triangles in the stl file. Its in a straight wall, so might be a different issue altogether.

[bill-orange]

@hrafnkelle Did changing the max resolution from 0.05mm to 0.5mm cause any collateral damage? For instance, was the text on the stern intact?

0.5mm seems pretty course.

[hrafnkelle]

Tried to take as detailed photos as I could. You should be able to zoom in alot since the resolution is high.

The text on the stern is there, not very readable, seems to have some zits but I can't tell if it is just in this print or general.

[nallath]

Well, it doesn't have to be 0.5 of course. It can be lower than that. I do think that the number might need to be higher than what the default creality profiles have now.

[hrafnkelle]

I just did a series of test prints on the bottm 30 layers of a benchy without infill, varying the maximum resolution I did a "bisection search" between 0.05 (default ender profile) to 0.5 (the UM3 value and value tested yesterday). This suggested that the lowest acceptable value af max resolution is 0.187

I did print a benchy with that setting with ok results, few minor zits. This suggest perhaps a value around 0.2. Could others try that value using the nightly build as well.

Pictures of the benchy shells and a Benchy attached.

The benchy still shows the discontinuity at the seam. Perhaps nozzle pressure issue because of the slowdown when going beteween perimeters?

My printer is an Ender 3 with stock hotend. Fans and bowden tube have been upgraded but I dont expect that to have an influence on this. Firmware is Marlin 2.0.7, no linear advance

[Ghostkeeper]

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.

Quite a complicated matter, honestly. Consider the amount of line segments the printer can handle. This will be different from printer to printer due to capabilities of firmware and electronics, so let's take the example of about 200seg/s for the Ultimaker 2 (Ultimaker's fastest printer). Then take the fastest print speed into account where you'd like to prevent these underruns from occurring. For instance, maybe you don't find it important during printing infill, so you take the inner wall print speed of 60mm/s. So in 1 second you can print 60mm and 200 segments. That is 0.3mm per segment. This is your theoretical maximum resolution for an ideal curve.

Your print is not an ideal curve though and this is where it gets complex. There is a Maximum Deviation setting too which adds segments. And Wall Overlap Compensation can split parts of the segments off, which is done after the resolution is reduced so this can cause the number of segments per second to rise. So it's good to take some leeway. On the other hand, not all prints are a worst-case so it could be acceptable to have buffer underruns sometimes. This is best done with extensive testing but just from gut feeling I'd put the Maximum Resolution then on 0.4mm or so for the UM2. In actuality it's 0.5mm in the profile, probably because the Maximum Resolution setting was added when the profiles for UM2 were already tuned, so it's just using a sane default.

But yes, 0.05mm is incredibly low. 0.3mm is more realistic as to what your printer can reach.

[Ghostkeeper]

I think what contributes to the confusion here is that the simplification algorithm in 4.6 and before simplified the shapes way too much with very low Maximum Resolution. This is one of the bugs that was fixed, but since the Creality settings set their Maximum Resolution very low, this change greatly increased the resolution for them, resulting in buffer underruns for them.

[Skaifer]

Nightly build - much better than 4.7 but still has some zits, resolution 0.4, travel resolution 0.5, deviation 0.025. Cura 4.6.2 - Much cleaner, same settings as nightly. Cura 4.7 - worst case scenario with standard settings.

I hear no poping sounds, and z seam is always on the back. And I've checked gcode with the latest resolution settings nightly build, and there are no more sudden changes in direction resulting in speed drops. So, there's something else going on. I'll try to print with the new filament and change nozzle later on. As those are last resort changes that could possibly affect quality on my end, that I could think of. And prints were made off SD card.

[rburema]

@Skaifer Thanks for the report! Please also take @Ghostkeeper last comment (just above yours') into account.

In other words: We don't expect the 'same' simplification settings to behave exactly the same in 4.6.x versus later, since one of the things we fixed for 4.6.0 was the oversimplification given the settings. That is, if you specified this and that length or angle to be kept as 'maximum allowed' it would sometimes still smooth things over (merge two line-segments into one) even when the settings said not to allow that. Part of that was taken into account in the upgrade scripts, but of course the defaults of printers where tuned to the old (wrong) behaviour.

So, to summarise:

• In 4.6.x: Wrong, but 'papered over' (by the tuned printer settings) behaviour for the simplification.
• In 4.7.x: A (broken) fix which attempts to address the issue above, but instead it under-simplifies, rather than over-simplifying. This can cause problems depending on the printer-model.
• 'Next': The new fix(es) for the upcoming (beta) release(s), which (hopefully) finally fix at least the above problems, but for which simplification parameters might have to be re-tuned, depending on how much the old default parameters for that printer depended on the 4.6.x behaviour.

[nallath]

Can anyone also check if these zits happen in the spot where they see the slowdowns in the g-code (just to confirm it's really the same problem!)?

[Skaifer]

Hey, I found out something. Horizontal expansion has something to do with these speed drops, because when I set expansion to zero those spots become much less noticeable. That setting amplifies the issue, I guess. Here are some screenshots from gcode analyzer. With positive expansion With negative expansion Without expansion but high resolution, 0.05 and deviation 0.05. There are still in some places these weird spots. Because they are small it isn't as noticeable zoomed out. And with resolution 0.5 deviation 0.05 I can't seem to find these artifacts anymore. But if I increase expansion with lower resolution, those spots appear again. Also, with different combinations of these two settings spots appear on different places.

I'll make a test if these spots actually affect quality later. Had to mention I have CR-10s with original mainboard.

I sliced benchy with expansion and high resolution, strange, but my model has more obvious spots than on benchy, but still, there are slight speed drops and these diagonal inserted moves or something. Here is example.

[Skaifer]

Good day to you, reader! So did two test prints. One with target to eliminate all zits decreasing resolution quite a bit. Resolution 0.8, travel res. 0.5, deviation 0.025. Results in completely smooth surface. Well, at least as it was before.

Then I ran a second test with same resolution settings but negative horizontal expansion. Horizontal expansion -0.05 Can't see any defects on points where it should be according to gcode analyzer. There should be around 8 spots, but nothing. Although, this print did not turn out as clean as the first one without expansion. There are some zits on the other side where analyzer showed nothing unusual.

Maybe gcode analyzer misinterprets Cura gcode? Or those spots are so small, that it does not show up on the end result? Anyways resolution gives the most profit on quality. Maybe the only thing expansion does, amplifies resolution defects.

[rburema]

@Skaifer We have a report from an internal user now too, that shows some blobs (way less, but) still show up in actual print. We've got one fix in code review (which originally was for something related but slightly different, that I now think also might already fix the last blobs) and I'm working to see if we need another one after that.

Though, reading your message, I'm glad there is already a workaround for the current level of 'fixedness' for a lot of our 3rd party users then.

Actually, since I'm testing a few things, would you be able to attach the dog model?

[dpreed]

A suggestion from a computer systems hacker viewpoint on this general issue of "zits" is at the end of this comment. But it may also be interesting for some of the other readers of this discussion of the "zit problem" in 4.7.0, which can also appear in other slicers, I am convinced. It's useful to understand how tenuous the connection between g-code description and the actual plastic deposition can be.

From the various reports, I am starting to believe that these "zits" come from a single cause which is only indirectly slicer related. And one which cannot be detected directly in a gcode analyzer. I observed similar zits on a completely flat surface that is preceded by a very complicated surface around the corner from the surface with the zits.

This cause is inside the printer firmware, where the gcode is translated into the input to the motion planner. In my case, the translator is Marlin, and the target is a delta hardware system.

In such a system, there is a buffer between the gcode analysis step and the motion planner. What happens when that buffer holding motions is empty? The mechanism stops moving (very precisely in the case of nozzle position) but the chamber behind the nozzle is at a pressure sufficient to continue pushing out a little bit of filament. A "zit".

Now I think some of this discussion's contributors understand this issue - that a "buffer underrun" can cause a "zit".

But looking at the g-code doesn't show the cause of the underrun. The underrun isn't caused by a particular g-code line. It's not caused by precision of positioning.

And the underrun doesn't directly cause the zit - that's caused by the fact that stopping moving the extruder doesn't stop the pressure-driven emission of molten plastic immediately.

Extrusion is done to manage pressure (not volume directly). To get uniform deposition of plastic, there must never be a stop in the uniform motion of the nozzle along the skin of the print.

Now in a delta this is possible in a "straight line" motion, because the three stepper motors are being accelerated and deceleerated when the nozzle is moving uniformly. This is why the motions of the steppers are broken down into steps by the marlin firmware.

Of course in a cartesian printer, "curves" (actually polygons when emitted as g-code) are broken down into small segments, too.

But the common thing here is that anything that causes an underrun in the motion planner's buffer of segments to be output will likely cause a zit, if the underrun is not very brief.

Unfortunately, firmware doesn't report underruns that occur during a print. And no g-code analyzer can do so, unless it contains an cycle-accurate emulator of the firmware running on the printer.

I've been doing some research on Marlin's design, as have others.

But the key thing here is that to underrun the buffer between g-code interpretation and motion planning involves some very printer-dependent issues.

While it depends partly on always making sure g-code is delivered to the printer, that isn't the only problem to be managed.

Even if g-code is available, if g-code processing can't keep up with all steps of the motion, underruns will occur, sometimes because of segments that are not fully copied into the buffers that directly drive the steppers.

And note also that zit-position is not necessarily at g-code move boundaries. Whereever a buffer underrun happens to occur is where the zit will be.

This suggests that slowing the overall feed rate may be one of the best ways to avoid underruns, but of course that isn't perfect - slowing the feed rate on a layer isn't easily made automatic in the slicer. And remember, feed rate doesn't directly control plastic flow out of the nozzle - because the extruder stepper only indirectly controls it via pressure changes in the chamber. A constant feed rate is far more stable and predictable in its effect.

The user can retune their printing settings for a slower overall feed rate, but what they are tuning for would be a lot easier to tell if the firmware reported on buffer underruns that occur during a print.

I've been thinking that one way to explore this is to avoid a g-code analyzer, and instead use a dry-run of the printer firmware where the stepper outputs are completely disabled at the logic level. Of course this will take as long as the print. The underruns can be detected (ideally logged into a fast log buffer) in the hardware.

Obviously, this is not an end-user friendly feature. For a print, it takes as long to run as the print itself. But this could both be a good quality control test for slicer+firmware combo, and also help figure out how best to tune the slicer in general.

[rburema]

@dpreed Thanks for the write-up, it'll explain some things for the people unknown to this aspect of 3D-printing nicely.

We're familiar with the buffer-underrun problem, and it is one of the reasons why this is so hard to debug (especially from a distance, for printers we don't have here to test with). And it is indeed part of the reason at least the bug in 4.7.x is large for some models of printer, while others hardly notice.

However, when I mentioned that internal report, it specifically investigated that, and was still producing blobs while the buffer should have been OK, given the amount of separate actions/second that where produced. I know you didn't claim so, but it still seems prudent to mention that buffer-underruns can't be the entire story.

[claytono]

@dpreed FWIW, Klipper does actually report underruns for this sort of problem. The field in the log lines is print_stall. It can also print to a simulated AVR processor: https://www.klipper3d.org/Debugging.html

[Zogar89]

What viewer have you used to generate those images?

[Skaifer]

@Zogar89 I guess it's - gcode.ws. There's "Render line slightly transparent", under 2D render options tab.

@rburema It's paid 3D model, I can't share it. I'll find alternative model, that behaves similar and share that tommorow, ok?

[nallath]

For those interested, yet another set of improvements are proposed in this PR: https://github.com/Ultimaker/CuraEngine/pull/1345

[Skaifer]

@rburema Ok, printed French bulldog from Thingiverse and it prints just like mine model. Included profile just in case. Just make sure to lower it by few millimeters on z axis. Printed 5 cm in height.

Standard settings And 0.8 resolution without expansion.

[Ghostkeeper]

We've released the 4.8 beta today, so there'll be another version with our latest fixes on this matter. As far as we've seen the issue is resolved completely now.

However for Creality users there will be one remaining issue: Your Maximum Resolution is set to a value that your printer just can't handle. We don't know how to tune this for you, so I hope that someone is able to determine better defaults for that printer before the stable version.

[Zogar89]

Compare the size of the files in 4.6 and 4.8 beta to see if the amount of code generated is back to normal. It can be misleading if we get the same quality as before with more information since this chokes the controllers of the most modest printers.

[Sebazzz]

However for Creality users there will be one remaining issue

Does that also apply to 32-bit boards? I'm also curious what the resolution was in Cura 4.6.x where this issue didn't happen - That that is where the correct number is, isn't it?

[gluap]

@Sebazzz I've been following this issue for some time and I think the gist is that Cura 4.6.x was over-simplifying during simplification steps. The maximum resolution setting for creality printers used in cura 4.6.x profiles was matched to that over-simplifying simplification algorithm. The over-simplification issue is now fixed, so the same setting(s) as 4.6.2 will yield much higher resolution g-code with cura>=4.7. Therefore a new sensible value for maximum resolution needs to be found for creality printer profiles.

32 bit boards may be able to handle a higher resolution thanks to their computing power -- Another factor may be whether the user is printing from SD or via USB (and if he's printing from a computer via USB the exact limits may depend on the software dumping the g-code into the serial connection, for instance octoprint has some limits on how fast it supplies g-code to the printer).

[dpreed]

I'd like to make a small suggestion (based on my experience with a 32-bit delta printer running Marlin on a 72-MHz STM32 processor. Deltas being different in how they manage motion for the same g-codes.

Here's my first-order observation. Printer firmware like Marlin use a pipelined strategy to process g-code. They do not directly map gcode into stepper-rate-segments. Instead, in order to handle varying acceleration, and the delta inverse kinematics dimensional transformation that maps linear motion into non-linear pulse sequences on 4 stepper motors, they queue (into a modest sized buffer) a series of small motion blocks.

This pipelined structure creates an internal, variable depth FIFO buffer of motion blocks whose timing is only loosely coupled to the g-code processing rate.

When g-codes cannot be processed quickly enough by the gcode interpreter and then the motion planner, eventually that internal buffer of motion blocks empties. This may happen at a very different position on the tool path of the nozzle and extruder than the point where the g-coide runs out.

Thus, quality defects may not even show up on curves or highly detailed features, but elsewhere.

This is a worse problem on 32-bit systems, delta systems, etc, because of its "asynchrony" relative to the slicer's view of what is going on.

As a result, users will not be able to correlate quality issues with the cause, and they may not know what settings to change.

As an example from my own experience with 4.7.1, I observed zits on a completely flat "straight" run on a side of a box where the adjacent side had detailed lettering (and only on the vertical position where the lettering occurred, not above or below). The lettering looked GREAT. What I slowly was able to determine was that the straight side wasn't "straight" to the delta motion planner in Marlin - it was a series of small segments because the natural motion of the 3 steppers creates spherical lines, unlike cartesian printers.

So, what we really need, both from the slicer and the firmware, is a way for the user to know what the cause of the problem is, and what they can control in the settings. I suggest two parts to a remedy:

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

2) the slicer needs to be able to be managed by the user (via some kind of settings?) how to control the gcode so that these conditions won't happen subsequent to the gcode in question.

Neither the slicer nor the firmware can manage this problem without user help, and the user cannot manage the problem unless they can "see into the state of the firmware" enough to do something.

What worries me is the assumption that 32-bit processing is enough. It isnt.

[bill-orange]

@Sebazzz Your idea is well worth posting on the Marlin Github site as a feature request.

[chendo]

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

I've opened a PR https://github.com/MarlinFirmware/Marlin/pull/19674 which adds buffer monitoring to Marin that aims to achieve this. It can report command and planner buffer underruns, as well as the max time in milliseconds of each underrun between the report interval. It does not report exactly where the zit occurs in the stream, as for 4.7.1 sliced gcode would easily overwhelm the serial TX buffers which would add more delay when printing over USB unless buffers were filled. I'm still awaiting feedback on the PR however.

I am working on an Octoprint plugin called BufferBuddy (https://github.com/chendo/BufferBuddy) which aims to mitigate print quality issues when printing with Octoprint by keeping the command buffers full. However, the segments generated by 4.7.1 are so small that it cannot eliminate planner underruns entirely.

[Ghostkeeper]

Thus, quality defects may not even show up on curves or highly detailed features, but elsewhere.

True. Only, we are speaking here about line segments on the order of magnitude of 0.2mm, and buffer sizes of 16, so it's normally only one or two millimetres off. It would slow down slightly before the high-resolution curve, as it sees the motion buffer getting almost empty.

1) the firmware should be able to report when it is causing zits. This is when the steppers cannot continue to drive the tool as expected. Two facts need to be captured/logged: a) where the zit is on the model, and b) where in the gcode stream the underrun occurs that causes the zit. Those are not the same, and the slicer doesn't know enough to predict the problem.

Ultimaker printers actually do log planner buffer underruns happening. It's not visible in the screen or anything, but it is present in the logs.

2) the slicer needs to be able to be managed by the user (via some kind of settings?) how to control the gcode so that these conditions won't happen subsequent to the gcode in question.

This is what Cura has the Maximum Resolution and Maximum Deviation settings for, really.

[BagelOrb]

I've made a model for testing resolution specifically. resolution_checker_2.2.stl.zip

The screenshots don't show as much difference as I had hoped.

4.6:

4.7:

4.8 beta:

[Liger0]

Indeed, the circular parts aren't really working as they should on 4.8 beta (cr10s, 0.05 on max deviation and resolution)

[Asterchades]

If you're referring to the yellow extrusions at the top of the circles, that's completely unrelated and should be addressed when Arachne gets implemented. Circles when expressed as polygons rarely have even wall thicknesses which makes filling the middle portion awkward.

Also, 0.05mm maximum resolution is far too small for a CR10s now that the setting is working properly - especially if you're using the stock electronics. At 50mm/s that would allow for up to (though never actually reaching) 1,000 segments/second, which the printer simply cannot handle. You'll want to increase that to at least 0.25mm, if not as high as 0.5mm depending upon your print speed.

[Liger0]

I am referring to them, in the sense the segments are too much long, making it look a low-amount of lines polygon rather than a circle, so the perimeters don't touch and the result is a very weak piece.

I am using a 32-bit board with LPC1768, skr 1.4, and sd card. I tried all of the settings but the internal gap fill is still too much scattered.

[Asterchades]

Different issue, then. Arachne should fix it, but in the meantime you could try a narrower Wall Line Width (drop by 10-20um) or perhaps give SmartAvionics' build a try instead (he uses a different formula for gap fill - https://github.com/smartavionics/Cura/releases). Adjusting the maximum resolution settings won't change that in the slightest as they're not causing it.

Personal experience with an SKR Mini E3 v2.0 has 0.3mm maximum resolution working just fine at 60mm/s. In fact that's specifically being calculated from the speed setting divided by 200. Could probably push it further but I'm yet to notice any visible reason to do so - even printing 32mm miniatures.

[Ghostkeeper]

Indeed the yellow lines in Liger0's cylindrical extrusions on that screenshot are generated by first drawing small line segments to fill the gaps and then combining those small line segments together. The line segments are a simple lines pattern with 50% line width so this is independent of the Maximum Resolution setting.

It would be good if one or two of you could run a few tests with high-resolution parts to see what value for Maximum Resolution works for your printer in the 4.8 beta. Benchy is a good test for this. It doesn't have to be an extensive test, if time is short, but we can make at least some improvements then for the Creality users.

[hrafnkelle]

It would be good if one or two of you could run a few tests with high-resolution parts to see what value for Maximum Resolution works for your printer in the 4.8 beta.

I did a small test max resolution on Benchy like I posted earlier in this thread https://github.com/Ultimaker/Cura/issues/8321#issuecomment-709235235

Is this similar to what you have in mind @Ghostkeeper?

I can repeat these tests with the 4.8beta on my Ender 3.

[Ghostkeeper]

Yes, that is exactly what I had in mind, @hrafnkelle but then with the 4.8 beta. With the improvements in the 4.8 beta I'd expect no big changes w.r.t. the motion buffer, only changes that might lead people to believe they had a buffer underrun going, so perhaps you can narrow the binary search somewhat.

[hrafnkelle]

Are we checking for issues because of underruns or because of changed simplifcation algorithm? If because of underruns then the controller hardware matters I guess. I have upgraded to a 32bit board. I can put the 8bit stock board back in if that would be more helpful. Or I can print from SD card to eliminate the influence of printing over serial/usb.

[bill-orange]

@Ghostkeeper In earlier posts you referred to Arachne. What is that?

[rburema]

@bill-orange It's the '''code-name'''* for our variable line width strategy/implementation, which is someday going to be in CuraEngine. We're working on it (at least) a little each sprint now. You can find the big draft PR here if you're interested: https://github.com/Ultimaker/CuraEngine/pull/1210

*] Well... it was originally going to be the name of the separate library before we decided to merge it into CuraEngine. The name stuck when discussing it though!

[Liger0]

I noticed max resolution and standard deviation are not saved in the profiles when exported, is it normal?

[BagelOrb]

Any setting is not saved if it's not changed (or if it's the same as what's already in the default profile).

[c3-eng]

Just downloaded 4.8.0 in replacement of 4.7.x. The "Vase mode zits" problem frustratingly persists as shown, even after endless changes to maximum resolution and deviation.

I am running Modix Big 60 Printer with 32 Bit Duet Wifi board. Printing at 80mm/s.

[hrafnkelle]

Max resolution of 0.25mm with max deviation at 0.025 gives me a very nice Benchy on my Ender 3 with a Skr e3 mini 2.0 board. I printed from SD card. Before printing I printed a few Benchy hulls (first 28 layers) with no infill, varying the max resolution from 0.05 to 0.25 At 0.15m it was almost acceptable with a smooth surface at 0.25mm

It still suffers from the discontinoutiy at the seam like I reported in https://github.com/Ultimaker/Cura/issues/8321#issuecomment-708487496

[msteele999]

I'm still seeing my original problem which is defects on the edge following a curve. Changing Max res to 0.25 and max dev to 0.025 I still see the problem areas. But now, I see them clearly in the slice. It looks like the layers are not ALL starting at the same point. I have Sharpest Corner / Smart Hiding turned on so all the layers should start in the same spot. I am assuming this is no longer an 8321 issue and wonder if I should start a new issue?

[image: Screenshot_102720_090655_PM.jpg]

On Tue, Oct 27, 2020 at 7:03 PM Hrafnkell Eiríksson < notifications@github.com> wrote:

Max resolution of 0.25mm with max deviation at 0.025 gives me a very nice Benchy on my Ender 3 with a Skr e3 mini 2.0 board. I printed from SD card. Before printing I printed a few Benchy hulls (first 28 layers) with no infill, varying the max resolution from 0.05 to 0.25 At 0.15m it was almost acceptable with a smooth surface at 0.25mm

It still suffers from the discontinoutiy at the seam like I reported in #8321 (comment) https://github.com/Ultimaker/Cura/issues/8321#issuecomment-708487496

— 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-717591483, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRMUYILIR2E7MO2XXRZVNLSM5GVJANCNFSM4QYPYE7A .

[bill-orange]

@c3-eng If you print at a lower speed, say, 60 mm/sec, do you see the defects?

[rburema]

@msteele999 The maximum deviation controls how much the shape may differ. Lower values => shape may differ less => less simplification is applied (unless something can be removed without deviation) => less simplified shape is more likely to give blobs and zits for certain reasons. Sorry, I misread the comment.

[Ghostkeeper]

@msteele999 I think it would be best to keep issues with the seam placement to a different thread. There you can upload a project file that will allow us to reproduce the problem and take a look.

[msteele999]

Understood - I created a new issue

On Wed, Oct 28, 2020 at 7:20 AM Ghostkeeper notifications@github.com wrote:

@msteele999 https://github.com/msteele999 I think it would be best to keep issues with the seam placement to a different thread. There you can upload a project file that will allow us to reproduce the problem and take a look.

— 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-717867906, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABRMUYNENXC5ETTO2Z2HRXTSM7463ANCNFSM4QYPYE7A .