[BUG] X SENSORLESS_HOMING no longer works

[JohnnyTheOne]

Did you test the latest bugfix-2.0.x code?

Yes, and the problem still exists.

Bug Description

X SENSORLESS_HOMING no longer works after this change Y and Z works

Bug Timeline

No response

Expected behavior

No response

Actual behavior

No response

Steps to Reproduce

No response

Version of Marlin Firmware

bugfix-2.0.x

Printer model

No response

Electronics

No response

Add-ons

No response

Your Slicer

No response

Host Software

No response

Additional information & file uploads

No response

[ellensp]

Please attach your configuration files.
Need example config to check for other facktors.

[JohnnyTheOne]

Configuration.h

Configuration_adv.h

[DerAndere1]

There is a small chance that merging of 6 axis support improved sensorless homing (or made it even worse!). Can someone test with latest bugfix-2.0.x ?

[JohnnyTheOne]

Just tested again 15 minutes ago but still the same

[thisiskeithb]

There is a small chance that merging of 6 axis support improved sensorless homing (or made it even worse!). Can someone test with latest bugfix-2.0.x ?

No issues with sensorless homing on my builds before or after that PR (+ followup fixes).

[DerAndere1]

Have you sent M502 followed by M500 after uploading Marlin? If the issue persists:
Whenever there are homing or leveling issues, we now ask everyone to follow a standard procedure to gather more information:

Enable DEBUG_LEVELING_FEATURE and M114_DETAIL and re-flash the firmware.
Connect to your printer from host software such as Cura, Printrun or Repetier Host.
Send M502 and M500 to ensure your Configurations are applied.
Issue the command M111 S247 to enable maximum logging.
Perform a G28 to do your standard homing procedure.
Do a G29 to probe the bed. This will also enable bed leveling.
Do some of the moves that revealed problems before. Take notes.
Copy the log output into a .TXT file and attach it to your next reply.

Repeat this procedure, if needed, to demonstrate inconsistencies. From these logs we should hopefully get a better idea of what's going on with your machine.

[JohnnyTheOne]

Here the log file Log#22012.txt
Log#22012-150621.txt

[salfter]

When you say X-axis homing "doesn't work," what, exactly, do you mean? I was having homing issues with my Hypercube 300 recently until I got the driver current and stall sensitivity settings dialed in properly. Before that, a fair bit of the time, the printer would halt with homing issues, while other times the carriage simply wouldn't move to the home position.

I also enabled CODEPENDENT_XY_HOMING, since Hypercubes are CoreXY printers. Your bug report makes no mention of the printer you're using, but if it's a CoreXY design of some sort, you might try that.

[JohnnyTheOne]

Got the problem figured out. if I use #define EXTRUDERS 5 X home does not work and with #define EXTRUDERS 1 it works again. i need 5 extruders for mmu2s .
I have CoreXY DIY

[kursatu]

@JohnnyTheOne @DerAndere1
I can confirm that I've also replicated this defect on bugfix , pulled June 18.
It also happens with the optical switch not just with stallguard/sensorless homing
and for both X & Y for me.
One of the recent commits must have regressed it.
My config, custom CoreXY, custom MMU2, SKR2, TMC2209
Setting EXTRUDER 1 made the stallguard/sensorless homing work again, for both sensorless and optical homing.
I also need mm2, otherwise the printer would not work,

[Minims]

Is there already a workaround for this issue ? Did you find the commit that cause this problem ?

[github-actions]

This issue has had no activity in the last 60 days. Please add a reply if you want to keep this issue active, otherwise it will be automatically closed within 10 days.

[JohnnyTheOne]

@DerAndere1 the problem is still there can you look at this please?

[DerAndere1]

I wrote the initial 6 axis code but the big refactoring of extruder / axis code was mainly done by others. According to comments at #22181 , endstop/stallguard detection is working fine with EXTRUDERS 3 .

• Obviously it is not caused by the number of distinct axes exceeding 8.

Some places in #21953 that I would change as a test:
in file Conditionals_LCD.h :

  #define E_AXIS_N(E) AxisEnum(E_AXIS + E_INDEX_N(E))

That macro should be tested

---

Also do the following changes:

Marlin/Marlin/src/module/motion.cpp

Line 127 in ed0c5ae

HOTEND_LOOP() LOOP_LINEAR_AXES(a) hotend_offset[e][a] = tmp[a][e];

change that to:

    HOTEND_LOOP() LOOP_ABC(a) hotend_offset[e][a] = tmp[a][e];

---

If that does not help, change file types.h : replace the enum starting with enum AxisEnum : uint8_t { with the old code:

enum AxisEnum : uint8_t {
  X_AXIS = 0, A_AXIS = X_AXIS,
  Y_AXIS = 1, B_AXIS = Y_AXIS,
  Z_AXIS = 2, C_AXIS = Z_AXIS,
  #if LINEAR_AXES >= 4
    I_AXIS,
  #endif
  #if LINEAR_AXES >= 5
    J_AXIS,
  #endif
  #if LINEAR_AXES >= 6
    K_AXIS,
  #endif
  E_AXIS,
  X_HEAD, Y_HEAD, Z_HEAD,
  E0_AXIS = E_AXIS,
  E1_AXIS, E2_AXIS, E3_AXIS, E4_AXIS, E5_AXIS, E6_AXIS, E7_AXIS,
  ALL_AXES_ENUM = 0xFE, NO_AXIS_ENUM = 0xFF
};

//typedef IF<(NUM_AXIS_ENUMS > 8), uint16_t, uint8_t>::type axis_bits_t;

That change will revert some progress related to the effort of @thinkyhead to reduce the internal number of axes with EXTRUDERS 0, but its worth trying, IMHO .

If that does not help, try to replace the whole types.h file with the types.h file from before PR 21953 which can be found here: https://github.com/thinkyhead/Marlin/blob/1570d868d01720494899c148830127fa0b6747a6/Marlin/src/core/types.h

[JohnnyTheOne]

Ok i just tried again and it works again.
@kursatu, @Minims does it work for you too?

[DerAndere1]

In bugfix-2.0.x, as well as in the 2.0.9.2 release, HOTEND_LOOP() LOOP_ABC(a) hotend_offset[e][a] = tmp[a][e]; in motion.cpp is fixed, thanks to ellensp.

[ellensp]

Seems like this is fixed, Closing till I hear otherwise

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.