[feature] Adaptive / Feedforward Temperature setpoint

[Adrian52]

Another experiment, with a 60W e3d revo heater, and no socks. The print is a 20x100mm cube, and a set of 6 8mm diameter cylinders. The cylinders print quite slowly and the cube at 140mm/sec.

This is an excel graph of csv data captured by btncmd (not worked out how to plot calculated values in btncmd).
I added the active temp to the boost (a+b) to compare to the actual temp(current). You can see there is a bit of a lag on both the heating and cooling phases.
I also plot the extrusion volume, and you can see that the boost anticipates the increase in extrusion, although not by enough to align with the current temperature. I plotted extrusion+active temp(e+a) to move the extrusion line up to the area of the current temp line.
Not quite sure why the active +boost is below the current temperature in the initial phase - this is the relatively slow printing of the first layer.

[Triet]

@Adrian52 If the command would allow an option to limit the extrusion (=speed) to match the actual temperature, it would be much better, as layer adhesion would be optimal. Delamination and sudden breaks under mechanical load would be a thing of the past.

[Adrian52]

@dc42 the 60w heater on the revo seems to work fine, albeit with a tendency to overshoot a bit. The heat /cool curve (current) is not too bad, but lags the extrusion /boost curves by about 6 seconds. I tried increasing the queue size to 120, which is probably near the limit for my old duet2wifi. The A parameter at 50 works then. Is there any way to adjust for the lag?

[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?