Versions newer than 2.5.59.0 disable fan speed override!

[CuredPrusa]

What happened?

For some strange reason M106 is written by slicer at every layer, sometimes at every move. This disables adjusting the fan speed from printer's control panel or by manual input of M106 at certain height.

Project file & How to reproduce

Version

2.5.59.8

Operating system

W10

[supermerill]

You can set a very small fan speedup time (printer -> general -> cooling fan), like 0.01. That way, this post-porcessing is activated and will remove any duplicate of M106.

Maybe I should always run it. I'll do that for next version. I didn't yet, as I wasn't very confident of it messing with gcode. Now it's more stable and shouldn't create bad gcode anymore.

[CuredPrusa]

I have tried your latest nightly (nightly from two days ago). It's still not working correctly. But I have tried your proposal. With speedup 0 it's obvious M106 gets overwritten instantly:

With speedup 0,01 there is no custom code value at all. :

[supermerill]

With speedup 0,01 there is no custom code value at all. :

did you spot an issue? your fan speed has been moved up, as the move was very short.

It's still not working correctly.

What is the issue?

[CuredPrusa]

did you spot an issue? your fan speed has been moved up, as the move was very short.

If you refer to line 62538 in first picture, yes that was correct introduction of custom code M106. But it lasted only for one move (62539) and that is wrong because it should last much longer. In that layer there are hundreds of command lines (G1) to complete the layer. And yet, fan speed got instantly retrieved to default value (line 62540) after a single G1.

What is the issue?

in second picture you see the beginning of the same layer as first picture, but with speedup set to 0,01. In instruction line 62546 the custom code got announced but the value is nowhere to be found.

[Rewwan]

I confirm the user code M106 cannot be set, it is constantly overwritten.

[Alexxx775]

The M106 command is installed, but then overwritten and does not work properly as it should.

[supermerill]

Can't reproduce, maybe give me your test project?

[Rewwan]

3mf.zip Here is a project, it has custom code M106 S255 installed on layer 65. In version 2.4.58.5, custom code M106 was applied to all subsequent ones, and in the latest version there is a permanent override.

[supermerill]

your gcode file you sent me was made in the working 2.4.58.5, right? can't reproduce in my nightly (my nightly in the left, your gcode in the right): what's the problematic version?

[Rewwan]

Code.zip It was chopped up in the new version. Here are two files from different versions of the slicer, in them the M106 S255 behaves differently

[supermerill]

Seems like it's working as intended, now. no?

[Rewwan]

No, in 2.4 the code is applied to all subsequent layers, and in 2.5 the airflow is constantly changing, even if the values ​​in the settings for perimeters and padding are set to -1, the default airflow is applied instead of the custom code as before.

[supermerill]

understood

[supermerill]

behaviour (in next nightly):

• if an override is -1, it's considered that it is at the default fan speed.
• if the default speed is -1 (disabled) then:
  • there won't be a M107 start, unless 'disable fan for the first layer'
  • if a fan override is not -1, at this feature the fan will be set + M107 at the end of the feature.
  • for fan_below_layer_time, -1 is considered as 0

So now (if defautl fan is -1) if you put a M106 S255, the fan won't be erased until a feature that isn't disabled

Is it okay?

[Rewwan]

Yes, I just checked the nightly build. The code is applied and remains. Thanks!

[CuredPrusa]

No, I don't think this should be a final solution, it's more like a temporary workaround. I don't understand ( and forgive my ignorance please) why does new version have to write M106 constantly (in normal fan mode), while in 2.4 the setpoint for fan speed was written only in the beginning and that's all. So fan starts ( 2.4) in the beginning of print (as it should be) and then you can do with it whatever you want afterwards. Now, with this new nightly you can manipulate fan only if you disabled the fan. So I have to start fan manually in the beginning of print if I want to change it later on.

Moreover, I think you should consider every printer's ability to adjust the fan speed during printing. Constantly writing the fan speed by slicer is disabling this important feature, especially useful when following the printing process during prototyping. If someone wants to run fan 50% all the time without too much thinking, but then in the middle of print he want's to increase it to 100% because it's melting, he can not do that from printer if using the latest version of SS.

I don't know anything about coding so it's quite interesting to see that such simple sounding feature (which all other slicers have by default) could be so tricky: KEEP THE FAN RUNNING AT SETPOINT UNTIL NEW SETPOINT GETS INTRODUCED MANUALLY (M106 - from manual gcode line or from printer override).

Yes, there are many additional fan speed tweaks in new SS which I appreciate a lot. That could be the root cause of all the hassle. I don't think new features should disable basic crucial workflow of settings. I'd rather live without them and keep the solid fan commands of 2.4.

[supermerill]

Moreover, I think you should consider every printer's ability to adjust the fan speed during printing.

like the speed? then it's on the firmware side to just interpolate with your %, like for the speed.

KEEP THE FAN RUNNING AT SETPOINT UNTIL NEW SETPOINT GETS INTRODUCED MANUALLY

In the nightly, it's now smart enough to not write it, and it's smart enough to detect the M106 from custom gcode. If you want just a fan command at the start and then change it manually, then just write the command in the custom gcode. It's simple enough (and disable all fan settings).

[CuredPrusa]

like the speed? then it's on the firmware side to just interpolate with your %, like for the speed.

Control Panel on my V400 sends M106 over Klipper when I want to manually adjust fan speed from the panel. And then instantly gets annulled by frequently generated M106 from g-code.

In the nightly, it's now smart enough to not write it, and it's smart enough to detect the M106 from custom gcode.

Unfortunately this is still not true. In picture below is how nightly writes gcode for top fill which should have fan at S76.5 (30%). At every single non extruded move (travel) it is writing default fan speed S229.5 (90%). Why? Why can't it write one M106 S76.5 at the beginning of top fill and then write default M106 when top fill ends? So, there is NO WAY to interfere with fan speed by sending one M106 from the panel/firmware. Perhaps this is happening because this new version is smart not to write surplus M106 down the gcode lines, but it writes it as soon as it detects there was a M106 change.

And that affects the good old easy manual M106 input at vertical scroll bar which version 2.4 process so naturally. Here, new nightly just waits for a new M106 intruder to annul it asap.

If you want just a fan command at the start and then change it manually, then just write the command in the custom gcode. It's simple enough (and disable all fan settings).

If this is your final solution about the manual M106 input which worked perfectly in 2.4, than I guess I should stick to 2.4 or Prusa for projects that require fan speed manipulation at critical layers. I certainly don't intend to write fan speeds for 12 layers in beginning ( I have one project which uses gradual fan increase during 12 layers, otherwise it gets loose from the bed) if this can be automated as it always was.

[Nbeknel]

I've also noticed when using the arachne engine the slicer will insert M106 commands before and after every width change. I've been able to reduce the amount by using a g-code substitution: M106 S\d*(\.\d*)?\n; -> ; (regex), but now all M106 commands call the same value, even when it's printing the same feature.

[gmakedonski]

We are printing concrete, filament was set to ABS and fans speeds are :

but after every width move

[gmakedonski]

For me not fixed again on every width : M107

attached slicerconfig and 3mf project 3DCP.zip

[supermerill]

For me not fixed again on every width : M107

sorry, it's only for the ninghtly, in the 60.0 version.

[CuredPrusa]

Here I am again. I'm sorry if this could be annoying, but it certainly is to me. Here's a project opened in 2.5.59.12. Blue squares are pointing at M106 commands. There are 25.928 M106 commands and 635 M107 commands.

The same project opened in 2.4.58.5 has 4 M106 commands and 7 M107 commands.

I'm not sure this doesn't influence the processing power during printing.

[CuredPrusa]

Should I check latest nightly?

[CuredPrusa]

I think I see what is going on here... As many new controls you have added to the fan cooling, that many times the command gets repeated in front of every possible fan speed change. If certain move has a possibility to get a new command for fan, but there's no change (-1), then fan command is still written but with default value. True?

[CuredPrusa]

A note, not to miss the momentum... in latest version 2.5.59.12, when ALL fan settings are at -1, gcode is packed with M107 like a pomegranate.

[supermerill]

it's better in the nightly, I added some code to not repeat itself. I'll let the stable version as-is as it's more secure.