All Prints Stuck at 99%

Get Help
1

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 ...)

https://pastebin.com/twE26S1y - 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)

1 Like
2

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
3

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

4

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

5

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

6

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.

https://pastebin.com/ytwx6jsD

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?

7

What's with the R?

M190 R50

Isn't that supposed to be S50?

8

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.

https://reprap.org/wiki/G-code#M190:_Wait_for_bed_temperature_to_reach_target_temp

9

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

10

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.

11

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.

12

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.

13

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.

2 new photos by Josh Armour
14

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
15

Hi! I had the same problem when I started using the SKR Mini on my Ender 3. Everytime it finished printing via SD card through Octoprint it always got stuck at 99% and I was unable to input any command to the board. The worst thing is that the extruder didn't cool down and jammed several times my extruder due to the filament crystalizing.

Looking at the End G-code of my Cura settings, I tried changing some commands. What I found out is that for some reason the printer was waiting for a button press, and it was unable to receive any G-code command until it was pressed. The fix was to include a M108 (Break and continue) command at the end of the End G-code like this:

; Ender 3 Custom End G-code
G4 ; Wait
M220 S100 ; Reset Speed factor override percentage to default (100%)
M221 S100 ; Reset Extrude factor override percentage to default (100%)
G91 ; Set coordinates to relative
G1 F1800 E-3 ; Retract filament 3 mm to prevent oozing
G1 F3000 Z20 ; Move Z Axis up 20 mm to allow filament ooze freely
G90 ; Set coordinates to absolute
G1 X0 Y{machine_depth} F1000 ; Move Heat Bed to the front for easy print removal
M106 S0 ; Turn off cooling fan
M104 S0 ; Turn off extruder
M140 S0 ; Turn off bed
M107 ; Turn off Fan
M84 ; Disable stepper motors
M108; Break and continue
; End of custom end GCode

That seems to have fixed the problem including the extruder not cooling down.

1 Like
16

Prints complete physically, (print head moves clear etc.), but progress bar never moves beyond 99%

WRITE HERE

What did you already try to solve it?

WRITE HERE

eq: 900.0
|      ram: 917020672
|  os:
|      id: linux
|      platform: linux2
|  plugins:
|      pi_support:
|          model: Raspberry Pi 2 Model B Rev 1.1
|          octopi_version: 0.17.0
|  python:
|      pip: 19.3.1
|      version: 2.7.16
|      virtualenv: /home/pi/oprint
2020-07-14 13:46:57,097 - octoprint.server - INFO - ------------------------------------------------------------------------------
2020-07-14 13:47:18,856 - octoprint.plugins.tracking - INFO - Sent tracking event pong, payload: {'plugins': u'playlist:0.1.2,malyan_connection_fix:0.1.3,enclosure:4.13.1'}
2020-07-14 13:47:19,720 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 86424}
2020-07-14 13:51:50,273 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 13:51:50,279 - octoprint.access.users - INFO - Cleaning up user session FB5CC2CF9759454790EA4270CBFD88F7 for user geoff
2020-07-14 13:51:50,283 - octoprint.server.util.sockjs - INFO - User geoff logged out, logging out on socket
2020-07-14 13:51:50,289 - octoprint.access.users - INFO - Logged out user: geoff
2020-07-14 13:51:50,293 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 13:51:50,643 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.1
2020-07-14 13:51:50,649 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 13:51:50,711 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.1.41
2020-07-14 13:51:50,729 - octoprint.server.util.sockjs - INFO - User geoff logged in on the socket from client ::ffff:192.168.1.1
2020-07-14 13:51:51,479 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.41
2020-07-14 13:51:51,660 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 13:51:51,664 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 13:51:54,938 - octoprint.plugins.softwareupdate - INFO - Saved version cache to disk
2020-07-14 13:51:55,156 - octoprint.server.util.sockjs - INFO - User geoff logged in on the socket from client ::ffff:192.168.1.41
2020-07-14 14:01:57,058 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 14:02:19,861 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 87324}
2020-07-14 14:04:04,433 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.1.41
2020-07-14 14:16:57,061 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 14:17:19,720 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 88224}
2020-07-14 14:31:57,067 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 14:32:19,737 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 89124}
2020-07-14 14:46:57,069 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 14:47:19,786 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 90024}
2020-07-14 15:01:57,072 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 15:02:19,761 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 90924}
2020-07-14 15:16:57,075 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 15:17:19,757 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 91824}
2020-07-14 15:31:57,081 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 15:32:19,749 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 92724}
2020-07-14 15:43:04,842 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.8
2020-07-14 15:43:20,683 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.1.8
2020-07-14 15:44:05,215 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.41
2020-07-14 15:44:05,394 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 15:44:05,398 - octoprint.access.users - INFO - Cleaning up user session 5AC6CFFCE0404B3A9C2045D55A33D9DA for user geoff
2020-07-14 15:44:05,402 - octoprint.access.users - INFO - Logged out user: geoff
2020-07-14 15:44:05,405 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 15:44:05,554 - octoprint.server.util.sockjs - INFO - User geoff logged in on the socket from client ::ffff:192.168.1.41
2020-07-14 15:44:09,049 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 15:44:09,052 - octoprint.access.users - INFO - Cleaning up user session 5AC6CFFCE0404B3A9C2045D55A33D9DA for user geoff
2020-07-14 15:44:09,055 - octoprint.server.util.sockjs - INFO - User geoff logged out, logging out on socket
2020-07-14 15:44:09,060 - octoprint.access.users - INFO - Logged out user: geoff
2020-07-14 15:44:09,063 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 15:44:09,484 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 15:44:09,487 - octoprint.access.users - INFO - Cleaning up user session 5AC6CFFCE0404B3A9C2045D55A33D9DA for user geoff
2020-07-14 15:44:09,492 - octoprint.access.users - INFO - Logged out user: geoff
2020-07-14 15:44:09,496 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 15:44:09,970 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.1.41
2020-07-14 15:44:10,473 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.1.41
2020-07-14 15:44:10,645 - octoprint.server.util.flask - INFO - Passively logging in user geoff from ::ffff:192.168.1.41
2020-07-14 15:44:10,650 - octoprint.access.users - INFO - Cleaning up user session 5AC6CFFCE0404B3A9C2045D55A33D9DA for user geoff
2020-07-14 15:44:10,655 - octoprint.access.users - INFO - Logged out user: geoff
2020-07-14 15:44:10,661 - octoprint.access.users - INFO - Logged in user: geoff
2020-07-14 15:44:12,467 - octoprint.plugins.announcements - INFO - Loaded channel _important from https://octoprint.org/feeds/important.xml in 0.31s
2020-07-14 15:44:13,218 - octoprint.plugins.announcements - INFO - Loaded channel _releases from https://octoprint.org/feeds/releases.xml in 0.31s
2020-07-14 15:44:15,584 - octoprint.plugins.announcements - INFO - Loaded channel _blog from https://octoprint.org/feeds/octoblog.xml in 0.3s
2020-07-14 15:44:16,041 - octoprint.plugins.announcements - INFO - Loaded channel _plugins from https://plugins.octoprint.org/feed.xml in 0.31s
2020-07-14 15:44:16,569 - octoprint.plugins.announcements - INFO - Loaded channel _octopi from https://octoprint.org/feeds/octopi.xml in 0.31s
2020-07-14 15:44:17,173 - octoprint.plugins.pluginmanager - INFO - Loaded plugin notices data from https://plugins.octoprint.org/notices.json
2020-07-14 15:44:17,710 - octoprint.server.util.sockjs - INFO - User geoff logged in on the socket from client ::ffff:192.168.1.41
2020-07-14 15:46:57,082 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 15:47:19,796 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 93624}
2020-07-14 15:57:17,123 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.1.41
2020-07-14 16:01:57,084 - octoprint.server.heartbeat - INFO - Server heartbeat <3
2020-07-14 16:02:19,852 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 94524}
2020-07-14 16:13:27,658 - octoprint.util.comm - INFO - Finished in 25412.313 s.
2020-07-14 16:13:27,661 - octoprint.util.comm - INFO - Changing monitoring state from "Printing" to "Finishing"
2020-07-14 16:13:27,671 - octoprint.filemanager.analysis - INFO - Starting analysis of local:MSMV2E3D_Fence-adjuster-block2.gcode
2020-07-14 16:13:27,687 - 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/MSMV2E3D_Fence-adjuster-block2.gcode
2020-07-14 16:13:27,695 - octoprint.plugins.playlist - INFO - printer state: FINISHING
2020-07-14 16:13:27,748 - octoprint.printer.standard.job - INFO - Print job done - origin: local, path: MSMV2E3D_Fence-adjuster-block2.gcode, owner: geoff
2020-07-14 16:13:27,884 - octoprint.util.comm - INFO - Changing monitoring state from "Finishing" to "Operational"
2020-07-14 16:13:27,953 - octoprint.plugin - ERROR - Error while calling plugin enclosure
Traceback (most recent call last):
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/plugin/__init__.py", line 224, in call_plugin
    result = getattr(plugin, method)(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_enclosure/__init__.py", line 1573, in on_event
    file_name = os.path.basename(payload["file"])
KeyError: 'file'

WRITE HERE

Additional information about your setup

Octoprint 1.4.0
Raspberry Pi, Buster
Monoprice Select Mini

WRITE HERE

Subject line says it: print completes physically, but Octoprint does not return to the idle state, and the progress bar remains stuck at 99%.

1 Like