M106 Maximum Fan Speed Setting - unproportional

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.

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?