Open krhackbarth opened 6 years ago
That looks a lot like a problem I was having printing Benchys when I first switched to Slic3r from Cura. At the point where the deck of the Benchy was printed I'd get an artifact that looked like that. I mostly resolved it by changing my cooling settings so my fan was always at least at 50% (Slic3r was turning off the fan because the layer time was more than 60 seconds) but it never went away entirely.
Have you looked at the layers? Does the deck go all the way to the outer surface of the benchy or does it stop at the gunwale?
On the back of the benchy it goes all the way to the inner layer of the perimeter. At the front of the benchy it does not - there's infill there. So I didn't get a solid layer, but still saw artifacts around the print due to insufficient cooling. I don't believe Cura tries to do smart fan control, so it was always blasting the fan at full power and I didn't see any problems. But I think that even if Slic3r was creating the same layer as Cura/Simplify3d you might see the same artifact just because that layer takes a lot longer to print so it would turn off the fan.
I am also having this issue with a "false top" layer. It seems that whenever there is a flat face followed by another feature, in the same homogeneous part, that this happens. It is far from desirable as it makes the parts weak at this "seam". I should also mention that I have not had the artefacting issue.
This seems to be similar to https://github.com/prusa3d/Slic3r/issues/1719
We had a discussion on Facebook recently, see https://www.facebook.com/groups/prusacommunity/permalink/922016038139129/
There are multiple effects in play, therefore some of your prints may show a different effect than the prints from the others. Ideally we would compare apples to apples, we would work with Slic3r's 3MF files that contain all the modifiers and parameters, so we can keep track of most of the variables in play.
First, the Slic3r's logic to extend the solid infill is there to anchor the solid top infill into the sparse infill. The logic is sound, but it has its drawbacks as you guys found out, it consumes material , it adds to the print time, and currently it is not configurable in Slic3r. Cura and S3D just do not extend the infill, thus you may see gaps at the bottom of your boxes as you already have found out as well. In the future versions of Slic3r, we may make the extension into the solid infill configurable.
In addition, Slic3r applies perimeter-infill overlap to close some of the gaps between the solid infill and inner perimeters, which it may have a negative effect on the accuracy of the outer wall. You may try to decrease the overlap number with the risk of getting some gaps in solid infill, the config parameter is available to you.
Then there is sometimes an effect of thin walls being extruded with just perimeters with no infill, and it may happen, that the wall thickness is not an integer multiple of the extrusion width (this is again a bit complicated by the fact, that Slic3r calculates the wall width as the tangent width giving the "corrugated iron sheet" surface of printed vertical walls, you will find a "recommended object thin wall thickness" hint at the Print Settings -> Layers and perimeters page for a given integer number of perimeters), so Slic3r will produce some overlap of the inner most perimeters to fill in the space completely, if the "Detect thin walls" feature is disabled. If you enable the "Detect thin walls", then Slic3r will fill in the remainder inside the inner most perimeter with a single line. Unfortunately the "Detect thin walls" feature currently may produce some unwanted single line extrusions at sharp protrusions of a model, therefore we have it disabled by default in our profiles. In the future, we will split the "Detect thin walls" to "Thin walls inside / Thin walls inside and outside" the way it has been done recently in S3D. By the way, S3D's recent implementation most likely copied from the initial gap fill algorithm implemented some 3 years ago in the original Slic3r, as it manifests the same behavior including the negative artifacts (read bugs).
Lastly, it is the physics as others noted. Plastics, if extruded first from pellets into a filament, and then from filament into a very thin rectangular extrusion, will behave neither as a liquid, nor as a solid. The stretching of the plastic will align the long molecular chains of the polymer, introducing internal stresses to the extrusion. This internal stress will pull the extrusion together if not cooled quickly enough. Indeed, as many of you found out, in a cool basement the effects are more pronounced, also on my MK2 the 3D Benchy has the line more pronounced at the side away from the cooling fan.
So, it is "just" physics, and it will be very difficult to compensate for the internal stresses and cooling effects of the filament IMHO, one of the reasons being the viscoelastic behavior of the molten plastics, and the dependence of the plastic behavior on its composition, temperature, hydrolisis of the polymer molecular chains if the filament is not 100% dry (polyesters - PLA & PET are sensitive to hydrolisis, hydrolised filament contains shorter polymer chains, thus being less viscous), effectivity of the cooling, reflections of the cooling air from the already printed objects etc.
In the future versions of Slic3r, we may make the extension into the solid infill configurable.
commits: supermerill@d21c33e9b5777ade5c5644e088a4a696d153070a and supermerill@47ad0dad775458edc9c0d9d817ef517f301c0c96
Then there is sometimes an effect of thin walls being extruded with just perimeters with no infill, and it may happen, that the wall thickness is not an integer multiple of the extrusion width
When you will be ready to evaluate, i can pr the last thin wall code. With a threshold of (no more than) 100%, it resolve this issue.
In addition, Slic3r applies perimeter-infill overlap to close some of the gaps between the solid infill and inner perimeters, which it may have a negative effect on the accuracy of the outer wall. You may try to decrease the overlap number with the risk of getting some gaps in solid infill, the config parameter is available to you.
I created a function to resolve this problem: I stored the not-overlap area and with that, i can compute the exact amount of plastic that need to be extruded, and change the flow % to prevent under and over-extrusion. It's a bit complex so i need to create a pr also for this one.
I know you don't have time for that, but i write this here for reminder, feel free to ask me in slack when/if you want something.
What is the status of this issue, I have been seeing it for ages and have only come to realize what it actually is. This definitely seems like an issue baked into Slic3r and its branches. It is essentially eliminated by using another slicer and is quite an issue. Is anybody working on a fix for this?
this problem continue without fix
@rtyr this issue is still happening in PS 2.4.2. Is there any update on this?
This problem is alive and well, and this ticket is now over 4 years old. Is anyone looking into this?
Recent thread on the topic: https://forum.prusa3d.com/forum/original-prusa-i3-mk3s-mk3-how-do-i-print-this-printing-help/buldge-when-print-reaches-solid-layers/paged/23/#post-630455
I'm seeing this problem now with the new organic supports in 2.6.0-alpha4 version of PrusaSlicer. I've printed this model twice now, and I get both an over-extrusion and under-extrusion on the same layer right when one of the major trees has a fork.
I checked these layers and there isn't any solid layer being placed here (in the model or the trees), so I can't see anything unique other than this fork.
3MF: https://www.dropbox.com/s/1ribiouuif4e6vj/tray_v8.3mf?dl=0
GCODE: https://www.dropbox.com/s/uaycehgy7x33hfb/tray_v8_0.2mm_PLA_MK3S_12h39m.gcode?dl=0
Be awesome to see this get serious attention.
I have 3 files to try with 3 different ways I am going to try and eliminate the line.
Here is number two in print form.
Number 3 in print form
Number 1 still has line but alot less noticeable. So next test will be a hybrid approach to Number 2. Goal is the solid top but not in a way that the slicer thinks it's a 'solid top'
Same issue here with the latest release. I'm getting bulges on transitions where the horizontal size of the layer changes. It seems to be most prominent where the layer changes from big horizontal to small (long time to short time). I've been testing with different settings, to no avail yet. Interestingly, the change started/became more apparent when I upgraded from my stock cooler to dual 5015 coolers. I've got autospeed turned on, limiting the volumetric speed to 3mm^3/s (40mm/s) really helps a lot.
Version
Version of Slic3r used goes here Slic3r PE (Prusa Edition) Use
About->About Slic3r
for release versions version 1.40.0+win64 For -dev versions, usegit describe --tag
or get the hash value for the version you downloaded orgit rev-parse HEAD
Operating system type + version
What OS are you using, and state any version #s Windows 10 Home
Behavior
Is this a new feature request? No files.zip
STL/Config (.ZIP) where problem occurs
Upload a zipped copy of an STL and your config (
File -> Export Config
)