search

MarlinFirmware / Marlin

Marlin is an optimized firmware for RepRap 3D printers based on the Arduino platform. Many commercial 3D printers come with Marlin installed. Check with your vendor if you need source code for your specific machine.
https://marlinfw.org
GNU General Public License v3.0
16.25k stars 19.23k forks source link

"Heating failed" when starting with hotend that's already close to target temp #3167

Closed ghost closed 8 years ago

ghost commented 8 years ago

I'm getting "heating failed" trigger when starting with a hotend that is already close to the temp.

I'm running RC3

Steps to reproduce:

  1. Start a print as normal
  2. Have the print mess up, and fix the slicer settings :)
  3. Go to start print again, and end up with a failure.

The only workaround I've found is to let the hotend cool to around 100C before starting the heating again. Is there a better solution? I'm going to try tweaking the window in which the sample for heating failure is taken, but that window should really be proportional to how close you are to the target temp already.

Log:

Recv: ok
Send: N6 M104 S215 T1*32
Recv: ok
Send: N7 M109 S215 T1*44
Recv: T:195.5 E:1 W:?
Recv: T:194.6 E:1 W:?
Recv: T:194.1 E:1 W:?
Recv: T:193.6 E:1 W:?
Recv: T:193.1 E:1 W:?
Recv: T:192.7 E:1 W:?
Recv: T:192.3 E:1 W:?
Recv: T:192.3 E:1 W:?
Recv: T:192.3 E:1 W:?
Recv: T:192.3 E:1 W:?
Recv: T:192.7 E:1 W:?
Recv: T:192.7 E:1 W:?
Recv: T:193.2 E:1 W:?
Recv: T:193.6 E:1 W:?
Recv: T:193.8 E:1 W:?
Recv: T:194.2 E:1 W:?
Recv: Error:Heating failed, system stopped! Heater_ID: 1
Changing monitoring state from 'Printing' to 'Error: Heating failed, system stopped! Heater_ID: 1
'
Recv: Error:Printer halted. kill() called!
jbrazio commented 8 years ago

In the Configuration_adv.h have a look at the THERMAL_PROTECTION_HOTENDS section. Have a look at #3117, Thermal Protection was relaxed a bit due to similar issues.

I'm not saying this ìs your issue, but could be related.

ghost commented 8 years ago

I think this will fix my issue. Thank you. I'll test it, see if it works, and report back

Blue-Marlin commented 8 years ago

@jbrazio #3117 is not merged yet, but this issue is a further argument to do it.

@mzbotreprap All in all the algorithm we use is not that bad, but the default parameters are a bit tight. In your case WATCH_TEMP_PERIOD expired before the temperature reached the temperature when you started M109. The temperature was 1.3 + WATCH_TEMP_INCREASE ° away from what the algorithm was told to be acceptable for a healthy heater. That falling of the temperature before the energy reaches the thermometer is normal and quite strong at high temperatures. By setting a longer WATCH_TEMP_PERIOD the problem is perfectly solvable. I suggest +50 to 60%.

Please report back what values are working for you.

jbrazio commented 8 years ago

@Blue-Marlin nvm I believed it had been already merged, well at least he can try the new default values.

ghost commented 8 years ago

Thanks guys! Hope this gets merged for RC4. The new thresholds worked wonderfully.

Did the following tests: 190C -> 220C 200C -> 220C 210C -> 220C

No errors.

Should I close this, or will it get closed automagically when the commit is merged, since it's linked now?

jbrazio commented 8 years ago

Great to ear that ! You may close it, thanks.

Blue-Marlin commented 8 years ago

To reproduce your initial issue heating, waiting until sable, setting the higher temperature is not sufficient. That would have worked with the old settings. It needs set initial heating, waiting until sable, switch off, wait until you see the temperature falling, set the higher temperature.

ghost commented 8 years ago

I basically reproduced my original conditions. Let me elaborate on the testing steps:

Heat to 220C -> Let it stabilize -> Turn off heat -> As the temp falls, wait for it to cool to 190C -> Begin heating back to 220C

This was failing 100% of the time before. Now it's working even if I'm closer to the target temp.

Blue-Marlin commented 8 years ago

Just to visualize the effect

heatdelay Testcode and protocol:

M105
M109 S190
M105
G4 S20
M105
M109 S210
M105
M109 S190  ; RH does not draw the target graph with R
M105
M109 R190
M105
M109 S210
M105
M104 S0
M105

20:29:38.056 : N59 M109 S190*92
20:30:32.614 : ok
20:30:32.614 : N60 M117 ETE 00s*53
20:30:32.618 : ok
20:30:32.668 : N63 G4 S20*105    <<<< Graph skips for M4
20:30:52.662 : ok
20:30:52.662 : N64 M117 ETE 00s*49
20:30:52.666 : ok
20:30:52.713 : N67 M117 ETE 00s*50
20:30:52.740 : ok
20:30:52.743 : N68 M109 S210*85    <<<<
20:31:23.909 : ok
20:31:23.909 : N69 M117 ETE 00s*60
20:31:23.913 : ok
20:31:23.971 : N72 M117 ETE 00s*54
20:31:23.975 : ok
20:31:23.977 : N73 M109 S190*84    <<<< ~31s
20:31:23.983 : ok
20:31:24.006 : N75 M109 R190*83
20:32:04.784 : ok
20:32:04.784 : N76 M117 ETE 00s*50
20:32:04.788 : ok
20:32:04.842 : N79 M109 S210*85    <<<<
20:32:42.322 : ok
20:32:42.322 : N80 M117 ETE 00s*59
20:32:42.326 : ok
20:32:42.372 : N83 M104 S0*94    <<<< ~37s
20:32:42.375 : ok

In reality only the time until PID kicks in is relevant, but as the time from there to the end of M109 S210 is constant, the difference of ~6 sec is valid. At the end of the second 190° plateau we already heat a bit. So in reality the difference is more than 6 seconds.

thinkyhead commented 8 years ago

@mzbotreprap The behavior you describe is actually a bug. The temperature watcher was not being disabled properly, giving spurious errors when heating a second time. That bug has been patched in RCBugFix. I wonder if you could give the current RCBugFix branch a test to see if the error exists at this time. The relaxed settings may not be necessary in your case after all.

saintofinternet commented 7 years ago

could you please post the THERMAL_PROTECTION_HOTENDS settings after the correction...

jeffmagill commented 6 years ago

I believe I just ran into this - or something similar. I downloaded and installed a new, clean octoprint today on a RP2 (octopi-jessie-lite-0.14.0.zip). I started a print, realized I had the scaling wrong and cancelled. Fixed the scaling, uploaded the new gcode, and clicked the print button. This took about 30s.

The web interface paused for a few seconds, and then threw up the red error dialog with the message reported in OP (Error: Heating failed, system stopped! Heater_ID: 0). I rebooted the RP. Ever since, the web UI refuses to load and ~/.ocotprint/ogs/octoprint.log does not register any additional lines.

thinkyhead commented 6 years ago

@jeffmagill — We don't know much about OctoPrint. This issue queue is for reporting bugs or suggesting features for Marlin. If you have a bug to report, please open a new issue. Otherwise, please seek help from one of these community resources:

jeffmagill commented 6 years ago

My apologies. Too much late night debugging. I thought this was the octoprint repo.

On Fri, Apr 13, 2018 at 10:30 PM Scott Lahteine notifications@github.com wrote:

@jeffmagill https://github.com/jeffmagill — We don't know much about OctoPrint. This issue queue is for reporting bugs or suggesting feature for Marlin. If you have a bug to report, please open a new issue. Otherwise, please seek help from one of these community resources:

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/3167#issuecomment-381297470, or mute the thread https://github.com/notifications/unsubscribe-auth/AAxcWmmy8Ym5sojZKyJ1Wxh4y33agwUGks5toV9FgaJpZM4HyhNU .

TINLIANG commented 6 years ago

Hi then I would like to ask why can't I heat up my hot end when my build plate heats up perfectly fine.. Please help me out as I am fairly new to the 3D printing stuff

thinkyhead commented 6 years ago

@TINLIANG —

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. For best results getting help with configuration and troubleshooting, please use the following resources:

After seeking help from the community, if the consensus points to to a bug in Marlin, then you should post a bug report.

Ivomola commented 6 years ago

I know this post is a little bit "old", but I recently autotuned the Kp, Kb and Ki values of the bed and the hotend (with 12 and 15 cycles respectively) and I just started to suffer from this issue, and I have the MarlinTarantula Easy Config by @JimBrown, wich currently it's the version bugfix 1.1.x, from 20/1/2018, so I think it isn't fixed in rcbugfix, and it's a shame because this is my 5th thermistor I have coz I've alredy broken 4 and it has alredy saved my life 5 or 6 times when it broke during printing

thinkyhead commented 6 years ago

I just started to suffer from this issue

The thermal protection code is just looking for the machine to stay within the parameters that are set for it. So try relaxing your thermal protection settings to allow more time for the hotend to heat. Try increasing the hysteresis so the firmware won't throw an error when your hotend drifts far away from the target temperature due to cooling. And if the PID loop isn't keeping the temperature stable after M303, hand-tune the parameters until it does.

deanparmenter commented 5 years ago

to anyone searching this out, like i was. the issue was my psu not supplying enough voltage. I tested it at 23.4V i cranked it up to 25v and havent had any problems since.

Ivomola commented 5 years ago

I´m not a developer, and I´m not in charge of managing threads, but pretty sure this was closed a while ago. Either way, thanks for the heads up, that will probably help many people with the same issue that comes to this thread.

linuxgator commented 5 years ago

to anyone searching this out, like i was. the issue was my psu not supplying enough voltage. I tested it at 23.4V i cranked it up to 25v and havent had any problems since.

Probably just beating a dead horse with this comment, but I was also having the same error and it was taking forever to heat up. When I started looking at the voltage, I realized that the PSU was set for 230V input, and not 115V that is used in the US. I flipped the switch, and voila, no more issues and it heated up much quicker.

github-actions[bot] commented 2 years ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.