Homing issues if DELTA_HOME_TO_SAFE_ZONE disabled

[jwcrawley]

I wanted to change the homing position for safe_zone. If I print tall objects, I do not want the machine to then proceed to crush said part. (I believe the safe-zone is set too low, and appears to be a binary, not configurable - but that's a different issue)

When I proceeded to comment out the

#define DELTA_HOME_TO_SAFE_ZONE

the machine would home and stay at the endstops. If I proceeded to home again, motor "X" would not trigger the endstop and move upwards another few mm. This is a severe problem as it would eventually crash the rail against the top of the printer.

[jwcrawley]

Am using Marlin 1.1.0-RC8 - 6 Dec 2016 commit 7bea5e5.

Using Kossel Mini, with appropriate delta configs copied and settings modified for my printer.

[thinkyhead]

The "safe zone" height is calculated to be the highest point where you can still move X and Y in the full bed region. It's calculated from the printer's geometry, and as far as I know it's on the mark.

I'm not sure why your "X" endstop isn't triggering. If it's electrically triggered, then the firmware should detect that immediately and respond to it. I've been tuning a delta over the last couple of days —without DELTA_HOME_TO_SAFE_ZONE— and so far I haven't had any endstop issues.

Give RCBugFix a test and see if possibly there was an issue we fixed.

If I print tall objects, I do not want the machine to then proceed to crush said part

Well, strictly speaking, G28 is not specified for use at the end of a print, even on Delta. Instead, in your slicer "End GCode" you should use G1 X0 Y0 Ztop where "top" is the highest Z position, probably your Z_MAX_POS. That will always move the carriages to the top, no matter whether you have DELTA_HOME_TO_SAFE_ZONE on or off.

[jwcrawley]

Im at work right now. But when I get home, I could take a video to show what's happening.

If DELTA_HOME_TO_SAFE_ZONE is ON, then re-homing works well. No issues. It's only when the setting is OFF does the "X" motor (hooked up to X on Ramps 1.4) not engage the endstop until it moves back up a small amount.

Hardware-wise, I've upgraded to optical endstops after detecting significant slop in the microswitches. I have checked them extensively in Marlin to make sure they are configured correctly and passing the correct signals. They are, electrically doing as they should. There's also an indicator light on the endstops as well, showing when they are triggered.

(And the comment about the height for "SAFE_ZONE" was more wondering where I can set/override it. But it makes sense it's set via geometry. I have no issues with that detail, only other than it would be nice to see a variable set to the equation used to make this... But that's a feature request :)

[thinkyhead]

It's strange to only fail in the case of DELTA_HOME_TO_SAFE_ZONE being off. Maybe there is a code glitch. The only difference with it on should be coming after the second bump. I'll take a closer look.

[thinkyhead]

It almost sounds like the X endstop is getting un-triggered. Are the "flags" on your opto endstops large enough so they can't move past where the endstops trigger?

[jwcrawley]

Just as an update, the camera footage is on my HD camera but ran out of batteries :/

I have fixed the issue as a triage to use DELTA_HOME_TO_SAFE_ZONE=ON

I do see there was an update as well to trunk. I will test the current update to see if the same applies.

[jwcrawley]

Ok, after further testing , Marlin certainly is in error. What's happening on a G28 is the following:

X motor (I'm referring to the labeling on RAMPS) goes up to home, hits the microswitch, backs off at 1/10th the speed and slowly approaches the endstop. Once the endstop is triggered, it moves on to Y. Y motor does the same as X does, rapid ascent to endstop, then back slowly and approach slowly. Success.

Z motor just SNAPS into place, with absolutely no reverse and climb back up.

If repeated G28's are given X and Y both slowly descend and reapproach. Z does nothing at all.

I have enabled AND disabled #define DELTA_HOME_TO_SAFE_ZONE . The action of Z motor snapping to endstop happens regardless. The only difference is with SAFE_ZONE, the gantry moves downward.

I've included all of my config files below.

1.1.0-rc8-woozy-wookiee_jcrawley-error.zip

A video demonstrating this behavior is being uploaded to my youtube channel as I type this. The link is Kossel Mini, 1.1.0-rc8-woozy-wookiee, delta Homing Issue

[Blue-Marlin]

What does M119 show in mid air?
If z-min is triggered z can't go down.

[jwcrawley]

I have triaged my problem. I disabled #define USE_ZMIN_PLUG , and the erroneous behavior ceased with the Z axis.

The strange part, is that I could move around the buildspace of the printer with z_min: TRIGGERED with not an issue. In fact, with SAFE_ZONE active, the machine would SNAP Z to the endstop, then lower by the Safe Distance.

It was only causing weirdness with homing.

The following is a log of me manually moving the machine around manually triggering endstops. The only one showing issues is z_min.

SENDING:M119
Reporting endstop status
x_max: TRIGGERED
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: TRIGGERED
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: TRIGGERED
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: open
z_min: TRIGGERED
z_max: open
>>> M119
SENDING:M119
Reporting endstop status
x_max: TRIGGERED
y_max: open
z_min: TRIGGERED
z_max: TRIGGERED
>>> M119
SENDING:M119
Reporting endstop status
x_max: TRIGGERED
y_max: open
z_min: TRIGGERED
z_max: TRIGGERED
>>> M119
SENDING:M119
Reporting endstop status
x_max: TRIGGERED
y_max: TRIGGERED
z_min: TRIGGERED
z_max: TRIGGERED
>>> M119
SENDING:M119
Reporting endstop status
x_max: open
y_max: open
z_min: TRIGGERED
z_max: open

[Blue-Marlin]

// If you want endstops to stay on (by default) even when not homing
// enable this option. Override at any time with M120, M121.
//#define ENDSTOPS_ALWAYS_ON_DEFAULT

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