All Prints Stuck at 99%

What is the problem?

I have a Lulzbot Mini printer that I've been using with Octoprint on an Rpi 2 for almost 2 years now. Recently it starting doing something a bit odd. My current Octoprint Version is 1.3.11.

Prints go to completion and then the bed retracts and the extruder/bed go to their home positions to cool down. At this point the print job status says 99% done. The problem is that it never actually completes. The progress bar stays stuck at 99% and the bed temp has a set point of 50C. The actual bed temp goes down to like 20C which is about normal for the room. Then it just sits like that. I have to kill the print job to stop it.

This just started happening recently. It even happens for gcode files I've printed before with no problems. I have a "yard stake" that I print pretty regularly as my dogs like to knock over the solar lamps in my yard and snap the plastic stake off. It has always worked and now this happens. It happens for new files as well.

What did you already try to solve it?

I tried restarting Octoprint and the Rpi to see if this would clear the issue. Not exactly sure what else I could do (open to suggestions!). I hate to have to re-flash the SD card and start over but I guess if it comes to that I will.

Logs (octoprint.log, serial.log or output on terminal tab, browser error console ...) - Print job of the above mentioned yard stake. Towards the end you can see where I had to cancel the job.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ...)

Octoprint: 1.3.11
OctoPi: 0.13.0
Printer: Lulzbot Mini
Firmware: Marlin V1.0.2.2; Sprinter/grbl mashup for gen6 (as reported by Octoprint on Connection)

Hi @robweber!

First try in safemode. Then, share what is inside the end gcode script of both: slicer and OctoPrint.

Is seems you are running timelapse. Rendering the video at the end belongs to the print job. This is to prevent staring something new when the renderer needs all the CPU power of the PI.

1 Like

When I was first doing timelapses, I tried to set that feature where it copies the last frame a few times so that the video doesn't abruptly end. Only I didn't know how to do that and it calculated something crazy for the duration of that pause (like 42 minutes or something). More

Thanks. I'll try safemode and see if I get any other results. A plugin causing issues definitely makes a lot of sense.

It's not an issue - it's a feature...

I tried printing again in safemode with the same result. The print completes but then the print status stays at 99% and the cooldown procedure never seems to complete. Below is a link to the very last couple lines of GCODE from the file. I looked up the M190 command on line 10. This seems to be where things go wrong.

I can see in Octoprint that the temp is set to 50. According to what I read online this command should continue to the shutdown command once the 50C temp is met. This isn't happening. I can see the temp go below 50 and then the printer just sits in a waiting state. Is this perhaps and issue with the printer firmware? It's never done this before and suddenly it happens on every print. The temp seems to be reporting just fine.

My next idea is to plug it in to my computer directly and try a print without Octoprint, but the same GCODE and see if that gets the same result. Is that worth doing?

What's with the R?

M190 R50

Isn't that supposed to be S50?

I'm not an expert by any means but this page I found looked reputable and said you can use either. I guess S is for heating only and R is for heating or cooling. In this case we'd be waiting for cooling so that made sense to me.

And yet, all your prints are stuck. It's worth a try to see if it fixes this, right?

I understand what you're saying but every piece of gcode I've ever run through this printer has that in it. I always generate with the Lulzbot edition of Cura as it has some special code entered for the Mini to do it's auto leveling. It's the same version as I've used for over a year and this problem has only been happening for a few weeks.

I looked back through code loaded to Octoprint over the past year and it's in every one of them. Several of the prints are ones I use regularly and they've always completed before.

Have you tried refreshing the browser window? I've noticed on Chrome that sometimes my Octoprint tab stops updating (except for the webcam view) even though the print continues with no problems, and I need to refresh the tab to continue seeing updates. I'm pretty sure this is a Chrome bug and not an Octoprint bug.

Thanks for the help on this so far. In troubleshooting this I decided to update the firmware as Cura wanted to do that when I plugged the printer directly into my computer. Between the old firmware and the new there was a change (intentional by LulzBot) that the "home" on the y-axis is fully forward on the printer instead of the back. When testing out the functions after the upgrade I found out the end-stop switch on my y-axis is no longer working. Apparently this is a fairly common problem with original LulzBot Mini printers due to some wiring problems.

In any case now I need to fix that before troubleshooting this problem further. I'll post back here once I get to a point when I can test things again.

This is happening to me as well, not sure if its an octoprint issue or an MMU issue.

I have a video of it happening, and I do have octolapse turned on.

I recently started using a tft 3.5 inch with touchui and it seems like octoprint is a little less responsive.

I'm currently using a pi 3b.

Wanted to give an update on this, although probably not much help to others.

I ended up sending my Lulzbot Mini back to Aleph Objects. After some testing it seemed like more than just the end-stop for the bed was a problem. They identified issues with the temperature sensor on the bed as well, probably the whole wiring harness in that area had an issue.

In any case they replaced it and did a firmware update. The whole thing is working fine now. No way to really test this out but I wonder if the stuck prints had something to do with the temperature sensor. The bed would never have appeared to hit the target cool down temperature so the print probably never finished due to that. Hard to say but replacing those components worked in this case.

1 Like