Print cooling fan behavior doesn't match G-code on A1 mini

user_102303967 · April 20, 2025, 1:06pm

Bug Report: Print cooling fan behavior doesn’t match G-code on A1 mini (Firmware 01.04.00.00)

Printer: Bambu Lab A1 mini
Firmware version: 01.04.00.00
Material: PETG
Slicer 1: OrcaSlicer 2.3
Slicer 2: Bambu Studio 2.0.2.57
Model: (attached)

Issue summary:

During overhang printing, the cooling fan (M106) behaves inconsistently with the G-code and preview.
The fan:

may turn off too early,
or never turn on,
or turn on briefly but revert instantly to a previous value.

This results in poor cooling during narrow or long overhangs.

Case 1: OrcaSlicer 2.3 – “Start fan early” setting enabled

1. Screenshot: OrcaSlicer setting: “Start fan early by 0.5s” = enabled
2. Screenshot: Preview shows fan at 100% for both inner and outer overhang walls
3. Screenshot: Paint annotation of nozzle path shows:

Fan turns off too early, right at the start of a long overhang
It never turns back on, even though G-code expects 100%

Case 2: OrcaSlicer 2.3 – “Start fan early” disabled

4. Screenshot: Setting disabled
5. Screenshot: G-code preview: 100% fan only for overhangs
6. Screenshot: Annotated nozzle path shows:

Fan turns on briefly
Immediately reverts to the previous value before overhang is complete

Case 3: Bambu Studio 2.0.2.57 preview

7. Screenshot: Fan speed preview in Bambu Studio

Outer overhang walls are marked for 100% cooling
Inner overhangs are not cooled (treated as non-overhangs)

8. Screenshot: Real behavior sketch

Cooling does not match preview or G-code
Fan turns on/off in unpredictable patterns

Expected behavior:

Fan speed from M106 should follow G-code strictly
Especially on overhangs where consistent airflow is required for print quality

Actual behavior:

Fan doesn’t follow G-code commands as expected
Inner overhangs remain uncooled despite preview showing airflow
Real fan behavior contradicts both slicer preview and inserted M106 commands

Attachments:

Screenshots 1–8

Fan Speed Bug Report1920×1855 285 KB
Model file (.3mf)
Overhang test.3mf (31.2 KB)

user_102303967 · April 23, 2025, 8:56pm

Has anyone else run into something similar?

In my case, I’ve also noticed the fan turning off too early on bridges — not just with inner walls and overhangs.
It feels like this behavior might not be limited to one slicer setting or printer version.

I’m using the A1 mini, but I wouldn’t be surprised if this also affects other models.
Would be great to hear if others have seen the same.

user_102303967 · May 30, 2025, 2:24pm

I never got a reply from anyone on this issue,
but I accidentally found a way to fix it — so I’m leaving this here in case it helps someone else.

The parameter I mentioned earlier actually helped in some cases.
To fix the problem, simply set:

Fan speed-up time = 0.2s

This small change made a noticeable difference in my prints.
Hope it helps!

user_102303967 · October 6, 2025, 8:16pm

But the Fan speed-up time feature doesn’t work well when printing with multiple materials

github.com/SoftFever/OrcaSlicer

Fan speed not restored correctly with AMS or timelapse when "fan start early" option is enabled

opened 05:04PM - 27 Aug 25 UTC

glstas

bug

### Is there an existing issue for this problem? - [x] I have searched the exis…ting issues ### OrcaSlicer Version 2.3 ### Operating System (OS) Windows ### OS Version win 10 ### Additional system information _No response_ ### Printer a1 mini ### How to reproduce Enable "Fan start early" in print settings. Print a model with AMS (filament change) or enable timelapse recording. Observe that after filament change (or timelapse snapshot), the fan does not return to the expected speed. Check the generated G-code – sometimes the M106 command for fan start is inside a conditional block and does not appear in the final file. ### Actual results After AMS filament change or timelapse snapshot, the part cooling fan sometimes does not restart. The M106 command for fan speed is missing in the final G-code because it was wrapped in a conditional block and skipped. As a result, the fan stays off or runs at the wrong speed for the rest of the print. ### Expected results The part cooling fan should always start at the correct speed after AMS filament change or timelapse snapshot. The slicer should insert an unconditional M106 command both at the pre-start (early fan spin-up) and again at the actual fan start point, so the command is never skipped due to conditional blocks. ### Project file & Debug log uploads [Cube_fun_bug.zip](https://github.com/user-attachments/files/22010711/Cube_fun_bug.zip) ### Checklist of files to include - [ ] Log file - [ ] Project file ### Anything else? This issue seems to be the same as or closely related to previously reported bugs, which were closed without a proper fix: https://github.com/SoftFever/OrcaSlicer/issues/8796 https://github.com/SoftFever/OrcaSlicer/issues/9024 The problem is still reproducible in the latest OrcaSlicer release. I was able to work around the timelapse case by manually editing the settings and forcing the conditional block to be removed. However, this is only a workaround and does not fix the AMS filament change case. The issue still causes inconsistent cooling and potential print failures.

DimD · January 14, 2026, 8:50am

Hi. I encountered the same problem: the fan speed drops from 100% too early over overhangs and bridges.

I was able to get around this only with a very crooked solution, changing the gcode, removing the speed reduction after the bridge.
I used bambo studio

user_102303967 · February 21, 2026, 2:19pm

So if the wall speed and overhang speed are the same, the fan will reliably turn on. Interesting — I should try testing this.

user_102303967 · February 21, 2026, 2:20pm

I think this might be a feature to prevent overcooling the part, or a hidden downgrade for an entry-level printer.

user_3422326010 · February 22, 2026, 1:48pm

As I understand it, the problem still hasn’t been solved, and the only solution is to shift the fan start time.
I don’t have any other printers besides the Bamboo to test with right now, so I only use Orca/Studio. However, I never had such problems using the Prusa slicer before. Could the problem be in the Bamboo Studio source code, which then spawned Orca?

user_102303967 · February 22, 2026, 4:20pm

The issue is definitely not in the G-code — I checked it and the fan-on commands are clearly there. So it’s either something in the printer hardware (but likely not firmware, since there’s no widespread reports), or people just don’t notice the problem. The speed-related scenario described above is worth testing.

user_161777460 · April 23, 2026, 12:44am

Also experiencing this issue. I notice cooling sometimes turns on too late, and turns off too early.

Weirdly, when I am printing several objects at once, only the FIRST object experiences this bug. All other objects in the print are printed correctly. The objects have the same cooling settings and filament set. The objects are printed all at the same time, layer by layer.

I noticed others online also experience this bug in general:

github.com/OrcaSlicer/OrcaSlicer

Force cooling for overhangs and bridges doesn't work

opened 03:32PM - 09 Jul 24 UTC

closed 12:21AM - 16 Mar 25 UTC

vadixidav

bug stale

### Is there an existing issue for this problem? - [X] I have searched the exis…ting issues ### OrcaSlicer Version 2.1.1 ### Operating System (OS) Windows ### OS Version Windows 11 ### Additional system information AMD Ryzen 7950X ### Printer Bambu Lab A1 ### How to reproduce 1. Print the attached file. ### Actual results Regardless of what the fan speed is set to, the fans will not speed up during the overhang bridge or the bridging section. Check the first bridging section, for instance. You can try changing the settings however you like, I have tried no walls, all walls, etc but I cannot get the fan to speed up during bridging consistently. It will occasionally raise the fan speed, but it is rare, and it seems that the command to raise the fan speed is often omitted. ### Expected results The fan should go to 80% when an overhang wall or bridge is encountered. ### Project file & Debug log uploads [Bridging_Test_50 10% fan -> 80% fan keep on](https://github.com/user-attachments/files/16145504/Bridging_Test_50.zip) [Bridging_Test_50 0% fan -> 80% fan keep off](https://github.com/user-attachments/files/16145524/Bridging_Test_0_80.zip) ### Checklist of files to include - [X] Log file - [X] Project file ### Anything else? I am trying to print totally transparent prints (this is a cube, so very thick): ![image](https://github.com/SoftFever/OrcaSlicer/assets/12789579/e060a5c0-e38e-426f-9fcb-03d45f6d9ca4) To do this, I can't have the fan on, but I have to have the fan on to bridge. Unfortunately, I have been unable to get the fan to speed up during bridging consistently. Often times, it will start up then slow back down to the normal speed after it has been bridging for about a second or two. The bridges are happening quite slowly at 1mm/s. The bridges come out absolutely perfect when the fan is on, but when it is not on they have various issues. Some settings do cause the G-code to be emitted to turn the fan up correctly, but again, it doesn't remain on very long. Usually it never even turns up.

user_161777460 · May 3, 2026, 4:14am

I believe this problem is made much worse if there is dust trapped within the part cooling fan. It might not be visible externally and required dissaembly to clean in my scenario. There was about 1 cubic centimeter of a dust mass hidden inside. The part cooling fan did gradually become quieter over time with the dust accumulating.

The symptoms on my printer are partially releived now, though still present.