RE: Aliens have landed
Update: failed again
Message on Display: "MINTEMP fixed Please restart"
Can't click anything expect the X-Button.
I'm really not happy with it. Try to print a birthday present...
RE: Aliens have landed
"Print just freezes midprint and garbled message is displayed..."
this always happens at a certain z-height during printing?
This may indicate a loose contact in the extruder wire harness to Einsyboard. I had this problem with a broken wire in the near of the extruder and lost a stable thermistor connection which results in "MINTEMP BED error" - a small hidden error with great effect. Also had a problem with a hanging MMU2 during printing (flashing red/green leds) - it was a bad connection on the 5-pin data connector on the Einsy, happened after i did some operations on the board. I would check all moving cables...
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
of course not "MINTEMP BED error" rather "MINTEMP error" see here: https://help.prusa3d.com/article/am4dykf2rw-mintemp
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
@karl-herbert-g
no it's in different hight but I think you are not so far away. At the moment I think it's maybe the extruder thermistor. I opened a case at prusa hope this will be fixed quick.
That there appears that crazy symbols on the display is maybe a problem with Octoprint that tries to show a message on the display... Seen in the logs at the end
BTW:
I had some other problems that may help someone. I started a print from SD-card that stops mid skirt print three/four times in a row. I removed the USB cable and could print from SD-card, until the min-temp-error appears.... I'm using a Octoprint plugin that caused the mid-skirt-cancel named cancelobject that not worked like it should. I normally use it in combination with Cura and print multiple objects at the same time. If one of these objects I print fails, I can stop only this specific object and all other objects continue to print. But it seems it's not happy when there is a SD-card print running...
The Octoprint-log shows this lines:
2019-11-18 13:52:33,498 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2019-11-18 14:07:33,501 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2019-11-18 14:09:24,200 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: Temperature heated bed switched off. MINTEMP triggered ! - // action:cancel
| Last lines in terminal:
| Recv: ok
| Send: N35911 G1 X160.224 Y128.826 E0.01936*100
| Recv: ok
| Send: N35912 G1 X160.304 Y128.483 E0.01192*97
| Recv: ok
| Send: N35913 G1 X160.417 Y128.154 E0.01178*110
| Recv: ok
| Send: N35914 G1 X160.564 Y127.839 E0.01178*97
| Recv: ok
| Send: N35915 G1 X160.738 Y127.549 E0.01146*108
| Recv: ok
| Send: N35916 G1 X161.107 Y127.090 E0.01994*98
| Recv: ok
| Send: N35917 G1 X161.542 Y126.712 E0.01950*98
| Recv: ok
| Send: N35918 G1 X161.837 Y126.520 E0.01192*103
| Recv: ok
| Send: N35919 G1 X162.147 Y126.362 E0.01178*111
| Recv: Error:Temperature heated bed switched off. MINTEMP triggered !
| Recv: // action:cancel
2019-11-18 14:09:24,201 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Error: Temperature heated bed switched off. MINTEMP triggered ! - // action:cancel"
2019-11-18 14:09:24,210 - octoprint.util.comm - INFO - Force-sending M112 to the printer
2019-11-18 14:09:24,213 - octoprint.filemanager.analysis - INFO - Starting analysis of local:3D-Drucker/Nozzle_box_SPEED_0.2mm_PLA_MK3S_3h7m.gcode
2019-11-18 14:09:24,218 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/3D-Drucker/Nozzle_box_SPEED_0.2mm_PLA_MK3S_3h7m.gcode
2019-11-18 14:09:24,242 - octoprint.util.comm - INFO - Changing monitoring state from "Error: Temperature heated bed switched off. MINTEMP triggered ! - // action:cancel" to "Offline (Error: Temperature heated bed switched off. MINTEMP triggered ! - // action:cancel)"
And the Cancel Lines from the plugin:
2019-11-18 14:29:45,729 - octoprint.util.comm - INFO - Changing monitoring state from "Operational" to "Starting print from SD"
2019-11-18 14:29:45,748 - octoprint.printer.standard.job - INFO - Print job started - origin: sdcard, path: nozzle~1.gco, owner: None, user: None
2019-11-18 14:29:45,775 - octoprint.plugin - ERROR - Error while calling plugin cancelobject
Traceback (most recent call last):
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/__init__.py", line 219, in call_plugin
result = getattr(plugin, method)(*args, **kwargs)
File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_cancelobject/__init__.py", line 250, in on_event
with open(selectedFile, "r") as f:
IOError: [Errno 2] No such file or directory: 'nozzle~1.gco'
2019-11-18 14:29:45,783 - octoprint.util.comm - INFO - Changing monitoring state from "Starting print from SD" to "Cancelling"
2019-11-18 14:29:45,790 - octoprint.util.comm - INFO - Force-sending M108 to the printer
2019-11-18 14:29:45,797 - octoprint.printer.standard.job - INFO - Print job cancelled - origin: sdcard, path: nozzle~1.gco, owner: None, user: None
2019-11-18 14:29:45,816 - octoprint.util.comm - INFO - Pausing print job due to command M25
2019-11-18 14:29:46,051 - octoprint.util.comm - INFO - Changing monitoring state from "Cancelling" to "Printing from SD"
2019-11-18 14:29:52,899 - octoprint.util.comm - INFO - Changing monitoring state from "Printing from SD" to "Operational"
RE: Aliens have landed
@karl-herbert
yeah I saw this article too and checked all connections. So this is the source of my "maybe the thermistor".
I think it's not a good idea to switch the thermistor cables like in the article is said and then print. Maybe it solves a problem when this happens at the selftest but if I do it now and print I think I will burn the printer down to reach the 200°C at the bed 🤣
RE: Aliens have landed
@sedrah
I recommend to change the thermistorcable in cause of such errors. With a working thermistor your bed will never reach temps of 200°C. Because it's a cheap wear part I always have one to two cables in stock, both, bed and nozzle thermistors.
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
@karl-herbert
yes, and bigger problem is the printer will full power the extruder heater until the bed reach 200°C... not a good idea 😉
I just ordered a bunch of thermistors. If I measure the thermistor it's seems ok but until it fails the printer is the same opinion.
Sad to see it happens with a not one month old printer in an enclosure and really careful handled by his owner. But it's fragil electronics with really much movement and thin cables
RE: Aliens have landed
@karl-herbert
So as a small update:
The MINTEMP Message is missleading cause in 3.8.0/3.8.1 maybe older versions (but not in 3.7.1) it can be both bed and extruder... There is a really short message direct bevor the MINTEMP fixed message - maybe half a second with the correct message... I saw it on a video I took to capture the moment of failure.
In several! sessions with the support, my last step was to install 3.7.1 and there came the message MINTEMP bed error... Now I can reproduce the error by touching the correct cable at the correct position when the printer is preheating... At Monday I will receive a new thermistor for the bed.
RE: Aliens have landed
@karl-herbert
OK you would say "Wer lesen kann... ist klar im Vorteil" In the Octoprint-Log I posted, the important line: Temperature heated bed switched off. MINTEMP triggered ! - // action:cancel
why is prusa not possible to write a debug log on the sd-card or is it possible?
RE: Aliens have landed
Error: Temperature heated bed switched off. MINTEMP triggered ! ---- this indicates that the bed thermister reported a temp below 12 C likely a breaking thermister wire or loosening thermister plug
RE: Aliens have landed
@david-a66
I agree. Thats the magic trick in the enclosure with 35°C ambient temperature.
A new thermistor is on the way
RE: Aliens have landed
@sedrah
looking forward to your feedback!
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
@katie-o
the aliens are gone in the meantime?
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
@karl-herbert
at the moment... It's alive. 6.5h from 10h print done.
First thing I did after installing the new thermistor was a xyz-calibration including live z-high. After I finished everything I ran a 7x7 bed-leveling - it finished without any problems. Then started a print and the printer directly ram the nozlle in the bed... but now it seems to work fine, just with a dent in it... A little bit neurotic....
RE: Aliens have landed
@sedrah
Good news. I wish you a successfull 10h print without any crashes. To avoid a bed/nozzlecrash i mounted 2 distance blocks between z-motors and x-carriage (on the picture you see only the right side):
Statt zu klagen, dass wir nicht alles haben, was wir wollen, sollten wir lieber dankbar sein, dass wir nicht alles bekommen, was wir verdienen.
RE: Aliens have landed
The same aliens are in touch with me too.
Just started happening last week. It's not ESD related, I can predict exactly the point of the print when it will happen, repeatable to the second. See post about garbage characters. The garbage on the screen is different some times, other times it's exactly the same. Just updated to 3.8.1 MK3 firmware today but it didn't help.
RE: Aliens have landed
A human is not capable of detecting most small electrostatic discharges; a blanket claim that isn't the cause is a bit off the wall. For all we know the printer is building up a charge and it eventually discharges at the same point in a build.
That said, zip post a gcode that you think causes this. Also, contact Prusa support via CHAT, let them know that you have a reliably repeatable example that will always cause the gibberish on the display. They'd love to get a copy.
RE: Aliens have landed
@tim-m30
Stock .3mf and gcode sliced from prusaslicer 2.1.0 using generic ABS attached.
3mf source = mmu2 enclosure https://www.prusaprinters.org/prints/3673-mmu2s-enclosure#_ga=2.7608434.1591967266.1574711609-830574762.1574520854
Interestingly enough, if I export the .3mf to slt and reimport & slice it works fine. It's like something in that stock .3mf is causing an error in OctoPrint or the MK3.
I did recently update OctoPrint to the latest revision which does coincide with when the issues started happening.
Seems like multiple people in the hardware thread have reported giberish characters that just started happening recently.
Reaching out to support is my next route.
Thanks
Tim
RE: Aliens have landed
Attachment from post above. Apparently I ran out the 'edit post' clock.
RE: Aliens have landed
@karl-herbert
🤣 that was too easy... Feel stupid when I realize how long I tried to figure out how to prevent something like this and see the solution... Do you have a link or some Files?
What kind of powersolution do you use? Looks interesting!