M106 Maximum Fan Speed Setting - unproportional

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.

c310

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

have specified L0.25 H0.7, and now you send S0.3

i agree with @dragonn scaling should be up to the range, not to the maximum. in such a case everything works.

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

always scaling the requested PWM...

in discussion i see 3 trends \ use cases
(1) handling hardware limitations of the fan (i.e. low end controls minimum speed and high end sets limit for over-powered fan or noise level
(2) linking fan speed with printing speed that for me is logical
(3) linking fan speed with extrusion volume

we can start with (1) and than see if it is sufficient. if not, decide other add-on depending on complexity. somehow (2) and (3) are linked: faster printing means more extrusion volume.

lets start with (1)

wilriker

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

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

Since I have introduced this feature originally I think I need to answer what my intentions were: I wanted a measure to make GCode more material-independent. At that time I was planning (and since realized) to move heater control out of the slicer and into filament configuration on the Duet. What is still left in the slicer is fan control. For PLA it is set to e.g. 100% fan speed and for PETG to 30%.

With the max PWM I intended to have the slicer simply set to 100% fan speed for all materials and configure a lower maximum in firmware if that is too much for the loaded filament.

Originally I did not think of using variable fan speed and all the tricks that slicers now have up their sleeves (like intensively increasing fan speed for bridges, etc.) so I also did not think of scaling.

As an outcome of this thread I do actually like the idea of scaling. The defaults for min and max are 10% and 100% respectively so the average user won't see any real difference if scaling is enabled. Only if one is already actively modifying min and/or max this can have tremendous effects. So it is kind of a hard decision based on not-breaking-anything.

dc42

Based on this discussion, I've decided to implement scaling so that the X parameter represents full speed. This will be in the next 2.03 beta release.

wilriker

@dc42 OK. Then just reject my PR. Or should I close it myself?

c310

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

Based on this discussion, I've decided to implement scaling so that the X parameter represents full speed. This will be in the next 2.03 beta release.

does it mean that L parameter will be "almost 0%" ? and 1...100% will fit in between L and X ?
in other words, X and L determine hardware limits and DWC controlled range will completely fit in between?

in practical terms setting 50% speed in DWC will mean (X-L)/2 of real speed?

wilriker

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

in practical terms setting 50% speed in DWC will mean (X-L)/2 of real speed?

I think the real PWM value will be rather L + (X - L) * S where S is the commanded speed in percent. But only for S > 0. S=0 will still mean off.
But that is only how I implemented it in my PR. Not sure how @dc42 will handle it.

dc42

The L values doesn't mean you get zero airflow at that value, it it the minimum PWM value at which the fan will continue turning once started. So I implemented the PWM value as max(L, X * S) when S is nonzero.

wilriker

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

So I implemented the PWM value as max(L, X * S) when S is nonzero.

Which makes a lot more sense than what I had.

c310

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

Which makes a lot more sense than what I had.

why? lets say
(1) i limit fan with L50 (does not work with lower figures) and X200 (will blow model off the table )
(2) pull fan control to 50% in DWC

proposed formula max(50, 200*50%) will give 100 , but on the real physical scale it should be 75 (all scale is 150, so middle will be 75)
in other words, this formula caps the top values and eats lower end until it grows over L ?

wilriker

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

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

Which makes a lot more sense than what I had.

why?

Mainly because I was confused at the time of writing.
I think both approaches have their places. Mine was actually scaling fully in between L and X whereas David's approach scales by X and ensures a physical limit. Thinking about it I do again like my approach better but I can live with how it is implemented now as well.