[FEATURE REQUEST] Min temp Error Correction For Cold Climates

[DarrenW45]

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.

[eefweenink]

Goedemorgen Gijs,

@eefweenink Did you mean M190 or M109?

It is about M190, the bedtemp. (this is what causes the error here. As soon the room is warmer there is no problem)

Anyway, this is a very interesting find. I guess it removes all of the safety the standard mechanism provides. However, it seems that the unsafe way is the only way the printer stays usable in cold seasons.

I don't know much about the safety procedures in the firmware, but as I understand all safety is kept:

• The M190 has to wait until the temp asked for is reached. If there would be a "major" issue with temperature then the next M190 step will not be reached in time, and the error will be thrown as normal.

Regards, Eef

[Ghostbird]

Ah, that's better than I expected in terms of safety. ~In your first message it seems you mention M109 a few times where you mean M190 (unless I'm mistaken). If you'd like, you could go to the Github thread, and edit the message to correct that. It would help people who read this conversation later.~

[eefweenink]

In your first message it seems you mention M109 a few times where you mean M190 (unless I'm mistaken). If you'd like, you could go to the Github thread, and edit the message to correct that. It would help people who read this conversation later.

Thanks, I have changed it. 👍

[gisforgirard]

https://github.com/gisforgirard/Prusa-Firmware/tree/without-MINTEMP

i see no purpose that mintemp serves whatsoever so here it is removed if anyone wants it

[Prusa-Support]

Printing in very cold ambients without a thermally controlled chamber is not recommended but theoretically possible. Some of the concerns are explained above in the thread - https://github.com/prusa3d/Prusa-Firmware/issues/3053#issuecomment-1516735486 - however, our developers are making considerations about possible safe ways to go around the obstacle.

The MINTEMP error would occasionally be triggered if a thermistor is disconnected or damaged. Please note that by removing the MINTEMP safety features you are drastically lowering the protection barriers and exposing you and your printer to serious hazards in case of loosened or damaged thermistor. The Thermal Model protection is a big hand here but safety shouldn't be taken lightly anyway.

Michele Moramarco Prusa Research

[gisforgirard]

Printing in very cold ambients without a thermally controlled chamber is not recommended but theoretically possible. Some of the concerns are explained above in the thread - #3053 (comment) - however, our developers are making considerations about possible safe ways to go around the obstacle.

The MINTEMP error would occasionally be triggered if a thermistor is disconnected or damaged. Please note that by removing the MINTEMP safety features you are drastically lowering the protection barriers and exposing you and your printer to serious hazards in case of loosened or damaged thermistor. The Thermal Model protection is a big hand here but safety shouldn't be taken lightly anyway.

Michele Moramarco Prusa Research

while you are probably correct, i have considered your points and already addressed them in my temperature.cpp changes, see lines 1485-1487: https://github.com/gisforgirard/Prusa-Firmware/blob/b0ff16243ed96a26957a31270cf3d35510736b30/Firmware/temperature.cpp#L1485

furthermore, i looked at the code and i am confident the thermal model will trigger so personally i am not worried about it and consider MINTEMP obsolete with the addition of the thermal model and simply a relic that causes the printer to in many other circumstances perform unacceptably worse.

[3d-gussner]

i have considered your points and already addressed

Your commit may sound funny, but it is one thing if you modify your custom firmware and disable few safety features at your own risk and totally another when Prusa would do that.

[gisforgirard]

i have considered your points and already addressed

Your commit may sound funny, but it is one thing if you modify your custom firmware and disable few safety features at your own risk and totally another when Prusa would do that.

You're right. I'm just a frustrated user here posting my solution for similarly frustrated users to consider as a potentially available option, and based on the history of this issue I have zero expectation that it will ever be addressed by Prusa.

Let me point out, though, that this feature is extremely poorly implemented, and it provides ZERO safety by triggering when ALL HEATERS ARE TURNED OFF AND THE PRINTER IS COMPLETELY IDLE. I understand why this would be misunderstood by those who aren't attempting to operate their printer in low ambient temperatures, but for those of us who are, this is literally an issue that turns an otherwise fantastic device into a device that I want to drop kick into oblivion and go back to using my ender 3, which ironically is a far worse experience in every other aspect but has no such MINTEMP issue. My solution is FAR from optimal, but I assure you that it has made me happy to have a functioning printer again without this feature implemented. Hopefully one of these days someone who is more competent than I can come up with an acceptable solution, heck, it could even be you... actually, isn't that the point of this whole open source thing to begin with? Thanks for your input though.

[eefweenink]

Hopefully one of these days someone who is more competent than I can come up with an acceptable solution

Well, I am sure that I am not more competent, but in between:

• accepting as it is ... and.
• fighting for the better solution.

You may give this workaround a try: Put M190 S29 in the start G-code (printer settings), just before the first call to set the bedtemp (my workshop on the attic, is now 14 degrees, and with this workaround, the printer starts up nicely.)

Regards, Eef Weenink

[gisforgirard]

In the name of science, I even turned the printer on, set it to preheat via octoprint, and pulled the thermistor connection from the main board to see what happens, and instantly thermal anomaly triggered, despite having no MINTEMP code enabled. I still see no reason for it to exist.

[gisforgirard]

Hopefully one of these days someone who is more competent than I can come up with an acceptable solution

Well, I am sure that I am not more competent, but in between:

* accepting as it is ...
  and.

* fighting for the better solution.

You may give this workaround a try: Put M190 S29 in the start G-code (printer settings), just before the first call to set the bedtemp (my workshop on the attic, is now 14 degrees, and with this workaround, the printer starts up nicely.)

Regards, Eef Weenink

That doesn't help when the printer triggers MINTEMP before you can even use the menu or send any gcode... It triggers when the printer is just idle for absolutely no reason.

And with regards to the safety aspect of MINTEMP, in the name of science, I even turned the printer on, set it to preheat via octoprint, and pulled the thermistor connection from the main board to see what happens, and instantly thermal anomaly triggered, despite having no MINTEMP code enabled. I still see no reason for it to exist, and am happily operating as safely as ever with it removed from my currently running firmware.

[3d-gussner]

@gisforgirard

In the name of science, I even turned the printer on, set it to preheat via octoprint, and pulled the thermistor connection from the main board to see what happens, and instantly thermal anomaly triggered, despite having no MINTEMP code enabled. I still see no reason for it to exist.

Thanks for taking the time to support your point, but ...

Yes the Thermal model is way faster than the regular MIN/MAX temp functions. But as users can disable the TM and some do (Do they also remove the batteries of a smoke detector when it is beeping? Or do they investigate why the smoke detector triggers?) disabling the MIN temp function is NOT an option. Also setting TM model warning and error thresholds to insane high values would prevent the TM model to "catch" the MIN temp.

The MIN / MAX temp are proven safety features and will NOT be disabled. Improvement possible? Yes but the basic feature MUST stay and not be compromised. The Thermal Model is an additional advanced function which works way faster but it is also way more open to support different heater+thermistor combos and so in a mis-configured setup it would NOT detect the MIN temp.

I don't say that there is no room to improve the MIN temp behavior.

Proposals/workarounds like these are more than welcome

• The attempt of @eefweenink to slowly heat the printer, at this moment not working as the printer will freeze and request a reset.

[Ghostbird]

@3d-gussner Did you see my suggestion a few posts back? It won't be ideal, even for me, as it will not work unattended, e.g. when I just queue a job in Octoprint, but I think it might be a viable workaround. The idea was:

• Do not allow MINTEMP to occur when no heating element is engaged.
• Add a preheat mode where you have to hold down the knob to heat the printer to a maximum of 20°C. While you're doing that, MINTEMP is suspended.
• As an additional safety, the firmware can restrict the time that this preheat mode is active to e.g. 1 minute.

[3d-gussner]

@Ghostbird Thanks for the reminder, sometimes I loose track of the comments on different issues.

Do not allow MINTEMP to occur when no heating element is engaged.

An idea to discuss and at first look not compromising the safety feature

Add a preheat mode where you have to hold down the knob to heat the printer to a maximum of 20°C. While you're doing that, MINTEMP is suspended.

A dead-man switch, I had a similar idea but that isn't ideal for PL/PC/OctoPrint users.

As an additional safety, the firmware can restrict the time that this preheat mode is active to e.g. 1 minute.

Had same idea to slowly heat while comparing the thermistor values show changes to raise the temperature for a safe time period.

[Ghostbird]

Yeah, the dead-man switch isn't ideal. I too normally print from Octoprint. However, I do have to turn on the printer, do a quick inspection, and clean the bed anyway before I print. If I also manually preheat it then, it'll stay warm enough until I actually start the print. I do have an enclosure that keeps the "waste" heat around the printer, so this might work better than expected for my set-up.

[rvalle]

@Prusa-Support you just need to let disable this check.

All of us use run the printer in could rooms, enclosed and use a script to preheat the enclosure with the heat bed.

The safety concerns don't matter much, because the MINTEMP check will be ENABLED by default. You also allow to disable the check on whether print fans work, which is my opinion is equally or more dangerous than MINTEMP.

Of course this feature could be implemented in other, more elegant ways. but disabling the check is enough and appropriate.

[MystaraTheGreat]

The issue here is that MINTEMP is relied upon to sanity check that the sensors and heaters are working, right?

well such a check only makes sense based on your local environment. So why not make some kind of country code selection available during setup and use that to select an appropriate MINTEMP (and presumably MAXTEMP?)

to the extent that lowering the MINTEMP would be inappropriate for some countries, other settings that assume a warmer climate might be inappropriate for me and so by not setting these values intelligently, safety is still reduced.

[rvalle]

@MystaraTheGreat is not like that.

Temperature in sweden is fine If I had the printer in the office, but I have it in a storage room, enclosed, that will reach 5 degrees in winter.

It is not a problem.... I just use the heat bed at say 40 degrees for some minutes, and the chamber will be just like in the office. then printing works fine, better actually! no noise or smell, plus I reuse the heat.

The problem is that the MIN_TEMP check disables the whole printer. and then you have to go to the storage room with a hair dryer... as the printer wont work at all with this broken check.

[Adorfer]

i have housing around the printer (for ABS...), but if the printer refuses to start, then the enclosure is no help. Do i really have to put a hair dryier inside the housing plus a relais box, just to be able to start a print?

[rvalle]

@wmfmontrose Prusa itself didnt have this issue for many years.

the MINTEMP was introduced more or less at the same time all these MINTEMT github issues where created.

my guess is that not many brands are doing this test let alone block printer usage instead of simply warning the user.

[Knuckles92]

@gisforgirard I've compiled my own firmware with the same portions commented out that you have in the tempare.cc file. This is great and has helped to stop the beep, and the forced restart. But i am still unable to turn the bed on if the temperature is below 10C. If i set the bed to 60C, it shows 60C as the set temp for 1-2 seconds then drops it back to 0. Have you found a work around for this?

Thanks

EDIT: I was able to get everything working by commenting out this line in the temperature.cpp file.

Line 1469 -- "set_temp_error(TempErrorSource::bed, 0, TempErrorType::min);" -- by commenting out this line, the bed will now turn on and warm up even if temps are below 10C

[gisforgirard]

Using the code I posted earlier in this thread I believe I recall having the same issue, but with the most recent version I have had no problem starting the printer at ambient temps below 0°C: https://github.com/gisforgirard/Prusa-Firmware-without-MINTEMP/commit/789994ad322172bea2a6117d18db71a8ac455214

On Sun, Dec 10, 2023, 1:07 PM Knuckles92 @.***> wrote:

@gisforgirard https://github.com/gisforgirard I've compiled my own firmware with the same portions commented out that you have. This is great and has helped to stop the beep, and the forced restart. But i am still unable to turn the bed on if the temperature is below 10C. Have you found a work around for this?

Thanks

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware/issues/3053#issuecomment-1849037606, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEG7W33L5NEHHP6NC4ACPKLYIX25LAVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBUHEYDGNZWGA3A . You are receiving this because you were mentioned.Message ID: @.***>

[MechanicalCat]

I have found a work-around to this annoying issue: if the printer room is very cold then just before the first print of the day I set the bed temp to a target of 28C (and the nozzle to a target of 0C). This temp is quickly reached, before the MINTEMP time-out can shut down the printer. After a couple of minutes with the bed held at this temperature, the printer is warm enough to start a print without triggering MINTEMP.

[eefweenink]

I have found a work-around to this annoying issue: if the printer room is very cold then just before the first print of the day I set the bed temp to a target of 28C (and the nozzle to a target of 0C). This temp is quickly reached, before the MINTEMP time-out can shut down the printer. After a couple of minutes with the bed held at this temperature, the printer is warm enough to start a print without triggering MINTEMP.

Correct, but sometimes 29 is also too big a distance. It helps to put these lines in the startup G-code of your printer settings (for me in PrusaSlicer): This command forces to wait untill the temp is reached before proceed. M190 S13 M190 S15 M190 S17 M190 S19 M190 S21 M190 S23 M190 S25 M190 S27 M190 S29

PS: the MINTEMP did never react on nozzle temp here, so I did nothing to the settings of the nozzle temp.

Regards, Eef

[Prusa-Support]

This is a desktop 3D printer, the most popular for use in domestic and office environments. The working range has always been stated in the printer's manual. Cold temperatures are not recommended and we don't plan to disable the MINTEMP safety feature for various safety reasons - a few were also discussed earlier in this thread.

We strongly recommend printing in observation of the working conditions stated on the printer's Handbook and we can't overlook any possible safety concerns.

I totally get it. I understand your point of view and yours is a simple request after all, but I hope you can understand this matter can't be taken lightly from the point of view of our company. We support Open Source though and we have nothing against firmware customizations. Only please, in the case of modified firmware - especially with modified safety features - please use it at your risk.

However, please notice that this issue has been added as a milestone for the future firmware release. Our developers will do their best to find and approve an alternative way to go around this safety limitation, yet compliant with our company safety standards.

Michele Moramarco Prusa Research

[DaveTSG]

Our developers will do their best to find and approve an alternative way to go around this safety limitation, yet compliant with our company safety standards.

Hooray! Looking forward to a workable solution.

I've been using a smart plug, a Raspberry Pi, and a hair dryer inside my enclosure for years to get the printer up to minimum temperature. After that point, the print bed can heat the enclosure up just fine. While I realise there are safety concerns and Prusa needs to avoid litigation, it is frustrating for end users that have this issue.

Thank you for considering it.

[MechanicalCat]

eefweenink's suggestion (3 posts above) hints that the MINTEMP safety feature may have somewhat curious logic: the emergency shutdown seems to be triggered by the bed-temp at the moment the M190 command is sent combined with how long the bed takes to reach the M190 set temperature. The actual temperature of the bed appears to be ignored between the time the M190 is sent until the time the M190 set-temperature is reached. Fortunately, this safety-critical code does appear to do its job of preventing printer fires in case of thermistor failure, and I can entirely understand Prusa's reluctance to change it (with all the testing cost that would incur). eefweenink's simple solution - which makes use of existing options in Slic3r and doesn't require any firmware changes - should make this a non-issue for most users?

[rongith]

This is a desktop 3D printer, the most popular for use in domestic and office environments.

A 3D printer should have its place in a garage, a basement or an attic due to noise and COV release, not where people lives.

However, please notice that this issue has been added as a milestone for the future firmware release.

Nice to hear.

[Ghostbird]

A 3D printer should have its place in a garage, a basement or an attic due to noise and COV release, not where people lives.

Sorry, bit off topic, but I interpret "domestic" as "around the house", rather than something industrial, so I think it was on point. I certainly do not interpret it as on a table in the living room.

For example Encyclopedia Brittanica states:

Domestic cows are one of the most common farm animals around the world

This does not imply that the cows should be kept in the living room. Although, where I live, historically cows were kept in the living room during winter. So maybe there's something to it.

[eefweenink]

eefweenink's suggestion

Thanks for the compliment. The idea is not mine. And also the idea to put in in the startup code is not mine.

• I did not look into firmwarecode, but it is correct, by guessing and some deduction, it seems that the "Mintemp System" is only activated if the bedtemp is below 30degrees Celsius.
• The measurement is done on the time it takes to get to the next M190 temp.
• And several M190 temps after eachother cuts this distance in "non-dangerous" pieces.

[abdullahtahiriyo]

Heavily overengineered work-around in place for when you have the printer inside an enclosed cabinet: 1- Use prusalink with the MK3. 2- Use homeassistant with prusalink. [Use an older version of homeassistant, as prusalink still it the current release identifies as "legacy" and this breaks homeassistant plugin, possibly modify the code of prusalink so that it identifies as MK4 does. Please Prusa, release a proper prusalink for MK3 so that we can connect it to homeassistant out of the box, it is not that difficult, as MK4 does work out of the box]. 3- Connect a power strip to mains [strip 1]. 4- Connect a first tasmota plug connected to homeassistant to the power strip 1 [plug 1] 5- Connect a reptile heater to [plug1] 6- Connect a second tasmota plug connected to homeassistant to the power strip 1 [plug 2] 7- Connect a power strip to the second tasmota plug [strip 2] 8- Connect the MK3 and the RPI4 with prusalink to the second tasmota plug.

Now you can automate in home assistant. You can activate plug 1 until such time that the temperature sensor integrated in plug1 reaches the wanted temperature. Then you can activate plug 2 to switch on the printer and rpi with prusalink. Then you can start a print from prusalink.

Of course, if you only aim is preheating and you do not need remote activation or automation, you can just use a normal timer plug and a reptile heater connected to it (just program the timer plug some time in advance).

Of course, I would prefer to substitute the reptile heater with a proper MK3 function. The difference is that the reptile heater is power limited to very low power, whereas the Prusa heaters are not. The answer may be to: 1- limit the power of the prusa heaters when the temperature is under MIN, and 2- set a timer for ensuring the thermistor is not broken (achieves a given temperature increase in a given time)

You limit (1) by setting a fixed relatively low pwm independent of thermistor value (unless the thermistor provides a value higher than MIN_TEMP possibly with some hysteresis). If this does not manage to vary the thermistor by a couple of degrees during 30-60 seconds, then you stop because your thermistor is broken and you do not want to burn your garage/shop (2).

The Czech republic is not in the Caribbean and gas prices over there are not precisely cheap. They must be facing this annoying issue too...

[abdullahtahiriyo]

@wmfmontrose

I think Prusa does an outstanding job in supporting older printers with new features.

They go into developing "prusalink" when they have the MK4 with it integrated (although prusalink would love to see more frequent releases, specially after the flawed API key issue, that is fixed already for some months in the repo, but there is no release with the bug fix yet).

My MK3 is several years old and still produces a quality comparable to new market darling printers (it only takes more than double the time to finish the prints, which may be a problem for ROI when running a farm, but not for most hobbyists).

I also agree with them that the safety feature should not be "disabled". "Let's switch security functions off, nothing should happen", is a kind of flawed Chernobyl thinking.

If the reading of the thermistor is low, so that it is also out of spec, preheat (as we know it from the menu) should not be allowed. You may have a broken thermistor. You should not want to do that.

What I was proposing is to provide a mode (which can be enabled/disabled in the menu) "Cold Climate Start". When this is activated: 1) If temperature < MIN_TEMP (for both nozzle and heated bed) AND "Cold Climate Start" is activated, it will set the PWMs to a low amount, for example 10% (open loop, no PID involved), So if the heater is 40W, that would be 4W. 2) You would fire a timer, e.g. 120 seconds, if the timer times out without the thermistor surpassing MIN_TEMP, you set the PWM to zero and let it error as today (as the thermistor can be broken), if it reaches MIN_TEMP + 2ºC, you stop the open loop and the timer, until temp<MIN_TEMP, in which case you operate like in (1). 3) This should be a different state, neither "Idle" nor "Printing" (e.g. "WarmingUp")

10% and 120 seconds are just two guessed values. I think that there should be no fire risk associated with running two 4W heaters for 120 seconds, one in the bed, the other in the.

A refinement could be to retrigger the timer value (for another 120 seconds) if progress has been made in the thermistor reading, but the MIN_TEMP has not been achieved yet.

This mode keeps the printer ready to print while on, at the cost of an extra energy cost. If properly enclosed, much lower running cost that heating a garage or similar.

@Prusa-Support

Is this something you would consider?

[abdullahtahiriyo]

@wmfmontrose

You have hardware solutions and software (firmware) solutions.

If you are not changing the hardware, you do need something "software" to account for the fact that your hardware might not be adequate for lower temps.

If this cannot be made (or has drawbacks making) into a mainstream "fix", then it needs be a mode. If it can be made into a mainstream "fix" without issues, then nobody needs a new mode.

For hardware solutions, it is said in this thread the thermistor is a problem due to out of spec range. I have not checked this myself. It might be possible to specify a new thermistor with a wider range (not only low, but also keeping the upper part of the range). But then, you will need to have different firmwares (or a firmware adapted to several different thermistors as an option, which may not be as safe or robust to run, Fablin used to have that if I remember correctly).

I do not think it should be necessary to change a motherboard, but the issue with the firmware maintenance is the same: A new firmware would be necessary.

What is absolutely true is that Prusa should be much more reactive (for proactive can no longer be) regarding this topic.

I do not think it is appropriate is to neglect the problem. We are talking about an extension of range to 0-10ºC or maybe -10ºC to 10ºC, which is common for a garage/shop in Canada, Norway, Sweden, Finland, ... and even the Czech republic during winter (as well as many continental/mountain climates in much southern countries). I do not think anybody is demanding it works on the arctic winter.

P.S.: When I mentioned MK4 working, I referred only to authentication for the prusalink component, which the released version for MK3 does not (there is a fix in, but it is not released). It has nothing to do with cold temperatures, but with the ability to remote control the printer (e.g. enqueue jobs, similar concept to Octoprint).

@Prusa-Support

I would appreciate if you could comment. Just as a matter of transparency. You asked for ideas.

Do you intend to pursue a solution to this issue or you do not?

[gisforgirard]

Look, this is all way being made way more complicated than it needs to be. Just make the MINTEMP error STOP HAPPENING WHEN THE HEATERS ARE NOT ON!!! IT MAKES NO SENSE! SOMEONE PLEASE EXPLAIN WHY THIS IS NECESSARY! Make it error all it wants when it is doing anything besides being idle and that's fine! Why does it have to shut the entire printer down when it's not even doing anything? It's about as much of a safety issue as having the printer turned off, and if that's a safety issue then we've got bigger problems here...

On Wed, Feb 21, 2024, 2:21 AM abdullahtahiriyo @.***> wrote:

@wmfmontrose https://github.com/wmfmontrose

You have hardware solutions and software (firmware) solutions.

If you are not changing the hardware, you do need something "software" to account for the fact that your hardware might not be adequate for lower temps.

If this cannot be made (or has drawbacks making) into a mainstream "fix", then it needs be a mode. If it can be made into a mainstream "fix" without issues, then nobody needs a new mode.

For hardware solutions, it is said in this thread the thermistor is a problem due to out of spec range. I have not checked this myself. It might be possible to specify a new thermistor with a wider range (not only low, but also keeping the upper part of the range). But then, you will need to have different firmwares (or a firmware adapted to several different thermistors as an option, which may not be as safe or robust to run, Fablin used to have that if I remember correctly).

I do not think it should be necessary to change a motherboard, but the issue with the firmware maintenance is the same: A new firmware would be necessary.

What is absolutely true is that Prusa should be much more reactive (for proactive can no longer be) regarding this topic.

I do not think it is appropriate is to neglect the problem. We are talking about an extension of range to 0-10ºC or maybe -10ºC to 10ºC, which is common for a garage/shop in Canada, Norway, Sweden, Finland, ... and even the Czech republic during winter (as well as many continental/mountain climates in much southern countries). I do not think anybody is demanding it works on the arctic winter.

P.S.: When I mentioned MK4 working, I referred only to authentication for the prusalink component, which the released version for MK3 does not (there is a fix in, but it is not released). It has nothing to do with cold temperatures, but with the ability to remote control the printer (e.g. enqueue jobs, similar concept to Octoprint).

@Prusa-Support https://github.com/Prusa-Support

I would appreciate if you could comment. Just as a matter of transparency. You asked for ideas.

Do you intend to pursue a solution to this issue or you do not?

— Reply to this email directly, view it on GitHub https://github.com/prusa3d/Prusa-Firmware/issues/3053#issuecomment-1956033558, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEG7W337WDXUYOF7VB4ODKDYUWN6NAVCNFSM4YVE7BWKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJVGYYDGMZVGU4A . You are receiving this because you were mentioned.Message ID: @.***>

[3d-gussner]

The MINTEMP function is in the first place to detect

1. Thermistor is connected
2. Thermistor cable is broken
3. Thermistor is faulty

Same for MAXTEMP function is in the first place to detect

1. Thermistor cables are shorten
2. Thermistor Connector pins are shorten
3. Thermistor is faulty

Every thermistor has an operation range where it reads reliable while is less accurate outside this range. For the hotend and hed we need a reliable reading range between 40 and ~300 °C / 150°C. Even more reliable in the range between 170°C and ~300°C to have a stable filament printing temperature. So the reading in the lower temperature range are less accurate and at some low temperatures even outside the specs.

@gisforgirard Thanks for the suggestion

Just make the MINTEMP error STOP HAPPENING WHEN THE HEATERS ARE NOT ON!!!

Great now it will not error out, BUT how do you heatup the printer? As soon you turn on the heaters, following your suggestion the printer will immediately error out as this function is active again

Make it error all it wants when it is doing anything besides being idle and that's fine!

Heating is NOT idle. Idle is when the printer does nothing. Movements, fans and other things are way lower safety risk than turning on the heaters.

I hope you understand our dilemma that it is not that easy to keep the safety feature while allowing it to run outside the reliable thermistor range.

Please also understand that we need to ensure that the printers are safe and the MIN/MAX temp, Thermal Runaway and Thermal Model are implemented to do that.

[3d-gussner]

@abdullahtahiriyo Thanks for your suggestion and kind words in https://github.com/prusa3d/Prusa-Firmware/issues/3053#issuecomment-1952940213

At first peek it looks something I need to look in more detail and maybe we can discuss this internally.

BTW any community PR that doesn't disable the function (like lowering the MINTEMP values to out of spec values or disabling the error out for good) but improves the cold climate behavior would be very appreciated.

[3d-gussner]

Question: Would you install a community build firmware on your printer to be able to use it in cold climate? Which means that Prusa isn't responsible for any issue you may have. Vote :+1:

Or do you expect Prusa to implement such a feature with full support? Vote :rocket:

Or would it be okay that Prusa implements such a feature but with limited support and "use at your own risk"? Vote :smile:

[Patronics]

I also like that suggestion, but that's not the first time that sort of concept has been mentioned on here (I've suggested the same sort of process previously in this thread, way back in December 2022. Turn on the heater briefly, and see if the measured temperature has increased, and if not then it's a sensor failure, otherwise heat up is successful).

Regardless, I appreciate that it seems that Prusa's finally starting to look at this issue more seriously, and I really hope a solution like those suggested can be implemented.

To answer your other question, it's definitely the sort of thing that I'd want an official released firmware to support, as with a custom fork there'd be a lot less reliability on getting continued updates, etc. I'd be okay with there being an "use at your own risk" sort of warning or disclaiming of liability (as long as the warning didn't require interaction every time we use the feature, as that would largely defeat the point). I would want to be able to trust that I'd continue to get further firmware updates from Prusa when they are released, without worrying about if they've been merged, tested on the forked version, etc.

[3d-gussner]

@Patronics Thanks for your feedback and the old suggestion. It is not an excuse but this topic comes up every year and every year we struggle to find a good solution as most user expect to have a safe printer WHILE somehow run the printer outside the specs of its components and capabilities with full support and warranty.

I'd be okay with there being an "use at your own risk" sort of warning or disclaiming of liability

Added this as an additional vote option.

[abdullahtahiriyo]

I have run lots of custom firmwares with my first printer (it was not a Prusa), improving all sort of things (coincidentally dynamically changing thermistor types was one of the tweaks). This is fun when the hobby is to improve a 3D printer, as opposed to use a 3D printer for the hobby (or real job).

I want to have all improvements of every firmware update by Prusa directly in, without having to patch my code into it every time and compile. I also want that this is globally solved for all users having this problem, not just for me.

So, the answer is: No, I want to run a stock firmware.

From a point of view of the differentiation as company:

One can take the view of a established regular company: "You are trying to operate the printer outside the absolute maximum ratings for temperature. We do not support that. Sorry". I do not expect that answer from Prusa, unless there is truly no way, as it is not a regular company (and a solution is feasible). We are talking about Prusa Research. Prusa's way of thinking is an asset.

It may not be the most relevant topic ever, but there are a few people having this limitation. A limitation that other printers may not have. I absolutely agree to an argument that they are less safe because they lack that safety feature. Yet, they work while Prusa users receive an error and have to go with the hair-dryer to the (cold and unpleasant) garage/shop (I would ask you to picture you doing this every morning, while the guy next door just prints).

My guess is that other Prusa printers also have this issue. If they do and no solution is found for this issue, it is plausible that the next printer folks in cold climates buy is not a Prusa. That would likely be a pitty because the issue appears solvable and your marketing guys could also be making the feature an advertising point.

I would argue that this is one of the main selling points of Prusa: It works out of the box. Systematically. Safe and proven technology.

I think it is time to Prusa up and solve this for good.

[eefweenink]

I would surely welcome a firmware update (always easier then working around :-). In this thread I did my suggestion on warming up in small steps (to include in the custom G-code), what helps, but not completely. For the time being, I like the suggestion about printing in artic circumstances. If we have a workaround for that, we are good on all cold places. Several solutions/suggestions passed by in this thread. To put it together in a kind of short list: What to do to avoid MINTEMP error in artic temperature; avoid standing in the cold with a hairdryer and get the best prints possible:

1. The printer should be in an enclosure.
   2. Add a small heater to the enclosure, about 40 Watt is enough, and choose one with a max_temp_prevention.
   3. If the heater has no thermostatic switch, add a small thermostatic switch (on amazon, alieexpress for a few euros).
   4. Set it to a nice temp about 25 degrees C
2. Add two distance controlled switches (Hue, Zigbee, etcetera:
   6. The first one to control the heater, lights, raspberry, etcetera.
   7. The second one to control the printer. (after about 15-30 minutes) NB: Both can be controlled from out the nicely heated livingroom :-) PS: The second switch could be replaced by a timer
3. Add to the custom code many steps to heat the bed. M190 S13 M190 S15 M190 S17 M190 S19 M190 S21 M190 S23 M190 S25 M190 S27 M190 S29
4. Print and Enjoy.

And whenever the firmware is prepared for the cold, a couple of steps can be skipped. Regards, Eef

[3d-gussner]

I just tried Marlin bugfix 2.1.x and even vanilla Marlin does halt the printer by default.

However Marlin Configuration_adv.h allows some preheat without checking the MINTEMP for defined time. There are only 10 of 358 example configs that have this activated by default and only 3 printer manufactures. See https://github.com/search?q=repo%3AMarlinFirmware%2FConfigurations+PREHEAT_TIME_HOTEND_MS&type=code

Most companies do not activate this work around / feature for a reason.

The suggestion made by @abdullahtahiriyo and probably @Patronics are way more advanced than the vanilla Marlin solution.

[Patronics]

Most companies do not activate this work around / feature for a reason.

a big part of that reason is because they don't need to. From a quick search through that repo, I didn't see any of those configurations that had as high of a MINTEMP value as Prusa sets. Almost all of them had the limit set at 5 degrees Celsius, and some at 1, while Prusa sets the limit at 10 degrees.

So there's a pretty wide range of people in relatively mild climates (or warmer times of year), including me, who will sometimes run into this mintemp issue with Prusa printers, but none of the competitors' machines.

https://github.com/search?q=repo%3AMarlinFirmware%2FConfigurations+HEATER_0_MINTEMP&type=code

[abdullahtahiriyo]

@wmfmontrose

What you want is an option in the survey. Just hit the "rocket", which means you want Prusa to provide a solution with official support.

[3d-gussner]

@wmfmontrose

If your typical diesel car or truck is parked outside in -10 degrees F, or -40 degrees C, do you have to get the hair dryer out and warm it up before you can start it?

As Diesel starts starts to gel around -12°C you need something to heat it up or an additive.

I expect Prusa to develop a solution to this bug, not install a hack patch off the internet.

You can see this as an BUG but most companies see the MINTEMP as a safety feature and these companies don't want to temper with it. Again see my post above. I am at least open to discuss a solution and consider constructive ideas. I means myself and not Prusa.

Not rocket science, just simple, basic, 5th grade elementary school, product design.

Feel free to provide a constructive solution without compromising the essential function to detect faulty thermistors + cables and not turn on the heaters un-monitored to a level that is risky.

WELL, JUST FIX IT.

Shouting doesn't help, is not polite, constructive and for sure not a way to get a feature that most companies (see my comment above) DO NOT want to implement even vanilla Marlin has it as an optional feature.

After reading these kind of comments I am tempted just to stop engaging in this topic and leave it to the user to temper/modify the firmware. It is open source and anyone can change things to their needs.

[abdullahtahiriyo]

@3d-gussner

I guess Marlin is recommending max 30 seconds full power preheating, and the comment indicates this should be enough, because the thermistors are relatively close to the heat sources and even connected with heat conducting materials.

The only reason for needing a "Warming up" is because the thermistors are out of spec under MIN_TEMP. However, this does not mean one needs to heat all the printer enclosure to MIN_TEMP to be able to start operating it. It is sufficient that the thermistors are warmed up over MIN_TEMP, which may happen relatively fast even with a rather limited power and while the surrounding air is still well below MIN_TEMP. At that point, because we know the thermistor is working fine, we can just start printing or regular preheating and use the full power of the heater (with all the guarantees of respecting the MIN_TEMP mechanism).

In terms of energy (disregarding dynamic effects), 40W for 30 seconds equals 4W (PWM at 10%) for 300 seconds, or 8W (PWM at 20%) for 150 seconds. An important bit to figure out is which power and time can be regarded as safe enough...

[3d-gussner]

@wmfmontrose Thanks, please don't only listen. If you have constructive feedback it is always appreciated.

I can't talk on behave of Prusa, but as a company I would think twice or even more times to ALLOW an un-monitored feature like this. Better safe than sorry.

Let's keep it polite and maybe we as community come up with a solution that doesn't undermine the safety and is "bullet" prove to preheat in out of spec thermistor ranges.

One of the reason I try to engage in this topic is to get good ideas, discuss these and collect arguments so there is chance that it will be discussed and maybe implemented.

Modifications that just lower values (know as unreliable) or disable the MINTEMP have NO chance to be even looked/reviewed.

[abdullahtahiriyo]

@3d-gussner

Expanding more on the idea of using a different state "Warming Up".

Machine state-wise, it may make sense to restrict that one can only transition from "Idle" to "Warming Up" and back.

This restriction would avoid that a thermistor malfunction (breaking thermistor, wires disconnecting, ...) while printing (for example) may lead to switching to "Warming up" (Then it should error like the current firmware does). Also avoids that "Warming Up" can be used as a Error inhibitor work-around to directly switch to regular preheat or printing.

This would also keep the new functionality restricted to operate only starting from "Idle" state, so not interfering with other operations. From "WarmingUp" it can go to "Error" (if it is impossible to get to MIN_TEMP with the limited power and time of the Warming Up mode) or back to "Idle" (when MIN_TEMP is surpassed by a couple of degrees to provide some hysteresis).

It would probably lead to clearer intent in the code too.

A successful warming up sequence:

Boot --> Idle --> if(Idle &&Actic Mode == true && temp < MIN_TEMP) WarmingUp else Error as today --> Warming Up [Cannot print] [Cannot preheat] --> if (WarmingUp && temp > MIN_TEMP + HYSTERESIS[2ºC]) to Idle --> Idle [Can print] [Can preheat] --> Printing --> Idle [temp still over MIN_TEMP]--> Idle [temp<MIN_TEMP] --> Back to first "if" of this sequence.

A failed warming up sequence:

Boot --> Idle --> if(Idle &&Actic Mode == true && temp < MIN_TEMP) WarmingUp else Error as today --> Warming Up [Cannot print] [Cannot preheat] --> On timer timeout with temp < MIN_TEMP switch to Error state.

A refined version with temp value storing and N attempts (which can be of lower magnitude time, so step wise):

Boot --> Idle --> if(Idle &&Actic Mode == true && temp < MIN_TEMP) WarmingUp; oldtemp=temp; else Error as today --> Warming Up [Cannot print] [Cannot preheat] --> On timer timeout with temp < MIN_TEMP, if (temp > old_temp + DELTA) retrigger the timer and keep warming up, else error state [Potentially attempt Warming up following this method for N cycles while each completed iteration achieved at least a DELTA change of the thermistor in the good direction; error state otherwise].

This latter way might perhaps allow for a more controlled process, requiring an evolution of the thermistor reading (in line with the suggestion of others), for low power and shorter times. However, I am not sure how this would work, as the readings of the thermistor being out of scale may not reflect a meaningful progress despite a meaningful temperature change. That would require some testing to be determined.

Hope this is helpful in advancing the topic.

[3d-gussner]

@abdullahtahiriyo Thanks again for the input and idea. At this moment I am quite busy with FW 3.13.3 and FW 3.14.0 and hope to look into this next week.

@wmfmontrose Hotend thermistor is a ATC Semitec 104GT-2 type and here the corresponding table . Datasheet Bed thermistor is a EPCOS 100k type and the corresponding table

The EINSY uses an ATMega 2560 and its ADC, the thermistors have tolerances and there are other things that influence the readings. We found out that readings blow 10°C are very very unreliable. Some printers were able to read ~5-7°C while others where more around ~10°C this is the reason we set the MINTEMP to 10°C.

At some temperatures the firmware wasn't 100% reliable to detect if the thermistor was connected or not. And without a connected or unknown state thermistor you shouldn't actually can't turn on a heater.

[3d-gussner]

Also turning on the heater at lower power is kind of risky in case the firmware is buggy and actually powers at 100% for longer period of time.

Here some thought to think about:

To be safe the un-monitored turn-on-time can't exceed the time the most powerfull heater cartridge (yes there are more power full than 40W as also these have tolerances) would reach 70°C at 100%.

But we also need to prevent following scenario:

1. A Faulty thermistor or disconnected
2. Printer starts
3. We switch to the Arctic mode as MINTEMP is detected after start up
4. Printer powers up for defined time and errors out a. assuming it reached at this moment 70°C without the printer "knowing"
5. user reboots printer
6. As the thermistor is still in MINTEMP we again switch to Arctic mode
7. But now the hotend is already at ~70°C
8. The printer again powers up for defined time and errors out a. and now the hotend temp is again higher (assume 120°C) without the printer "knowing"
9. User does reset multiple times and the hotend heats up each time more and more. This is a potential meltdown as it was heated up un-monitored by the firmware multiple times

Writing a value to EEPROM may be an option to count BUT as we don't have any real time after booting up we don't know how long it has been that the printer heated up un monitored.

A 30 minute safety timer to prevent this would be an option. Timer needs to be defined how long a hotend needs to cool down even in warm / hot environment. I am pretty sure users will AGAIN complain, why we put the printer into a COOL DOWN mode.

I hope you see the dilemma we have implementing a feature like this.

There have been also ideas to use a dead-man switch where the user has to keep turning the knob to keep the heater on. BUT again someone pointed out that Host printing user will complain that they have to walk to the printer.