Closed VanessaE closed 4 years ago
I do believe I have the same issue. I was printing at 240° just fine. The fan came on and my nozzle temp drop so low it triggered thermal projection and stopped the printer. I rolled back to a previous build and dropped the temp to 230° so I could get the print done. I am now back on the build which is around 4 days old, but haven't printed again since. My build in question was downloaded and flashed when the LPC176x updates were added. I will have to test 240° with fan again I think. I've added a sock for good measure.
I've added a sock for good measure.
and the fan is aimed just below the nozzle so that it does not cool the nozzle?
@boelle , that's actually central to this bug report -- just about ALL layer fans cool the hotend at least somewhat, either by directly blowing on it, or by air being redirected back onto the hotend by the bed or by features of the printed part. In practice, a hotend is supposed to temporarily drop in temperature due to the fan, then pick back up within seconds.
Without this effect, I would not have seen the PWM/PID failure happen (probably because without the fan, there would be nothing to compensate for besides filament flow and thus drive the heater PWM to 127).
Come to think of it, if you extrude a lot of filament at a constant, fast rate (such as when flushing the hotend when switching from one type of plastic to another), the heater has to compensate for the added load. So, it may be possible to reproduce this PWM issue without involving any fans, though it would waste some filament.
@boelle Yes my nozzle doesn't pint directly at the nozzle
After updating to 534f2d69 and doing PID tuning by hand, I was able to somewhat compensate for this problem, but not entirely, and maybe this is why:
While tuning (again, by hand), one thing I saw was that PWM values would jump up and down wildly while the temperature is trending up or down.
In fact, even while at a steady state once I settled on PID values I was happy with, with the hotend holding at 230°, with the fan at max, and the nozzle positioned a few millimeters above the center of a cold bed, I was seeing the same wild swings in PWM values, i.e. 120...90...127...53...100...86...110...0...90...67...
Yes, all the way from rail to rail, while steady state after several minutes. I don't think this is how it's supposed to behave... I would think it would quickly settle somewhere with less than a range of, say, ±5.
I have this issue as well. When printing at 215C and the fan turns on at 50% the hotend drops to 200±5C and then increases back to 215C. Once it's up to temp. If I increase it to 230 manually even with the fans on it heats up to 230C with seemingly no issue. It seems that it only drops initially when the fans come on. Using an SKR 1.3 - Stock CR-10 Heater with an e3D v6 Block with a 12V 350W power supply. I tried PID tunning to no avail. Manually adjusting the PID gets it to a usable state where it doesn't trigger the thermal runaway.
@VanessaE i guess the release of 2.0 a few days ago has not changed anything?
and i dont mean 2.0.x but 2.0
I have not tried 2.0, but I was able to mitigate it enough by tinkering with my PID settings and reworking my cooling to keep the layer fan's airflow off of the hotend. That doesn't mean it's fixed, I just managed to "hide" it :smile:
well give it a shot when time allows, 2.0.1 should be out some time before weekend is over
so if you are good with programming its also an option to throw in a PR that can fix it
Heh, I'm a decent programmer... but not in C-like languages. I'll leave that to the more experienced.
Out of scope, but @boelle , Marlin 2.0.0 has now rolled out, maybe you could stop your issue report killer role. No ?
@Patag maybe, maybe not
@boelle yeah, I think it's safe for the "cleaning crew" to head home for the night. There'll be more stuff to deal with soon enough. :wink:
hehe, its my job here so i will pop up from time to time at random hours
and since @Patag does not have any issues open i cant see what his problem is other than trying bad french humor i dont understand :-D
This is still a problem on bugfix-2.0.x
at commit ccdeb3f2cd291e050f6a5e6f503455e697f893e8 . Freshly cloned, configured, compiled, and flashed in today. My previous attempt to mitigate the issue was unsuccessful.
Today's print was sliced in constant-flow volumetric mode, as are most things I print, and it was ticking along just fine at 235°C, with the fan on at 20% speed. It had been that way for nearly 2½ hours, so it was as close to a nice steady-state condition as it is possible for a print to be. That is, until Marlin decided it didn't want to apply the proper amount of power to the hotend heater.
Like before, if left unchecked, it'll gradually drop in temperature until it reaches the point where it thinks there's a thermal runaway. That happened once today on a very simple object (a large, square box), ruining the print.
It almost happened a second time today, but thankfully I caught it. When I saw that the temperature was low, this issue came to mind, so I simply turned the target up a few degrees (via Pronterface's control, which undoubtedly sends M104 Sxxx
). As in my initial report, that got Marlin out of this weird condition, and it started to correct the hotend temperature. Once it had come back up a bit, I simply set the target back to 235° (at no point did I allow the temperature to exceed that). I did not interrupt the print, or do anything that would have logically affected the hotend's heating capacity.
Clearly the hotend can heat up just fine, and the fan is running at such a low setting that it may as well be off as far as the hotend's concerned, and I'm not using the same board as in my initial post (that board died, so now I'm using an older SKR v1.1). So, I am 100% certain my hardware is not at fault, otherwise tweaking the temperature target would not have made it work.
didn't … apply the proper amount of power to the hotend heater.
Things like this which occur spuriously are hard to account for. Reproducibility is the one true hallmark of a logical bug. Leaving all our machines on at 235° for 2 ½ hours with no guarantee of a similar result is not something I want to do. But I have done several prints longer than 2 hours lately in the 210°C range without any thermal oddities occurring. (Broken bed heating wire notwithstanding.)
Since nothing in the G-code presumably altered the temperature during the entire print, the implication is that there is some kind of overflow condition in the PWM heater code. But, there is nothing that "accumulates" here as far as we are aware.
Since you have run into the issue on a few occasions, perhaps you can enable extra logging in your host software to observe the output of M105
along with the heater power values. Then if you hit the issue again you will be able to send along the logs and show where the PID / PWM starts to get wonky and apply too little power. From the logs it's possible the trigger condition will be obvious.
I did not interrupt the print, or do anything that would have logically affected the hotend's heating capacity.
I did spend a day chasing phantom issues for a while before I found that broken bed wire. Sometimes a spurious issue turns out to be a failing MOSFET, or a wire that gets a little loose once the printer is past a certain Z height. So of course, it's almost as tricky to rule out those types of issues. Since you were able to get things moving by raising the temp, it implies something can be reset by changing the target temp (which we're not so sure about). But it also doesn't necessarily rule out a funky MOSFET.
Reproducibility is the one true hallmark of a logical bug. Leaving all our machines on at 235° for 2 ½ hours with no guarantee of a similar result is not something I want to do
Agreed on both. However, I detailed a procedure in my opening post that should take more like 5 minutes.
In short: heat up the hotend to 230° or so, then turn on a fan pointed at the heatblock -- something with enough airflow that the heater won't be able to fully compensate. Hold it in that state for a minute or two, then turn the fan off before Marlin has a chance to throw a thermal runaway error. With a little luck, it'll fail to heat back up and THEN throw a thermal runaway.
Since nothing in the G-code presumably altered the temperature during the entire print, the implication is that there is some kind of overflow condition in the PWM heater code.
This was my first thought, since the host reports that the heater is pegged at PWM=127 when it gets into this state.
But it also doesn't necessarily rule out a funky MOSFET
I would consider that, if not for one detail: this happened on two boards (SKR v1.1 and a v1.3).
In short: heat up the hotend to 230° or so, then turn on a fan pointed at the heatblock -- something with enough airflow that the heater won't be able to fully compensate. Hold it in that state for a minute or two…
Should the temperature be made to drop? And by how much?
…then turn the fan off before Marlin has a chance to throw a thermal runaway error. With a little luck, it'll fail to heat back up and THEN throw a thermal runaway.
Ok, so I get a hint of what might be happening. With the "heater watching" behavior, a thermal runaway will be thrown if the temperature fails to rise as expected while the heater is turned on.
Generally speaking, the heater watch is only supposed to be enabled during the initial heatup. Once you reach the target that goes away and the regular thermal protection takes over. However, if the temperature drops below the target temperature by WATCH_TEMP_INCREASE + TEMP_HYSTERESIS + 1
degrees the heater watch will start again.
So, if you relax the settings for WATCH_TEMP_PERIOD
and/or WATCH_TEMP_INCREASE
and/or TEMP_HYSTERESIS
and it should at least prevent thermal runaway from occurring in cases where the temperature gets stuck hovering at too far below the target.
Should the temperature be made to drop? And by how much?
10 degrees would probably be sufficient. It really just depends on how much more power the heater has to spare, which of course depends on the heater type, voltage, and somewhat on the hotend it's in.
So, if you relax the settings for
WATCH_TEMP_PERIOD
and/orWATCH_TEMP_INCREASE
and/orTEMP_HYSTERESIS
and it should at least prevent thermal runaway from occurring in cases where the temperature gets stuck hovering at too far below the target.
Right, which is what I did when this first became an issue. The question then remains, why is it getting stuck in the first place?
why is it getting stuck in the first place?
In the test case we are blowing the fan onto the heater to drop the temperature to force a drop in temperature. We could also disconnect the heater wire to get a similar effect.
On your setup, presumably some component such as the MOSFET is failing or overheating and becoming highly resistant, or a wire is becoming frayed, and the heater is no longer getting enough current. There is nothing so far implicated in the firmware, because it is not unheard of for components to "reset themselves" when conditions are changed. And we have no way to know that other factors were not involved.
I can see no condition in the PID loop that would cause it to go haywire, and we have not heard other reports of this issue. So unfortunately, without detailed data (applied power, state of the PID loop, etc.) collected on your machine from several minutes before and during a failure, we have no way to see what is causing the heater to simply stop heating. A detailed log might show us that the firmware has turned on the pin or is generating PWM pulses, and yet the temperature is falling. Or, it might show that some value goes out of range and this breaks the PID loop or the PWM pulses.
As always is the case for such things where we cannot reproduce the issue, we depend entirely on the person experiencing the issue to eliminate all possible contributory causes and to collect data that ideally points directly to the culprit and the solution.
We've added logging to other systems like bed leveling to help us with collecting troubleshooting data. All we can do is be very thorough and add a bunch of logging to the PID loop and PWM generator, get that installed on your machines and always-on so next time this occurs we have a complete picture of what is happening.
We could also disconnect the heater wire to get a similar effect.
That should work, yeah, though turning on a fan may be easier on some machines.
On your setup, presumably some component such as the MOSFET is failing or [...]
But like I said, this happened on two different boards, and I do not use any kind of external power circuit to drive the heaters, so I'm certain that I can rule out the controllers and their MOSFETs. Don't get me wrong, it's still reasonable to question the hardware, since the hotend, its heater (a common 12v/40W cartridge), and its thermistor have remained unchanged.
I am building a second printer from almost all new parts (it's been kinda gnawing at me to give CoreXY a try), and hopefully in a few days, I'll be moving my hotend to it, but it'll be getting a new heater cartridge (because the new machine will be 24v). In effect, it'll be a brand new machine. In order to keep it functional, the old printer will get my previous hotend, with the common heater cartridge that comes with it.
So, when all is said and done, both machines will have had all suspect hardware replaced, just as a matter of course. With a little luck, I'll still be able to reproduce this issue afterward, on both machines.
There is nothing so far implicated in the firmware, because it is not unheard of for components to "reset themselves" when conditions are changed.
I could see that, but then that wouldn't explain why simply changing the target temperature by M104
would cause it to immediately start heating up, when it's in this "stuck" state. I mean, surely that doesn't do much more than update some "temperature target" variable?
Consider also #11490 (closed). Since that one only came into effect with a target temperature sufficiently near (above or below) 255°, both it and this one just scream "math overflow" to me.
As always is the case for such things where we cannot reproduce the issue, we depend entirely on the person experiencing the issue to eliminate all possible contributory causes and to collect data that ideally points directly to the culprit and the solution.
And I normally would, but I'm way out of my element here. :confused: Though maybe I could reproduce the issue again, and get an oscilloscope trace of the heater output during that time?
All we can do is be very thorough and add a bunch of logging to the PID loop and PWM generator [...]
I think this would be a good idea regardless of the issue, but I'd have to leave this to someone who's more qualified.
Is PWM 127 half power or full power? The value is stored as an int16_t
- I'd expect it to be from 0-255 and 127 to be half power. If that's so and you were seeing PWM 127 when it was stuck, that points to a code problem and not a hardware issue.
I believe that represents full power - or anyway, I have never seen it exceed 127 on any hardware, and I don't have any setting in place (intentionally) to limit it.
I wonder if somehow the PWM is not working properly. Does your board have an LED that shows the hot end power? If it seems to be flashing even when PWM says 127 that could be the problem.
It has, but the controller's inside an enclosure, so I haven't noticed the LED one way or the other.
My reading of the code implies that the PWM value is constrained to PID_MAX
(BANG_MAX
) which is 255. So I'm not sure why it wouldn't go past 127 unless there's a bug somewhere or I'm misreading the code.
I'd dig into it, but not being good with C-like languages, I wouldn't know what I'm looking at. I can barely manage to edit my configs. :smiley:
That aside, I recall something vague about 127 being the limit of the PWM code in general... something related to raw resolution?
Honestly, there is no point in this kind of speculation. We see it again and again in these threads and it only wastes time. The only way we can get anywhere is with detailed data and clues collected from the machines experiencing the issue. And this is the last thing most people want to do.
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.
This is Marlin bugfix-2.0.x branch, commit 61225e68, running on an SKR v1.3.
Description
For a while, I've been having problems with my hotend staying... well... hot. At the beginning of a print, it would maintain its target temperature just fine, but when the print would get to the point where the layer fan turns on, the hotend temperature would drop by several degrees, and often fail to recover. This has forced me to relax the hotend thermal runaway setting a bit (it should still be safe, though, just not ideal).
Such was the case for a print I was doing today. It just didn't want to heat back up once the fan kicked-in.
My layer fan is aimed just below the nozzle, and like almost all layer fans/ducts, the outlet blows a bit onto the nozzle and the bottom of the hotend. Naturally I assumed that this was the issue, so I made a simple "air dam" to put between the fan duct and the bottom of the hotend, blocking the airflow from reaching all but the lowest few millimeters of the nozzle itself.
I ran a second attempt at that print (same g-code), but the air dam didn't seem to do any good; after around half an hour of printing, the hotend temperature had dropped from its target of 230° down to 220°, with heater PWM holding at 127 (or so it said), and with the fan at only 25%.
With that second print still going, I told Pronterface to bump the hotend temperature up to 240°, just to see what would happen, then "came to my senses" after a few seconds, and turned it back down to 230° -- surely it has no hope of getting to 240° anyway, right?
Here's where it gets weird: when I turned the temperature target up and back down, the reported hotend temperature began to rise, and the reported PWM value began to drop. Within maybe 30 seconds, it had stabilized at 230°, and PWM was hovering close to 100. That's right where it was supposed to be to begin with, so it's not like fiddling with the temperature like that should have done anything; it was as if the heater/PID code got "stuck" somehow. I did not notice if it was the initial act of raising the target temperature that did it, or the seconds-later act of lowering it.
As of submitting this issue, that second print has been going completely normally for about three and a half hours, with the temperature remaining as stable as I would expect (within one degree). The print speed, fan speed, flow rate, linear feed rates, enclosure temperature, bed temperature, room temperature, etc. have all remained steady this whole time - that is, the conditions of the printer and its surroundings were the same when the hotend temperature corrected itself as when the fan switched on early in the print, Z position aside. UPDATE: the print completed without incident, and the temperature remained steady for the remainder of the time that I was around to watch it.
Steps to Reproduce
Observe as the hotend temperature corrects itself.
Logically, turning the temperature up and then right back down should have had no effect.
You may need to do this on a 12v machine (and hence 40W heater cartridge), since that's what I use.
Expected behavior: If there's more power to be had, and it's needed, the heater should heat up. :-)
Actual behavior: Something gets confused the hotend stops trying to heat up. :-)
Additional Information
Configuration.h
```c++ /** * Marlin 3D Printer Firmware * Copyright (c) 2019 MarlinFirmware [https://github.com/MarlinFirmware/Marlin] * * Based on Sprinter and grbl. * Copyright (c) 2011 Camiel Gubbels / Erik van der Zalm * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, seeConfiguration_adv.h
```c++ /** * Marlin 3D Printer Firmware * Copyright (c) 2019 MarlinFirmware [https://github.com/MarlinFirmware/Marlin] * * Based on Sprinter and grbl. * Copyright (c) 2011 Camiel Gubbels / Erik van der Zalm * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see(Above configs, as a Zip: Marlin-configs-2019-11-05.zip )