When the Print Starts, my Printer Will Unload the Filament

Sorry for creating a second thread, but the earlier thread (8822) seems to be dead.

What is the problem?
The filament will unload at the beginning of the 4th or 5th print.

What did you already try to solve it?
I replied to a different thread (8822) with the same issue about 4 days ago. I included the log files requested but no one has replied. I started the serial port logging and two days later. The printer did the unloading. I went to the serial log, compressed it, and uploaded it. It is attached below.

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!)
latest_serial.log.zip (1.7 MB)

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

I am using a Rasberry Pi 3B+ with the 0.17.0 image on it and 1.3.21 OctoPrint.

I use a MacBook Pro, OS 10.14.6, with Firefox and Chrome Browsers to view the Octopi.local interface.

My printer is a Monoprice Maker Select Plus with ADV3i v4.0.3 firmware.

The problem has been occurring since I setup the Octopi server 3 weeks ago. If I re-boot the OctoPi the problem persists, but If I Powercycle the 3D printer, the problem will go away for 4 or 5 prints. The problem does not occur if I print from an SD card.

Thanks for your support on this issue.
Salty Doug

I don't find a M702 command for unloading nor a huge negative value (>5) for the extruder in the log

But there are some serial errors in the log like this:

2020-01-22 17:14:31,124 - Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2793
2020-01-22 17:14:31,134 - Please see https://faq.octoprint.org/serialerror for possible reasons of this.
2020-01-22 17:14:31,145 - Changing monitoring state from "Operational" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2793)"
2020-01-22 17:14:31,163 - Connection closed, closing down monitor
2020-01-22 17:17:45,585 - Changing monitoring state from "Offline" to "Detecting serial port"

Could it be that the firmware unloads when losing the USB connection?

Not dead actually, I have it open in my list of "TODO tabs", but am currently busy with prepping 1.4.0rc4 and thus couldn't yet find the time to actually look into some analysis :sweat_smile:

So, important question... When at the print start does the filament unload happen? I take it after the heatup. But before or after the auto leveling routine that I see there?

What I also see is an M82 right at the start, setting the extruder to absolute mode. Then, before any E coordinate resets via G92 there are two G1 commands that set E to 9 and 18.5 respectively. If at this point the firmware thinks the current E coordinate is above that, it will cause a long retract/unload. So that's where I'd start poking. Either those two commands need to be framed in M83/M82 to quickly switch to relative and back, or you want an G92 E0 before that so the internal E coordinate is at 0 and thus a filament extrusion will happen instead of a potentially very long retraction. As things are now, the G92 E0 reset happens right after the offending lines:

M82                      ; !! absolute E coordinates
G21                      ; units are mm
G90                      ; absolute X, Y, Z coordinates
M107                     ; fan off
M140 S105                ; bed, no waiting
M104 S240                ; hotend, no waiting
M190 S105                ; bed, waiting
M113 S2                  ; busy timeout, injected by OctoPrint
M109 S240                ; hotend, waiting
M300                     ; beep
G0 F5000 X10 Y10 Z0.6    ; move hotend
G28                      ; leveling
G0 F5000 X10 Y5 Z0.3     ; move hotend
G1 F500 X10.0 E9         ; !! move hotend & extrude/retract to E9
G1 X110.0 E18.5          ; !! move hotend & extrude/retract to E18.5
G92 E0                   ; !! reset E coordinate to 0
[...]

Thanks for the help Gina.
I'll add the G92 E0 command before the G1 commands.

I am curious, does the G28 (Homing) command reset the E axis to 0?

Best

Salty Doug

I would be surprised to be honest, all it should do is really home X, Y and Z (not level as I wrote, that was a mistake on my part).

Hello, I'm seeking for help with similar issue during my prints. The filament is unloaded mid-print, after several layers are printed. I'm trying to figure out, why that happens. I seem to have G92 E0 in my GCODEs. Each prints correctly from SD card, but when I'm printing from OctoPrint, it hits the issue.

May I ask for your help identifying, what's wrong? I've attached a sample GCODE file, as it is generated by Ultimaker Cura.
CCR10_cable_strain_relief.gcode (2.3 MB)

Hello @mlemanczyk !

For the age of this thread (a lot of things have changed since then) and being not quite the same issue, I strongly recommend to open a new thread with all of the requested information.

Thank you Ewald, I'll open a new thread for my issue.

1 Like