Temperature Overshoot On Extruder

[Q*bert]

I'm getting a 19 degree temperature overshoot on the initial ramp up of the extruder when setting the temperature at 185.  This is using the stock firmware downloaded from the Makergear wiki. 

I've run Marlin auto-tune (M303 S185) add set the PID values (M301),

I still get a 19 degree overshoot in initial ramp-up.

At 225 degrees the overshoot is about 25 degrees.

Any ideas on how to fix this?

[Dale Reed]

Q'bert,

 

It sounds like the auto-tune function is tuning for quarter-amplitude damping (QAD).  This gets the temperature to setpoint faster, but results in the overshoot.  There are cases in industry where QAD is a good thing, because it minimizes the integral of the error over time.  (The overshoot error "makes up for" the undertemperature error, mathematically.)  But in most cases, lambda tuning is preferred.  Lambda tuning's goal is to provide decent temperature control (enough integral gain to drive to setpoint and hold there, mopping up disturbances "enough") but guaranteeing no overshoot.  (As you can probably guess, overshoot can be a VERY bad thing, like in damaging the PEEK component of the MG hot end, or, on chemical reactions that are exothermic, generating a runaway condition.  Proper lambda tuning prevents things like damage to property, people, cities, etc....  You might also guess that I'm a control systems engineer by profession.... if the engineer-speak above doesn't make sense, I apologize.)

 

Unfortunately, I'm not as familiar with the M301 / M303 and the other G-code elements as I would like to be, having just started out in 3D printing.

 

Is there an M code that lets you read back the P, I and D gain values generated by the auto-tune function?  (Maybe they are in the response to the M303?)  And is there documentation of the UNITS of these gain / time values and how the algorithm uses them?  Some algorithms use "dependent" gains, where a change to the P gain also propogates to the I and D gains   ---   Kp * ( e + (integral of error)/Ti + Td * de/dt ) --- note the parentheses --- and some algorithms use "independent" gains, where Kp only multiplies the error --- a change in parentheses ----   Kp*e +  (integral of error)/Ti  +  Td * de/dt.  Also some algorithms use "integral time" --- minutes per repeat --- and some algorithms use "integral gain" --- repeats per minute.  I would need to know these details in order to advise how to modify the values.  The most likely is the "dependent" gains algorithm.  In this case, dividing the proportional gain Kp by 2.0 should provide something closer to critical damping and minimize or eliminate overshoot --- without going through all the effort of doing lambda tuning.  If there's still some overshoot, your can safely divide Kp by 2 again, but response to disturbances will not be as good.

 

So, if I totally confused you, sorry.  Just try this:

 

Use the M303 to run the auto-tune.

 

Use whatever M code (or, with verbose mode, read the response to the M303?) to find out what the calculated P, I and D gains are.

 

Divide the P gain by 2.

 

Apply those gains (M301 with new parameters?) and test.  Let us know how it works.

 

I've noticed the overshoot on the extruder.  The bed is less prone to it just because of the higher thermal mass compared to the available heating.  The heater for the extruder can heat up that little brass nozzle PDQ.

 

There are some excellent non-linear (fuzzy logic) algorithms for temperature control, especially for heat-only applications, which basically modify the tuning on the fly and recognize the "uncontrolled" ramp-up at full heat vs. the "controlled" area close to setpoint.

 

Good luck.  If you are successful, please post back here with the M-codes you used and the responses from the printer (and a screen-grab of the temperature trend chart, if your software has one).

THANKS!

 

Dale

 

www.isa.org/cap

[Q*bert]

Thanks for the help Dale.  I tried your suggestion of cutting the P gain in half.  I also tried adjusting the I and D settings in the firmware and nothing would ever make any appreciable difference in the overshoot. The extruder would always overshoot by 20 or so degrees upon initial heating.  Changing the PID values only affected stability after the temperature settled after the initial overshoot.

Then it occurred to me that the problem was that so much power was being put into the extruder on initial heat-up and that the rate of heating was so high that the overshoot was inevitable.  The PID control would shut off power when the target temperature was reached, but the "inertia" was too great.

So, I changed the PID_MAX setting in the Marlin code from 255 to 127.  Now the extruder heats at a reasonable rate and the overshoot is kept to about 5 degrees.

It seems to me that the code posted in the forums as the shipping firmware is not exactly the shipping code  as I didn't have this problem, at least at this severity, until I re-uploaded the firmware using the posted code.   I'll check with the Makergear folks.

[Dale Reed]

Q'bert,

Okay, thanks for the info.  It looks like a classic "second-order system.  Think about it this way:  If you were dinking the output to the hot end heater manually, and set it to 255 to get the temperature ramping up nice and fast, then set it to 0, you'd still see the temperature measurement rise for a few seconds.  This is because the nichrome wire is hotter than the brass nozzle, so some more heat comes off of it and heats the nozzle more.  So it's two series "heatings", if you will.

This is the sort of thing that model-predictive controller algorithms excel at handling.  Instead of a single lag, there are two (plus, probably, a small sensor lag as well).  A model-predictive controller (MPC) is "tuned" by setting the controller gain, the loop dead time, and the various system lags.  (Deadtime is how long after you type in the 255 before you actually see the temperature start to rise...)   You can measure all the times you need from the trend chart of the temperature from the "open-loop" test described above.  They are entered directly into the algorithm.  Given those, it then "knows" how the temperature will respond to a change in power -- not just how much, but WHEN as well.  And MPC algorithms can be built with a similar "auto-tune" function -- it just does the open-loop test automatically and determines the gains and times just like you would from the trend..

In my experience, the PID's Proportional, Integral and Derivative gains make sense if you can deal with a bunch of nasty differential equations, but they don't really "relate" (by "feel") to the actual dynamics of the "process under control" --- the numbers are just numbers with no obvious relation to the actual process response.  MPC systems use numbers that are directly measured from the process response.  It really is a "model" that makes intuitive sense.

Now the real question becomes: how do we get the Marlin firmware programmers a good MPC second-order algorithm with auto-tune to replace the PID?  (Even a deadtime + 1st order lag MPC would be a vast improvement....)

One more thought comes to mind.  This might be WAY easier to code into firmware.  On a "large" change in temperature (when it's more than, say,  30 degrees from the current temperature to the target), the firmware could heat (or let cool) full bore, then turn off the heat and enable the PID algorithm.  The temperature would coast a bit toward the final value, and the PID would take over.  It's basically just a simple sequence that gets the process variable (temperature)  into the "linear PID controlllable range" before enabling PID control.

Q'bert, thanks for this thought-provoking discussion.  I'll have to find the Marlin firmware project and get involved.  Another thing I don't have time for.  I've been on vacation this past week and haven't run my M2 at all --- too much "spring" house and yard work to do!

Dale

[Michael Ang]

Another approach to work around this is to stabilize to a temperature a little less than your target temperature and then go to the target temperature.

For example if your target temperature is 220C then you could heat to 200C and then to 220C.  You might overshoot 200C but when that stabilizes and then you go to 220C the delta is only 20C and the overshoot seems to be a lot less.

Here's what I have in my start.gcode in Cura.  Not sure what software you guys are using but maybe you can do something similar (I'm using the E3D V5 on a Prusa i3 Berlin).

; Heat to temperature - a little lower at first to avoid overshoot

M109 S200.000

M109 S{print_temperature}.000

Just realized this thread is a year old, but I guess in Google it's forever ;)

  - mang