Extruding out a bunch of filament instead of printing

Get Help
1

What is the problem?
Sometimes prints start spitting out tons of filament, full speed, popping out my bowden tube instead of actually starting to print.

What did you already try to solve it?
I flashed a new octopi SD card
I tried different gcode files. However, I found that the same gcode file will print fine sometimes and other times this error happens.
Printing from the SD card on TFT28 screen does not seem to reproduce this problem.

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)

Ender 3 with MKS Gen L. Marlin bugfix 1.1.x
Octoprint 1.3.10 on freshly installed Octopi.running on a Pi 3B+

Serial.log relevant section (full log and gcode below)

2019-04-24 22:31:31,141 - Recv: ok
2019-04-24 22:31:31,146 - Send: N17 G92 E0*113
2019-04-24 22:31:31,152 - Recv: X:219.60 Y:220.00 Z:1.00 E:0.00 Count X:17568 Y:12429 Z:-277
2019-04-24 22:31:31,159 - Recv: ok
2019-04-24 22:31:31,164 - Send: N18 M117 "All systems go"*2
2019-04-24 22:31:31,170 - Recv: ok
2019-04-24 22:31:31,174 - Send: N19 G92 E0*127
2019-04-24 22:31:31,194 - Recv: X:219.60 Y:220.00 Z:1.00 E:0.00 Count X:17568 Y:12511 Z:-277
2019-04-24 22:31:31,200 - Recv: ok
2019-04-24 22:31:31,205 - Send: N20 G1 F2400 E-4*6
2019-04-24 22:31:31,340 - Recv: ok
2019-04-24 22:31:31,345 - Send: N21 M107*22
2019-04-24 22:31:31,350 - Recv: ok
2019-04-24 22:31:31,355 - Send: N22 M204 S5000*99
2019-04-24 22:31:31,360 - Recv: ok
2019-04-24 22:31:31,365 - Send: N23 M205 X30 Y30*20
2019-04-24 22:31:31,370 - Recv: ok
2019-04-24 22:31:31,375 - Send: N24 G0 F3600 X99.719 Y44.86 Z0.2*26
2019-04-24 22:31:32,508 - Recv:  T:200.04 /205.00 B:60.06 /60.00 @:127 B@:127
2019-04-24 22:31:33,381 - Recv: echo:busy: processing
2019-04-24 22:31:34,507 - Recv:  T:199.54 /205.00 B:60.49 /60.00 @:127 B@:0
2019-04-24 22:31:35,382 - Recv: echo:busy: processing
2019-04-24 22:31:36,358 - Recv: ok
2019-04-24 22:31:36,370 - Send: N25 M204 S500*84
2019-04-24 22:31:36,378 - Recv: ok
2019-04-24 22:31:36,382 - Send: N26 M205 X20 Y20*17
2019-04-24 22:31:36,388 - Recv: ok
2019-04-24 22:31:36,393 - Send: N27 G1 F2400 E0*40
2019-04-24 22:31:36,443 - Recv: ok
2019-04-24 22:31:36,448 - Send: N28 G1 F1500 X101.302 Y41.286 E0.13001*1
2019-04-24 22:31:36,508 - Recv:  T:199.97 /205.00 B:60.16 /60.00 @:127 B@:0

serial.log

gcode that was printing during this log:

If you could answer this question as well it would be great...In the serial.log file, all the lines seem to be multipled by some seemingly arbitrary number. For example: Send: N17 G92 E0*113 ....the corresponding gcode ends in E0. ....so... Where does the *113 come from? Also, why are my Z's negative here?

I really hope someone can help because this is driving me nuts.

Thanks,
Frank

2

The Nx WHATEVER*123 represents the line number after the initial N and then at the end is the calculated checksum after the asterisk. You can reasonably ignore that.

A negative Z value means a retraction. If you see a -4 then that's a retraction of 4mm of filament. I meant "E" there, obviously.

Your Dropbox link wants a login and I don't have an account with them, btw.

OctoPrint -> Settings -> GCode Scripts -> "Before print starts" may or may not have gcode in it. If it does, then this gets prepended to your gcode content and would be pertinent to this discussion.

The first 30 lines of your gcode file are pertinent here and you should include them for us to review (please).

Typical startup code might look like:

  • home the X/Y/Z axes
  • set the X/Y/Z motors to absolute mode
  • set the E motor to either absolute or relative mode
  • reset all motor's audits with a G92
  • perform an autolevel if the printer has this capability
  • heat up the hotend(s) and bed
  • optionally print a priming line, say, in the front of the printer, then resetting the extruder's audit

So if you indicate that your printer is ejecting a bunch of unwanted filament at the start of the job, I'd say to review the two script areas which I talked about. Also, look for any post-processing scripts you might have in your slicer or anything that might throw gcode based upon your printer profile.

1 Like
3

Thanks for your answer!

It should let you skip the dropbox login with a "continue to view file without logging in". Does it not show that for you? What file sharing method do you recommend? Pastebin says it's too large.

here's the first chunk.
2019-04-24 22:12:54,007 - Connecting to: /dev/ttyUSB0
2019-04-24 22:12:54,027 - Changing monitoring state from "Offline" to "Opening serial port"
2019-04-24 22:12:54,030 - Connected to: Serial<id=0x6d487050, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2019-04-24 22:12:54,031 - Changing monitoring state from "Opening serial port" to "Connecting"
2019-04-24 22:12:54,040 - Send: N0 M110 N0125
2019-04-24 22:12:55,094 - Recv: start
2019-04-24 22:12:55,099 - Recv: echo:Marlin bugfix-1.1.x
2019-04-24 22:12:55,103 - Send: N0 M110 N0125
2019-04-24 22:12:55,104 - Recv:
2019-04-24 22:12:55,106 - Recv: echo: Last Updated: 2018-07-31 | Author: (Frankie, Ender-3-Pro)
2019-04-24 22:12:55,108 - Recv: echo:Compiled: Apr 21 2019
2019-04-24 22:12:55,109 - Recv: echo: Free Memory: 3288 PlannerBufferBytes: 1232
2019-04-24 22:12:55,119 - Recv: echo:V55 stored settings retrieved (655 bytes; crc 41373)
2019-04-24 22:12:55,121 - Recv: echo: G21 ; (mm)
2019-04-24 22:12:55,123 - Recv: echo: M149 C ; Units in Celsius
2019-04-24 22:12:55,124 - Recv:
2019-04-24 22:12:55,125 - Recv: echo:Filament settings: Disabled
2019-04-24 22:12:55,126 - Recv: echo: M200 D1.75
2019-04-24 22:12:55,127 - Recv: echo: M200 D0
2019-04-24 22:12:55,129 - Recv: echo:Steps per unit:
2019-04-24 22:12:55,130 - Recv: echo: M92 X80.00 Y80.00 Z400.00 E415.00
2019-04-24 22:12:55,132 - Recv: echo:Maximum feedrates (units/s):
2019-04-24 22:12:55,134 - Recv: echo: M203 X500.00 Y500.00 Z20.00 E25.00
2019-04-24 22:12:55,135 - Recv: echo:Maximum Acceleration (units/s2):
2019-04-24 22:12:55,137 - Recv: echo: M201 X500 Y500 Z100 E5000
2019-04-24 22:12:55,138 - Recv: echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
2019-04-24 22:12:55,139 - Recv: echo: M204 P5000.00 R500.00 T5000.00
2019-04-24 22:12:55,144 - Recv: echo:Advanced: Q<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> X<max_x_jerk> Y<max_y_jerk> Z<max_z_jerk> E<max_e_jerk>
2019-04-24 22:12:55,147 - Recv: echo: M205 Q20000 S0.00 T0.00 X30.00 Y30.00 Z0.30 E5.00
2019-04-24 22:12:55,149 - Recv: echo:Home offset:
2019-04-24 22:12:55,150 - Recv: echo: M206 X0.00 Y0.00 Z0.00
2019-04-24 22:12:55,151 - Recv: echo:Auto Bed Leveling:
2019-04-24 22:12:55,152 - Recv: echo: M420 S0 Z0.00
2019-04-24 22:12:55,154 - Recv: echo: G29 W I0 J0 Z0.33000
2019-04-24 22:12:55,156 - Recv: echo: G29 W I1 J0 Z-0.24750
2019-04-24 22:12:55,156 - Recv: echo: G29 W I2 J0 Z-0.76250
2019-04-24 22:12:55,157 - Recv: echo: G29 W I0 J1 Z0.36750
2019-04-24 22:12:55,160 - Recv: echo: G29 W I1 J1 Z-0.31000
2019-04-24 22:12:55,161 - Recv: echo: G29 W I2 J1 Z-0.88250
2019-04-24 22:12:55,163 - Recv: echo: G29 W I0 J2 Z0.42750
2019-04-24 22:12:55,164 - Recv: echo: G29 W I1 J2 Z-0.26750
2019-04-24 22:12:55,165 - Recv: echo: G29 W I2 J2 Z-0.88000
2019-04-24 22:12:55,167 - Recv: echo:Material heatup parameters:
2019-04-24 22:12:55,168 - Recv: echo: M145 S0 H185 B45 F255
2019-04-24 22:12:55,169 - Recv: echo: M145 S1 H240 B0 F255
2019-04-24 22:12:55,171 - Recv: echo:PID settings:
2019-04-24 22:12:55,172 - Recv: echo: M301 P31.07 I5.66 D42.63
2019-04-24 22:12:55,173 - Recv: echo:Z-Probe Offset (mm):
2019-04-24 22:12:55,174 - Recv: echo: M851 Z-1.04
2019-04-24 22:12:55,944 - Recv: ok
2019-04-24 22:12:55,952 - Changing monitoring state from "Connecting" to "Operational"
2019-04-24 22:12:55,965 - Send: N0 M110 N0125
2019-04-24 22:12:55,976 - Recv: ok
2019-04-24 22:12:55,981 - Send: N1 M11539
2019-04-24 22:12:56,007 - Recv: FIRMWARE_NAME:Marlin bugfix-1.1.x (Github) SOURCE_CODE_URL:https://github.com/MarlinFirmware/Marlin PROTOCOL_VERSION:1.0 MACHINE_TYPE:Ender-3-Pro EXTRUDER_COUNT:1 UUID:cede2a2f-41a2-4748-9b12-c55c62f367ff
2019-04-24 22:12:56,018 - Recv: Cap:SERIAL_XON_XOFF:0
2019-04-24 22:12:56,020 - Recv: Cap:EEPROM:1
2019-04-24 22:12:56,021 - Recv: Cap:VOLUMETRIC:1
2019-04-24 22:12:56,023 - Recv: Cap:AUTOREPORT_TEMP:1
2019-04-24 22:12:56,027 - Recv: Cap:PROGRESS:0
2019-04-24 22:12:56,030 - Recv: Cap:PRINT_JOB:1
2019-04-24 22:12:56,033 - Recv: Cap:AUTOLEVEL:1
2019-04-24 22:12:56,038 - Recv: Cap:Z_PROBE:1
2019-04-24 22:12:56,040 - Recv: Cap:LEVELING_DATA:1
2019-04-24 22:12:56,043 - Recv: Cap:BUILD_PERCENT:0
2019-04-24 22:12:56,046 - Recv: Cap:SOFTWARE_POWER:0
2019-04-24 22:12:56,049 - Recv: Cap:TOGGLE_LIGHTS:0
2019-04-24 22:12:56,052 - Recv: Cap:CASE_LIGHT_BRIGHTNESS:0
2019-04-24 22:12:56,055 - Recv: Cap:EMERGENCY_PARSER:0
2019-04-24 22:12:56,059 - Recv: Cap:AUTOREPORT_SD_STATUS:0
2019-04-24 22:12:56,062 - Recv: Cap:THERMAL_PROTECTION:1
2019-04-24 22:12:56,064 - Recv: ok
2019-04-24 22:12:56,070 - Send: M155 S2
2019-04-24 22:12:56,076 - Recv: ok
2019-04-24 22:12:58,079 - Recv: T:30.62 /0.00 B:24.34 /0.00 @:0 B@:0
2019-04-24 22:13:00,079 - Recv: T:31.59 /0.00 B:25.54

4

An observation:

G1 X219.6. Y20 Z0.3 F5000.0 ; move to side a little

There's a trailing . there after the X coordinate that doesn't belong. Not sure if that might cause issues in the firmware depending on its internal state but I'd get rid of it just in case.

I also notice that your file assumes absolute positioning for the X, Y and Z coordinates but doesn't explicitly set it, so depending on what you do before printing you might modify that mode and cause weird behaviour too. You should put a G90 in there that goes along with your existing M82.

I've seen this happen in case of serious communication issues where a simple movement line was mangled in transport, the checksum (the *123 bit there) still matched though (it's just an XOR, nothing fancy or very robust) and the printer happily tried to make sense of the garbage data it received. Also in cases of an overstressed controller, causing interrupts to not be handled with the expected timing. So that might be a factor here. Usually goes along with a ton of resends though. Does your serial.log contain the communication from when you encountered the issue? Because it looks fine. Commands are sent to the printer, no resend errors, nothing out of the ordinary. GCODE looks ok too other than what I mentioned above.

When exactly does this happen? The last line in the serial.log or actually the last processed command before it happens would be interesting.

As already mentioned, those "multiplications" are OctoPrint adhering to the N<linenumber> <command>*<checksum> format to allow detection of transmission errors by the controller and telling OctoPrint about it/request a resend of an affected line.

I can't see negative Z coordinates in the whole file. The G29 output shows that some bits of your bed are lower while others are higher than the reference Z height, hence negative values there. And your Z offset is also negative, putting your nozzle closer to the bed than the detected zero point. Also normal.

1 Like
5

@foosel caught one problem, a missing G90. I think I caught another one (which would explain sometimes spilling out tons of filament), a missing G92 E0.

There are two G92 E0 in the section labeled ; Ender 3 Custom Start G-code but both are after the lines that extrude filament. Move the first one up before the G1 Z1.0 F3000 ; move z up little to prevent scratching of surface line and things should work better.

1 Like
6

Thank you!

I have implemented these changes in my starting gcode now and also, I went through my Marlin config and noticed that my bed in the config was set to 230 instead of 220. I don't know if that could cause this (since my ABL finishes at the top right (220x220) corner, I'm wondering if this confuses OP somehow because I had 220x220 set in OP. I changed it and reflashed and with your changes and that I have not had the problem again so far for 3 prints....so...fingers crossed for now.

Thank you guys for your help! I really appreciate it

1 Like
7

Hope your problem is fixed. If not, I had a similar problem that you can look at here: https://youtu.be/VVq6TqEOLKE (Original post on Reddit https://www.reddit.com/r/ender3/comments/avpbbs/my_ender_3_sometimes_has_a_mind_of_its_own/ )

It was also intermittent from both the SD card and Octoprint. I tried quite a few things, new SD card, new cable, fresh install, everything I could think of, nothing helped. It was not until I switched out the Pi to a 3B (no +) that it started working as it should every time. Seems strange that switching that out fixed my problem but it did, so I cant argue with it.

8

In your startup gcode, I'm used to seeing a G0 command to first set the place where a movement is about to start and then a series of G1 commands which actually move/extrude.

...as in...

G0 Z2.0 F3000             ; Move Z Axis up little to prevent scratching of Heat Bed
G0 X3.1 Y20 Z0.3 F5000.0  ; Move to start position
...

I could be wrong but I thought that Marlin needed to see a G0 first. :man_shrugging:

And yes, I read the part where everything was fixed by replacing your Pi with an earlier model.

9

@MongoRanger Looking at the reddit post your start code doesn't have a G90 either (see above). If a previous print job ended in relative mode (G91), then the next job with this start code could very easily exhibit the strange behavior you describe.

Another possibility is that the previous job was cancelled while in relative mode. This would, of course, make the strange behavior happen much less often.

10

@OutsourcedGuru While you are correct that the convention is G0 for moves (without E) and G1 when there is an E. The Marlin documentation recommends it, but doesn't need it. Marlin firmware treats G0 and G1 identically, see http://marlinfw.org/docs/gcode/G000-G001.html and/or marlin_main.cpp in the Marlin sources (search for G1).

11

You'll have to forgive me because about seven years ago I ran a CNC (among other things) and there's a big difference in that world. I'm pretty sure they have two separate feedrates for both those modes. So you'd use G0 to position for the start of each part's layer and then G1 to get it done, so-to-speak. The G1 speed would be something programmatic/appropriate for the material and bit size, the G0 is more of a global/static setting.

12

@OutsourcedGuru, you are forgiven :grin:

From the Marlin documentation above:

Marlin 2.0 introduces an option to maintain a separate default feedrate for G0 . Note: Slicers tend to override firmware feedrates!

  • Developers: Keep using G0 for non-print moves. It makes G-code more adaptable to lasers, engravers, etc.
13

Thanks for pointing out what you see in my problem but all of my problems with that went away when I switched out to the 3B from the 3B+. I still to this day can not figure out why that fixed it but it did, even with everything else being exactly the same. Since I saw he was using a 3B+ I just thought I would mention it and give the background so he could compare. I was not trying to hijack the thread but thank you for your points, it gives me something to consider if I run into that issue again. :+1: