Fan speed incorrect for first layer after filament change

[psiberfunk]

Is there an existing issue for this problem?

• [X] I have searched the existing issues

OrcaSlicer Version

2.2.0

Operating System (OS)

macOS

OS Version

15.0.1

Additional system information

N/A , slicing issue, not crash/render issue.

Printer

Bambu X1C

How to reproduce

1. Slice attached project.
2. Inspect Layer 200, notice normal fan speed of 18%.
3. Inspect layer 201 , with abnormal fan speed of 100%, which should be ~18-19%.

Actual results

Notice that layer 201 improperly has 100% fan speed, as inherited from the filament start GCODE sequence, but the normal "on layer change set fan speed" logic doesn't not appear to trigger, leaving the fan @ 100% for the whole layer, until the following layer. This results in very weak layer bonding in this PETG print (but problem also would apply to most non-PLA/TPU prints).

This is bad because it can result in prints looking like this, with an "easy break" layer inserted in by mistake, where the print will likely be extremely weak:

And here's the offending filament start GCODE that doesn't get clobbered (like it should) by a layer-change fan instruction:

Expected results

Fan speed should be normally set according to the filament cooling rules, not according to filament start code during a filament change. The proper result here would be a fan speed of ~18-19% based on subsequent layers.

Project file & Debug log uploads

FanSpeedLayerChangeIssue.3mf.zip

Checklist of files to include

• [x] Log file
• [X] Project file

Anything else?

Nasty bug that's hard to notice unless you happen to look at the fan speed preview!

[psiberfunk]

Note: this test file was sliced originally in 2.2.0-beta2 , I just downloaded and verified that this is still a problem with 2.2.0-rc as well.

I also verified that this is pre-existing in the 2.1.1 release, so has apparently not been introduced/made worse by the 2.2.0 branch.

The model in this file is my own work, in case anyone cares.

[Noisyfox]

This is in fact caused by the difference in layer time, due to color change.

[psiberfunk]

This is in fact caused by the difference in layer time, due to color change.

@Noisyfox, I think I disagree with you here.

From the simple perspective, it does not make any sense that you should get 100% fan here since the nominal layer time due to change of filament is LONGER , not shorter. Longer layer times result in less cooling... which is obviously not what's happening here.

From a precise tracing-the-code perspective:
The key is that there appears a couple bugs in setting the per-layer cooling in the GCODE so that the filament-change GCODE (useful during purging) is clobbering the intended layer-time based fan speed setting. To disambiguate, i've attached the exact GCODE i'm talking about here. This way we can go line-by-line to identify and agree on the issue. Let's play along with this file:

Fan_problem.gcode.zip

In the slice file, the slicer appears to try and set the fan speed for the layer to the min fan speed called for (10%) on line

159975: M106 S25

Note that this happens right before the toolchange sequence... so.. this then gets clobbered by the filament change routine here, on line:

160160: M106 P1 S255

, and never set back to the proper part fan speed by layer (which ought to be a "M106 S48", which comes before the next layer @ line 160948.

There are actually TWO bugs here:

2. The layer time fan speed for the layer after the swap gets clobbered by the filament-change routine, which causes the fan to be 100% until the second layer after the change starts, at which point it resumes the proper speed.
3. For the purposes of calculating the cooling fan speed: the layer time of the layer AFTER the filament swap is incorrectly calculated as including the filament swap time (whereas it should be the layer prior that includes it, since it will have more cooling).

Obligatory screenshot showing the longer layer time being mis-attributed to the layer following the filament swap:

[psiberfunk]

P.S. i'm happy to discuss this interactively on discord if you wish.

[Noisyfox]

Yeah you're right. Will take a closer look.

[Noisyfox]

The issue is actually caused by the fan mover. Fan mover does not work properly for printers that control multiple fans with Mxxx commands. If you look at https://github.com/SoftFever/OrcaSlicer/blob/cc8d90c224f6381d2fe68f7f3316275f299c87ea/src/libslic3r/GCode/FanMover.cpp#L290-L300 you will notice that it does not care about which fan the current command is changing, and for gcode sequence like

M106 P2 S25
M106 S25

it will think the second command is the same as the first one, then the second one get removed: (Left: the gcode before fan mover, Right: the gcode after fan mover)

[Noisyfox]

Fan speed is correct now after disabling fan mover

[psiberfunk]

Well, that's an evil bug! Is it easy to fix for the mover so that kickstart/speedup can still be used?

Even without the mover, however, It's still setting the cooling for the wrong layer though.. the long layer time (and hence no need for lots of cooling) should be for the layer before the change, right ?

[Noisyfox]

Well, that's an evil bug! Is it easy to fix for the mover so that kickstart/speedup can still be used?

Even without the mover, however, It's still setting the cooling for the wrong layer though.. the long layer time (and hence no need for lots of cooling) should be for the layer before the change, right ?

The plan is to exclude the toolchange time at the beginning of each layer, which should work relatively well. Though the better option will be to add that time into previous layer, but that's not possible at current situation due to how each layer is processed individually.

[psiberfunk]

Well, that's an evil bug! Is it easy to fix for the mover so that kickstart/speedup can still be used? Even without the mover, however, It's still setting the cooling for the wrong layer though.. the long layer time (and hence no need for lots of cooling) should be for the layer before the change, right ?

The plan is to exclude the toolchange time at the beginning of each layer, which should work relatively well. Though the better option will be to add that time into previous layer, but that's not possible at current situation due to how each layer is processed individually.

Yeah, I recall being told about this kind of linear GCODE generation approach that doesn’t allow look back easily. It would have to be some kind of post-processing hack or something , and that feels like a nasty bit of tech debt to add here. I agree that just blowing away the filament swap time from the current layer estimate is “good enough”.

thanks for taking the time to address the issue .. I try to be as specific and detailed with my bug reports as possible in the hope that it will make them easier to understand and address.