Cura turning fan off when printing mid air

[deebeo-blip]

Application Version

4.10.0

Platform

Windows 10

Printer

Voron 2_300

Reproduction steps

Sliced a model with 90 degree overhangs further up the model and initial layer fan speed 0% and regular fan speed 100%. See yellow overhang next to the top of each column.

Actual results

Cura turned the fan off when reaching the yellow bottom layer parts in mid air which causes the print to fail. the gecode shows several M107 I don't understand. They are in the following combination
;TYPE:SKIN
;BRIDGE
M107
I can not find a setting to control the fan speed differently for these occasions so I'm assuming it's a bug.
V2_Aspect-of-the-Gods-Lv7-v1.0.gcode.txt
V2_Aspect-of-the-Gods-Lv7-v1.0.3mf.zip

Expected results

Fan should stay on for 100% of the time onwards form layer 2 since the manual states that "fan speed initial layer" only affects layer which are actually connected to the build plate.

Checklist of files to include

• Log file
• Project file

Additional information & file uploads

Please review the attached Project an Gcode. I never noticed the fan turning off in mid print when printing bridges/overhangs. What is the reason for this?

[nallath]

Well, you seem to have bridging enabled and that does set the fan to 0%

[GregValiant]

I don't think those flat areas can qualify as a bridge. When the inner and outer wall loops go down they are completely over air and there is no opposite abutment that they can connect to.
This is the first layer of those overhangs and it is doomed to failure without support. It is air printing and no amount of cooling is going to help this. It's a gravity thing.

[GregValiant]

With matching 2.2mm holes in each part you can split it, drop 6mm pieces of filament into two of the holes, and glue it together. There is still some hard to remove support being generated in the Arch part.
GV_V2_Aspect.zip

[Ghostkeeper]

So the problem is then that those areas are being misclassified as a bridge. On the other hand, generic overhang might as well be printed as bridging.

One problem with our bridging algorithms at the moment is that they don't look at where the individual lines are going. It can know the general direction of lines, but doesn't know whether lines are resting on 0, 1, 2 or more spots along their paths. That would be expensive to calculate for each line. And you'd want to use bridging if there are at least 2 resting places, but only for the part of the line that is between those two places. The experimental bridge detection in general needs more attention; we basically imported that from a PR and never really updated it significantly ever since.

I'm currently unable to import this project file by the way because it depends on the Voron_2_300 definition which doesn't exist. The one that ships with Cura is called voron2_300. It may be a different definition. Reading through the profiles I don't see the bridge_settings_enabled setting being overridden. Maybe Nallath didn't realise that it had just imported the models, not the whole project file?

But yes, bridging is a likely candidate as to why this happens, purely from the description.

[GregValiant]

Is this still an issue in current versions of Cura (5.8.0 and up)? Can this be closed?

[github-actions]

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.