Y Axis crashes after using Octopi

Get Help
1

Hello community,

I hope you can help me - I am really new in 3D printing abd octopi/octoprint. About one week ago I finished my Prus i3 MK3S+. The first 20 printes are perfekt (for me at least). Then I read about octopi and I thought that is pretty cool.
I installed everything - typed in the measurements and everything worked. So time to test the first print.
Here is my problem - when I start a print from Octopi my Prusa Y axis crashes in the back. So I stoped the print - unplugged the pi from the printer - copied the file on the sd card - started the print from the sd card - crashed again - so I let the printer cool down - shut it off - started the print from the sd card again - works like a charm again - I double checked my settings - I cant find the problem and I am afraid from trying all the time - It cant be cood to crash all the time...

thanks for your help
Jagsi

2

Hello @Jagsi !

Nice you use OctoPrint (in this case not OctoPi).

But sadly you deleted the template that asked some questions that help us to help you.

What is the problem?

WRITE HERE

What did you already try to solve it?

WRITE HERE

Have you tried running in safe mode?

WRITE HERE

Did running in safe mode solve the problem?

WRITE HERE

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support! )

WRITE HERE

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, .... as much data as possible

WRITE HERE

3

Sorry I thought this is just a guideline :slight_smile:

What is the problem?

Y Axis crashes since I use Octoprint

What did you already try to solve it?

try a restart and checked my settings - now I am too afraid to try because I dont know what to do

Have you tried running in safe mode?

no

Did running in safe mode solve the problem?

I didn't try

Additional information about your setup

My printer is a Prusa i3 MK3S+
OctoPrint 1.7.3
Python 3.7.3
OctoPi 0.18.0

I hope this is better - sorry for the beginner post.

Thanks

4

This is the most important one:

5

octoprint-systeminfo-20220211210304.zip (101.5 KB)

6

Hmm no idea at all? Nobody knows about this problem?

7

Just came back from work...

It's hard to find out what command exactly did this.
Even if a y-value would be too large, the printer should not go that far.

Could you share the gcode file?

8

I downloaded the file and used the prusa slicer - like I wrote above the strange thing is that from the sd card it didn't happen.
I can't upload the G-Code it is too big :frowning:

9

You can zip it

10

great idea...
Version 3 Winder CASING STANDARD high_0.15mm_PLA_MK3S_1h48m.gcode.zip (1.5 MB)

11

Do you have something in OctoPrint's Gcode Scripts Before print job starts section?

12

Hmm I cant answer this question to be honest... I just installed and did nothing else... do I have to?
befor when I used only the SD card the printer always did a bed leveling.

13

Usually that section is empty.
I'm just curious because of this:

2022-02-11 16:49:37,861 - octoprint.util.comm - INFO - Got a resend request from the printer: requested line = 20, current line = 22
| Last lines in terminal:
| Recv: ok
| Recv: echo:enqueing "G1 E-1.000 F2700"
| Recv: echo:enqueing "G1 Z14.942 F800.000"
| Send: N21 G1 Z0.2 F720*30
| Recv: LCD status changed
| Recv: echo:enqueing "CRASH_DETECTEDY"
| Recv: T:215.4 /215.0 B:61.4 /60.0 T0:215.4 /215.0 @:20 B@:15 P:0.0 A:32.6
| Recv: LCD status changed
| Recv: tmc2130_home_enter(axes_mask=0x01)
| Recv: echo:busy: processing
| Recv:   0 step=62 mscnt= 995
| Recv: tmc2130_goto_step 0 61 2 1000
| Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x01
| Recv: tmc2130_home_enter(axes_mask=0x02)
| Recv: T:215.0 /215.0 B:61.5 /60.0 T0:215.0 /215.0 @:26 B@:0 P:0.0 A:32.6
| Recv:   0 step=18 mscnt= 290
| Recv: tmc2130_goto_step 1 49 2 1000
| Recv: tmc2130_home_exit tmc2130_sg_homing_axes_mask=0x02
| Recv: echo:enqueing "CRASH_RECOVER"
| Recv: Resend: 20

This is the terminal section of a reported crash.

This is the first line with a move command (G1) in your gcode file after the homing G28:

| Send: N21 G1 Z0.2 F720*30

But before there are these lines in the printer buffer:

| Recv: echo:enqueing "G1 E-1.000 F2700"
| Recv: echo:enqueing "G1 Z14.942 F800.000"

In between there is only G80 (bed mesh levelling)
Maybe that is going faulty.

14

what would you suggest? try to slice another one?
can you check a new one before I upload it if it has the same fault?

15

The gcode seems to be ok.
You may slice a small cube and try with that.
Before that you may enable the serial.log so that we can see what is going on with the USB connection.

16

I dont understand this "Before that you may enable the serial.log so that we can see what is going on with the USB connection." means print the cube first? or can I download the serial.log before? do you speak german?

17

Ja, tue ich :slight_smile:
Also, bevor Du den kleinen Würfel druckst könntest Du das serial.log aktivieren.
Dann werden alle Daten aufgezeichnet, die zwischen OctoPrint und dem Drucker ausgetauscht werden.
Wenn es beim Druck des Würfels keine Probleme gibt ist es gut.
Dann könntest DU nochmal das andere Modell drucken. Dann gibt es genauere Daten was kurz vor dem Crash passiert.

Manchmal verhält sich die Prusa Firmware zusammen mit OctoPrint etwas komisch.

18

ok da tue ich mir mal um einiges leichter - danke
ok das habe ich aktiviert - jetzt habe ich so einen würfel raufgeladen und dann kam so eine fehlermeldung das der würfel zu groß sei obwohl er nur 20mm groß ist - und im slicer sieht man das, dass er sehr klein ist.
kann das die ursache sein?

Bild 12.02.22 um 21.02
Bild 12.02.22 um 21.02646×748 321 KB

19

hmm aber die werte sollten stimmen im profil oder?

Bild 12.02.22 um 21.12
Bild 12.02.22 um 21.121124×1316 108 KB

20

Das kannst Du in den OctoPrint Settings abschalten:

grafik
grafik783×303 8.8 KB