Disable Axis and Z Safe Home Clash

[Nocturnal42]

So this one took me a while to figure out, but basically, having an axis set to disable when "inactive" will lead to issues with z home. For example

G28
G29

or

G28 X0 Y0
G28 Z0

Will both lead to the unhelpful "Home X/Y before Z" error. Personally, I don't consider the time it takes to move from one instruction to the next as inactivity, but there it is. Plus this comment

// - Allow Z homing only after X and Y homing AND stepper drivers still enabled

While helping to enlighten me as to what was going on, did not actually inform of the clash while I was making my configuration choices.

P.S. Thanks for the software, I'd be very unhappy without it.

[Blue-Marlin]

That behaviour does look as if you are not using a recent RC or RCBugFix.

[Nocturnal42]

Would these be the release candidates listed as "Not for production use – use with caution!"?

I'm using the "latest release" 1.0.2-1

[Blue-Marlin]

Yes.
1.0.2-1 is stable in the sense of - No error has been fixed since 18 month.

[thinkyhead]

I don't consider the time it takes to move from one instruction to the next as inactivity

@Nocturnal42 Neither do we. So I'm curious. What are your configured settings for DISABLE_X (etc.), DISABLE_INACTIVE_X (etc.), and DEFAULT_STEPPER_DEACTIVE_TIME?

[Nocturnal42]

@thinkyhead I left most things things at their defaults. I can't find DISABLE_INACTIVE_X in Configuration.h or Configuration_adv.h so its safe to say its set to whatever it's default is.

// Disables axis when it's not being used.
#define DISABLE_X true
#define DISABLE_Y true
#define DISABLE_Z false
#define DISABLE_E false // For all extruders
#define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled

DEFAULT_STEPPER_DEACTIVE_TIME is also set to its default.

//default stepper release if idle
#define DEFAULT_STEPPER_DEACTIVE_TIME 60

[thinkyhead]

Change DEFAULT_STEPPER_DEACTIVE_TIME to 300 for a better experience.

[Nocturnal42]

@thinkyhead Tried it. Had zero effect on the stated issue.

[Blue-Marlin]

I'm not joking. There was an error in 1.0.2-1. It's fixed now.

[thinkyhead]

I concur with @Blue-Marlin. This is a bug apparently in 1.0.2-1. And Marlin 1.0.x is not being patched at this time. It is therefore recommended you update to 1.1.0-RC7 or start tracking along with RCBugFix. If you're very attached to 1.0.2-1 then perhaps someone can locate the place where the bug was patched and you can apply it to your own copy. Tricky, as there have been ~800 patches since 1.0.2-1.

[thinkyhead]

#2956 and #2989 may offer some guidance.

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