[feature] Adaptive / Feedforward Temperature setpoint

[Triet]

@dc42 The thoroughgoing extrapolation of this idea would be an
INo Trident

[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 moton 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 .