Print does first line then goes wonky

What is the problem?

This problem just started after several months of no issues. The printer warms up does bed leveling then does the first print line. After that it moves up then to the front corner and just starts retracting and extruding a ton at super fast speeds. Not a great video and I killed the power to prevent jam. https://youtu.be/8Hh38NkpBfY

What did you already try to solve it?

Tried different cable. tried different gcode's. Same Gcoode's prints fine from SD card. Removed G34 from script since the problem started around the same time i started using it.

Have you tried running in safe mode?

Have not tried but will today

Complete Logs

serial.log (32 KB) New Bracket 2.gcode (2.3 MB)
Ignore my very very crude bracket. Lol

WRITE HERE

Additional information about your setup

Octoprint 1.5.3. Octopi 0.17.0 Marlin v2.0.7.2

WRITE HERE

at first glance I don't see anything wrong in your serial.log

I guess we should wait and see whether the safe mode helps or not.

Since you also wrote that it could be related to G34 I would also try to reset the eeprom

M502 ; reset
M500 ; save
1 Like

I tried in safe mode and got the same result. Here are the logs but seem to be pretty much the same. I will try the m502 and m500 after a current print gets done. Thanks for helping. Would posting my marlin configs help at all? octoprint.log (404.2 KB) serial.log.2021-02-09_18-21-06.log (54.4 KB)

I found these in you serial.log.

2021-02-09 18:20:54,302 - Send: N14 G92 E0.0000*92

The steps per unit have been set to zero???

https://reprap.org/wiki/G-code#M92:_Set_axis_steps_per_unit

Then the extruder would not extrude at all, but who knows what the firmware does from this...

Line 14 (and later line 19) is quite early. They may appear in the slicer start gcode.
You may check your slicer if there is something messed up

Wouldn't this be an issue when printing from the sd card as well? Same gcode works fine from SD. I also posted the gcode in the first post. It does extrude the initial line.

Edit: I will try a gcode from Cura and see if it does the same just to rule this out. My normal is S3D

That is why you might check in save mode. Maybe a plugin is the culprit.

Yeah I posted in post 3 that I checked in safe mode and same issue.

I think you have mistaken G92 for M92

G92 E0 just resets the extruder position :slight_smile:

Argh - darn...

Sorry! :blush:

1 Like

I tried a cura gcode with same results. I let the printer run for about 5 seconds after it moved to the corner to try and see the info. Got a little info about it moving to the corner. Still not sure why it does though.

2021-02-10 18:44:09,467 - Recv: X:10.00 Y:290.00 Z:20.00 E:6.06 Count X:800 Y:23200 Z:8123

serial 2021-02-10_18-44-17.log (134.7 KB)

Can you tell us something about your printer: printing size, delta or cartesian, and your printer profile settings in OctoPrint?

I built it from scratch. It's a cartesian style built with all 2020 and 2040 extrusion. Build size is roughly 315x315x320. 24v with skr e3 mini v2, BMG extruder, E3d v6 hotend, 12 inch mains powered heat bed. I'm not sure what info you want from the printer profile? Lower left origin, rectangle, size set to what i put above, nothing in the scripts.

I assume that you set the origin of the printer to the lower left in the printer profile.
This issue seems quite tricky.

That seems firmware related.
The printer performs such a move on pause or filament change.
Some things do not happen during SD card print but on serial print.

I did think it resembled a filament change. Not sure why it would be doing that though? What type of firmware related?

Do you have filament change provided in your firmware setup?

Either the filament sensor pin of the board is triggered or there is some kind of overflow in the firmware.

Ok so you've jogged my memory and i started going line through line of my marlin. I had been making firmware changes to install a filament runout sensor. I do believe now the firmware is setup for filament runout but i haven't installed the sensor yet. I'm guessing that is the issue. I made a change on my carriage so i re-flashed the firmware with the new settings and forgot i made those filament runout changes.

2 Likes

Hmm hooked up the filament runout sensor and getting the same thing. It is definitely moving to the park position and doing it's thing. I can't figure out why it would do this through octoprint but not from SD? I guess i will turn off all the filament runout stuff in marlin and reflash and see if that fixes. Unless someone has something to try?

Got it solved. Runout state had to be changed to HIGH. Apparently marlin doesn't care if the print starts with the runout sensor open and just prints. Octoprint must check for that state? or something because it would fail every time.

2 Likes

I'm afraid Marlin can not check the states of the the printer boards input pins.

You may have to use a pullup/pulldown resistor to stable the state.