Cooling Fan Kickstart

[Penguin-fach]

I have noticed that my cooling fan frequently fails to start reliably. Usually this is when the requested speed is under 30% but sometimes as high as 50% if the speed has been increased over a number of layers.

It occurs to me that this is also a problem for large scale speed controlled ventilation systems. To overcome this problem some speed controllers 'kickstart' the fan motor by ramping it up to 100% for a few seconds before chopping down to the normal controlled speed. It seems to me that this would be a useful option for Cura.

I imagine that this function would have several controls.

1. Checkbox to turn the function on or off.
2. Lower kickstart Threshold - default 50%. Any requests to increase speed up to and including the threshold would see a brief period of higher (or full speed) operation before dropping down to the preferred speed.
3. (Optional) - Maximum kickstart percentage - default 100%. In some cases kick starting to 100% may not be desirable as it may excessively chill the print so users may want to drop this value (it would not be possible to drop it lower than Lower Kickstart.
4. Kickstart Period - default 1 second. Some blowers can take time to respond (as can some controllers) so being able to set this up to 5 seconds would be useful.

I looked into doing this through the firmware on the printer. The code was not going to be too difficult to implement but the need to tweak this potentially on a print by print basis makes changing the controller code an additional hassle.

I feel that this has the potential to benefit anyone using print cooling as it would permit more refined and reliable speed control.

The only potential drawback/challenge I can see is ensuring that Gcode ensures reasonably accurate timing of the kickstart duration.

[dxgldotorg]

You should be able to do a reasonably accurate time using G4, for instance to do 1 second delay do G4 P1000

[Penguin-fach]

G4 risks glitching the print. If the controller is executing a movement that will take longer than a second then no problem otherwise the printer will stop until the dwell time has expired and that risks ruining the print. It is better to write an algorithm to parse the Gcode and calculate how many steps forward to insert the required second fan speed instruction. I have done this by manually editing the Gcode and it works fine but it requires a bit of thought and square-bashing so an instruction in Cura would streamline the process hugely.

Started a print this afternoon and didn't check the fan until about an hour in. The fan had a ramp over four layers to 50% - didn't start - AGAIN GRRRR.

[Ghostkeeper]

I'd also categorise this more under the firmware features than slicer features. The firmware knows more about the printer's hardware than Cura does. The decision for when to kickstart the fan depends heavily on that and the desired fan speed, which is known to both Cura and the firmware. Not so much on the shape of the model itself, which is something that Cura knows about but not the firmware.

I'll ask what my colleagues think, but the slicer may not be the best place to solve this issue.

[Penguin-fach]

Not sure that I understand your reasoning. Reliability of fan start depends on not just the printer model but also the users specific hardware. Some users have no issues with fan start and others have glitchy startup. The problem becomes more common as cooling fans age and bearing dry out. This is a commonly reported issue across many printer models using multiple firmware revisions and board types .

Agreed that this is not to do with part shape but it is to do with fan speed change decisions and that is something Cura takes charge of. Getting this sort of change or option implemented within printer firmware is not straightforward and would very likely fall to the individual user bit bashing their own code. Changes implemented within firmware routinely take a very long time to ripple through to end users.

All the required controls to implement this function presently exist within Gcode as standard so operational control of the print is unlikely to present a high risk of bugs unlike modifying firmware with an entirely new code function.

[nallath]

All the required controls to implement this function presently exist within Gcode as standard so operational control of the print is unlikely to present a high risk of bugs unlike modifying firmware with an entirely new code function.

But it does put the responsibility somewhere where it doesn't really belong (and also, it puts the burden of maintaining it with the slicer)

I think changing this in the firmware is about as difficult as adding it in Cura. It would also make it easier to use, since the user wouldn't even need to think about it. Last (but not least) it would also mean that you don't need different g-codes, so even if you have an older & newer machine, you can just use the same g-code.

[Ghostkeeper]

but it is to do with fan speed change decisions and that is something Cura takes charge of.

Cura knows, through the settings set by the profile, that it needs to set a certain fan speed on a certain layer. But once that's established the decision for how to implement that is somewhat the same.

For instance to go to 30% fan speed, Cura currently instructs the printer to make the fan spin at 30% of the maximum speed. The firmware interprets that as "I need to emit pulses of power to the fan of 0.7ms off then 0.3ms on." The firmware could also interpret that as "I need to first emit an acceleration pulse of 500ms and then PWM at 30%." In Cura it currently looks like M106 S76, but it could also add M106 S255, then process the time estimation for the following moves and a few g-code lines later insert the M106 S76 once it predicts that 500ms must have passed (rounded to the nearest interval between lines). Of course, then the firmware could also interpret the second line again as "Accelerate at 100% for 500ms and then PWM at 30%." which causes it to do the compensation work double. Basically, it can be implemented on either side, and hopefully not both with different thresholds or in different ways.

However we're really arguing that semantically, the function of the firmware here is to drive the hardware to produce the result indicated in the g-code. The g-code indicates to spin the fan at 30%, so the firmware must do whatever is in its power to produce that result.

Temperature is a related example that the firmware currently does. Cura's g-code just says "make sure the nozzle is at 210 degrees". The firmware knows then that it must heat up at full power first to get at this speed, then once the 205 degrees is reached power down to 60% or something, then at 210 degrees stabilise at 40% power. Yes, Cura knows when to be at which temperatures, but it's the task of the firmware to make sure that this happens. It's the same for the fan speed.

[future-figs]

Sorry about the duplicate issue! Didn't search very well...

It's a good point that dealing with the peculiarities of the hardware is usually the firmware's job, not the slicer's. However, my firmware doesn't have any relevant options built-in, and it's equally inappropriate to ask the firmware maintainers to accommodate my problematic DIY modifications. I think a good compromise between these is a post-processing script.

I wrote a very simple, very dumb script to accomplish this. For each layer, it checks the first M106. If it's under a threshold, it revs up the fans during a G4 delay at the beginning of the layer. It doesn't care if the fans were off or already spinning in the prior layer. As mentioned, this risks glitching the print, but I think it's preferable to running with no fan, or running full-blast for a full layer. It handles multiple speed changes correctly, as long as the speed is only set once per layer.

I've verified it by looking through the gcode output, but I haven't been able to use it for a real print yet—I started a 24-hour job this afternoon. I hope this is an agreeable solution.

FanKickstart.zip

Edit: That 24-hour print failed for…unrelated reasons. But as a result, I can confirm that the script works :wink:

[Ghostkeeper]

and it's equally inappropriate to ask the firmware maintainers to accommodate my problematic DIY modifications. I think a good compromise between these is a post-processing script.

Well, you're not the only one with the problem.

Marlin actually has a configuration option for this already: https://marlinfw.org/docs/configuration/configuration.html#pwm-fans-kickstart