[feature] Adaptive / Feedforward Temperature setpoint

[dc42]

@Adrian52 you should be able to reduce the overshoot by increasing the M307 R parameter a little.

RRF only knows exactly how a move will be performed about 50ms before it is executed, so unfortunately values of advance higher than 50ms are not possible.

[Adrian52]

@dc42 Have been wondering if a post process would be possible, and came across this article
https://www.nature.com/articles/s41467-025-56140-1#MOESM1
A rather impeccable source - maybe this is the way things might develop.

[Triet]

@Adrian52 I actually went through that article. I understood the basic postulates, and I even believe in the results, but why didn't the authors use regular filament material? I doubt the relevance for regular 3D printing. And you would need a T-Code slicer on the long run to avoid resync operations.

[Triet]

@dc42 I am astonished that a firmware with such a blatant limitation works so well nontheless. In my naivity, I always assumed a way farther advance scope. Processing the whole loop or all contiguous segments (not necessarily the whole layer) would be optimal, as all movements belonging together could be handled more consistently. Is RAM nowadays such a scarce asset?

[dc42]

@Triet we do process a lot of segments together, however we need to retain low latency for starting movement and for pausing. If you want to advance feedforward by 6 seconds then that means we would have to delay starting motion for 6 seconds from when you send the first motion command; otherwise how can we apply the correct feedforward to that first move? Similarly we would have to delay responding to a pause command for 6 seconds so that we don't apply incorrect feedforward to moves that have already been queued.

The compromise we have chosen is to use 50ms latency. So moves already in the queue can be amended up to about 50ms before they are due to start. We could maybe increase it to 100ms without users complaining too much, but certainly not to 6 seconds.

[Adrian52]

@dc42 could the 6 second delay work in principle, if one wanted to go down that route?

[Triet]

@Adrian52 Of course, that is possible - in principle. I don't think there is currently an option for that. It would be nice to let the user choose/set the advance time, assuming RRF can take advantage of the farther scope of impending movements.

You could not anticipate the feedforward values for the first 6 sec (or whichever advance time is set), but you would for the rest of the print time - usually hours. So in my view advantages predominate - not to mention the possibility to compensate the usual delay in temperature modulation.

But you asked DC42, so ignore my post .

[yoshimitsuspeed]

I am so stoked to see this being implemented. I have been wanting this for years now but deff didn't have the need or drive to try to develop something on my own.

I will admit I quickly skimmed a lot of the more recent posts.
Reading through my first thought was that I would greatly prefer something that aimed for the middle of a filaments range instead of starting at the low end then ramping up.
Let's say a manufacturer recommends 230-250 printing temps I would want to set the printing temp in my slicer at 240.
Then I think it would be awesome to have a min and max from there. Either deviation say +20-15 from that or just actual temp min 225 max 260 .

Then reading about the discussion on how far to look ahead I think the above strategy would largely solve the issue of a longer look ahead because you are starting in the middle of the acceptable printing range instead of way too low for most print speeds.
Using the above example if the printer is just sitting there at 240 it shouldn't really be cooking the filament and could start printing slowly or pretty fast.
Then if you had a 6 second look ahead it wouldn't need to wait 6 seconds to start. It just starts at 240, starts printing, and starts looking forward as soon as it does.

I also assume there must be some sort of averaging or smoothing on how it does that?
If it looks ahead 6 seconds and just averages flow rate over that 6 seconds then it should basically be processing real time and as soon as you hit start it just adjusts to the average for the next 6 seconds.

I would think setting the target temp in the middle would eliminate the need to wait before starting to print but it might be nice to be able to change that look ahead time depending on our machine, needs, etc, especially if there is any tradeoff. My nozzles change temp pretty fast so I don't think I would need 6 but I think being able to go into that few second range would be a lot better than 50ms.

Also right now thinking of how even typical starts take a while. Moving from the home position, pause position, etc usually takes a second or two. Print head temp could have already changed a few degrees by the time is starts pushing filament and with that inertia already heating or cooling.

I basically do this when I'm printing with my IDEX printer. I don't have it pause to heat. Have standby temp for say 215 so it doesn't cook the filament. Then by the time extruder one parks and extruder two starts pushing filament it's at 220. By the time the filaments that has been sitting nice and hot in the nozzle is pushed out it's up to 225 and a few seconds later 230.

[yoshimitsuspeed]

Out of curiosity if I started playing with this is there an easy way to make the target temp the middle of the range with heating for faster and cooling for slower than x rate? Or is there no easy way to do that?

[yoshimitsuspeed]

I have been playing with this for the last week or so and I have to say even in it's current state it is a game changer.
I think there is a lot that could be done with the idea that would make it infinitely better but I also see that there are challenges in how to implement that with existing firmware, hardware, memory, etc.

For ages I have had printing profiles in Prusa for both print settings and filament settings in about 10C increments ranging from 10-20C below to at least 20C above recommended settings for various printing speeds, part sizes, etc.

I think the current implementation can take me down to about two for most filaments which is awesome.

TPU is an example where I have configurations that go all the way down to 180C for printing tiny, super low volumetric flow rate things. And admittedly probably not with the driest filament because I can print perfectly dried filament at those speeds and higher temps without issues.

As I suspected I think the biggest evolution from here would be to use a nominal temp and printing speed in the middle somewhere and then run hotter for faster, cooler for slower.

I also think more look ahead is probably the other biggest gain that could be had.
I think something like a 2-3 second look ahead would be a massive improvement. More than that I think would still show some improvement but from there definitely at a rate of diminishing returns.

It is good enough that I am pretty sold and expect to be using this for the large majority of my printing as is. I also hope it can keep evolving and would especially love to see it switched to starting at a mid point heat, and trying to get as much look ahead as possible.

On the note of look ahead I have set to 50ms on my 3HC and 5+ and they seem to be running just fine at that.
Is there any way we could get it running higher values?

[timschneider]

@yoshimitsuspeed said in [feature] Adaptive / Feedforward Temperature setpoint:

As I suspected I think the biggest evolution from here would be to use a nominal temp and printing speed in the middle somewhere and then run hotter for faster, cooler for slower.

first find a S value that fits your setup!

you can already archive this by tuning the algorithm with the lowest possible temperature for the filament T_nom at nominal speed, e.g. F30 ( the speed you use to calibrate the e-steps). Now go to the upper end, set the hotend temp to the highest possible temperature T_max you want to extrude the filament. Now determine the maximal througput for T_max at speed F_max (use the determind maximum flow rate as flow limit in the slicer). Set the temp in the slicer to T_nom. Determine the T parameter for the temp increase from T_nom to T_max with F_nom to F_max - thats it.

An Example for PETG
T_nom: 190 °C
F_nom: 30 mm/min -> 0.5mm/s
T_max: 275 °C
F_max: 960 mm/min (40mm³ for 1.75mm FIlament) -> 16mm/s

T = (T_max - T_nom) /(F_max-F_nom) = 85°C / 15.5 mm/s = 5.48 °C / mm/s

e.g. for 24 mm³/s (1.75mm filament) it will correspond to around 245°C which is like common sense for petg.
Bare in mind that you need to tune Non Linear Extrusion after appling heater feed forward! I disable NLE for heater feedforward tuning, and tune NLE after that.

for calibration, you always have to move one non extruder axis with the extruder axis e.g.
G1 E100 F30 for e-step calibration (do not apply NLE / or feed forward)
G90 G1 X0 F2000 G91 G1 E100 X100 F960 for flowrate at F_max (apply feed forward)

the lookahead from dc42 will take care of the average and will keep the temp high for normal crusing speeds