Release 1.9.0 - printer halted middle print

What is the problem?

After upgrading to the last release, I've been having a lot of print errors were the octoprint just get the printer halted. The first error the software suggested to disable something on the settings, can't really remember what, but I did it. It was because according to octoprint the piece that was about to be printed was too big (it was a 15mm spur gear, 14mm tall, so obviously not that big). Then after uploading some files, when loading them, I just couldn't see them on the gcode viewer, I had to either load another file until at some point I could see the loaded file in the viewer. Now it's easy to just reload the page in the browser to see the file loaded in the viewer. But that's not all, whenever I send the file to print, at some point it just stops showing an error about mintemp, but as mention before the last 3 times it happened while I was looking at the printer's lcd and the temps were stable (210 / 65). Before this last release I never had this problem, actually no problem at all with octoprint and I haven't change any hardware at all, same RPI 3B+, same 3Dprinter (AnetA8), same slicing program (Cura 14.07 that came with the printer), I haven't even updated Cura.

What did you already try to solve it?

I tried with another slicing software Ultimaker Cura 5.0.0 but the problem remained. I tried to downgrade to version 1.8.0 but can't ssh to the raspberry cause I can't remember my password, so no luck there.

Have you tried running in safe mode?


Did running in safe mode solve the problem?

Same thing .... (64.5 KB)

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)


Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

octoprint 1.9.0, octopi 0.18.0, printer Anet A8, Marlin, Chrome, Win10 Pro 64 22H2, PC (i7, 32GB) connected by wire to router, Raspberry 3B+ connected via wifi.

Just looked at the serial log.
It's like I suspected - the issue is on the printer side.
There are different kinds of protections in the Marlin firmware that protect you from catastrophic failure.
In this case mintemp was triggered.
Mintemp makes sure that the sensor is working at normal parameters and doesn't show something like -273,15°C which would indicate that your printer is frozen in time :wink:
I don't know which value was configured in your firmware as mintemp, but it was probably something like 5°C.
Most likely either the thermistor wire is broken or there is a loose connection on the board.
While printing there is a very short time when the sensor sends wrong measurements to the mainboard and the firmware reads a temperature below mintemp. The wrong reading wasn't detected for a long time - a second later (after the firmware restarted) the readout was normal again.

An unlikely, but still possible option is that there is too much noise on the board and the processor reads false values because of that.
Maybe the problem has always existed, and it was only just barely working, and now a small change has caused it to stop working.
The Anet A8 was and is still one big disaster. I'm not just a hater - it was also my starter printer and I know it very well.

But no matter what caused it, we can't do anything on the OctoPrint side against it.

So there are two options:

  1. Replacing the thermistor(s)
  2. disabling or lower the mintemp value (you have to build a new firmware if you want to do that)

I can't recommend the latter - it's a security feature which is there for a reason

Now to your second issue - the gcode viewer. Does this problem also persist when you run OctoPrint in safe mode?

If yes could you please report this issue here

Hi there! Thanks for looking at the problem. I did take a look at the printer to find out a loose cable, one side of the bed's thermistor, so I guess it was a printer's problem. That explains the printer's halting on error, however doesn't about the size of the pieces to print or the lack of loading the gcode on the viewer. Btw, can you tell me please what option did I disable about the size of the print? The error suggested to disable something, but I can't recall what. The error mention that the print was bigger than the bed and I disable it because I knew at the time that wasn't true at all. Any ideas?

You probably got a wrong bed size in the printer profile.
Just open the OctoPrint settings and put in the correct numbers :slight_smile:

That's certainly not that, bed size is 220x220x240, always been, it won't change. And to get an error like that the bed's size would have been like 20x20x15, and not even the print was that size. It was 01 spur gear, 15mm diameter pitch, 14mm height, in the middle of the bed.

Could you upload a screenshot of the error? Just to confirm which one it is.

As I said before, that was a one time error and since I've disable whatever option it was, I'm guessing it won't happen again. On the other hand, yesterday while printing I got another mintemp error, this time from the nozzle, and that is a big coincidence. Honestly I don't know what to think, still thinking there is something wrong with the release. Btw, what about the fact that the print won't load on the gcode viewer? Anybody else had that same error? Cause it keeps happening.

Check the end of my first post :slight_smile:
Please report it in the issue tracker if it also happens in safe mode
I don't have the issue and cant recreate it.

I'm 100% with you that it's a weird coincidence that it happens with both sensors at the same time out of the blue.
But as I said it could be the noise problem. I found something in the marlin issue tracker

that doesn't solve you preoblem, but it could explain it.

If you want you can aks the guys on the Marlin discord. They will tell you the same - the OctoPrint update itself doesn't trigger mintemp errors on your printer.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.