[feature] Adaptive / Feedforward Temperature setpoint

droftarts

@timschneider Interesting! There is a discussion in the OrcaSlicer community about this, see https://github.com/SoftFever/OrcaSlicer/discussions/5057, and an implementation as a post-slicing app here https://github.com/sb53systems/G-Code-Flow-Temperature-Controller

I think while it could be firmware controlled, a slicer implementation might be more desirable.

Ian

dc42

@timschneider interesting! This could be implemented as an extension to M309, https://docs.duet3d.com/User_manual/Reference/Gcodes#m309-set-or-report-heater-feedforward, perhaps by adding a T parameter to specify the temperature increase(s) per unit of extrusion speed.

timschneider

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

@timschneider Interesting! There is a discussion in the OrcaSlicer community about this, see https://github.com/SoftFever/OrcaSlicer/discussions/5057, and an implementation as a post-slicing app here https://github.com/sb53systems/G-Code-Flow-Temperature-Controller

I think while it could be firmware controlled, a slicer implementation might be more desirable.

Ian

hey cool - yes i though that a slicer implementaion is even better, but the problem is the calibration of it, it takes ages to calibrate the PA and NLE for every setpoint and since we can automatically calculate the NLE in the printer as a macro, we can also tune the adaptive temp control with it, automatically.

timschneider

@dc42
do you mean something like the following:

From 83be8a6fac88110fc62f6e105f522ef601164b69 Mon Sep 17 00:00:00 2001
From: Tim Schneider <tim@schneider.engineering>
Date: Wed, 21 Aug 2024 14:22:41 +0200
Subject: [PATCH] - M309: added T parameter to specify the temperature
 increase(s) per unit of extrusion speed

---
 src/Heating/Heat.cpp        |  4 ++--
 src/Heating/Heat.h          |  2 +-
 src/Heating/Heater.h        |  2 +-
 src/Heating/LocalHeater.cpp | 17 +++++++++++++----
 src/Heating/LocalHeater.h   |  4 +++-
 src/Heating/RemoteHeater.h  |  2 +-
 src/Tools/Tool.cpp          | 15 +++++++++++++--
 src/Tools/Tool.h            |  1 +
 8 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/src/Heating/Heat.cpp b/src/Heating/Heat.cpp
index 397c25bd..cd4cb7d0 100644
--- a/src/Heating/Heat.cpp
+++ b/src/Heating/Heat.cpp
@@ -876,14 +876,14 @@ void Heat::FeedForwardAdjustment(unsigned int heater, float fanPwmChange, float
 }
 
 // This one is called from an ISR so we must not get a lock
-void Heat::SetExtrusionFeedForward(unsigned int heater, float pwm) const noexcept
+void Heat::SetExtrusionFeedForward(unsigned int heater, float pwm, float degree) const noexcept
 {
 	if (heater < MaxHeaters)
 	{
 		Heater * const h = heaters[heater];
 		if (h != nullptr)
 		{
-			h->SetExtrusionFeedForward(pwm);
+			h->SetExtrusionFeedForward(pwm, degree);
 		}
 	}
 }
diff --git a/src/Heating/Heat.h b/src/Heating/Heat.h
index 7ca1e5e4..5e49680b 100644
--- a/src/Heating/Heat.h
+++ b/src/Heating/Heat.h
@@ -128,7 +128,7 @@ public:
 	GCodeResult SetActiveOrStandby(int heater, const Tool *tool, bool active, const StringRef& reply) noexcept;	// Turn a heater on
 	void SwitchOff(int heater) noexcept;								// Turn off a specific heater
 	void FeedForwardAdjustment(unsigned int heater, float fanPwmChange, float extrusionChange) const noexcept;
-	void SetExtrusionFeedForward(unsigned int heater, float pwm) const noexcept;
+	void SetExtrusionFeedForward(unsigned int heater, float pwm, float degree) const noexcept;
 
 #if HAS_MASS_STORAGE || HAS_SBC_INTERFACE
 	bool WriteModelParameters(FileStore *f) const noexcept;				// Write heater model parameters to file returning true if no error
diff --git a/src/Heating/Heater.h b/src/Heating/Heater.h
index 64f61666..b71f3405 100644
--- a/src/Heating/Heater.h
+++ b/src/Heating/Heater.h
@@ -57,7 +57,7 @@ public:
 	virtual void Suspend(bool sus) noexcept = 0;						// Suspend the heater to conserve power or while doing Z probing
 	virtual float GetAccumulator() const noexcept = 0;					// Get the inertial term accumulator
 	virtual void FeedForwardAdjustment(float fanPwmChange, float extrusionChange) noexcept = 0;
-	virtual void SetExtrusionFeedForward(float pwm) noexcept = 0;
+	virtual void SetExtrusionFeedForward(float pwm, float degree) noexcept = 0;
 
 #if SUPPORT_CAN_EXPANSION
 	virtual bool IsLocal() const noexcept = 0;
diff --git a/src/Heating/LocalHeater.cpp b/src/Heating/LocalHeater.cpp
index 9059d7f2..eaff1314 100644
--- a/src/Heating/LocalHeater.cpp
+++ b/src/Heating/LocalHeater.cpp
@@ -86,7 +86,7 @@ void LocalHeater::ResetHeater() noexcept
 	mode = HeaterMode::off;
 	previousTemperaturesGood = 0;
 	previousTemperatureIndex = 0;
-	iAccumulator = extrusionBoost = 0.0;
+	iAccumulator = extrusionBoost = extrusionTemperatureBoost = lastExtrusionTemperatureBoost = 0.0;
 	badTemperatureCount = 0;
 	averagePWM = lastPwm = 0.0;
 	heatingFaultCount = 0;
@@ -189,7 +189,7 @@ GCodeResult LocalHeater::SwitchOn(const StringRef& reply) noexcept
 		return GCodeResult::error;
 	}
 
-	const float target = GetTargetTemperature();
+	const float target = min<float>(GetTargetTemperature() + extrusionTemperatureBoost, GetHighestTemperatureLimit());
 	const HeaterMode newMode = (temperature + TemperatureCloseEnough < target) ? HeaterMode::heating
 								: (temperature > target + TemperatureCloseEnough) ? HeaterMode::cooling
 									: HeaterMode::stable;
@@ -282,9 +282,17 @@ void LocalHeater::Spin() noexcept
 		if (GetModel().IsEnabled())
 		{
 			// Get the target temperature and the error
-			const float targetTemperature = GetTargetTemperature();
+			const float targetTemperature = min<float>(GetTargetTemperature() + extrusionTemperatureBoost, GetHighestTemperatureLimit());
 			const float error = targetTemperature - temperature;
 
+			if (extrusionTemperatureBoost != 0.0 || lastExtrusionTemperatureBoost != extrusionTemperatureBoost)
+			{
+				// calculate new heater mode to prevent heater fault due to exceededAllowedExcursion
+				String<1> dummy;
+				(void)SwitchOn(dummy.GetRef());
+			}
+			lastExtrusionTemperatureBoost = extrusionTemperatureBoost;
+
 			// Do the heating checks
 			switch(mode)
 			{
@@ -570,9 +578,10 @@ void LocalHeater::FeedForwardAdjustment(float fanPwmChange, float extrusionChang
 }
 
 // Set extrusion feedforward. This is called from an ISR.
-void LocalHeater::SetExtrusionFeedForward(float pwm) noexcept
+void LocalHeater::SetExtrusionFeedForward(float pwm, float degree) noexcept
 {
 	extrusionBoost = pwm;
+	extrusionTemperatureBoost = degree;
 }
 
 /* Notes on the auto tune algorithm
diff --git a/src/Heating/LocalHeater.h b/src/Heating/LocalHeater.h
index cf0840c5..d5a18221 100644
--- a/src/Heating/LocalHeater.h
+++ b/src/Heating/LocalHeater.h
@@ -39,7 +39,7 @@ public:
 	float GetAccumulator() const noexcept override;							// Return the integral accumulator
 	void Suspend(bool sus) noexcept override;								// Suspend the heater to conserve power or while doing Z probing
 	void FeedForwardAdjustment(float fanPwmChange, float extrusionChange) noexcept override;
-	void SetExtrusionFeedForward(float pwm) noexcept override;				// Set extrusion feedforward
+	void SetExtrusionFeedForward(float pwm, float degree) noexcept override;	// Set extrusion feedforward
 #if SUPPORT_CAN_EXPANSION
 	bool IsLocal() const noexcept override { return true; }
 	void UpdateRemoteStatus(CanAddress src, const CanHeaterReport& report) noexcept override { }
@@ -76,6 +76,8 @@ private:
 	float lastPwm;											// The last PWM value set for this heater
 	float averagePWM;										// The running average of the PWM, after scaling.
 	volatile float extrusionBoost;							// The amount of extrusion feedforward to apply
+	volatile float extrusionTemperatureBoost;				// The amount of extrusion feedforward to apply
+	float lastExtrusionTemperatureBoost;					// The amount of extrusion feedforward to apply
 	float lastTemperatureValue;								// the last temperature we recorded while heating up
 	uint32_t lastTemperatureMillis;							// when we recorded the last temperature
 	uint32_t timeSetHeating;								// When we turned on the heater
diff --git a/src/Heating/RemoteHeater.h b/src/Heating/RemoteHeater.h
index a6c09029..a30872d7 100644
--- a/src/Heating/RemoteHeater.h
+++ b/src/Heating/RemoteHeater.h
@@ -30,7 +30,7 @@ public:
 	float GetAccumulator() const noexcept override;							// Return the integral accumulator
 	void Suspend(bool sus) noexcept override;								// Suspend the heater to conserve power or while doing Z probing
 	void FeedForwardAdjustment(float fanPwmChange, float extrusionChange) noexcept override;
-	void SetExtrusionFeedForward(float pwm) noexcept override { }			// We can't yet set feedforward on remote heaters because this is called from an ISR
+	void SetExtrusionFeedForward(float pwm, float degree) noexcept override { }			// We can't yet set feedforward on remote heaters because this is called from an ISR
 	bool IsLocal() const noexcept override { return false; }
 	void UpdateRemoteStatus(CanAddress src, const CanHeaterReport& report) noexcept override;
 	void UpdateHeaterTuning(CanAddress src, const CanMessageHeaterTuningReport& msg) noexcept override;
diff --git a/src/Tools/Tool.cpp b/src/Tools/Tool.cpp
index c0676b8f..b41174c9 100644
--- a/src/Tools/Tool.cpp
+++ b/src/Tools/Tool.cpp
@@ -946,6 +946,12 @@ GCodeResult Tool::GetSetFeedForward(GCodeBuffer& gb, const StringRef& reply) THR
 		gb.GetFloatArray(heaterFeedForward, numValues, false);
 		ToolUpdated();
 	}
+	else if (gb.Seen('T'))
+	{
+		size_t numValues = heaterCount;
+		gb.GetFloatArray(temperatureFeedForward, numValues, false);
+		ToolUpdated();
+	}
 	else
 	{
 		reply.printf("Tool %u heater feedforward:", myNumber);
@@ -953,6 +959,11 @@ GCodeResult Tool::GetSetFeedForward(GCodeBuffer& gb, const StringRef& reply) THR
 		{
 			reply.catf(" %.3f", (double)heaterFeedForward[i]);
 		}
+		reply.printf("Tool %u temperature feedforward:", myNumber);
+		for (size_t i = 0; i < heaterCount; ++i)
+		{
+			reply.catf(" %.3f", (double)temperatureFeedForward[i]);
+		}
 	}
 
 	return GCodeResult::ok;
@@ -964,7 +975,7 @@ void Tool::ApplyFeedForward(float extrusionSpeed) const noexcept
 	Heat& heat = reprap.GetHeat();
 	for (size_t i = 0; i < heaterCount; ++i)
 	{
-		heat.SetExtrusionFeedForward(heaters[i], extrusionSpeed * heaterFeedForward[i]);
+		heat.SetExtrusionFeedForward(heaters[i], extrusionSpeed * heaterFeedForward[i], extrusionSpeed * temperatureFeedForward[i]);
 	}
 }
 
@@ -974,7 +985,7 @@ void Tool::StopFeedForward() const noexcept
 	Heat& heat = reprap.GetHeat();
 	for (size_t i = 0; i < heaterCount; ++i)
 	{
-		heat.SetExtrusionFeedForward(heaters[i], 0.0);
+		heat.SetExtrusionFeedForward(heaters[i], 0.0, 0.0);
 	}
 }
 
diff --git a/src/Tools/Tool.h b/src/Tools/Tool.h
index 2c2e5afb..e071000b 100644
--- a/src/Tools/Tool.h
+++ b/src/Tools/Tool.h
@@ -188,6 +188,7 @@ private:
 	float activeTemperatures[MaxHeatersPerTool];
 	float standbyTemperatures[MaxHeatersPerTool];
 	float heaterFeedForward[MaxHeatersPerTool];
+	float temperatureFeedForward[MaxHeatersPerTool];
 
 	// Firmware retraction settings
 	float retractLength, retractExtra;			// retraction length and extra length to un-retract
-- 
2.39.2.windows.1

I'm not sure about the change of the method interface and so on but if it is heading in the right direction I can prepare a merge request.

Update
The implementation will not fit into Duet2 due to too less rom.
It will fit if the wifi is compiled without W5500 and the ethernet without WIFI
or both without FTP and Telnet support

Tinchus

@droftarts I was just about to post a question regarding feed forward till I found this post.
I think the feedforwwar tool doesnt cover all the issue. As mentioned here, you can print perfectly PLA at 180 degrees with excelent quality, BUT you will be restricted on how fast you can print. On the other hand, you can print PLA at 150 mm/s on a 0.8 nozzle only if you go up in your temp to 230 degrees oir little more, but as soon as you slow down you quality goes to the trash bin because of that excesive temp.

The feedforward config at least to me has not solved this in my prints, I have to either choose print really fast and hot or normal/slow and "cold". My question was going to be if the feedforward command could add some type of algorithm to take into account the cubic mms being extruded instead of the printing speed, in that way you would be covering all nozzle spectrum and printing speed at the same time.

And regarding where: I think the oposite. It should be the formware the one in charge of that because the slicer never knows the real speed of a path. Final real speed is decided by firmware, the slciewr never knows the real printing speed (and that is the reason why the time calculation on slicer are allways really off)

timschneider

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

And regarding where: I think the oposite. It should be the formware the one in charge of that because the slicer never knows the real speed of a path. Final real speed is decided by firmware, the slciewr never knows the real printing speed (and that is the reason why the time calculation on slicer are allways really off)

Thats a good point!

I made a PR for this https://github.com/Duet3D/RepRapFirmware/pull/1036

But due to memory contrains, it will not fit in the ROM of a regular Duet2 combined firmware. You need to disable other not important features to make it work e.g. Telnet and FTP.

timschneider opened this pull request in Duet3D/RepRapFirmware

closed [WIP] M309: add T parameter to specify the temperature increase(s) per … #1036

Tinchus

@timschneider I wonder if temp increase VS speed will be ok when you change to a bigger noozle and you go slow; in that situation you would have a potential huge increment of mm3/s but a lower speed. Example: 100 MM/s speed with a 0.4 noozle . The you switch to a 0.8 nozzle and go to 80 mm/s

timschneider

@Tinchus it is extruder speed e.g. movement of filament per sec, not travel speed so it is accounting for that. I print with 0.8mm to 1.2mm nozzles.

Tinchus

@timschneider that is what I meant. May be Im wrong so please clarify: the push request is using the new requested T parameter in terms of extrusion speed or volumentric speed? Because the firmeware actually never knows what size of nozzle you are using: if slicer request a 10 mm/s extrusion move and you are using a 0.8 nozzle volumen and needed temperature will be quite dfifferent if the slicer request the same speed but you are using a 0.4 nozzle. am I wrong?

timschneider

@Tinchus, it's the extrusion speed. So I use 2.85 mm filament and if I use an extrusion speed of 1 mm/s, for example, it is about 6.38 mm³/s, regardless of the nozzle size. The only difference between extrusion speed and volume speed is the area of the filament, e.g. for 2.85 mm filament 6.38 mm² and thus only a factor.

droftarts

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

So I use 2.85 mm filament

I thought it was just me using up everyone else's 2.85mm filament! If I ever get my Trident-ish machine finished, I've got a Titan extruder with volcano CHT nozzles (probably 1mm nozzle dia) tool earmarked for it, to get through all the old stock (after it's spent time in the filament dryer), and print big things fast! So some form of temperature feedforward would be good.

Ian

droftarts

@timschneider As this feature has been added (https://github.com/Duet3D/RepRapFirmware/commit/b300085b44b2fe403d231a674b3b29f702c6b66f), have you got any suggestions for the tuning method that I could add to the feedforward documentation?

M309 in the Gcode dictionary has been updated to say:

Parameters
...
Tddd:eee:fff... Feedforward temperature increase coefficients. The number of coefficients provided must equal the number of heaters configured for the tool when it was created (see M563). Supported in RRF 3.6.0-beta.2 and later.
Aggg Feedforward advance time in milliseconds, maximum 100. RRF will attempt to apply the temperature and PWM adjustment this time in advance of the start of the corresponding move. This advance time may not always be achieved, for example when commencing movement from standstill. Supported in RRF 3.6.0-beta.2 and later.

Notes
...
The units of T are degrees Celsius per mm/sec of filament forward movement.

No notes on the A parameter.

Ian

0

dc42 committed to Duet3D/RepRapFirmware

Refactored heater feedforward implementation, added T and A parameters

timschneider

@droftarts
Hi @droftarts
I use the following tuning method:

determine the lowest possible temperatur Temp_base for the filament, e.g. extrude with F30 (0.5 mm/sec Speed_base) so that the filament is melting and will bond to each other
define your desired extrusion rate, e.g. 35 mm³/sec -> calculate the required extrusion speed -> around 5.5 mm/sec (Speed_desired) for 2.85mm filament -> F330
Extrude the filament with the desired speed + 20% and increase the temperature of the hotend till you are able to extrude at the desired speed. Note the needed temperature for that speed Temp_required. The extrusion length should be at least two times your hotend length. The 20% increase is some kind of error margin for non linear extrusion and when the fan is on.
calculate the needed temperature boost with Temp_boost = (Temp_required - Temp_base) / (Speed_desired - Speed_base)

For Example PLA

Temp_base = 190
Temp_required = 230
Speed_base = 0.5 mm/s
Speed_desired = 5.5 mm/s
Temp_boost = 40 / 5 => 8 => T8

Edit: Temp_base will be the temperature you set in your slicer for that material.

timschneider

@droftarts
I have updated the description so that it hopefully becomes clearer how much material has to be extruded and why you should aim for a 20% plus error margin and that you should use the temp_base for slicing.

timschneider

@dc42
thank you for implementing the temperature feedforward.
It took me a while to get it installed on a machine and test it, unfortunately I was not able to get it working. Maybe its a pure display thing, but I do not see the temperature increase I was expecting.

I set M309 P0 S0.06 T8 A100 and was extruding at 245°C with 0.6mm/sec, so I was expecting an temperature increase of 4.8°C but the temperature in DWC was still at 245°C.

the following chart is showing the print process and a pretty stable temperature without the increase and decrease of the temperature feed forward.

The printer is on

timschneider

@dc42
The problem is the A100 - without the A param it works.
What is the purpose of the A param - I thought it is kind of a look a head and will set the temp increase in advance.
But it will not work for short moves.

To reproduce:

G28 X Y
M568 P0 R160 S230
T0
G91
echo "will not work"
M309 P0 S0.05 T8 A100
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120

G4 S5
echo "will work"
M309 P0 S0.05 T8 A0
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120
G1 X1 E1 F120

dc42

@timschneider we knew that large A values will not work correctly, because there need to be enough moves in the queue that have been committed in order to look that far ahead. I think A40 should generally work: can you try that?

Triet

@dc42
I dared to try

Using firmware version 3.6.0-beta.4 and with following command in my config.g:
M309 P0 S0.06 T10 A40
I can confirm that temperature modulation based on flow rate works.

I used the small model below as a preliminary experiment, printed at a nominal temperature of 190 deg C. (usually I print this material at 212 deg C).

Remarks:
During the first layer the temperature jumped to over 220 deg C but with the bed at 45 deg C this was unnecessarily high to achieve bed adhesion. To avoid such surprises I managed to disable this feature for the first layer alone using
the macro command
M309 P0 S{(layer_num == 0 ? 0 : 0.06)} T{(layer_num == 0 ? 0 : 10)} A{(layer_num == 0 ? 0 : 40)}
which yields M309 P0 S0 T0 A0 for ths 1st layer only; then the temperature set for the 1st layer in the slicer is used unchanged.

I needed several retries because I was getting a heater fault error right at the 1st layer. The increase was too sudden I guess. Only after I reconfigured the heater fault detection I could continue the print:
M570 H1 P15 T20 ; wait 15 sec, allow 20C deviation

The maximum temperature increase happened at the widest height of the model and was about 5 degrees, but only a short time.
Most of the time the print temperature stayed around 192C, that is, only 2 degrees higher than set. Although the speeds were set up to 300 mm/sec, due to a layer time limitation and weak cooling fan, the print went quite slow with 20-35 mm/sec.

The deviation between target and actual temperatures can't be assessed during the print, because the increase introduced by this feature is done in the firmware - this is as expected, but raises the need of a plug-in in DWC to preview the effect.

Manually overriding the extrusion speed live during the print (or perhaps using M220) did cause a corresponding increase in temperature, as it should be.

It is unclear to me whether extrusion rate increases caused by non-linear extrusion configuration (M592) also cause temperature increases. In theory, his could lead to a vicious circle, because a temperature increase by itself also promotes a higher extrusion.

I learned that this feature works only increasing the temperature, never decreasing it. That means that one is compelled to choose a nominal printing temperature (the one set in the slicer) that should be low enough that no decrease is necessary due to a smallish flow. This could happen to be inconvenient, depending on the average flow and temperature range needed. This method is suitable to adapt temperature in regions with higher flows, overcoming potential bottlenecks.

A better approach would have been (in my opinion) to consider the nominal temperature to correspond to the average flow rate, allowing both increases and decreases. In most cases no special tests or calibrations would be needed with this method; for example, setting 205C for PLA, thus allowing a range of +/- 15C=30C. Flow rate "spikes" would be still accounted for. This way, small details and overhangs would benefit too (a more common concern than printing at very high speeds, if quality is important).

In other words, as it is implemented, you would set for a benchy a nominal temperature corresponding to the chimney top - suboptimal I think.

Print details:
Duet 2 WiFi + 0.4 nozzle, PLA, 0.12 mm layer height, 0.3 mm layer width, one wall only (to challenge the operation!)

And I got this result:

The print was quite good in my opition, and was not worst than a good one done without the feature under same conditions. Still learning.

I have gathered some experience using the post-processing script mentioned above. It is difficult to believe how felicitous that script manages the temperature/flow relationship. That solution works differently though: It controls speeds in such a way that the flow matches the temperature when the temperature can't be changed fast enough; it also smoothes the flow rate - sounds dangerous, but works surprisingly well. Unfortunately, it is only a post-processing script with the respective disadvantages. The author was told that such feature belongs to the firmware realm - here we have it.

I think this feature of the version 3.6.0 will be vastly underestimated. I consider it a big jump, really.

By the way, the description in the documentation of M309 should be corrected. It states:
"This feature is intended for high flow hot ends or pellet extruders. It's not normally needed on regular hot ends with a 0.4mm or similar size nozzle where the temperature drop caused by extrusion is less than 1C."
The feature may be inteded as described, but it is not limited to mere anticipation of temperature fluctuation of the nozzle due to changing flow. In fact, it contributes to a much better control of a key parameter, namely temperature. I myself will be using it quite often, I think.

Hope I helped a bit.

timschneider

@dc42

ok, A40 is working - but shouldn't A100 act like A0 if A100 can not be maintained? Instead it was acting like T0.

@Triet
thanks for you tests! You can maybe increase the layer height to increase the volumetric flow rate, as the T parameter from M309 is multiplied by the speed in mm/s of the filament (extruder) - not the movement speed of the X and Y axis. Your absolute maximum flow rate is about 5.44 mm³/s which is about 2.26 mm/sec for 1.75mm or 0.85 mm/sec for 2.85mm filament, which corresponds to 227.6°C or 213.5°C. Thats a steep increase, unless you have a powerfull heater, your printer will not be able to follow. I use T8 with an 60W heater and 2.85mm filament. I run my prints with 25 - 40 mm ³/s.

Triet

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

0

This was a test I spontaneously decided to do without planning, but it turned out unsuitable for the purpose of temperature modulation. The maximum flow rate of 5.44 mm3/s (using a 1.75 mm filament) happened very shortly and was not representative at all. I did notice the jump though - causing a heater fault at my first try.

I also use a 60 W heater, in a copper block (E3D style) and an original CHT nozzle. It can achieve a 25C increase faster that one would think, but certainly not fast enough if the model consist of parts with disparate flow rates in succession. And that is exactly the test case I am printing right now:

As you can recognize here:

The temperature is set at 195C but settles at around 199C +/-2C, it can't follow as you say. The range would be much wider if it could. But there are some layers with predominantly high flow, I am waiting to see how the temperature behaves then (I am staring at the display).

Based on my experience using the postprocessing script mentioned above, the maximum temperature lag was about 5C, in most cases only 3C - but that script uses a different method, where the flow rate is adapted (smoothed) to match the predicted temperature, very clever in my opinion. The temperature/flow rate relationship is defined there by entering three points of desired temperature at the given flow rates, quite easy. I could envision that a similar method is implemented in the firmware. But even this T-Parameter is a thing as it is now. I have learned to appreciate the value of temperature control and am quite excited about it.

More tests following.