[3.5.1/3.6.0-Beta] Fill Gaps Between Walls follows "Top/Bottom Pattern" and results in terrible vibrations, quality and longer print times with Lines/Zigzag.

[JohnEdwa]

Application Version 3.5.1 and 3.6.0-Beta Platform Win 7 64-bit Printer Creality Ender 3 Steps to Reproduce

• Enable 'Fill Gaps Between Walls'
• Change Top/Bottom Pattern from Concentric to Lines or Zigzag

Actual Results

• Cura 3.5.1 will fill the gaps using your top/bottom pattern of lines or zigzag, resulting in terrible vibrations and lots of tiny movements.

Expected results

• Cura 3.4.1 used Concentric to fill between long lines with smoother and much faster results.

Additional Information

If this is not a bug but working as intended, please let us choose the pattern ourselves by simply changing the current "Nowhere/Everywhere" to "Disabled/Using Lines/Using Concentric" or something similar. The current behaviour is quite literally destroying my printer as it's shaking my part cooling fan bearings to bits.

Cura 3.5.1:

Cura 3.4.1

[Vandrasc]

Hi @JohnEdwa , could you please share the project file with us? Will help us more in trying to reproduce the issue if we are using the same configurations as you do. Many thanks!

[JohnEdwa]

@Vandrasc , ah, of course, here you go.

I did it with both a CR-10 and Ultimaker 2 just to make sure it wasn't any of the machine specific difinitions, which it isn't as the issue is on both of them.

You can see it in the side walls from layers 17 and up, on 3.4.1 it's a single line on each layer but on 3.5.1 and 3.6.0-beta it's an alternating Lines pattern.

3.4.1_UM2_PanelMountBox.curaproject.3mf.curaproject.3mf.curaproject.zip 3.4.1_CCR10_PanelMountBox.curaproject.3mf.curaproject.3mf.curaproject.zip

[JohnEdwa]

Okay, I did some more testing, I can confirm this is still on 3.6.0 and I also noticed it is not only tied to the Top/Bottom Pattern, but Infill as well. If you change "Infill" from "Lines" to "Gyroid", they are back into wiggles even if you have "Concentric" top/bottom pattern. The Infill called "Concentric" is also odd, as it does not will not fill any gaps that don't fit in the infill pattern itself.

Also, setting infill to 0% removes the gap filling completely no matter what patterns are used, which makes sense as Cura treats it as infill, but I think it shouldn't as "Fill Gaps Between Walls" is a "Shell" setting, not an "Infill" setting.

To recap: Having any other Top/Bottom pattern than "Concentric" OR selecting "Gyroid" infill will result in terrible wiggles instead of straight lines for "Fill Gaps Between Walls", which increases print time and results in noise and vibrations on your printer.

As an example, this collapsible basket goes from (with my settings) 2h 17min with no filling to 2h 31min with Concentric gap filling, but it increases to 3h 50min if I use anything else than "Concentric" patterns and it starts doing the wiggles

[rbryson74]

I have to throw in my 2 bits on this issue as well. I have a Monoprice Maker Select Plus. Prior to 3.5 walls with small widths in multiples of the nozzle width (0.8,0.12,0.16, etc) would print as a set of concentric lines. In cura 3.5 or 3.6 I am getting zig-zags or line infill similar to the top/bottom skin areas. However, mine will stay as lines no matter what infill pattern or top/bottom pattern I select.

[JohnEdwa]

Another problem with this - these tiny wiggles absolutely murder the serial connection with OctoPrint (and I would assume printing through Cura USB as well). The printer has to slow to a crawl when printing these as they saturate the connection, at 70mm/s my printer can manage maybe 15mm before the buffer is drained and the print speed lowered by Marlin. And this is after I bumped the buffers in Marlin as high as I have free memory to do.

[tpchristian]

Me too. Violent shaking in small gaps between walls.

[pansono]

I can confirm it for Cura 3.6 (no beta) and I tried to raise the wall line count and activated "print thin walls - no effect. It really seems to depend on Infill and top bottom settings. Did someone find another workaround?

[Ghostkeeper]

This bug was introduced due to some rework that we did on this feature in 3.5. We made some improvements in 3.6 and again in 4.0. We consider it partially fixed now in 4.0.

[pansono]

Thanks for the fast response. I tried the same model (created in Autodesk Fusion 360 and exported as stl) in the version 4 Beta. So far I can not see a real difference to the results from version 3.6.

[smartavionics]

Hello @pansono , the reason that your last image doesn't look too bad and the earlier images do look bad is my fault. There's some code in Cura that is meant to convert those zig-zag lines into straight lines (like the bottom image) but when the gyroid infill is enabled, that code is disabled. I did that because it screwed up the gyroid infill.

Hey @Ghostkeeper , if the infill optimization has really been fixed, perhaps it should no longer be disabled when printing gyroid infill? It doesn't worry me either way because I have permanently disabled it anyway and don't actually seem to be missing out.

[Ghostkeeper]

Yeah the original issue for which we disabled it for Gyroid infill has been fixed. We don't get the thick infill lines any more. I'll put up a ticket to remove that exception.

[rburema]

Devs: See CURA-6143

[runam0K]

My actual version of Cura 3.6.0 does no zig zag lines when fill gaps is enabled. But I want it back... The Walls where stronger with it. Is there a way to re enable the old behavior?

[Ghostkeeper]

No, and I don't think we'll want to add it back. You can sort of mimic the behaviour with skin but it won't be in the same locations.

[Vandrasc]

Hi @JohnEdwa, we did a fix where merging the infill lines are now correctly handled, could you also confirm your issue fixed? https://we.tl/t-FM3NOUvOyv Thanks!

[JohnEdwa]

@Vandrasc You did fix the Gyroid infill breaking Concentric pattern, but the original tiny moves with lines/zigzag part is still there.

However, during this time I've first swapped from the basic "Jerk" to "Junction Deviation" in Marlin which smooths out these moves, and then flashed the Klipper firmware that also removes the serial bandwith issue, I'm now even more inclined to highly suggest implementing the option for this behaviour as I did in the original issue post:

If this is not a bug but working as intended, please let us choose the pattern ourselves by simply changing the current (Fill Gaps Between Walls) "Nowhere/Everywhere" to "Disabled/Using Lines/Using Concentric" or something similar.

Because if your printer can do these zigzags without shaking itself apart or overflowing the serial buffer and grinding to a halt, it actually is a "better" method of filling the gap as it kinda stitches the lines together. It's just really not feasible on a lot of printers or when printing fast through Octoprint.

(the changing number is line width, btw)

[Ghostkeeper]

The single line vs. striping is not a simple matter of changing the pattern to draw the lines. It's different tunings of the algorithm to combine the striping into one single line. It's not simple for a user to understand.

For completeness, this tuning is implemented here:

https://github.com/Ultimaker/CuraEngine/blob/cdbd922b44e30f1d58022a306286e47405221099/src/MergeInfillLines.cpp#L278-L307

and here:

https://github.com/Ultimaker/CuraEngine/blob/cdbd922b44e30f1d58022a306286e47405221099/src/MergeInfillLines.cpp#L154-L218

[dvilo]

I have a similar issue wid gap filling in Cura 3.6 but it is not showing up in preview.

50mm diameter cylinder with 2mm wall from Fusion 360. (attached)

Line width 0.4mm. Same result with or without "Fill gaps between walls".

Cura preview is showing five proper lines:

G-code reveals sub micrometer extrusions in second WALL-INNER. There are multiple moves without any extrusion in-between the micrometer ones.

Sample g-code: (full file attached)

G1 X105.189 Y133.502 E1796.67905
G1 X105.2 Y133.504
G1 X105.363 Y133.532 E1796.67916
G1 X106.647 Y133.752 E1796.68201
G1 X106.659 Y133.755 E1796.68249
G1 X106.669 Y133.756
G1 X106.782 Y133.768 E1796.6825
G1 X108.131 Y133.915 E1796.68536
G1 X108.142 Y133.917 E1796.68579
G1 X108.202 Y133.919 E1796.68588
G1 X109.621 Y133.986 E1796.68891
G1 X109.633 Y133.987 E1796.68938
G1 X109.644 Y133.987
G1 X109.661 Y133.987
G1 X111.087 Y133.967 E1796.69203
G1 X111.112 Y133.966
G1 X111.124 Y133.965
G1 X111.135 Y133.965 E1796.69225
G1 X112.528 Y133.856 E1796.69498
G1 X112.602 Y133.85
G1 X112.614 Y133.849
G1 X112.625 Y133.848
G1 X113.927 Y133.663 E1796.69776
G1 X114.079 Y133.641 E1796.69786

A chart showing extrusion moves relative to distance moved. Normal for this file is 3.9% but in the second WALL-INNER things go wrong: (x-axis is lines of g-code, values above 4% are retractions)

This chart is showing location of G1 starting point vs relative extrusion for the move

50mm cyl 2mm wall Medium STL.zip

50mm 2mm shell medium G-code.zip

[smartavionics]

Try setting the minimum wall flow to 50 or a value that is high enough to zap those little extrusions.

[dvilo]

Thanks @smartavionics!

"Minimal wall flow" tooltip says "Compensate wall overlaps" and "Outer before inner" must be enabled.

With "Minimal wall flow" set to 50 and "Compensate wall overlaps" + "Outer before inner" enabled, the issue remains.

If "Minimal wall flow" is set to 50 without enabling Compensate wall overlaps and Outer before inner, the microextrusions disappear and g-code line count goes from 21,630 to 17,279.

Five lines are shown in layer view but g-gode has six:

Lines in one layer of g-code charted as extrusion relative to distance moved: (all clean but one line too many, spikes are retractions)

Plotting the G1 positions in one layer with dot size representing relative extrusion shows that a sixth line is squeezed on top of the center line with full flow. I suppose this will lead to substantial overextrusion: (large dot in SW is retraction)

Detail of above:

[smartavionics]

Sounds like you need to use a higher value of min wall flow (along with the wall overlap compensation enabled). Try 80.

[dvilo]

Even at 99% min wall flow I get exactly the same g-code. Also tried disabling "fill gaps between walls" which also return exactly the same g-code.

Temporary solution is to widen line to 0.43mm (less is not enough).

Thanks for your input, will wait for 4.0 and see how it behaves.

[mv1005]

Here are my two cents. I can confirm the zig-zag issue still exists in 4.0.0.

It even happens that identical layers are sliced with different filling. In one layer, the gap is filled with a straight line, in the next one it is filled with zig-zag. This is very confusing.

However, I found a workaround while playing with the settings. Setting the option "Skin Overlap" to 0 made the zig-zags dissapear, at least for my model. Hopefully, this is helpful for someone else too.

[Ghostkeeper]

It even happens that identical layers are sliced with different filling. In one layer, the gap is filled with a straight line, in the next one it is filled with zig-zag. This is very confusing.

This is because the pattern alternates direction orthogonally every layer. I'd expect this to alternate every other layer.

However, I found a workaround while playing with the settings. Setting the option "Skin Overlap" to 0 made the zig-zags dissapear, at least for my model. Hopefully, this is helpful for someone else too.

Changing the Skin Overlap effectively pretends like the model is slightly wider or thinner (while filling the skin), so I'm guessing that other people will have the same problem at different values for Skin Overlap. However it might still be worth the time to fiddle with this setting in order to arrive at a correct thickness that gets properly filled.

[mv1005]

This is because the pattern alternates direction orthogonally every layer. I'd expect this to alternate every other layer.

The changes between straight line and zig-zag do not appear in alternating layers. The part in question of my model covers layers 1 through 8, where layers 1 through 3 are sliced using a straight line and layers 4 through 8 are producing zig-zags.

Examining my model right now I realize that on top of the zig-zag, starting from layer 9, the model narrows and continues with an outer wall at the same location where the zig-zag is in layers 4 through 8. May this somehow be related to the feature that ensures proper support underneath walls which are printed on top skin?

[TypQxQ]

I'd like to add that this is still a problem in 4.1 and 4.2b1. It creates holes, inconsistent slicing at diffrent layers with same wall widths. This makes for example Lithophanes unprintable! Here is the same stl sliced with Cura 4.2b1 and 3.4.1.

Here are the project files, stl and Fusion360 project: Filament Sample.zip

Is anyone still working on this?

[smartavionics]

Hello @TypQxQ. Yes, the Ultimaker release still has this problem. You could try one of my releases (Linux or Windows only) because they have a different implementation of the thin wall printing and gap fills. Here's what your design looks like when I slice it...

You can find my releases at https://www.dropbox.com/sh/s43vqzmi4d2bqe2/AAADdYdSu9iwcKa0Knqgurm4a?dl=0

Hope this helps!

[TypQxQ]

Hi @smartavionics! Your implementation looks better but I see there are still holes in the sliced output at the A in "PLA" for example. Also, why is it changing from wall "red" to top/bottom (yellow) on the right hand side and not consistent as the width there is consistent. And I'm not really comfortable with downloading forks from Dropbox. Why not using GitHub?

[smartavionics]

Yes, there are some holes. I can't work out why they are there unless the wall is so thin at that point that it disappears completely. As a test, can you please make a version that uses a slightly thicker min thickness? I would be interested to see if that fixes the problem.

As for the red walls on the yellow area on the right, increasing the line width to 0.41 made them disappear. The wall thickness must be very close to the line width.

All the source is on github, so you can build yourself if you wish!

[smartavionics]

Err, don't bother to make another stl, I will just scale up the one I have.

[smartavionics]

OK, I tweaked a couple of settings and made one change to the slicer code and now get this:

Here's the gcode if you want to try printing it..

CFFFP_ClasOhlson_PLA_4.2.gcode.zip

[smartavionics]

I printed it. Came out reasonably well but suffered somewhat due to the sub-optimal print cooling fan I have on that printer. Bridging worked well over the gaps :). The rear side shows some bumps (especially behind PLA).

[Ghostkeeper]

TypQxQ's case is separate from gaps between walls. It is the "Print Thin Walls" feature. This is being discussed here: https://github.com/Ultimaker/Cura/issues/5445

[Antotabo]

Hi, is there a plan to fix this issue ? It is still a major one as of today (Cura 4.3.0):

EDIT: Oh ! By the way, I'm using concentric Top/Bottom Pattern and I still am getting a that zig-zag gap fill pattern so we now have absolutely no way around it seems like.

I would really, really like to print structurally sound parts (with no gaps between inner/outer walls) without shaking my printer appart. It should really print a continuous line, midway between the lines producing the gap, and be of variable width (variable extrusion rate) equal to the distance between them.

Side note, I wonder why these continuous gaps aren't fixed by the setting "Compensate Wall overlap"?

Pretty please ?

[Antotabo]

I have a suggestion that could be of easy implementation as it would propably easily piggyback on top of the current small gap fill implementation instead of having to refactor the whole thing:

Take the existing parrallel small gap fill lines and chain together a new "corrected"path that passes thru the center of each of those overlaping parralel segment. Here a couple of conditions that may or may not help to decide if two segment should be merged into that corrected new toolpath chain:

• previous and next parralel segment must overlap (touch eachother)
• angle between previous and next new corrected path must be below a certain threshold
• segment shall be below a threshold length (mm) (long lines might be ok to keep as is)

Here is a picture for added clarity. In pink is the new toolpath, created by connecting the center position of each parrallele fill segment:

Please let me know if that might work. Also sorry for double post but really the last one is me trying to express my frustration and wishes and this one is about a possible solution. Thanks !

[neworld]

I believe there is an even easier fix. Narrow gaps between walls are filled as the purple line in your picture, if you use top/bottom pattern = Concentric as in this picture:

[Ghostkeeper]

Hi, is there a plan to fix this issue ?

Plans, yes. Time, no. We still have an issue in our Top-30 issues list about this to investigate it better and an idea for a different approach. There is also a more long term research project going on to fill spaces with variable line width.

Side note, I wonder why these continuous gaps aren't fixed by the setting "Compensate Wall overlap"?

Because there is no overlap going on (and the gaps are not monotone if that's what you meant). There is only overlap when there is a gap between 1 and 2 line widths wide, not when there is a gap between 0 and 1 line width wide.

Take the existing parrallel small gap fill lines and chain together a new "corrected"path that passes thru the center of each of those overlaping parralel segment.

This is exactly what Cura is doing, or rather should be doing. See our documentation about the technique here. We have a list of conditions here:

https://github.com/Ultimaker/CuraEngine/blob/c4cbadb09140883f77aedce360b15ba27255330b/src/MergeInfillLines.cpp#L255-L364

This works for most cases, but the problem seems to be that these conditions are somehow not met for your case. I've not been able to reproduce this problem with a simple case since 4.1 (when I made some adjustments to the thresholds). But I've seen it with complex models once in a while when I was working on other things.

I believe there is an even easier fix. Narrow gaps between walls are filled as the purple line in your picture, if you use top/bottom pattern = Concentric as in this picture:

It could be that the shape that has to be filled with gap filling becomes different in your case and that prevents the problem, but it'll still occur with different shapes then. The gap filling technique is still applied and the algorithm to fill the gaps is the same.

[Antotabo]

@neworld I'm already using Concentric patterns and it is not helping me:

This is exactly what Cura is doing, or rather should be doing. See our documentation about the technique here. We have a list of conditions here:

Yeah ! I'm a badass developer's mind reader.

This works for most cases, but the problem seems to be that these conditions are somehow not met for your case. I've not been able to reproduce this problem with a simple case since 4.1 (when I made some adjustments to the thresholds). But I've seen it with complex models once in a while when I was working on other things.

Well, it happens to me on every single circular print on most layers where top/bottom shell occurs ( line type diplayed as yellow )... By the way, I find it quite confusing that this algorithm is called MergeInfillLines, when really it should be and is probably used also on inner walls & tops/bottoms (my case here). Could the problem be that simple ? Agorithm just isn't applied to all path types ?

Meanwhile, I stumbled on @smartavionics 's Cura builds which has implemented a fix and I thank him for that !

Thanks for the update @Ghostkeeper .

[Ghostkeeper]

By the way, I find it quite confusing that this algorithm is called MergeInfillLines, when really it should be and is probably used also on inner walls & tops/bottoms (my case here). Could the problem be that simple ? Agorithm just isn't applied to all path types ?

No, that's not the problem. That's just bad naming originating from historic behaviour. The algorithm is actually applied to 3 things: Skin lines, small gap filling (this problem here) and "Print Thin Walls" lines. Not to infill at all afaik.

[cmontgo]

I’ve been having the same issue in 4.6.1 (I can attach details if needed)

But thanks to all of the discussion here, and the link to the master, it seems to be fixed there. Not sure what did it though

[Ghostkeeper]

We have a work in progress for this issue here: Ultimaker/CuraEngine#1210

[no-response[bot]]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[nallath]

Whoops. It still had the wrong label.

[Ghostkeeper]

This is fixed in https://github.com/Ultimaker/CuraEngine/pull/1210.