Infill extrusion width getting way too wide when printing thin Layers

[simonkuehling]

I'd like to open a discussion about the maximum extrusion width used for a specific nozzle diameter.

My reference setup:

• Nozzle diameter 0.35mm
• Extrusion widths all in "auto" mode (=0)

With these settings, for 0.1mm layers i get an infill extrusion width of 0.98mm, which is 2.8x the nozzle diameter:

; generated by Slic3r 1.2.6-dev on 2015-01-29 at 23:39:38

; external perimeters extrusion width = 0.35mm
; perimeters extrusion width = 0.59mm
; infill extrusion width = 0.98mm                         <-----------------------------
; solid infill extrusion width = 0.59mm
; top infill extrusion width = 0.59mm
; support material extrusion width = 0.35mm

For 0.05mm layers i get an infill extrusion width of 1.93mm, which is 5.5x the nozzle diameter:

; generated by Slic3r 1.2.6-dev on 2015-01-30 at 00:10:27

; external perimeters extrusion width = 0.35mm
; perimeters extrusion width = 0.59mm
; infill extrusion width = 1.93mm                         <-----------------------------
; solid infill extrusion width = 0.59mm
; top infill extrusion width = 0.59mm
; support material extrusion width = 0.35mm

I think there should be some (static?) limit for the maximum extrusion width a nozzle can safely handle in the automatic calculation. This may depend on the shape of the nozzle tip of course - meaning that a bigger diameter of the flat face on the tip could possibly print wider lines than others, but i think we can find a safe value that fits most hardware designs. Something like 1.5-1.6x the nozzle diameter would be my suggestion (which still may be manually overwritten in the Print Settings) - but i'd really like to hear other's opinions on this as well!

Edit: The full config files for reference config.ini for 0.1mm layers config.ini for 0.05mm layers

[alranel]

@simonkuehling, as you can see a limit is applied to other widths. But for internal infill we just use the full flow since we have room for the extra volume. Do you see any physical problem caused by this?

[alranel]

In other words, in case of internal infill we extrude a constant volume. Then you see a width in the G-code comments that is calculated by dividing that volume by layer height, and that produces the large number. But in fact that's just a volume...

[simonkuehling]

@alexrj, yes - the reason i came up with this issue is that there is indeed a physical limit of the maximum trace width a nozzle can successfully lay out.

I'll add some pictures to illustrate the effect of this - a part printed in 0.1mm layers, all extrusion widths automatically calculated:

This was still sliced in v1.1.7 where infill and top solid layers were the same width (if i remember correctly). As becomes visible in the topmost layer (it looks the same througout the whole model), the nozzle could not squish the plastic as wide as intended, leaving grubby extrusion traces that do not touch each other. I can confirm that the general calculation of the extruded material volume is absolutely correct - it's just that the print head is unable to form the desired shape of the extrusion (ideally flat on top and bottom)

From my experience, many nozzle designs are only capable of lines roughly 2x nozzle diameter wide at the very most - thats where my proposed maximum safe factor of 1.5-1.6x came from. Could it possibly be more universal to calculate the maximum flow not over layer height but over nozzle diameter in general, for this reason?

[CCS86]

I am running into this as well.

With a .4mm nozzle, set to auto width, Slic3r is trying to use 2.52mm wide infill. There is no chance of that turning out successfully.

Please add a max width multiplier, thanks!

[alranel]

@simonkuehling, I can see how that was a problem when internal infill extrusion width was also used for external surfaces, but now the situation is different. Automatic extrusion width is always limited to 1.7x nozzle diameter. The only exception to this is the internal infill which is not limited and uses full flow. Of course such large widths will not be real, but for internal infill we don't care about actual widths (we only care about density)…

@CCS86, what's the actual problem you're getting? Can you put a picture of a printed object showing the problem?

[alranel]

The rationale behind the idea of using full flow for internal infill is that many infill patterns have bridging parts (think about rectilinear or honeycomb) that are not continuously extruded on top of a flat surface. When using a thin layer height, flow turns out to be very poor and extrusions get stretched and broken when performing those little bridges. So we basically extrude using bridge flow. Just like for bridges, we should just not write the width value to the G-code comments as it creates confusion...

[CCS86]

I did not print that code. Experience tells me it would not have worked.

I understand that bridging moves, especially when using thin layer heights, need an extrusion multiplier. But 5-6x?? I don't see how that can help. I also don't see why you liken rectilinear or honeycomb infill to bridging. It is not printing on top of a flat surface, but it is printing on top of itself, so it is supported, therefore not a bridge.

I haven't tested the practical limitation of extrusion width multiplier, but the physics just don't support this kind of extreme. Here is a visualization of printing at this kind of extreme relative to nozzle width. The anticipated result on the left, a more realistic outcome on the right.:

Even if it worked as intended, it totally throws off the infill density. If you set infill to 20% dense, and slice with an infill width close to your nozzle size, you get the pattern you would expect. But with this excessive auto width value, the grid spacing is massively increased. Where there might have been 10 squares in a given area before, there are now 1 or 2. This defeats the purpose of infill. I want my infill to be distributed well to provide strength to the print, and act as support structure for what would be internal overhangs, especially top surfaces which begin in the middle of a shape. If I have one or two massively overextruded infill members, which are not near these overhangs, the print is lost.

Thanks for listening!

Lars

[simonkuehling]

@CCS86, thanks for your illustrations - they illustrate exactly what i am experiencing when trying to print those extremely wide extrusion lines for infill.

@alexrj, i do understand your point to maximize extrusion width for infill in general. There is one catch though: A real nozzle will never be able to lay down arbitrarily wide extrusions without any max limitation. As visualized by @CCS86, at some point the extrusion will begin to buckle up behind the nozzle, effectively filling over the current layer height - which will collide with the next layer, leave gaps in a solid infill structure and generally mess with subsequent top surface quality.

The consequences on too coarse infill pattern spacing, like @CCS86 mentioned, are important as well.

Take this example: Slicing my model from the pictures above with a 0.05mm layer height (which is totally printable with PLA) and a 0.35mm nozzle installed will result in this using auto-width:

It is 1.93mm extrusion with for infill, which is 5.5x the nozzle diameter - no way that any .35 nozzle will ever print this.

[alranel]

@CCS86, your drawing on the left is not the "anticipated result" as you say. We don't expect to print that wide. Slic3r should just not write that "width" value in the G-code comments. In fact, it just uses the bridging flow rate and does NOT rely on that width.

@simonkuehling, does that image portray a model printed at 100% density? I agree that in that case Slic3r should revert to a normal infill since it can rely on infill being extruded on a flat surface (and bridge flow does overstuff in that case).

[simonkuehling]

@alexrj thanks for the hint - yes, i missed to underline that all my troubles always refer to 100% solid infill at the moment.

regarding the necessity of bridge flow, do you refer to a specific infill pattern here? Rectilinear infill is indeed more bridging than anything else - that's true. Does this also apply for honeycomb or 3D honeycomb? i thought these are also always laminating on top of the last layer in nearly full contact..

I think it is a good idea to distinguish between different infill patterns for this discussion.

[alranel]

@simonkuehling, agreed! Rectiliner, line, honeycomb, they're all bridging. Concentric and the other fancy ones are not (so it could be a good idea to revert to the normal flow for them). We might need to add a triangle or grid pattern that doesn't bridge...

[CCS86]

You haven't addressed the issue with infill spacing disruption.

What do you guys hope to accomplish by allowing such heavy width multiplication on infill?

On Mon, Jul 6, 2015, 9:16 AM Alessandro Ranellucci notifications@github.com wrote:

@simonkuehling https://github.com/simonkuehling, agreed! Rectiliner, line, honeycomb, they're all bridging. Concentric and the other fancy ones are not (so it could be a good idea to revert to the normal flow for them). We might need to add a triangle or grid pattern that doesn't bridge...

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2599#issuecomment-118869154.

[alranel]

@CCS86, that's a separate thing. Density is a matter of volume, not spacing. It's still honored, since that volume is actually extruded. I think that configuring infill as spacing (like 4mm) instead of % density would be more user-friendly. Spacing varies a lot across different patterns even using the same density, so density is a pattern-dependent setting as well...

[CCS86]

Yes, I understand that. Spacing is more important, functionally, than volume though. There is no point in having massively thick and widely spaced infill members.

On Mon, Jul 6, 2015, 10:18 AM Alessandro Ranellucci < notifications@github.com> wrote:

@CCS86 https://github.com/CCS86, that's a separate thing. Density is a matter of volume, not spacing. It's still honored, since that volume is actually extruded. I think that configuring infill as spacing (like 4mm) instead of % density would be more user-friendly. Spacing varies a lot across different patterns even using the same density, so density is a pattern-dependent setting as well...

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2599#issuecomment-118888367.

[kefir-]

Printing rectilinear infill at layer height 0.1mm isn't really the same as bridging, is it? I'd rather say it's like printing at layer height 0.2, except at the point where we're crossing the previous layer. If printing at 0.2mm layer height, the previous infill layer is 0.4mm below, which means we're bridging with a 0.35mm nozzle, but not with a 0.5mm nozzle.

The original example here was 0.1mm layer height and extrusion width of 0.98mm. If we consider the infill layer height to be 0.2mm instead, the extrusion width is actually 0.49mm (at least if we simplify and consider the extrusion to be rectangular). Could the problem be considered to be overextrusion/pressure build up when crossing the previous layer? At 100% infill you're always crossing the previous layer, and you'll get trouble.

[CCS86]

I agree.

If we are alternating directions for sparse infill lines, then it would be appropriate to print infill lines as if they are at double the layer height, minus a small correction for the intersections.

On Mon, Jul 6, 2015, 11:39 AM kefir- notifications@github.com wrote:

Printing rectilinear infill at layer height 0.1mm isn't really the same as bridging, is it? I'd rather say it's like printing at layer height 0.2, except at the point where we're crossing the previous layer. If printing at 0.2mm layer height, the previous infill layer is 0.4mm below, which means we're bridging with a 0.35mm nozzle, but not with a 0.5mm nozzle.

The original example here was 0.1mm layer height and extrusion width of 0.98mm. If we consider the infill layer height to be 0.2mm instead, the extrusion width is actually 0.49mm (at least if we simplify and consider the extrusion to be rectangular). Could the problem be considered to be overextrusion/pressure build up when crossing the previous layer? At 100% infill you're always crossing the previous layer, and you'll get trouble.

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2599#issuecomment-118920177.

[alranel]

That's an interesting approach...

[whosawhatsis]

"Small correction" depends on the infill density (because the scale of the correction is directly proportional to infill density. In fact, assuming that the line spacing is calculated as one would expect, the extrusion volume for a line of infill should (on average) be: length * extrusion_width * (layer_height * 2 - layer_height * infill_density) assuming a pattern of straight lines in alternating directions. For a triangular pattern passing over the same line every third layer, you would replace the two with a three. In these cases, you actually wouldn't want the line spacing to be calculated as one would expect, because you end up with double the amount of plastic each layer (or tripple in the triangle case), minus the "small correction" amount, so you need to take that into account when calculating your line spacing from the infill density setting.

You could, of course, get more precise results by counting the actual number of times you pass over a line of infill from the previous layer, or more precise still by actually generating separate segments with less extrusion for when you are passing over another line. In either case, you will want to make separate segments for parts of the line drawn over solid infill, because the density of the layer below in those areas is 100%.

BTW, FWIW Cura's infill algorithm creates a full grid each layer, seemingly without such a correction factor, and what looks like it should be double extrusion in a space with an area of extrusion_width^2 doesn't seem to cause any issues. MatterControl expands on this algorithm to create a triangular pattern that should have tripple extrusion in a hexagonal area of 1.5/sqrt(3)*extrusion_width^2 and double in the same area again centered around it (forming a stellated hexagon), but it's still barely noticeable for some reason.

[CCS86]

Good insight into the different executions. whosawhatsis.

Slic3r devs: any thoughts on implementing any of these strategies, or to at least put a reasonable limit on absolute extrusion width (even a manual setting)?

I think we would all love to be able to let Slic3r auto calculate widths, but don't want the sparse infill distribution to be messed up, or run into filament grinding issues from over pressure conditions. (think about the volumetric flow needed to extrude at 5x nozzle diameter, when printing at higher speeds!)

Thanks

[CCS86]

Any plans to fix this?

[julianrendell]

I'm having some pretty serious print problems that appear to be related to this. I'm using a 0.8mm nozzle (E3D) and with 0.2mm layer height, the auto width setting is pouring out 2.54mm infill. It's "rounding up" so much beyond the edge of the head that the machine is audibly "bumping" into the infill during moves. At best this is loosening bolts on the machine, but at worst, it's damaging- lots of rapid, sharp, obstacles. This is improved with a 0.25mm lift on retract, but not eliminated. Even worse, small bits of the infill are being scraped off and accumulated on the head. This eventually ends up as blobs on the print, that usually ends up with a print failing midway, or completely messing up the top surface. I'm new to using a 0.8mm nozzle, but I'm noticing it's exponentially more fiddly to get work than my previous 0.35mm head. So I suspect these auto-fill settings are also exponentially troublesome as nozzle size increases ;-)

I'd like to be able to set some min & max values that the algorithm fits within- then I can let it do what it does so well, but set some bounds based on the physical geometry of my nozzle, and observation.

Thanks.

[CCS86]

To me, this is a huge issue, fundamental to an important feature of Slic3r. I think it deserves immediate attention.

On Mon, Sep 14, 2015 at 5:00 PM Julian Rendell notifications@github.com wrote:

I'm having some pretty serious print problems that appear to be related to this. I'm using a 0.8mm nozzle (E3D) and with 0.2mm layer height, the auto width setting is pouring out 2.54mm infill. It's "rounding up" so much beyond the edge of the head that the machine is audibly "bumping" into the infill during moves. At best this is loosening bolts on the machine, but at worst, it's damaging- lots of rapid, sharp, obstacles. This is improved with a 0.25mm lift on retract, but not eliminated. Even worse, small bits of the infill are being scraped off and accumulated on the head. This eventually ends up as blobs on the print, that usually ends up with a print failing midway, or completely messing up the top surface. I'm new to using a 0.8mm nozzle, but I'm noticing it's exponentially more fiddly to get work than my previous 0.35mm head. So I suspect these auto-fill settings are also exponentially troublesome as nozzle size increases ;-)

I'd like to be able to set some min & max values that the algorithm fits within- then I can let it do what it does so well, but set some bounds based on the physical geometry of my nozzle, and observation.

Thanks.

— Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2599#issuecomment-140217034.

[wfcook]

Are you sure it is calculating the extrusion rate correctly? My experiments with 100% infill layers (principally with thin wall prints) indicates that the 1.2.x versions of Slic3r do not print anywhere near the correct total volume of filament, sometimes underextruding and sometimes overextruding by 20% or more (other slicers, including Slic3r 1.1.7, Cura and Simplify3D seem to extrude approximately the correct volume).

I cover this in issue #2960, and would sure like to see a fix because it's stopping me from using Slic3r, so I'll quote it again here:

I ran an interesting test this morning which I believe is relevant. I slic3d a rather large and complex thin-wall model with gap fill on in slic3r 1.1.7, 1.2.6, and 1.2.9 using the same settings exported from 1.1.7 in all three. Then I looked at the total extrusion length. The results for 1.75mm filament:

Slic3r 1.1.7: 64422.53mm Slic3r 1.2.6: 56872.62mm Slic3r 1.2.9: 77011.22mm

Additionally, with similar settings:

Simplify3D 3.0: 65117.37mm (15% infill overlap) Cura 14.12.1: 64230.95mm

The raw volume of the part is 153951.51 mm^3, which would imply a total required extrusion length of 64005.60 mm

This would imply that something is a little off with the Slic3r 1.2 family's extrusion rate calculators.

EDIT: Just to be clear, this was using 100% infill and 0% infill overlap. Also, after initially posting I realized I had skirt turned on, so I re-ran it without a skirt and corrected the numbers. Simplify3D was run with 15% infill overlap because it seems to have some issues with dropping infill when the overlap gets low. Wall thickness was nominally 3.2mm and I was set up for a 0.6mm nozzle.

[julianrendell]

Here are some photos of yesterday's failed prints:

Middle row is the most important:

• left- full auto, stopped midway as it was destroying my print head
• middle- locked infill to 1.2mm, solid infill to 1mm. Lots of extra plastic scraped around while printing. Extra bits melted into and completely messed up the top surfaces.
• right- locking infill/solid infill to 1.2/1mm, partial print.

Front row- printing the thin wall example referenced in the Slic3r wiki for extrusion multiplier. I have the extrusion multiplier set to 1.

• left- set perimeter params to 0.4mm. Messed up extrusion, gaps, and wall thickness is consistently 0.6mm
• right- set perimeter params to 0.8mm. Spot on (within 0.05mm), other than not generating a complete shell.

Close up. Left is all auto, generated infill extrusion width was 2.54mm. You can see it's bulging above the plane of the exterior... it's a printer killer. Middle is surface of item printed with infill/solid infill of 1.2/1mm. Right is part print with infill/solid infill locked to ~1mm. You can see it doesn't really go above the plane of the perimeters.

Close up of the thin wall print. Left with width locked at 0.4mm; result is 0.6mm. Right is locked at 0.8mm (nozzle width), result is 0.8mm.

Acceptable result. All values locked to 0.8mm extrusion, except perimeters, which are set at 0.4mm (otherwise I get gaps in the walls.) Top surface has some 'ridges' between beads. Not what I was hoping for, but they scrape off pretty easily and the final result is ok. You can see a patch in the middle-right where I scraped them off with a fingernail.

I'm using slic3r 1.2.9 on OS X.

[a4jp-com]

@alexrj any small tweaks that could help?

[wfcook]

@alexrj thanks for all your efforts.

[bubnikv]

Hello Alessandro.

First, you are my hero. Doing such a great programming job for free, having an architecture degree is quite an achievement!

I seem to have similar issues with over extrusion using Slic3r 1.2.9. When printing membrane structures like the wonderful throw plane, http://www.thingiverse.com/thing:1115840

Slic3r extrudes too much material and I am getting excessive pressure at the 1st and 2nd layer. The 2nd layer is the last on the wings and the print looks ugly and the excessive pressure causes curling of the material away from the bed. G-code generated by Cura prints much better for this model.

I may set the extrusion width manually, but I understand that fixing the extrusion rate effectively disables the automatic, so some gaps may then be created in the print, which are too narrow for an infill and too wide for a regular extrusion. The way Cura handles the gaps is a zig-zag infill. The zig-zag infill strains the machine and it often ruins the print on overhangs, which is deadly when printing ABS with cooling off. Your heavy over-extrusion tactic works wonderfully for PLA prints for me. PLA fuses with the already lain threads very well and the newly added PLA flows into the gaps easily. With ABS, I am having issues with the nozzle scratching and digging into the uneven lower layer. Some over-extrusion will likely be helpful to make the print stronger, to accelerate the print and to prevent the gaps or the need for the zig-zag infill, but the over-extrusion needs to be limited.

I would wish for another column in the manual extrusion width configuration page. How about having a "maximum" field for each extrusion width? So the automatic extrusion width would still work, but it would heed the maximum value?

Thanks, Vojtech

[ghuser2]

You might try PETG instead of ABS... could resolve some things.

[koreywithak]

I see this was opened about a year ago, but hasn't been resolved? I have been running into an issue that I think is the same problem. If you see the attached pictures, the middle of the thin wall is seen as a gap (if I set gap filling to 0 in Slic3r, it's an open space). The gap fill produces a wide extrusion (around 1mm). Due to buckling or issues when cooling it starts getting bumpy and the extruder begins to hit the bumps the next time around. If I change settings manually to include additional perimeters of thinner width to fill the gap, it turns out wonderfully and prints way faster (see last photo). I don't see a way around manually changing things so that the gap can be filled with additional perimeters (in this case), but more complicated cases may not be so easily resolved.

[newydave]

@alexrj Does commit https://github.com/alexrj/Slic3r/commit/9576973b578f0c39f8cbd73c225187ba65b6cef4 refer to this problem in any way?

[lordofhyphens]

@newydave it refers to the reworked gapfill logic that is in 1.3.0-dev. You could do a build and check if it solves this issue too, but I wouldn't necessarily expect it to.

[lordofhyphens]

@koreywithak Use 1.3.0-dev, which fixed gap fill (which is what you are seeing).

[koreywithak]

Nice. I'll check it out when I get a chance.

[koreywithak]

It's been a while since I've been on here :-). Is there not a 1.3 build for Windows out yet? I'm not a pro at building from source, especially with Perl, although I see there are instructions here. If anyone knows of a compiled 1.3.0-dev for Windows, that'd be great! I have something I can test this out on now.

[lordofhyphens]

I've got an autobuild script set up to put -dev builds at http://bintray.com/lordofhyphens/Slic3r/ as commits are made. This should be mentioned in the main README.md now.

slic3r_dev is the master branch and Slic3r_Branches are more experimental things. The "versions" are the build numbers, so here there be dragons :)

It's a bit different than the Cava packaged version people are used to. The good news is that all of the Perl-specific stuff is accessible and tweakable.

I have heard of some issues with a segfault/crash on Windows, but I haven't been able to follow up on it myself. I do know that there are some build issues on Windows with current-dev. Mostly because windows perl. :(

I need to get my Win32 build system back up and running (or switch to MSVC on the build server, which I need to read the docs @bubnikv provided).

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Mon, Nov 28, 2016 at 8:54 PM, koreywithak notifications@github.com wrote:

It's been a while since I've been on here :-). Is there not a 1.3 build for Windows out yet? I'm not a pro at building from source, especially with Perl, although I see there are instructions here https://github.com/alexrj/Slic3r/wiki/Running-Slic3r-from-git-on-Windows. If anyone knows of a compiled 1.3.0-dev for Windows, that'd be great! I have something I can test this out on now.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/2599#issuecomment-263462198, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CntHAne6PyQ6CztM6VTqj4Xbs8gVks5rC5QAgaJpZM4DZP3Q .

[lordofhyphens]

@koreywithak https://bintray.com/lordofhyphens/Slic3r/download_file?file_path=slic3r-1.3.0-dev.2016.12.31.2be6e1a.zip should work.

[koreywithak]

Thanks. I need to print something soon and I'll see if I can try that same part I did earlier as well to check this.

[koreywithak]

@lordofhyphens, I downloaded the latest Slic3r from your bintray (slic3r-1.3.0-dev.2016.1.1.2be6e1a). When opening the .stl from my original post with similar settings (not sure exactly what my former settings were), it slices it as shown in this photo. The width of that section is 2.4 mm and my layer height is 0.15. All of the extrusion width values are set to zero (default, auto-calculated) and my number of perimeters is set to 3. Despite that, it's putting only 3 strips of filament in that section and the gap fill is about 1.0 mm with 0.7 mm perimeters. These widths are way too wide. Of course, I can get the proper shape by forcing my own widths, but it seems my original concern is not yet fixed.

This is the .stl: http://www.thingiverse.com/download:1394785

[lordofhyphens]

Math says you can't fill it with an even integer number of loops with those perimeters. The perimeters are being chosen probably to make the lower area work out better.

That's why gapfill is being chosen for the space. There is not enough room to stick 2 more perimeters in and it is too small for proper infill.

[lordofhyphens]

As has (probably) been said before, the maximum width is more a function of the flat area.

I think that a maximum width may be called for as originally posted but it is going to cause other problems. Especially with gapfill.

[koreywithak]

It's understandable that the minimum perimeters value (of 3 in this case) is not followed due to the small width of the feature. However, I don't understand why it allows such elliptically flat extrudates under any circumstance. It has happened to me in other circumstances as well. I figured there would be some over-riding limit to the flatness of the ellipse that would force a subroutine. For example, if two perimeters of 3 lines (6 lines) won't fit, try 5 lines (with adjusted equal widths or call the center one a gap and it can be a little wider, within reason). If not, go to 4, etc. This is basically what I'm doing manually when I notice the issue. A maximum width might be useful, but it seems to me that the logic in this circumstance is what needs to change (although I'm not familiar with the details of it).

[lordofhyphens]

That circumstance comes from the defaults for perimeter width, which is apparently 1.7*nozzle diameter from what I can see from Flow.cpp. I don't know why external perimeters aren't being used here though.

I personally think that the gap fill move should be replaced by wider perimeters but there is a ton of rework involved in using the variable width code for that (finding nearest perimeters, defining a new segment that matches the length of the gap and then widening it and moving it). If someone wants to work on it I will review the source, but this is a problem with a ready workaround.

If you run into this situation then your first action should be to override the perimeter extrusion width. Because Slic3r is currently incapable of getting everything perfect.

[lordofhyphens]

Also, that perimeter on the FFCX model you linked has a 1.5mm wide rim, not 2.4mm (measured with netfabb basic). So Slic3r with my 0.35mm nozzle doesn't have any issues putting 4 lines in there.

[lordofhyphens]

@koreywithak Can you create a separate issue for your problem? I've been looking back over the thread and what you are talking about isn't the same as had been discussed here. Your instance is because the perimeter generation is incapable of matching flow to the area to be filled and relies on gap fill to make things solid.

We can link this one for continuity of discussion, but I'd rather not continue discussing your unrelated issue.