M106 Maximum Fan Speed Setting - unproportional

dragonn

Why not?
This could work nice with filaments profile, so you are able to set cooling from filament profile in Duet by just scaling it.
I even though this is how it works, unfortunately not :/.
For examples to be more explanatory:

for ABS I would set M106 L0.0 X0.2
for PLA I would set M106 L0.8 X1.0
for PET-G I would set M106 L0.1 X1.0

Maybe add an option to M106 to enable scaling.

wilriker

@dragonn said in M106 Maximum Fan Speed Setting - unproportional:

Maybe add an option to M106 to enable scaling.

I think there is no right or wrong way here. Both variants have their place. I think an option to enable scaling would be a good idea.

Changes are minor to achieve this. @dc42: What do you think about an option? I can implement that quite easily. Hardest part as always: which parameter to use.

deckingman

@wilriker Yup. Optional would be good. More chance of pleasing "all of the people, all of the time" rather than "some of the people all of time" or "all of the people some of the time".

wilriker

Have this implemented and ready to create a PR if @dc42 is OK with the basic idea.

Only one open question: what should the fan status report as the set speed? Physical or logical speed? I have it implemented as physical speed but swapping it to logical is just deleting one line of code.

BTW: I used Wnnn as the parameter for now. Like "Whatever you want the fan to behave".

dragonn

@wilriker logical, it need to report the same as you set. Otherwise it will confuse paneldue and DWC

wilriker

@dragonn You are right - also because this could have potentially led to side effects where the fan suddenly runs slower than commanded. So changed this back to logical/commanded speed.

deckingman

@wilriker said in M106 Maximum Fan Speed Setting - unproportional:

Only one open question: what should the fan status report as the set speed? Physical or logical speed?

Optional

wilriker

@deckingman said in M106 Maximum Fan Speed Setting - unproportional:

Optional

Seriously?

No, but really seriously: that would make things probably a little awkward and confusing. Example: you have the fan set to M106 P2 L0 X0.5 W1 (i.e. min 0%, max 50%, scaling on) and then pull the speed slider in DWC all the way to 100% - once RRF would have executed that command the slider would jump back to 50%.

I could add it as a separate information to M106 status output though.

deckingman

Now what would be cool would be to have fan speed act in proportion to filament volume flow flow rate - I'd settle for extruder speed.

If you've' ever played around with large nozzles or multiple melt chambers and high speeds, then you'd know that you need much more cooling than for low volume flow rates.

deckingman

@wilriker said in M106 Maximum Fan Speed Setting - unproportional:

@deckingman said in M106 Maximum Fan Speed Setting - unproportional:

Optional

Seriously?

No, but really seriously: that would make things probably a little awkward and confusing. Example: you have the fan set to M106 P2 L0 X0.5 W1 (i.e. min 0%, max 50%, scaling on) and then pull the speed slider in DWC all the way to 100% - once RRF would have executed that command the slider would jump back to 50%.

I could add it as a separate information to M106 status output though.

That's the problem with effectively having two speed ranges. 0 to 100% of what the fan is capable of and 0 to 100% of some range within that range. Which one do you report?

wilriker

@deckingman said in M106 Maximum Fan Speed Setting - unproportional:

Now what would be cool would be to have fan speed act in proportion to filament volume flow flow rate - I'd settle for extruder speed.

Implementation complexity would be the same for both ways since the firmware always knows the flow rate because that will be converted into extruder movement. But that is the easy part here.

Ref which value to report: I think it is mandatory to internally work with the commanded (logical) value. Otherwise you would have controls that jump around and cannot reach certain values - which is what we already have right now with min and max values... The longer I think about it the less of an opinion I have.

EDIT: I got totally confused so I had to revert back to check: right now it will report whatever the user has commanded. If you tell the fan to run at 100% but set max to 50% it will still report 100% although the fan is turning at 50% speed.

dragonn

@wilriker yeah, this is how it schould work.

c310

@wilriker said in M106 Maximum Fan Speed Setting - unproportional:

RRF would have executed that command the slider would jump back to 50%.

@wilriker i see it this way:

like @dragonn suggested
M106 Laaa Xbbb in config.g or in filaments sets hardware limits.

once limits are set - DWC should treat them as end parts of 0...100% scale.
so, if in DWC I drag fan to 100% physically it it would be set to bbb value from related config.

this "logical scaling" behaviour can be initiated by W1 option, with W0 (no scaling) being default.

Reporting for DWC can show both values (physical and logical)

wilriker

@c310 I came to that conclusion also now. Since RRF is reporting the commanded value to the outside ever since I won't change that behavior. But I will add the value for physical speed to M106 Pnnn output.

Since there is no good way (I can think of) to permanently show both values in DWC as well as it would tremendously increase complexity of this change I will not even attempt to show both values any other way than described in the paragraph above.

wilriker

I just submitted this pull request. Now it is up to @dc42 to accept or reject it.

c310

@dc42 said in M106 Maximum Fan Speed Setting - unproportional:

it behave differently from other firmwares.

@dc42 we have the best firmware lets add some power options to it

dc42

I'm not going to accept that PR without further discussion here, because it's adding extra complexity that I don't think is justified. Every bit of added code is something that has to be tested, interacts with other code, and increases the likelihood of bugs.

The question to address is: what is the M106 PWM limit for? Is it:

(a) A means to handle the situation of an over-powerful fan, so you will never want to run it at full power? If so, then it makes sense to scale the S parameter in some way so that 1.0 or 255 is the max PWM that you specified in the H parameter. What's not so clear is what to do at the bottom end. Obviously S0 must mean off. But suppose you have specified L0.25 X0.7, and now you send S0.3? What I think that means is that you are asking for PWM of 0.3 * 0.7, which is 0.21 - but that is lower than 0.25, so you will get 0.25. But there are other possible interpretations.

(b) Or is it a means to temporarily restrict the maximum PWM, for example I might reduce the speed factor and also set a fan PWM limit in order to make the printer quieter? If so, would it matter of the PWM was scaled instead as in (a)?

If always scaling the requested PWM by the X value is not going to cause a problem for anyone, then I'd rather just implement scaling. An incidental advantage of doing this is that it makes GCode more portable, because the slicer can always assume that 255 means maximum cooling.

dragonn

@dc42 said in M106 Maximum Fan Speed Setting - unproportional:

S0.3? What i think that means is that you are asking for PWM of 0.3 * 0.7, which is 0.21 - but that is lower than 0.25, so you will get 0.25. But there are other possible interpretations.

I think you mean X parameter, not H.
No, I think when you send S0.3 when L0.25 X0.7 is set then you schould get a true power of S0.385.
Scaling should not be according too the range, not to the max value. So when you send 30% you get 30% of the available range, not 30% from the max value.

Phaedrux

@deckingman said in M106 Maximum Fan Speed Setting - unproportional:

Now what would be cool would be to have fan speed act in proportion to filament volume flow flow rate - I'd settle for extruder speed.

I had a proposal for exactly this a while ago. The idea was to use some sort of look ahead in the gcode file to get an idea of what the flow rate or movement speed would be ahead of time and using a speed factor to ramp up the fan speed ahead of time. I was frustrated with slicer fan control algorithms at the time.

The response at the time from David was that it would be rather difficult to get the flow rate information in a timely enough fashion to be useful.

deckingman

@phaedrux said in M106 Maximum Fan Speed Setting - unproportional:

@deckingman said in M106 Maximum Fan Speed Setting - unproportional:

Now what would be cool would be to have fan speed act in proportion to filament volume flow flow rate - I'd settle for extruder speed.

I had a proposal for exactly this a while ago. The idea was to use some sort of look ahead in the gcode file to get an idea of what the flow rate or movement speed would be ahead of time and using a speed factor to ramp up the fan speed ahead of time. I was frustrated with slicer fan control algorithms at the time.

The response at the time from David was that it would be rather difficult to get the flow rate information in a timely enough fashion to be useful.

Do you think we actually need look ahead for the cooling fan? Yes, in an ideal world but I can understand how that would start to get very complex. But unlike heaters, fans tend to ramp up pretty fast. So maybe a more simple link between "real time" extruder speed and fan speed might be "good enough". If you have a rapid change in extruder speed, there will be some delay or inertia before the filament coming out of the nozzle reacts to that sudden change. That "inertia time" for want of a better expression might actually be quite close to the fan "ramp time".

I could see though that extruder only moves such retractions might screw things up and it's probably a lot more difficult to code than I imagine.