wp/Marlin-2-0-x-Anycubic-i3-MEGA-S
1
0
Fork 0
Code Issues 28 Pull Requests 2 Actions Packages Projects Releases 30 Wiki Activity

[BUG] Z AXIS endstop fail #558

New Issue
Open
opened 2024-11-30 19:02:37 -06:00 by KlucVYET · 6 comments
KlucVYET commented 2024-11-30 19:02:37 -06:00 (Migrated from github.com)
Copy Link

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
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 commented 2024-12-02 15:33:55 -06:00 (Migrated from github.com)
Copy Link

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.

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 commented 2024-12-02 15:50:14 -06:00 (Migrated from github.com)
Copy Link

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).

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 commented 2024-12-04 09:40:09 -06:00 (Migrated from github.com)
Copy Link

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.

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.
KlucVYET commented 2025-01-08 10:43:19 -06:00 (Migrated from github.com)
Copy Link

I think I may have a clue as to what the problem is. I noticed that after a while, after finishing a print, the menu to access Marlin is no longer available in the print section of the printer. Once the printer is turned off and on again the option comes back.

I think I may have a clue as to what the problem is. I noticed that after a while, after finishing a print, the menu to access Marlin is no longer available in the print section of the printer. Once the printer is turned off and on again the option comes back.
fiasko-imrvere commented 2025-01-25 17:35:54 -06:00 (Migrated from github.com)
Copy Link

I have the same issue, however disconnecting from Octoprint doesn't even help. When I play around with the offset it seems to be crashing until I put it so much higher that it's too far away from the bed. Playing around with offset within slicer is the only way the print can be set at the correct height, but the nozzle wipe still seems to be crashing just as before.

I have the same issue, however disconnecting from Octoprint doesn't even help. When I play around with the offset it seems to be crashing until I put it so much higher that it's too far away from the bed. Playing around with offset within slicer is the only way the print can be set at the correct height, but the nozzle wipe still seems to be crashing just as before.
KlucVYET commented 2025-03-14 08:00:13 -05:00 (Migrated from github.com)
Copy Link

Information to support my theory coming from the fact that the special menu is deactivated after a certain time, which could cause the bug. After a certain time as I said the menu disappears, but I did a refresh to make the menu appear and it comes back but it is impossible to select it.

Information to support my theory coming from the fact that the special menu is deactivated after a certain time, which could cause the bug. After a certain time as I said the menu disappears, but I did a refresh to make the menu appear and it comes back but it is impossible to select it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Something in the Firmware isn't working
documentation
Improvements or additions to documentation
duplicate
This issue or pull request already exists
good first issue
Good for newcomers
help wanted
Extra attention is needed
invalid
This doesn't seem right
new feature
New feature or request
question
Further information is requested
stale-closing-soon
wontfix
This will not be worked on
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
wp
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wp/Marlin-2-0-x-Anycubic-i3-MEGA-S#558
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?