[feature] Adaptive / Feedforward Temperature setpoint

jay_s_uk

@Adrian52 you could plot it with BtnCmd if its in the object model

Triet

@Adrian52 Wouln't you need to repeat the same print (with/without silicon sock) to properly quantify the effect? What are you comparing to?

Adrian52

@Triet Indeed - I was just looking at the feasibility of leaving off the sock. I was concerned that it would make temperature control unstable, but this doesn't seem to be the case. I thought a next step would be to plot the boosted temperature against the actual temperature, but waiting for an update that has the boosted temperature in the OM. On a learning curve with btncmd too - not used it before. Will aim to do a more formal comparison, including maximum speed and print quality.

Triet

@Adrian52 I share the same interest. If I get somewhere customizing DWC to show the temperature deviation I will post my findings.

By the way, removing the silicon sock to facilitate better temperature control is a brilliant idea.

dc42

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

By the way, removing the silicon sock to facilitate better temperature control is a brilliant idea.

Even better would be to replace the hot end by one with much lower thermal mass and heating/cooling times, such as the E3D Revo.

Adrian52

@dc42 I am in fact using a revo micro on my delta, and just ordered a 60w heater, to see if it shortens the heating time. Hope it doesn't melt my part cooling duct!

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.
alt text
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?