prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.76k stars 1.93k forks source link

Bridge infill overextrusion #3225

Open skeltoac opened 4 years ago

skeltoac commented 4 years ago

Version

2.1.0+

Operating system type + version

MacOS Mojave 10.14.6

3D printer brand / version + firmware version (if known)

Original Prusa MK3S

Behavior

Bridge perimeters are fine, but bridge infill overflows into the space under the bridge.

I am printing a temperature tower. I sliced the PETG version from https://www.thingiverse.com/thing:2493504 using the default MK3S 0.4mm profile and generic PETG. I observed the printing of the bridges. The bridge inner perimeters print first and they are acceptable. The bridge outer perimeters print next and they are acceptable. Lastly, the bridge infill prints and it extrudes too much material, creating a lot of slack that hangs down into the void. It may also be moving too fast during these moves, as these are about 75% faster than the perimeter moves.

image

Screen Shot 2019-11-22 at 12 45 04 AM

image

Below is the gcode for the bridge. I have marked the relevant lines with comments. The extrusion rate for the bridge infill moves is double the extrusion rate of the bridge perimeter moves.

M204 S800
G1 F1033 ; perimeter speed
G1 X135.583 Y107.368 E0.05876
G1 X114.417 Y107.368 E0.71647 ; bridge perimeter (yellow)
G1 X114.417 Y105.632 E0.05876
G1 X135.523 Y105.632 E0.71444 ; bridge perimeter (yellow)
M204 S1000
G1 X135.240 Y105.225 F10800.000
M204 S800
G1 F1033 ; perimeter speed
G1 X135.240 Y100.225 E0.16924
G1 X144.790 Y100.225 E0.32326
G1 X144.790 Y109.775 E0.32326
G1 X135.240 Y109.775 E0.32326
G1 X135.240 Y107.775 E0.06770
G1 X114.760 Y107.775 E0.69325 ; bridge external perimeter (orange)
G1 X114.760 Y109.775 E0.06770
G1 X105.210 Y109.775 E0.32326
G1 X105.210 Y100.225 E0.32326
G1 X114.760 Y100.225 E0.32326
G1 X114.760 Y105.225 E0.16924
G1 X135.180 Y105.225 E0.69122 ; bridge external perimeter (orange)
M204 S1000
G1 X135.639 Y105.257 F10800.000
G1 X135.615 Y105.429
[...]
M106 S127.5
G1 F1800 ; infill speed
G1 X116.105 Y105.989 E1.29858 ; bridge infill (blue)
G1 X116.105 Y106.500 E0.03541
G1 X134.637 Y106.500 E1.28486 ; bridge infill (blue)
G1 X134.637 Y107.011 E0.03541
G1 X115.907 Y107.011 E1.29858 ; bridge infill (blue)
supermerill commented 4 years ago

The extrusion rate for the bridge infill moves is double the extrusion rate of the bridge perimeter moves

1) it seems you didn't checked the "print bridged perimeter with bridge flow" in the perimeter tab of your print setting, hence why it's not the same. 2) printing a bridge is printing a round filament, as it can't be squished against an other layer, so it's flow is ~PI radius² bridgeflow. If your nozzle is 0.4mm and your layer height is ~0.15, the flow should be double, of course. 3) if your bridge are dropping down:

skeltoac commented 4 years ago

@supermerill Thanks for looking.

I don't have a "print bridged perimeter with bridge flow" checkbox there. I have "Detect bridging perimiters" which did not affect the extrusion rates of any of the moves when I tried it.

To reiterate: it is only the bridge infill that droops. The bridge perimeters are printing fine. To me this suggests that the flow rate is too high during the bridge infill moves. Can you explain why this is not so? I understand your point 2 about squish, but why wouldn't this apply to the perimeters and why are they fine?

Assuming the higher flow rates are correct, I have another theory to offer as to why the infill is drooping. In the screenshot below, you can see significant portions of the bridge infill being printed over the top of solid infill. These segments are being overextruded and causing pressure buildup. When the nozzle reaches the area actually being bridged, this pressure is released and extra filament is extruded. If this is the case then we have identified a candidate for improvement in the slicer.

Screen Shot 2019-11-25 at 11 41 03 AM

supermerill commented 4 years ago

The bridge perimeters are printing fine.

if you want to print bridges at 50% flow because it's better, do it.

I don't have a "print bridged perimeter with bridge flow" checkbox there. I have "Detect bridging perimiters"

yes, it's that one.

When the nozzle reaches the area actually being bridged, this pressure is released and extra filament is extruded. If this is the case then we have identified a candidate for improvement in the slicer.

I agree, that's why I added a setting for the bridge "overlap" in my fork.

skeltoac commented 4 years ago

Thanks again for your attention.

bubnikv commented 4 years ago

@skeltoac Is this issue resolved for you? Could you please close it?

RC-Thoughts commented 4 years ago

I have this same exact issue (2.2.0+win64 on Win10 64), inner and outer bridge perimeters are fine but bridge infill is clearly over-extruding. The checkbox "Detect bridging perimeters" is checked but I'm assuming from the name it only applies to perimeters which bridge infill is not?

rongith commented 4 years ago

@bubnikv , @supermerill, I noted that for bridging infill, the mm3_per_mm is calculated only from the spacing, there is no other parameters taken into account. For example if I have a spacing of 0,508, the width = spacing - BRIDGE_EXTRA_SPACING = 0.458 then the mm3_per_mm = pi*(width/2)^2 = 0,165. (lines ~390 of Layer::make_fills()) I came to investigate that because I tried to find why by playing with different parameters I had poor bridging capabilities with nGen which has the reputation to have low viscosity. Playing with the fan speed had quite no effect. Only important parameter is the bridging flow ratio that can decrease the spacing. There were a difference between 0,95 bridge flow ratio and bridge flow ratio 0.9 but not by decreasing it further. Same results for 0.9, 0.85 and 0.8. That is because when going from 0.95 to 0.9, the spacing decreased (one more path extruded into the boundaries) but not with a lower bridging flow ratio.

In my case 0.165 mm3_per_mm is catastrophic for nGen @240°C. It is too much weight per mm for a bridge. When decreasing the bridging flow ratio to 0.9, the spacing is 0,435 then the mm3_per_mm is 30% lower (0.116) and that gives acceptable bridging.

I don't know if you plane to make something about that or if it works as wanted. But I think a better control of what happens is welcome.

Here my 3mf. Test-Bridge-r00 - Defaut-essai2.zip

supermerill commented 4 years ago

I changed BRIDGE_EXTRA_SPACING by BRIDGE_EXTRA_SPACING_MULT * nozzle_diameter with 0.125 as BRIDGE_EXTRA_SPACING_MULT in my fork. Because i tough that this thing should scale with nozzle.

Also, the bridge flow ratio decrease the width of the extrusion (and height), so if it's lower, the extrusion will extrude less plastic.

[EDIT] BRIDGE_EXTRA_SPACING is only used to know by what amount the bridges lines can overlap. I tied it to nozzle diameter because that's what creates the bridge width and as the overlap have to scale with the width, it scales with the nozzle diameter.

rongith commented 4 years ago

If the bridge infill area is narrow (as for @skeltoac), for now the spacing is high then the section of the extruded filament is high. In his case, PrusaSlicer decided to set only 3 paths in the boundaries. The spacing is estimated to be about 0,511 then the width and hight about 0.461 and finally 0,1667 as the section. That huge section combined with a heavy filament (1.27 density) plus maybe high temperature gives very poor bridging. If the bridge infill is larger, the spacing should converge to the "nozzle diameter"*sqrt("bridge flow ratio"). That issue is specific to narrow bridge infill.

I made some test on nGen to see what is the biggest mm3_per_mm to extrude. On the printed part I changed the mm3_per_mm. Between parts I changed the temperature and the speed. Here the look of the part @240°C, fan 100%, speed: 20200526_222820 There are 10 paths on the part from 0,09 mm3_per_mm to 0.18 mm3_per_mm. We can see that with standard parameters, 0.17 mm3_per_mm (the third from the front) is catastrophic. That section is the one @skeltoac had. Here the other results: 20200526_192955 From left to right: 15mm/s - 30mm/s - 60mm/s From top to bottom: 240°C - 230°C - 220°C I put some black dot on the path with the bigger section that seems good at bridging. Here the GCodes: Test-Bridge.zip

Section close to the noozle diameter seems good in that test. I know that for nGen I would go fast with sections about 0.13mm2, even for infill like rectilinear or others with big overhang like gyroid.

It is the 0.13mm2 target that will be annoying to control.

@supermerill , I think it is the spacing in the bridge infill area we have to control first. For me it is unreliable. I didn't go deep enough in the code to propose something. I'm afraid it will take me too much time to do so.

EDIT: Spacing of bridge infill is affected by Fill::_adjust_solid_spacing then:

// Calculate a new spacing to fill width with possibly integer number of lines,
// the first and last line being centered at the interval ends.
// This function possibly increases the spacing, never decreases, 
// and for a narrow width the increase in spacing may become severe,
// therefore the adjustment is limited to 20% increase.

20% increase is 44% more for the section. It is too much for the bridge. I prefer Prusa decide what is the best strategy to handle that as there maybe some drawbacks I'm not aware of.