fan speed-up time

[supermerill]

Hi
I was looking at the kick_start_time for the fan.
The exemple ini show a positive value.
But in fan.py, I see print_time += self.kick_start_time.
For what i understand, the kick-start just help to start the fan spinning but it doesn't reduce the speed-up time.
My problem is my fan takes 2 seconds to speed-up to full speed and my bridge line takes 1.5 sec to print.
What i wanted is to say to the firmware to speed up the fan a bit before to have it at the right speed when the g-code say it.
Can i try to code something an make a pull request for that? (an acceleration & deceleration parameter, and a bit more planning on fan.py)

[oderwat]

I think this is a cool idea! I believe I had a similar problem in the past while printing PETg.

[supermerill]

untested proposal:
https://gist.github.com/supermerill/4795f51b7464fddd842f639cb2f55359

[KevinOConnor]

What i wanted is to say to the firmware to speed up the fan a bit before to have it at the right speed when the g-code say it.

Modifying the planner so that fan speeds are processed out of order would be a lot of work. The scheduling and flushing mechanisms, in general, expect actions to occur in ascending time.

-Kevin

[supermerill]

In my proposal, i kept it in-order.

[KevinOConnor]

If you want to start spinning the fan 2 seconds before the next move after an M106 command, then I can see two options:

• delay printing for 2 seconds while the fan spins up
• or, always read, parse, and buffer 2 seconds of moves so that the fan speed can be found and implemented 2 seconds out of order with respect to moves.

The first does not require any code change at all - just add a "G4 P2000" to the g-code commands after the M106 command.

The second would require a great deal of work.

-Kevin

[sniperlucian]

Maybe easiest way could be to pre process the G-Code file and push the M106 up the time. Time could be roughly estimated by calculated the time needed for the moves beforehand. Also could only be activated between moves.

Not very accurate but should be enough for this purpose. And should be fairly easy realized.

[supermerill]

Well, I was thinking it's the job of the firmware, not the slicer. Currently, nobody do this.
I may try do make something in the slicer side, as it's easier for me to test, and i don't have the time this year to create an OoO pipeline for klipper.

[supermerill]

Heelo again.
In my slic3r fork, i added an option to move fan activation before to let the printer speed it up.

There are two option : just move the gcode, and move the g-code and add a DXXX option to M106 to send the time (in ms) it has to spin up.

exemple without:

G1 Z1.040
G1 E6.00000 F2400.00000
G1 F1800
G1 X119.790 Y119.790 E0.50231
G1 X100.210 Y119.790 E0.50231
G1 X100.210 Y100.210 E0.50231
G1 X119.730 Y100.210 E0.50077
G1 X119.686 Y100.596 F10800.000
G1 F8640
G1 X119.790 Y119.790 E-5.16697
G1 X117.770 Y119.790 E-0.53303
G1 E-0.30000 F2400.00000
G1 Z1.640 F10800.000
G1 X118.662 Y101.338
G1 Z1.040
G1 E6.00000 F2400.00000
M106 S255
G1 F1200
G1 X118.662 Y118.662 E0.81458
G1 X101.338 Y118.662 E0.81458

exemple with:

G1 Z1.040
G1 E6.00000 F2400.00000
G1 F1800
G1 X119.790 Y119.790 E0.50231
G1 X100.210 Y119.790 E0.50231
M106 S255 D1562
G1 X100.210 Y100.210 E0.50231
G1 X119.730 Y100.210 E0.50077
G1 X119.686 Y100.596 F10800.000
G1 F8640
G1 X119.790 Y119.790 E-5.16697
G1 X117.770 Y119.790 E-0.53303
G1 E-0.30000 F2400.00000
G1 Z1.640 F10800.000
G1 X118.662 Y101.338
G1 Z1.040
G1 E6.00000 F2400.00000
G1 F1200
G1 X118.662 Y118.662 E0.81458
G1 X101.338 Y118.662 E0.81458

In this exemple, (made with my setting to "at least 1 second"), it says "from here, please spin up the fan to have it at 100% power in 1.5 sec". This time is a rough computation (infinite acceleration), but as it's not critical, it should be good enough.
It should be easier for klipper to plan the exact time to change the velocity of the fan, assuming he know the acceleration curve of it. When there are a long extrusion before a bridge, I don't want to split it in two to place the M106 in-between, if I can avoid it.

If you think it's possible & welcome, i may be able to code something to implement this in the future.