Y Axis crashes after using Octopi

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

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.

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.

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?

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.

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?

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.

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?

hmm aber die werte sollten stimmen im profil oder?

Das kannst Du in den OctoPrint Settings abschalten:

sollte ich das tun? kann das der fehler sein?

Eigentlich nicht, das ist nur für die Größenüberprüfung

ich hab den druck jetzt abgebrochen weil er das "bed leveling" wieder zu weit hinten begonnen hat - da wäre er dann sicher wieder hinten angefahren... sehe ich da jetzt trotzdem was im logfile?

octoprint-systeminfo-20220212202330.zip (166.0 KB)

so jetzt wird es komisch - habe den drucker ausgeschaltet - den pi abgeschlossen, und von der sd karte gedruckt und wieder ein crash - puh ich dreh noch durch....
soll ich vielleicht octopi anschließen und die achsen max refernzieren? geht das?

Da gehen seltsame Dinge vor sich:

2022-02-12 20:20:11,011 - Recv: start
2022-02-12 20:20:11,012 - Printer sent 'start' while printing. External reset? Aborting job since printer lost state.
2022-02-12 20:20:11,026 - Changing monitoring state from "Printing" to "Cancelling"

hmm na das war wahrscheinlich ich weil ich beim drucker selbst abgebrochen habe oder?

Das kann sein.

Also nach dem Homing und beim Bed Leveling gibt es den Crash.
Fängt er denn vorne links an?

ja genau wenn er in y ganz nach hinten fährt steht er an
ja er fängt vorne links an (aber halt nicht ganz vorne) als wie wenn das bett verschoben ist....

Normal würde ich sagen: Ein Hardware Problem, aber was mich irritiert ist, dass es vom Drucker aus ohne Probleme geht.