[BUG] Delta with Sensorless Homing crashing into tower during G28

[BirkBinnard]

Bug Description

The Marlin 2.0.7.2 BugFix G28.cpp module is written only for Cartesian printers. It ignores deltas. Consequently a delta printer cannot perform a Home function. Here are the key lines of code:

#if ENABLED(SENSORLESS_HOMING)
sensorless_t stealth_states {
tmc_enable_stallguard(stepperX)
, tmc_enable_stallguard(stepperY)
, false
, false
#if AXIS_HAS_STALLGUARD(X2)
|| tmc_enable_stallguard(stepperX2)
#endif
, false
#if AXIS_HAS_STALLGUARD(Y2)
|| tmc_enable_stallguard(stepperY2)
#endif
};
#endif
do_blocking_move_to_xy(1.5 * mlx * x_axis_home_dir, 1.5 * mly * home_dir(Y_AXIS), fr_mm_s);

The do_blocking_move statement is the critical bug - it has 3 parameters: X-distance to move, Y distance to move, and move speed. As written the statement moves only in the X and Y directions at speed = fr_mm_s. For a delta printer there needs to be a 4th parameter which is the distance to move in the Z direction.

This problem happens only when Sensorless Homing is specified.

Configuration Files

Required: Include a ZIP file containing Configuration.h and Configuration_adv.h.

Marlin Configs.zip

Steps to Reproduce

1. Move end effector away from Home position
2. Issue Home command
3. End effector crashes into either X or Y tower

Expected behavior:

Successful Home function

Actual behavior:

End effector crashes into either X or Y tower

Additional Information

• Provide pictures or links to videos that clearly demonstrate the issue.
• See Contributing to Marlin for additional guidelines.

[BirkBinnard]

After searching Marlin for the term "delta" I discovered that homing for delta printers apparently uses module Marlin\src\module\delta.cpp, and not the G28.cpp module I identified in my original post. Consequently I am closing this Bug since it's original premise was wrong. Also, I have given up trying to use sensorless homing. Instead I'll do it the old-fashioned way by using microswitches.

PS: While looking at the code in delta.cpp I found what looks like a bug:

// Start from the origin of the old coordinates and add vectors in the
// old coords that represent the Xnew, Ynew and Znew to find the point
// in the old system.
cartes.set(delta_tower[A_AXIS].x + ex[0] * Xnew + ey[0] * Ynew - ez[0] * Znew,
delta_tower[A_AXIS].y + ex[1] * Xnew + ey[1] * Ynew - ez[1] * Znew,
z1 + ex[2] * Xnew + ey[2] * Ynew - ez[2] * Znew);

In the last statement it looks like z1 should actually be just z. But I can't really tell if this is the case or not.

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