[BUG] Z AXIS endstop fail

[KlucVYET]

I have an intermittent endstop problem when starting printing. The first detection by the Z axis switch goes well and when it straightens it sinks into the bed. I updated to 1.5.4 seeing this bugfix (Fix ignored z endstop when only one endstop is used) but it doesn't seem to have worked for me. The solution I found is to do a power reset between each print.

Here is my printer information:

• Firmware : Marlin 2.0 (Knutwurst V1.5.4)
• Anycubic i3 - Mega X (DGUS clone display)
• Only one switch for the Z axis stopend
• ABL: BLTouch 3.1 (Antclabs)
• TMC: BIGTREETECH - TMC 2209-V1.2

[markecskace]

I have the same problem with I3 Mega S connected to OctoPrint on my Windows PC and MEGA_S_TMC_BLT_10_v1.5 fw.
I must disconnect the USB connection between print jobs, otherwise it also sinks into the bed after the initial endstop trigger.
Likewise, I also use both endstop switches for Z axis and original BLTouch with TMC 2209.

[TripitakaBC]

This may be completely unrelated; correlation does not equal causation, however...

I changed my Start G-code from what I had to the code listed on this site and when I did, I also had the issue that the nozzle would home OK and then promptly sink into the bed and drag. When I investigated, the line G1 Z0.15 was what was triggering that action so I removed it.

To be transparent, I was also working on a bunch of other stuff at the same time and had forgotten that I needed to re-evaluate the Z offset after changing the hotend. PEBKAC in full effect.

You may want to isolate which command in g-code is causing the unwanted behaviour. I am on 1.5.4 with a Mega S and BLTouch but I have the original stepper drivers (until next week).

[TripitakaBC]

Update from my earlier comment:

I should have kept my mouth shut. Now I have the same issue as the OP which is different from the one I commented on. It doesn't seem to be G-code related.

Firmware: Knutwurst 1.5.4 - MEGA_S_DGUS_BLT_10_v1.5.4
Printer: Anycubic Mega S
Two z-switches
Control: Octoprint 1.10.3 - camera streamer
Slicer: Cura 5.9.0

It was printing files just fine, on the 4th print of the day it started exhibiting the behaviour which seems to occur right after G0 X0 F6000 in my start code block:

G21 ; metric values
G90 ; absolute positioning
M82 ; set extruder to absolute mode
M107 ; start with the fans off
G28 X0 Y0 ; move X/Y to min endstops
G28 Z0 ; move Z to min endstops
M501 ; restore epron settings
M420 S1 ; apply bed leve mesh (if you updated the firmware)
M106 S255 ; fan on
G0 Z0.2 F1800 ; move nozzle to print position
G92 E0 ; specify current extruder position as zero
G1 X190 E50 F1200 ; extrude a line in front of the printer
G92 E0 ; specify current extruder position as zero
G0 Z20 F6000 ; move head up
G1 E-6 F2400 ; retract
G04 S2 ; wait 2s
G0 X0 F6000 ; wipe from oozed filament
G1 E-1 F2400 ; undo some of the retraction to avoid oozing
G1 F6000 ; set travel speed to move to start printing point
M117 Printing...
G5

Like @markecskace, if I disconnect the printer from Octoprint between each print, the problem does not occur. If I do not disconnect, the problem occurs.