2.4.b2: Gap filling

[CCS86]

Hey guys, I've been having really good luck with 2.4's gap filling.

Today I found a situation where a couple funny things happened though...

Settings:

3 identical parts here, odd infill deviations between them:

Subsequent layers look good at first glance. But if you look more closely, that center band is actually printed twice in sort of a "perforated" manner. It seems like this will lay two underextruded beads on top of one another, and would be a worse situation then just filling once.

UMO_Handle Spacer 3.gcode.txt

Model:
Handle Spacer 3.stl.txt

[BagelOrb]

The first problem is a consequence of how the gap filling is computed. We generate normal lines infill in those areas and of two subsequent lines meet some criteria, we print one line along the middle of those two segments.

That bug has been in there for quite a while and has been logged a number of times already.
Fixing it will cost a lot of time, though. I don't think this is a huge problem, but the solution is quite difficult.

The second problem is not a gap filling problem. THat situation is just two perimeters being printed really close to each other. The flow of the second printed perimeter is adjusted if you have the setting Compensate Wall Overlap enabled.

[CCS86]

Bummer.

Any thoughts on my suggestion to simply re-run the normal algorithm on the space not filled by the first infill pass, with a reduced nozzle size, as an alternative method of gap filling. Maybe it would avoid these situations altogether?

[BagelOrb]

@CCS86 your idea seems simple, but it is actually quite difficult and computationally expensive.
It requires the following steps:

• compute the space which is occupied by the gap filling lines
• subtract that from the perimeter gap areas
• rerun the algorithm with a smaller nozzle width

We could however do the gap filling with half the nozzle size, so that more narrow gaps can be filled.
That does make sense, since the perimeter gaps are always smaller than the nozzle size.

[CCS86]

My thought was to do this instead of the current gap filling algorithm. To take the original layer area, subtract the perimeter and infill areas, then rerun the original infill algorithm on the remaining area, with a reduced nozzle size. Since the area would be so small, I figured that calculation would take too long.

You guys would certainly have a far better idea of feasibility and difficulty then I do though.

Just reducing nozzle size for current gap filling could be a cool and easy test though!

[BagelOrb]

I've just implemented doing the gap filling with a reduced nozzle size (half).

Let's see what our testers think of the results.

[BagelOrb]

This bug is related to #393