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] Anycubic Mega S not X homing anymore with 1.5.4 #542

New Issue
Open
opened 2024-07-09 16:38:14 -05:00 by Alkerion · 3 comments
Alkerion commented 2024-07-09 16:38:14 -05:00 (Migrated from github.com)
Copy Link

Bug Description

My Anycubic Mega S (with TMC2209) doesn't home anymore in X axis with 1.5.4, working well with 1.5.3

Steps to Reproduce

  1. Install MEGA_S_TMC_v1.5.4.hex firmware
  2. Load FW default
  3. Save Eeprom
  4. Try to home, Y = OK, Z = OK, X = not OK
  5. Restart printer
  6. Home again, Y = OK, Z = OK, X = not OK
    1. Install MEGA_S_TMC_v1.5.3.hex firmware
  8. Load FW default
  9. Save Eeprom
  10. Try to home, Y = OK, Z = OK, X = OK

Expected behavior: [What you expect to happen]
X axis should be homing

Actual behavior:
X Axis not homing

Additional Information

If I push manually the X axis to the left and lunch a print everything is going fine.
Just the homing seems not working for X axis.

  • Provide pictures or links to videos that clearly demonstrate the issue.
  • See How Can I Contribute for additional guidelines.
### Bug Description My Anycubic Mega S (with TMC2209) doesn't home anymore in X axis with 1.5.4, working well with 1.5.3 ### Steps to Reproduce 1. Install MEGA_S_TMC_v1.5.4.hex firmware 2. Load FW default 3. Save Eeprom 4. Try to home, Y = OK, Z = OK, X = not OK 5. Restart printer 6. Home again, Y = OK, Z = OK, X = not OK 7. 1. Install MEGA_S_TMC_v1.5.3.hex firmware 2. Load FW default 3. Save Eeprom 4. Try to home, Y = OK, Z = OK, X = OK **Expected behavior:** [What you expect to happen] X axis should be homing **Actual behavior:** X Axis not homing #### Additional Information If I push manually the X axis to the left and lunch a print everything is going fine. Just the homing seems not working for X axis. * Provide pictures or links to videos that clearly demonstrate the issue. * See [How Can I Contribute](#how-can-i-contribute) for additional guidelines.
mithrandir42 commented 2024-10-02 10:57:46 -05:00 (Migrated from github.com)
Copy Link

I am experiencing a similar behaviour with a highly modified Mega X (GH Smartshaper (TMC 2225-SA) drivers for XY, stronger steppers, filament motion sensor, inductive Z probe,24V for most stuff, etc.)

YZ homing works, X not. The carriage moves some amount to the left, maybe around 10 cm, then the printer stops with:

2024-10-01 18:01:57,335 - Recv:  T:28.36 /0.00 B:58.65 /0.00 @:0 B@:0
2024-10-01 18:01:58,015 - Recv: echo:Homing Failed
2024-10-01 18:01:58,021 - Recv: Error:Printer halted. kill() called!

After a downgrade to 1.5.3 homing works again.

Also checked the endstop states in home position with M119:

Send: M119
Recv: Reporting endstop status
Recv: x_min: TRIGGERED
Recv: y_min: TRIGGERED
Recv: z_min: open
Recv: z2_min: open
Recv: z_probe: open
Recv: filament: TRIGGERED

With printf debugging I have tracked this down to endstops.cpp:457:Endstops::validate_homing_move. Commenting #define VALIDATE_HOMING_ENDSTOPS prevents the kill(), but the missing movement remains. So there seems to be a problem with left moves while X homing. Tried to reduce HOMING_FEEDRATE_MM_M, but no success.

Does this sound familiar? Maybe this is the same issue. Is VALIDATE_HOMING_ENDSTOPS enabled in your build, do you also see the kill() call?

Any further ideas?

I am experiencing a similar behaviour with a highly modified Mega X (GH Smartshaper (TMC 2225-SA) drivers for XY, stronger steppers, filament motion sensor, inductive Z probe,24V for most stuff, etc.) YZ homing works, X not. The carriage moves some amount to the left, maybe around 10 cm, then the printer stops with: ``` 2024-10-01 18:01:57,335 - Recv: T:28.36 /0.00 B:58.65 /0.00 @:0 B@:0 2024-10-01 18:01:58,015 - Recv: echo:Homing Failed 2024-10-01 18:01:58,021 - Recv: Error:Printer halted. kill() called! ``` After a downgrade to 1.5.3 homing works again. Also checked the endstop states in home position with M119: ``` Send: M119 Recv: Reporting endstop status Recv: x_min: TRIGGERED Recv: y_min: TRIGGERED Recv: z_min: open Recv: z2_min: open Recv: z_probe: open Recv: filament: TRIGGERED ``` With printf debugging I have tracked this down to endstops.cpp:457:Endstops::validate_homing_move. Commenting #define VALIDATE_HOMING_ENDSTOPS prevents the kill(), but the missing movement remains. So there seems to be a problem with left moves while X homing. Tried to reduce HOMING_FEEDRATE_MM_M, but no success. Does this sound familiar? Maybe this is the same issue. Is VALIDATE_HOMING_ENDSTOPS enabled in your build, do you also see the kill() call? Any further ideas?
stklcode commented 2024-10-02 15:28:21 -05:00 (Migrated from github.com)
Copy Link

Sound pretty much like the issue with Z axis in 1.5.3 (#521) which is a bug resolved in Marlin 2.1.2.4 (v1.5.4)

Likely some misconfiguration around the endstops, endstop pins and/or axis direction. We didn’t change those configs between 1.5.3 and 1.5.4 but Marlin upstream has changed quite a bit in the actual logic. Wondering if only TMC flavors are affected 🤔

Are all endstops reported correctly in 1.5.4 when pushed manually?

Do all axes move in the correct direction, e.g. G91 (relative positioning) followed by G0 X10 moves X 10mm away from home?

Sound pretty much like the issue with Z axis in 1.5.3 (#521) which is a bug resolved in Marlin 2.1.2.4 (v1.5.4) Likely some misconfiguration around the endstops, endstop pins and/or axis direction. We didn’t change those configs between 1.5.3 and 1.5.4 but Marlin upstream has changed quite a bit in the actual logic. Wondering if only TMC flavors are affected 🤔 Are all endstops reported correctly in 1.5.4 when pushed manually? Do all axes move in the correct direction, e.g. `G91` (relative positioning) followed by `G0 X10` moves X 10mm away from home?
github-actions[bot] commented 2025-08-01 21:03:36 -05:00 (Migrated from github.com)
Copy Link

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.
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
stale-closing-soon
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#542
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?