[FEATURE REQUEST] Min temp Error Correction For Cold Climates #3053
Comments
DarrenW45
added
the
feature request
DarrenW45
changed the title
|
Maybe you could detect the ambient temperature with the ambient thermistor and activate a corrective measure? |
|
The printer is about to leave my workshop via a window..... Why is a fantastic printer let down by firmware?? The solution is a small change... come on Prusa as I'm sure you can tell I'm getting rather pissed off at having to heat the printers every morning before they get to work. |
|
I am seeing this problem with OctoPrint. My printer is in an unheated garage and at night I can hit the low bed temperature warning which cascades into an octoprint disconnection. It seems the low temperature warning is active just when being monitored. Is the fix to only have the warning when actively heating and the heating isn't making progress? Is the point of the monitor to notice an attempt to heat and failing todo so? Or is it some sort of condensation monitor. Here is someone with the similar octoprint issue from the prusa forums. |
|
The solution to this is a very simple code change. Having the min temp active only whilst heating would make little difference as you will still have to heat the bed by external means before using the printers own heater. I've got 5 Mk3's that fail every morning and all get one step closer to being replaced by another brand. I don't like that idea as the Prusa is such a great all round printer but support is close to F... all. |
At 5 you have a significant investment to replace. Since the firmware is open source I would suggest you fork the firmware and make the change yourself or pay someone todo it. It would likely be cheaper than replacing 5 printers. Reviewing the code there is already a debug build parameter to disable this check see You just need a build with this bit of code uncommented out. Or a build that doesn't hard code these values and allows them to be set at run time. From reading the code comments my guess is the min temp is the lowest end the thermistor can detect. I suspect this error isn't that the temp is too low to print rather it is displaying a possible thermistor failure. I guess the assumption is that if the system is on its heating. Which isn't the case for octoprint which is just monitoring the bed temps. As for the cold morning startup a better fix than just disabling the warnings might be to delay it a fixed amount of time after the bed heat has started. Allowing the bed to sometime to reach the operating zone of the thermistor before entering a disabled a failed state. If a bed is applied some heat over a fixed time even with a failed thermistor it shouldn't be in a run away heating situation. Someone would need to 'reset' the heating period to trigger more heat, eg constantly cycling the power. Of a hardware fix of thermistors with a wider (and lower) operating temperature range would also fix the issue. |
|
I just need an extra ~60 seconds before the timeout, so it has time to heat to above the mintemp threshold. I end up starting the print or pre-heating, waiting for the mintemp error, then I press reset and then for the second time it'll be fine because it has already heated a bit from the first attempt. |
|
I agree with that. The Prusa Mk3s printer itself is a very good machine. But to use hairdryer for the printer and not for the hair isn't very comfortable and also isn't safe. Just would be nice to get like additional mode inthe settings to make printer never go lower like 18oC degrees would be perfect. And everytime it will preheat if it will go lower than 14oC. So we wouldn't get a mintemp error. If you want no heating at all with this mode, just turn off the printer. Will wait for the news. |
|
Hello, thank you for the comment, sorry for intervening so late on this thread. Currently, the temperature threshold, on MK3-family, for Mintemp to occur, is 10 °C, 50 °F, for both hotend and heatbed. Was is still problematic? Unfortunately, regarding MK2-family, the threshold are higher due to different hardware design of the motherboard (hotend thermistor - temperatures below 22 °C, 71.6 °F, heatbed thermistor - temperatures below 15 °C, 59 °F). In case of more feedback, feel free to let me know here, it might be not possible but I'll certainly review this aspect in more detail with devs to see if there might be any possibilities. Alessandro Pantaleo |
|
Hi Alessandro,
Thanks for your response. The 10c min temp has made it easier to work with but in the U.K. as from November onwards my workshop is below 10c on a morning. Ideally the mon temp would be a float value as long as the hot end and bed temps were equal on power up.
I understand the methodology of the sensor failure detection but if the startup code was an IF hot end && bed temp are = then heat to preset temp.
Regards
Darren Wandless
On 26 Oct 2022, at 4:57 pm, Prusa-Support ***@***.***> wrote:
Hello, thank you for the comment, sorry for intervening so late on this thread. Currently, the temperature threshold, on MK3-family, for Mintemp to occur, is 10 °C, 50 °F, for both hotend and heatbed. Was is still problematic?
Unfortunately, regarding MK2-family, the threshold are higher due to different hardware design of the motherboard (hotend thermistor - temperatures below 22 °C, 71.6 °F, heatbed thermistor - temperatures below 15 °C, 59 °F).
In case of more feedback, feel free to let me know here, it might be not possible but I'll certainly review this aspect in more detail with devs to see if there might be any possibilities.
Alessandro Pantaleo
Prusa Research
—
Reply to this email directly, view it on GitHub<#3053 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ATDFEHV5EQPQZC5NAJZAKD3WFFIEVANCNFSM4YVE7BWA>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Now that there's the new beta/RC features to improve detection of anomalous temperature circumstances, could this issue be addressed? My printer's also in an unheated garage, with no room to add a heated enclosure for it, and it's really frustrating to need to use a hairdryer with it or hold my hands on the nozzle and heatebed to heat it up before I can start printing. Why can't the firmware have some logic to turn on the heaters briefly if in a mintemp circumstance when the printer has been inactive, and measure whether the temperature increases as it should, and only trigger the error if no heating is detected? |
|
Can you be more precise regarding the ambient temperature where this is happening? I think there are a couple of ways to improve this. For example, using a fixed safe power output at low temperatures for warm-up instead of PID regulation could be one strategy, although a slow one. Just to clarify, and as probably already written in other issues, the main issues is that the hotend thermistor is at the edge of the range at such temperatures. It's really designed to work at 200C, and will have higher error margins at either edge (low or high), and stop working close to zero. Even the new temperature control can't really work if there is no stable reading. At that point you have to make guesses to check if the temperature is just low or the thermistor is faulty. The current guesses are perhaps too much on the edge of fail-safe. |
|
I've had it happen in rooms as high as 16°C, which isn't even very cold. I don't think we need to overthink it and we've basically workshopped the answer: Best Resolution: Watch the increase in temperature as a difference over time, instead of a static threshold after a certain amount of time. Ie. If the temperature has increased by more than 2 or 3 degrees in the past minute and appears to continue increasing steadily, we can assume it's fine and it's just taking a longer time to warm up due to the ambient temperature. Fine Resolution: Compare the temperature of the bed to the nozzle. If they are both increasing, assume it's fine. Acceptable Resolution: Increase the time before it times out. That's it, just give it another minute or two to get up to temperature before triggering the failsafe. Anyway, until this is changed, we all just wait for the error, then restart the printer and it's fine the second time (because it has pre-heated a bit). It's not the end of the world, jus super annoying. |
|
Yep, @wavexx I agree with @IntegersOfK about this, except that for my case the "Acceptable" option likely wouldn't help much, as I use the printer with octoprint, so it's usually always already on and has long-since triggered the mintemp errors. To answer your specific question, it tends to happen for both the hotend and bed mintemp, and the most recent time it happened the ambient temperature was around 10°C, though the environment is certainly sometimes somewhat colder than that, and it likely has happened in somewhat warmer environments as well. In this case, the thermistor does accurately represent the temperature, but is just not trusted by the system due to the fact that a failed thermistor tends to give the same sort of range (or that's my understanding at least). To me the solution seems rather obvious and simple, enabling the printer to try to heat up the nozzle and bed (rather than just refusing to due to the error), and then only throwing the error if it doesn't detect the temperature rising at the expected rate, which it would unless the thermistor truly has failed or disconnected. |
A problem with the slow increase in temperature is that it can be due to a busted heater or a degraded thermistor (see the "degraded thermistor sim" in #3552). On a cold start the ramp-up time is a lot slower, and because of the thermistor noise at these temps it's a wild guess what's happening (you can have +/-10C, on top of the einsy +/-5C). It's true you can say "ambient temp is low so keep heating" using more sensors, but the thermistor can also be underreporting the whole time so the hotend is maybe actually getting a lot hotter and you can't check this using the einsy or bed thermistor. IMHO a safer approach is what I wrote before. On a cold start we could keep a low, but safe power level (say a fixed 20% instead of full power) combined with a timeout. On a standard 40W heater cartridge it would settle at <200C so even if the thermistor is shot overheating is not possible. This will require longer to exit from a cold start though, and a timeout is still necessary (if the hotend doesn't recover from X minutes something is also wrong). |
|
The trouble with turning on the heaters on startup and looking for a temperature increase is that if the thermistors were faulty and for some reason the firmware crashed and entered a restart loop, then power would be applied to the heaters indefinitely. At the moment, there has to be human interaction before the heaters are turned on. I think finding a power level that is safe under open loop control is a good idea, and in most cases won’t be that slow because we only need to raise the temperature by a few degrees. Alternatively we could require some user interaction (to prove we aren’t in a restart loop) before running the heaters at a higher power for a limited time. |
|
Another tidbit which would be useful for feedback is interaction. You might start the printer and get into mintemp, but you might also get into mintemp progressively while idling (overnight for example). Assuming we have a cold-start procedure, what should trigger it? Preheat I guess, if you're in front of the menu. This means mintemp shouldn't immediately lock the printer. |
|
When I control my printer with OctoPi, I set the temperature to 20°C and once it gets up to that temperature I increase it to the full 215°C to prevent it from triggering the mintemp failsafe / locking me out. |
|
@IntegersOfK do you also have a sock? |
|
I don't have a sock, I find it hard to get on and stay put. |
wavexx
added
temperature
|
IMHO this is related and needs to be fixed along with #3898 |
|
It's getting frustarted over the years that such a simple thing can't be
fixed. It wastes a lot of time if used every day. Even with a new 3.12
firmware nothing changed. I don't know its because of law regulations or
something like that But actually it would be nice that it would let to turn
off mintemp error with somehow until like 4oC.
…On Sun, Jan 15, 2023, 19:48 wavexx ***@***.***> wrote:
IMHO this is related and needs to be fixed along with #3898
<#3898>
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A3N7XALJN2NGUOS4YVVYC23WSQZ7JANCNFSM4YVE7BWA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Why is the new thermal model not able to tell the difference between a cold ambient temperature and a faulty thermistor? The Prusa blog discussing the thermal model discusses some complex thermal anomalies it can detect; detecting a cold environment (either through comparing against other thermistors or from historical data) seems easy by comparison. |
|
@knmorgan when the hotend thermistor goes below MINTEMP the temperature readings are increasingly unstable (it's effectively operating out of spec). At that point you cannot distinguish cold temperature from a hardware fault anymore. Ignoring low temperatures is easy to do, but it's a hack, not a solution. If you want to maintain safety check integrity there are a many places to change where you need to add exceptions to critical logic that needs to work. |
|
When looking at a single data point I understand, but the Prusa blog on the new thermal model implies the printer is able to look at a history of thermistor readings to better understand thermal anomalies. I would assume a steady decline from 15C to 10C over the course of a few hours (like what happens in my garage before MINTEMP is triggered) looks a fair bit different than a faulty thermistor. |
|
Guys, just think simple. If its not possible to lower treshold temp due to
safety concerns. Then add a function to the printer. It will be even more
safe to printer itself.
"Cold environment protection", function if heatbed or hotend temp < 13oC
then heat it up to 18oC. Fairly simple.
And if Prusa team cant do this fairly simple and very useful I will need
to install an octoprint and try to program and run myself. Somehow
…On Mon, Jan 16, 2023, 03:02 Kyle Morgan ***@***.***> wrote:
When looking at a single data point I understand, but the Prusa blog on
the new thermal model implies the printer is able to look at a history of
thermistor readings to better understand thermal anomalies. I would assume
a steady decline from 15C to 10C over the course of a few hours (like what
happens in my garage before MINTEMP is triggered) looks a fair bit
different than a faulty thermistor.
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A3N7XAMDR7WDRNQEICK5HNDWSSM3TANCNFSM4YVE7BWA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@wmfmontrose I do agree that this is close to the original idea. I proposed something very similar. However I was then informed that many people run the printer much more remotely than I, and they would like a way to perform this override remotely. If possible, I'd like to find a solution that covers that use case too. |
|
I can get it is not your use case. It is, however, my use case and the case of others. I do it all the time without any disaster at all. I just works. The heated bed is cleaned from the previous day. The nozzle cleans well with the start of the print. The file is sent via Prusalink (and the button to start is a webpage running in Prusalink). No physical button needs to be touched on the printer. I just go to pick up the part and leave the printer prepared for the following printing cycle. The camera in Prusalink shows be, from afar, that everything is happening properly. I can also remotely cut off the power if something goes wrong (which I, so far, never needed to do). This thread is running to try to solve a problem, where different users have different requirements. We are proposing solutions in trying to drill the problem through and give enough feedback to however may eventually implement this. Deciding on the complexity, the safety and which requirements will be fulfilled is part of the task of that person. |
|
This is all so convoluted. Have I mentioned that the sensors are within
spec to -50°C?
…On Wed, Mar 6, 2024, 7:55 AM abdullahtahiriyo ***@***.***> wrote:
Your pair of suggestions make sense, except that I don't think the Arctic
mode you describe should apply only when the printer is first turned on, as
that would require wasting a lot of energy on keeping it warm no matter how
long it was sitting unused. Instead, I'd suggest that it start at the
beginning of a requested print, when needed.
If I understand them correctly, keeping the MINTEMP means that if at any
time the mechanism is triggered, it shall error. If you switch on the
printer, but do not want to use it right away, and MINTEMP error triggers,
you cannot do anything. You cannot even ask for a preheat. I understand
that getting out from MINTEMP, other than by resetting, is out of their
plans (or inside the "ain't gonna happen", save for the rotatory encoder
mechanism).
That is why I have transitioned from asking to keep it warm at all times
(previous idea), to only execute the warm up after reset/boot. It may also
be the less convoluted implementation, so if implemented, the easiest to
get reviewed, tested and approved.
The working could be as follows:
Boots up & temp < MIN_TEMP & artic mode ON => you enter "warming up mode
directly", it warms up => MINTEMP Error does not get triggered. The
thermistor gave a reading higher than 10ºC, so you can clear the E2PROM
flag (meaning that you won't have to wait full 30 minutes if it cools down
under MIN_TEMP again). You left it idle during 40 minutes and MINTEMP is
triggered. Only way out is via reset (physical cross button, or remotely
via serial/Raspberry pi), or if you are physically in front of the thing
and the rotatory encoder gets implemented, rotating it.
The rationale, is that when one switches on the printer, usually wants to
use it (it is like preheating the bed on filament change). Yet, there is no
continuous consumption for trying to keep it over 10ºC at all times.
Of course, if both mechanisms get implemented, users physically close to
the printer can have the artic mode OFF (so no warming up upon reboot), and
still rotate the rotatory encoder when printing is necessary.
This would also allow the printer to often ensure it wasn't just reset
during an overheating failure even without writing to EEPROM, simply by
tracking how long the printer has been idle after restarting, and refusing
to start a print if it's been on for less than a half hour (or whatever
time threshold is deemed reasonable).
If you do not use E2PROM, you need to assume that after any reset with
temp < MIN_TEMP, you have been heating, so you will always need to have the
printer ON for 30 minutes before being able to print (and if you reset or
reboot, the timer starts over again from the beginning). That is possibly
an inconvenience, as most people want to print reasonably right away after
switching on. Using the flag allows to determine that there was no previous
attempt to "warm up", so one can start warming up directly, without having
to wait for 30 minutes (the first time).
However, I have just realised there might be a problem with the solution
as I describe it when using prusalink:
When the printer is connected to prusalink via USB, the printer switches
on and boots, then after one minute or so, prusalink ends up booting and
resets the printer (or at least it looks like it does). If the printer was
"warming up" when this reset happens, and the thermistor did not arrive to
enough temperature to get out of the MIN_TEMP zone, this reset will trigger
a 30 minute cooldown... so there is still some extra work to do for this
use case...
PINDA sensor's measured temperature too
It can help determine the other thermistors are broken (If Pinda=30ºC and
other thermistor=0ºC), not to ensure it is not broken (Pinda=0ºC && other
thermistor=0ºC => are both broken? or none? or one of them only? which
one?). It may be that some exceptional circumstance causes all to break at
the same time (e.g. grid spike)... then it is not save to assume that the
three giving 0ºC means the three of them are just ok...
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEG7W3YAKBELLWGUNCGGZOTYW4G27AVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJYGA4DAOBQG43A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
@gisforgirard Even they are rated from-50C tests have shown that temperatures under 10°C can't be read reliable on the controller board and by the firmware. Readings below 10°C are unreliable and that is why it is set as MINTEMP. Maybe bit extreme example: The firmware could read 8°C but at the same time it could be -20°C or even a disconnected/broken thermistor, we just can't trust the values. |
|
This thread is at 156 comments now (included this one from myself :-) Maybe the time has come to end this thread. Conclude the conclusions. And get 3D-printing again (that is why all of us are here (at least in this thread)).
NB: I learned a lot in this thread, my machinery is running better than ever before on the cold attic of my house. Now spring has come, temps go up. Thank you all, enjoy life and see you in another thread. Regards, Eef |
I agree that this thread has gone on for more than long enough, it's the single longest open issue on the git repo by far. To me that indicates that it's definitely something that urgently needs fixing, and we haven't yet gotten much of a conclusive response from Prusa that it will be fixed in a satisfactory way. In other news, I'm not sure if it's because of the 3.13.3 update or the fact I just set up octoprint for the first time in a couple years, but this morning my printer was stuck in mintemp (as usual), but was continuously beeping rather than just the one alert beep at the start, waking up my family. It also seemed to be at a different screen than usual, blank except for a circle in the bottom right corner, and when the wheel was clicked it displayed the usual mintemp message. |
|
For me, the winter time is not gone yet. I keep using the reptile heater. Today I forgot to program it enough time in advance and I had to delay the start of printing because of min temp error. Can you share any progress on this topic? |
|
@abdullahtahiriyo Sorry can't give you any update yet, we are working on FW 3.14.0. Also the MK3.5, MK3.9, MK4 and XL firmware get most attention. |
|
Thank you. I understand. The issue persists to the same extent for MK3.5 (hotend thermistor is the same as MK3), and to a slightly lesser extent for all the others (5ºC instead of 10ºC)... |
|
@3d-gussner any news on this yet? I understand that the newer printers' firmware needs the most attention overall, but that has me more worried that if this isn't fixed soon it might never be, as the Mk3 series is further deprioritized and deprecated over time. Do you have any information on a potential timeline (either of a solution for mintemp, or info on the expected support lifetime for the Mk3 series firmware updates)? |
|
It's starting to get to that time of year again, my printer was stuck in mintemp this morning as the weather cools down, and a lot more people will also be encountering this again soon. Any updates on getting this fixed? |
|
Ah, it's that time of the year again. This thread becomes active again. ❄️ |
|
Luckily, someone burned my garage down and the printer was in it so I don't
have to worry about this issue again for a while at least... I must make
absolutely 100% clear that the garage burning down was entirely unrelated
to the printer and is being investigated as arson, so I still stand behind
my statements that removing MINTEMP entirely is completely safe.
…On Thu, Oct 31, 2024, 12:16 PM Gijsbert ter Horst ***@***.***> wrote:
Ah, it's that time of the year again. This thread becomes active again. ❄️
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEG7W33QF4HEK7FHQAM2XHTZ6JJVVAVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENBVGAZDQMZZHA3Q>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
In response to this argument from @3d-gussner against removing or working around mintemp, and in general with a lot of the discussion above, this feels like an example of letting perfect be the enemy of good. Yes, there are always still going to be some situations in which it simply will be too cold for the printers to handle. That doesn't mean that a solution that fixes the issue for most users, most of the time, is not a viable option. If the firmware reads the temperature as 8°C, yes it's possible that the temperature is really -20°C or the thermistor is disconnected, but far more often the temperature really will be 8°C, just slightly below the operational limits. What harm is there in, when heatup is requested, such as at the start of a print, running the heater with the thermal model active, and seeing if the measured temperature does rise as expected? If the thermistor is actually far colder than measured, or completely disconnected, then the thermal model will flag the issue and shutoff the heaters in a few seconds, and no harm is done. But the vast majority of the time, in all the cases where the temperature reading is accurate, the printer is now usable, and safely able to heat up and print as expected. Optionally, to be extra careful, you can even compare the measured temperatures between the hotend, bed, and PINDA probe, and only allow the above functionality if the three readings start out at roughly the same temperature, and define a new temperature threshold below which the above functionality is also disabled. For a lot of people, even just expanding the usable range down to 5°C or 7°C instead of 10°C, for example would likely be sufficient. Similarly, you could always define a short time threshold, if the temperature fails to reach the normal usable range within that time threshold, then trigger mintemp. And since the heatup would only be active when requested by gcode or preheat in the interface, there's no risk of a reboot-loop causing continuous heating. @3d-gussner and/or @Prusa-Support, now that firmware 3.14.1 is out, which this fix was originally a milestone for, I really think it's time for an update on this issue. I'd be happy to make a pull request with an attempt to improve this behavior, but as someone that's unfamiliar with the details of this codebase, it's somewhat tricky to know where to start on modifying things, to avoid inadvertently disabling other safety features, etc (especially since I can't really freeze my printer on demand for quick iteration of testing). Some pointers as to where to start looking in the codebase would be welcome. |
|
Hello everyone. This is not an official answer or comment, I am writing as a community member. I hoped to get a solution into FW 3.14.1, but as we can see there is none. At this moment the only option I see is to create a community firmware. Feel free to make PRs to my personal fork of Prusa-Firmware. Question at everyone here: Vote with 👍 Yes 👎 No Last time I asked, only a official support was an option from those who vote. If nobody is willing to flash a community firmware version, it doesn't make sense to create one. |
Thanks for the response, I appreciate it. Personally, I'd be happy to test and work with a community fork of the firmware, but I'd want the project to be designed with the intention of being added to the official branch, once it was sufficiently validated or tested, assuming it did indeed work well and behave safely. Of course, I recognize that that couldn't be guaranteed from the start, but I'd prefer not to need to commit to a firmware version that would be at risk of abandonment and prone to potentially diverging further from the upstream source over time, or would be late to have updates merged in, etc. I guess at this point the MK3 series firmware is pretty mature so there's less likelihood of major upstream changes, but regardless, that's my opinion on the matter. A 3rd party fork to add cold climate support is a lot better than no options for cold climate support, but I don't want the presence of such an option to be used as an excuse to avoid adding support to the official firmware, where it otherwise might have been, if that makes sense at all? Also thanks for mentioning the Mk404 simulator, I hadn't heard of that before, it definitely does seem like an easier environment for testing this sort of situation in, I'll have to give messing with it a try! Probably will be a while before I have free time to mess with it too much, but I'll update back here if I do come up with anything, and/or open a pull request to your fork as you mention. |
There are community features added to the official branch BUT these are never used in official builds. Okay there is one exception the E3DRevo builds. So any "Arctic" mode solution needs to be |
The MINTEMP issue is as old as I got my first Prusa MK2 printer (I never had that issue as my printers never have been in a so cold environment) and there is still no official version. But I like the spirit. |
|
We ran into that issue again, one of the printers (current fw) was screaming... neighbors complained and called us to get into the lab to silence it. Find FW-versions and details here |
|
@Adorfer Danke für die detailierte Info. Thanks for the detailed info. Please vote on #3053 (comment). If I have multiple users willing to use a community version, I will provide one. |
|
I modified the firmware for my three MK3S printers and one Mk2.5S to work better in an un-heated workspace and have been using it for the past 1.5 years. I no longer need a hairdryer to pre-heat in winter to get the heatbed past 29°C and get far fewer long beep alarms after a print completes and sits overnight. I just recently updated to 3.14.x firmware and made the same changes so figured it might help some folks to share. Its a 4 line change in Mk3S.h and/or other printer variant definition files. From: #define MINTEMP_MINAMBIENT 10
#define MINTEMP_MINAMBIENT_RAW 1002
#define BED_MINTEMP 10
#define BED_MINTEMP_DELAY 50000To: #define MINTEMP_MINAMBIENT 0
#define MINTEMP_MINAMBIENT_RAW 1012
#define BED_MINTEMP 0
#define BED_MINTEMP_DELAY 60000 |
@3d-gussner thank you for this! I am convinced that the problem can be fully addressed, without sacrificing any safety, with some of the ideas floating around here - in particular Patronics of doing a test-heat, to see if the temp rises, and after a short time, throw an error. Do you have a specific methods in mind yet? Thanks again, 3d-gussner, for considering us cold-shop dwellers. :) Once my printer gets warm, it's smooth sailing. |
Thank you for this hint. I compiled a version incl. this fix. https://github.com/pl4st3/Prusa-Firmware/releases/tag/3.14.1-cold-climate-edition |
If the sensors are disconnected, what happens? This is why I live with heating mine with a hair dryer - because I don't want to remove the life-safety intent of MINTEMP, which is to stop people from losing possibly everything due to a fire. There are fixes proposed in this thread that do not violate the life-safety mandate for MINTEMP. They just need to be decided upon, designed, coded, and tested. :) |
|
I removed MINTEMP completely and the thermal model instantly recognizes
when a sensor is unhooked. I tested this multiple times, try it for
yourself, this code is a relic from the past and we're still debating it...
…On Fri, Dec 20, 2024, 11:09 PM clintonefisher ***@***.***> wrote:
I modified the firmware for my three MK3S printers and one Mk2.5S to work
better in an un-heated workspace and have been using it for the past 1.5
years. I no longer need a hairdryer to pre-heat in winter to get the
heatbed past 29°C and get far fewer long beep alarms after a print
completes and sits overnight. I just recently updated to 3.14.x firmware
and made the same changes so figured it might help some folks to share.
Its a 4 line change in Mk3S.h
<https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/variants/MK3S.h>
and/or other printer variant definition files.
From:
#define MINTEMP_MINAMBIENT 10#define MINTEMP_MINAMBIENT_RAW 1002
#define BED_MINTEMP 10#define BED_MINTEMP_DELAY 50000
To:
#define MINTEMP_MINAMBIENT 0#define MINTEMP_MINAMBIENT_RAW 1012
#define BED_MINTEMP 0#define BED_MINTEMP_DELAY 60000
If the sensors are disconnected, what happens?
Could it thermally run away, thinking it just needs more heat, and
possibly cause a fire?
I do not know what will happen with your printer, but you might want to
test this for your own safety's sake.
This is why I live with heating mine with a hair dryer - because I don't
want to remove the life-safety intent of MINTEMP, *which is to stop
people from losing possibly everything due to a fire.*
There are fixes proposed in this thread that do not violate the
life-safety mandate for MINTEMP.
They just need to be decided upon, designed, coded, and tested. :)
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEG7W32XQTGBOXRMKRM3PSL2GTSYRAVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJVG44TQNRWG44A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
The 4-line firmware change does not fundamentally alter the built-in safety mechanisms of the firmware. It is only setting different limits:
1. For the heatbed, rather than raise a mintemp fault when unable to heat past a threshold temperature range within 50,000 ms, it raises a fault after 60,000 ms. With extra time, crossing the key 29 -> 30°C threshold is far more likely to succeed.
IMHO the extra time adds minimal risk and I suspect the default 50,000 value was chosen arbitrarily rather than through any specific safety testing. There are even comments in the source about 60000 being a safe default elsewhere.
2. For both heaters, rather than raise a mintemp fault at 10°C, it raises a fault at 0°C.
The thermistors are less accurate at lower temperatures. So setting the mintemp to 0 could in practice, be anywhere from -5 -> +5. Choosing 10°C already has some innacuracy so in practice maybe it could be 8°C -> 12°C. The inaccuracy isn't the biggest concern as it will get more accurate as the heater warms. The thermal model will still apply and shut down the heater if the measured values don't fit the model. Open circuit and short circuit of the thermistor will still cause immediate shutdown.
The bigger concern is that at lower temperatures, the resistance of the heaters is lower so at constant 24 volts, the current will be higher. I've tested this with an ammeter and an AC/Mains power monitor and noticed the higher current on initial heatbed warmup at ~5°C compared to 15°C. But the wires and connectors on Mk3 and later printers are still thicker than they need to be to meet the higher current, so added risk is minimal.
The 240W Meanwell and Delta PSU over-current and over-power protection ratings are above this modest current increase as well
Sidenote: Even at 10°C on default firmware, the power usage at 110V AC/Mains, spikes over 315W for a minute or two, then settles down. Once warmed up, average power usage is 100W or less depending on filament type.
Mk2/Mk2.5 with 12V heatbeds are different. The heatbed current is already close to the safety limit for the wires and connectors, so it might not be good to do the 0°C change on those printers.
…________________________________
From: clintonefisher ***@***.***>
Sent: Friday, December 20, 2024 8:09:44 PM
To: prusa3d/Prusa-Firmware ***@***.***>
Cc: Dan Charlton ***@***.***>; Comment ***@***.***>
Subject: Re: [prusa3d/Prusa-Firmware] [FEATURE REQUEST] Min temp Error Correction For Cold Climates (#3053)
I modified the firmware for my three MK3S printers and one Mk2.5S to work better in an un-heated workspace and have been using it for the past 1.5 years. I no longer need a hairdryer to pre-heat in winter to get the heatbed past 29°C and get far fewer long beep alarms after a print completes and sits overnight. I just recently updated to 3.14.x firmware and made the same changes so figured it might help some folks to share.
Its a 4 line change in Mk3S.h<https://github.com/prusa3d/Prusa-Firmware/blob/MK3/Firmware/variants/MK3S.h> and/or other printer variant definition files.
From:
#define MINTEMP_MINAMBIENT 10
#define MINTEMP_MINAMBIENT_RAW 1002
#define BED_MINTEMP 10
#define BED_MINTEMP_DELAY 50000
To:
#define MINTEMP_MINAMBIENT 0
#define MINTEMP_MINAMBIENT_RAW 1012
#define BED_MINTEMP 0
#define BED_MINTEMP_DELAY 60000
If the sensors are disconnected, what happens?
Could it thermally run away, thinking it just needs more heat, and possibly cause a fire?
I do not know what will happen with your printer, but you might want to test this for your own safety's sake.
This is why I live with heating mine with a hair dryer - because I don't want to remove the life-safety intent of MINTEMP, which is to stop people from losing possibly everything due to a fire.
There are fixes proposed in this thread that do not violate the life-safety mandate for MINTEMP.
They just need to be decided upon, designed, coded, and tested. :)
—
Reply to this email directly, view it on GitHub<#3053 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADDHQQF3KVTOYZJHTZXQCIT2GTSYRAVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJVG44TQNRWG44A>.
You are receiving this because you commented.Message ID: ***@***.***>
|
The Thermal model is very fast and triggers mostly earlier than MIN/MAXTEMP. |
|
Okay, check if the thermal model is enabled and if it is then disable
MINTEMP, seems like a reasonable compromise to me.
…On Mon, Dec 23, 2024, 1:16 AM 3d-gussner ***@***.***> wrote:
I removed MINTEMP completely and the thermal model instantly recognizes
when a sensor is unhooked. I tested this multiple times, try it for
yourself, this code is a relic from the past and we're still debating it...
The Thermal model is very fast and triggers mostly earlier than
MIN/MAXTEMP.
BUT as there are users who DISABLE the TM instead of investigate when the
TM triggers an error, the MIN/MAXTEMP is a well established safety net.
Any pull request removing it has 0% chance to be approved even for a
community build.
—
Reply to this email directly, view it on GitHub
<#3053 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEG7W3Y2RVMGUXDMRKMA6T32G6TD5AVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TENJVHA4TQMZXGU3A>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I have exactly the same problem. I put bottles with hot water into the printer's housing when it is too cold. But why can the printer not heat up the housing by itself? |
and others
In colder climates the printer (MK3) powers up and goes to error min bed temp. After heating the bed with a hot air gun it clears to hot end min temp and after a little heating so does the hot end. It's then all good after a restart.
This is a work around that I have to do every day when I turn on the printers and it's becoming somewhat laborious as overnight my building temperature drops well below the 16c threshold for errors, hence the problem every morning.
I know the threshold is there to detect a sensor failure of either hot end or bed but, on start up can this not run a different parameter?? Something along the lines of;
If hot end and bed values are within 2-3c of each other then allow preheat to commence and once each value is over 16c revert to original safety code.
The fact that the printer locks when the min temp error appears eliminates the possibility to select a preheat to get the machine warming slightly.
It's a small niggle but massively common in colder countries and i believe requires sorting as heating a brilliant printer with a heat gun to get it working isn't ideal.
The text was updated successfully, but these errors were encountered: