Oh! I see you already tried M303 in your photo. Sucks! Well I guess you need to go for option #2 above.
Oh! I see you already tried M303 in your photo. Sucks! Well I guess you need to go for option #2 above.
Try cutting P and I in half from original and leaving D alone:
M301 P18.30 I0.76 D110.03
Also how much more powerful is the new hot end? If it is 50% more watts then I would reduce all the values by the inverse (multiply them by 0.66).
power = p*(current error in degrees) + I*(integrated error) - D*(slope of temp change)
(D term is actually +D*(slope of error change) which is the same as -D*(slope of temp change) because the set point doesn't move much).
Thanks Gr5 for the quick answers you are always helping...
:smile:
In the meantime i have tried several other settings all with the same result of massive overshoot.
e.g.
M301 P1 I0.1 D100
gave the same result as
M301 P18 I100 D10
and everything in between.
I will start over and try your algorithm to see if this works better, but i am starting to think that this hasn't to do anything with the PID-Controller....
Otherwise the massive changes i made should have shown at least some effect (e.g not even reaching target temperature as described in at the end of this http://reprap.org/wiki/PID_Tuning), but it was always the same...
The heating cartridge ishttp://e3d-online.com/RepRap-Spares-Electronics/RepRap-Heater-Cartridge:
http://e3d-online.com/RepRap-Spares-Electronics/RepRap-Heater-Cartridge
I have followed your routine for five steps and ended up at:
P0 I0 D110
Same problem of massive overshoot and Autotune abort.
I also tried negative values:
P-18.3 I-0.76 D110
I give up for the weekend.
The strangest thing is that even with negative or any other values the hotend seems to be capable of holding one set temperature, if i use the Cura-Print-dialogue to set it.
This clearly isn't a problem of the PID-settings. Otherwise i would have seen any change in the behaviour of the hotend as i changed the values. These PID-Values i entered seem to change nothing. Although i stored them in EEPROM already which is -i assume- the "harddrive" of the Arduino.
In the meantime i have tried several other settings all with the same result of massive overshoot.
e.g.
M303 P1 I0.1 D100
gave the same result as
M303 P18 I100 D10
and everything in between.
Do you mean M303? Should be M301, for setting P, I & D (which is what you used earlier in the thread). You might also save your settings to EEPROM, and then power-cycle the machine to make sure that any changed settings get used. There was definitely a bug in the Ulticontroller code earlier this year that prevented new values from getting used until you rebooted the printer - but you're not using an ulticontroller to set the values, i don't think?
Yeah, right. I meant M301. edited this... thx
That thing about the powercycle i haven't tried. I will as soon as i get back on the printer.
And no i wasn't using the ulticontroller to set the PID-Values. I have one connected though.
P-18.3 I-0.76 D110
This should turn it off when you ask for high temp. So yes, I agree, the PID values aren't doing anything.
when you start pronterface it queries the UM for the PID values. Check those values to make sure they agree with what you set them to (after a power cycle).
Unless you've built your own, more recent, firmware the Ulticontroller will show and store totally wrong values for I and D, and then not use them until you power cycle it. I fixed that bug last Spring, but UM still ships UM1 firmware from last March with Cura.
If you have the 'retraction bug fix' in your firmware, then you almost certainly also have the Ulticontroller PID bug fix.
However, I was pretty sure that the 'don't use it until a reset' bug didn't happen when setting the values via gcode.
but UM still ships UM1 firmware from last March with Cura.
That recent? I thought it was more than a year old.
No, not much changed between December and March, but there were a few tweaks. But the last build was for Cura 13.03. The bug fixes I made just missed the 13.03 build.
I had to install a Firmware i built with ginges Marlin builder, because of the EPCOS NTC i am using. I think the PID-Fix should be in there.
I can't verify that the power-cycle bug isn't active, because i am not at my university right now. But if the power-cycle-bug and the Ulticontroller-PID-bug are propably not the reason, what is it then?
P.S: I have checked the EEPOM with M501. It held the settings i had given it...
I think it's the power cycle bug. If not then you are using "bang bang" heating instead of PWM/PID heating. I know that is an option for the heated bed but I don't think that's even an option for the nozzle heater.
Hmmm...
Does it do something when current to nozzle is definded as well for the bang-bang mode as for the PID-mode?
// PID settings:
// Comment the following line to disable PID and enable bang-bang.
#define PIDTEMP
#define BANG_MAX 255 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX 255 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
It also seems that a change in PID-Values does only change the behaviour of the hotend if it is to hold a given Temperature. When i run Autotune it just heats up with full power even though i have used P0 I0 D255.
I will set BANG_MAX to 127, compile, flash and run M303 again.
Here is a screenshot that illustrates my problem: First i ran M303 to 50°C, which led to 100°C overshoot (as before). Then i let it cool down to 55°C and set the Temp to 65°C. That Temperature was never reached because the majorly altered PID-Settings i have mentioned are now used.
Greetings Jump
This is an interesting thread - please keep us informed.
I think I remember seeing something a while back about some changes Daid made to the PID code to do with the initial heat up; I'm not exactly sure what it was, but I remember some comment about 'being able to heat up faster initially'. I wonder if this is what you're seeing - perhaps it was changed so that the PID only kicks in after temp is reached... and in your case that may be causing a huge overswing because of your different configuration compared to the standard one. Or maybe I'm totally mis-remembering it??
I know he found a bug in the PID code and he fixed it and sent in the fix to the Marlin erik zalm version a while back. I think that fix made it heat and cool a bit faster. Not sure though.
"PID functional range"
The problem I fixed in the PID Marlin implementation had to do with the functional range on the PID controller. Normally the PID only starts to regulate when within 10 degrees, which is far to close if your hotend is over-powered and heats up fast. It's also silly to have a functional range in a PID controller, and the only reason to have it in there is to protect against runaway control. If your heating is stuck 10C above or below the set temperature, then the PID controller is not actually doing anything except pushing it out of the function range all the time.
Anyhow, the bug I fixed had to do with the initialization of the D factor in the PID controller. The D factor was not "running" while the PID controller was not controlling the temperture. This caused the heater to go off for a while as soon as the temperature was in the function range, causing an odd temperature jump. Which in turn can "confuse" the PID controller a bit.
Note, some overshoot is not that bad. On the UM2 I setup the PID controller so that it initially overshoots a bit once, and then stabilizes on the set temperate. This makes it reach the final temperature quite fast, some initial overshoot is not that bad, as the heater block needs some time to adjust itself to the new temperature anyhow.
So which versions of Marlin now calculate the D factor (slope of the error) before it hits the +/-10C window? I assume the versions of Cura that come with UM1 don't have this fix, correct? Also UM2 has the fix, correct? Also the latest ErikZalm version has this fix, correct?
UM2 has this fix, I'm unsure if I fixed it in the mainline marlin, I'll double check tomorrow.
Planning to make a new UM-Original firmware for the next Cura release ;-)
Yay!!!!!! :-)
Planning to make a new UM-Original firmware for the next Cura release :wink:
yay, too....
Okay, so after a few months I am back on this problem. Here is my current Marlin setup concerning the PID-values and ranges.
-You can see that i significantly reduced the PID_MAX and BANG_MAX to one fourth of its original value (255) and even that seems to be too much still.
-Also changed PID_FUNCTIONAL_RANGE. This is what made the PID Autotune stop.
Thanks Daid :wink:
-The PID-Values are what i got from running M303 P150 C10
#define PIDTEMP
#define BANG_MAX 64 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX 64 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
#ifdef PIDTEMP
//#define PID_DEBUG // Sends debug data to the serial port.
//#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX
#define PID_FUNCTIONAL_RANGE 200 // If the temperature difference between the target temperature and the actual temperature
// is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.
#define PID_INTEGRAL_DRIVE_MAX 64 //limit for the integral term
#define K1 0.95 //smoothing factor within the PID
#define PID_dT ((16.0 * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine
// If you are using a preconfigured hotend then you can use one of the value sets by uncommenting it
// Ultimaker
#define DEFAULT_Kp 6.75
#define DEFAULT_Ki 0.42
#define DEFAULT_Kd 27.80
The problem is still there but it is not as bad as before. The overswing was reduced to 7° when I set a target temperature of 210°C as shown in the screenshot i attached.
(Ignore the small dent after set-temperature is reached. It is because my tempsensor fell out...)
I have tried to run M303 again to get rid of that -even tried manual tuning- but it didn't help so i think i have to live with this. :-/
Recommended Posts
gr5 2,228
2 things:
1) When you do do autotune you set the goal temperature. Simply lower this goal temperature to avoid the abort issue. For example download and install pronterface/printrun (it's free) and you can now send gcodes to the printer by typing them.
https://github.com/ErikZalm/Marlin/
Search for M303 in the above. Again, use a different goal temperature for the tuning.
The nice thing is it displays the calculated P,I,D values in pronterface when done.
2) I recommend this article on PID controllers:
http://en.wikipedia.org/wiki/PID_controller
There's tons of information in there. I guess the thing you want to understand:
P is the most important factor. You can set P alone and it will work but it will oscillate if too high or it will take forever and never quite get up to temp if too low.
I helps long term to find the exact right temp. It integrates the error over the whole time you've had it turned on and adjust accordingly. This is what makes it eventually work perfect after a few minutes.
D reduces oscillation and over shoot - it sees that you are heating up too fast and puts on the brakes so to speak.
Daid has a mode in the latest marlin that lets you see the contributions from P,I, and D as a graph in Cura. I don't know how to enable all that. To get the latest Marlin you would have to build your own as this isn't offerred with any Marlin's that come with Cura.
So if you have oscillation you want to increase D a little and decrease P and I a little. But it could take weeks to figure this all out with many trial and error. So hopefull #1 above will help you.
Link to post
Share on other sites