There is some inconsistent oddness with the last several versions of firmware, and the M106 cooling fan gcode command. Let's break this down into two sections:
"Prioritizing GCode Settings" On and Off
When On, it's not clear what Prioritizing GCode Settings ignores/forces. But it seems to ignore any fan settings. Using Dremel filament, and non-Dremel filament, when Prioritizing is set to Off, the fan is always running on layer 1 regardless of M106 or M107 commands. However, if you set the printer's filament settings to 0% fan, it will be off - and remain off during the hole print.
When Prioritizing setting is OFF, that's where the inconsistent behavior happens. The fan, as commanded, will be off during the first several seconds into the first layer. And then randomly start spinning during the rest of the first layer.
Also during printing, changing the fan speed with M106, like from 30% to 100% bridging and then back down to 100%, doesn't seem to have any effect that the human ear can detect.
Maybe there's a gcode buffer reading ahead (as typical MCUs do), and when it encounters M106, it goes ahead and starts the fan instead of buffering the command?
There is some inconsistent oddness with the last several versions of firmware, and the M106 cooling fan gcode command. Let's break this down into two sections:
When On, it's not clear what Prioritizing GCode Settings ignores/forces. But it seems to ignore any fan settings. Using Dremel filament, and non-Dremel filament, when Prioritizing is set to Off, the fan is always running on layer 1 regardless of M106 or M107 commands. However, if you set the printer's filament settings to 0% fan, it will be off - and remain off during the hole print.
When Prioritizing setting is OFF, that's where the inconsistent behavior happens. The fan, as commanded, will be off during the first several seconds into the first layer. And then randomly start spinning during the rest of the first layer.
Also during printing, changing the fan speed with M106, like from 30% to 100% bridging and then back down to 100%, doesn't seem to have any effect that the human ear can detect.
Maybe there's a gcode buffer reading ahead (as typical MCUs do), and when it encounters M106, it goes ahead and starts the fan instead of buffering the command?