search

prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.8k stars 1.94k forks source link

[Feature Request] 'Active Temperature Control' for multi-extruder prints: dynamically heat/cool tools so they are ready when needed. #5554

Open n8bot opened 3 years ago

n8bot commented 3 years ago

PrusaSlicer has very accurate print time calculation built in. Using this ability, it should be fairly simple to implement a feature to cool down and heat up tools so that they are ready for use when they are needed. The feature is intended to reduce the time taken waiting for tools to heat up at tool changes.

The slicer IceSL has this feature. They describe it like this:

Active temperature control is specifically designed to avoid material to degrade and ooze from idle extruders. The idle extruder is dynamically cooled down and heated during printing, such that it is ready when needed and cooled when not needed. Adjust extruder parameters idle_extruder_temp_degree_c and extruder_degrees_per_sec when using this feature.

IceSL implements this feature well. A target standby temperature is set very low: 100 degrees C by default. The user then estimates and inputs the time it takes to heat/cool in degrees per second. The slicer then calculates, for all tool changes, at what point during the layer to start pre-heating the next tool. Also, importantly, it decides to what temperature to cool the tool being deselected so that it doesn't cool down too much for the time it needs to be inactive. This means the tools may be commanded to different temperatures for standby depending on how long it will be inactive. It gets as cool as possible, given the time, and with enough time will be cooled down much lower than other slicers achieve.

This is only really useful for printers with discrete tools: IDEX or toolchangers. Prusa may not have any such printers on the market right now, but they should make an IDEX printer because they are friggin rad.

Also, if Prusa Research is not willing to implement this feature, I would be glad to help in any way I can, and seek help form others to implement this feature in a way that would be acceptable to the Prusa team.

Kachidoki2807 commented 3 years ago

Duplicate https://github.com/prusa3d/PrusaSlicer/issues/5248

n8bot commented 3 years ago

Duplicate https://github.com/prusa3d/PrusaSlicer/issues/5248

Oops! Sorry about that. I tried searching and couldn't find that one. I should have looked under the multi-material tag rather than searching.

I'm glad to know I'm not alone in wanting this!

Have you tried IceSL? How do you like they way they do this?

When they close this for being a duplicate I will re-add my comments of support to your issue.

Kachidoki2807 commented 3 years ago

Oops! Sorry about that. I tried searching and couldn't find that one. I should have looked under the multi-material tag rather than searching.

No problem. ;-)

Have you tried IceSL? How do you like they way they do this?

I have tried IceSL a long time ago, but unfortunately not under this aspect.

But I tried this feature from IdeaMaker, and what I remember is that the temperature reaching is not awaited at the toolchange. So when going to some extreme deltas, I got a cold extrusion error. But that's not the worst, I also got a printer kill heating failed, because under some conditions, the PID never stabilize cause the temperature setpoint constantly change.

I have also gave a try to the ooze prevention from PrusaSlicer, not compatible with wipe tower and imply to use an ooze shield. This one wait for the temperature, but the ooze shield is the worst I have ever tried. The nozzle wait few millimeter outside the ooze shield, which make it ooze a lot (!) and then the shield is supposed to grab the ooze... sometimes.

So it is not trivial to implement, but with a wipe tower to help, it might be doable.

bubnikv commented 3 years ago

We plan to do exactly that: To use the time estimator to plan for the extruder heat up. It may be part of PrusaSlicer 2.4.

n8bot commented 3 years ago

Fantastic. Thank you.

Starscream83 commented 3 years ago

Hi, any news about this topic? Will this feature be present in 2.4?

n8bot commented 3 years ago

@bubnikv how are the chances looking that we will see tool pre-heating for toolchanges in 2.4.0?

I know I am not the best coder, but I would be willing to volunteer time if needed to test this feature or anything, to expedite its arrival in prusaslicer.

Also, would be cool if custom toolchange/start/end g-code is included in time estimation if it's not already. Even just the ability to add a user-determined number of seconds for specific events would be good.

bubnikv commented 3 years ago

We plan to implement extruder preheat to support our upcoming XL printers.

n8bot commented 3 years ago

Lol, yes, I guessed that. Hence my offer for help testing it! Just an offer.

n8bot commented 2 years ago

@bubnikv would it be possible to allow custom g-codes to manually adjust the estimated amount of time required to execute?

For instance, in my tool change G-code I call a custom .gcode file on my printer's sdcard to park the tool. 

M98 P"tpark{previous_extruder}.g" ; park tool

The time estimator probably thinks this takes zero time, but maybe it takes an average amount of time, or an exact time, that the user can determine. Then maybe we could tag the line with the amount of time to add (or subtract? who knows) from the time estimate. I.e.:

M98 P"tpark{previous_extruder}.g" ; park tool [time_adjust=20]
; or
M98 P"tpark{previous_extruder}.g" ; park tool [time_adjust=-20]
Ro3Deee commented 4 months ago

We plan to implement extruder preheat to support our upcoming XL printers.

from my experience with Prusa XL, a next tools (plural) preheating is need. When layer time is small (for current and some future tools) like, for example, when each tool extrudes just tiny bit of filament on the model, not just the next tool needs preheating, but some of the futures ones. I propose a new setting for the mashine (or tool), where the user can draw the time/temperature graph and the slicer than can calculate the time need to heat the extruder from the idle temp of the filament to the temperature needed for printing and start heating the future tools (plural) at the appropriate moment, so the printer doesn't pause (to wait for temp) when picking the tool

image

Ro3Deee commented 3 months ago

The current implementation of M104.1 is to ignore the P and Q params ( time in seconds till the temperature S is required) simply process this command as if it was standard M104.

M104.1 GCode was introduced to Prusa-Firmware-Buddy by this commit: https://github.com/prusa3d/Prusa-Firmware-Buddy/commit/652a65f8c176db7069917d13bb51dab6b40769ae to early set hotend temperature so that the printer can start preheating the tool in advance.

PrusaSlicer started to use M104.1 in place of M104 with this commit: https://github.com/prusa3d/PrusaSlicer/commit/c916249f2b0e2d9b50077cf3c2402115426ef4f4

OrcaSlicer started to use M104.1 with this commit: https://github.com/SoftFever/OrcaSlicer/commit/7d0fb4f42a3f6a1f43503a601491071b8e29052c and issues it even on current tool to set a delayed future temp.

As the current implementation is to simply process this command as if it was standard M104, M104.1 is wrongly used.

Prusa Buddy FW has an incomplete implementation of M104.1. There are 3 different issues related to M104.1:

In my opinion, what is need is not an early preheating command M104.1 that tell the firmware "I need X degrees for that extruder in 10 seconds from now", but a gcode that sets the extruder temperature when is need (like M109 with a boolean param for preheating) that actually starts heating earlier. So the fw should look ahead (for 1-2 minutes of gcode), find the relevant M109 commands (with that boolean param true) for the other tools and start to preheat them according to their pid values at the appropriate time so when execution arrives at M109 for that tool, it already has the desired temp. When parking a tool, the fw should determine the minimum temperature allowed for cooling and start heating it up when reached so, when it will be picked it will have the needed temp.