Marlin "RCBugFix" ignores endstops after homing

[tkbletsc]

UPDATE: I'm dumb and didn't know about the "ENDSTOPS_ONLY_FOR_HOMING" option, which explains all of the below. Issue resolved.

I have a Mostly Printed CNC machine with a fairly normal configuration: RAMPS 1.4 board, near-stock configuration.h.

When I first boot the machine and have it move to an endstop, it triggers and stops successfully.

However, if I home the machine (G28), then have it move to an endstop, IT IGNORES THE ENDSTOP! This occurs on both X and Y axis in both positive and negative direction. Further, I've added debug output to Stepper::endstop_triggered, and in the bugged case, this function is apparently not called.

In all cases, the M119 command correctly prints the state of all endstop switches, so the firmware is getting the switch state properly, it's just not triggering a movement stoppage if moved after a homing operation.

To make clear the issue, I've recorded a brief video demoing the problem.

Also, here's my configuration file.

[tkbletsc]

I can now confirm that Marlin isn't calling Endstops::update() at all when in the bugged state.

(I had it toggle a pin for each call to the function and watched it on my scope. In normal operation I saw the expected square wave, but in the bugged post-home state, I did not.)

[tkbletsc]

And my search has led me to the advanced "ENDSTOPS_ONLY_FOR_HOMING", which defaults to true. I disabled it and am getting the expected behavior. Duh.

My only remaining question is: why is ENDSTOPS_ONLY_FOR_HOMING the default? If you have a 3D printer, wouldn't you still want to stop at endstops instead of barreling through them?

[thinkyhead]

@tkbletsc There are a few facilities related to movement limiting.

• ENDSTOPS_ONLY_FOR_HOMING simply leaves endstops enabled during a print.
• ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED allows (see M540) halting SD printing if an endstop is triggered. It doesn't halt host printing. (Hosts can see that endstops are triggered.)
• min_software_endstops and max_software_endstops, if enabled, will constrain moves to the configured limits. This includes all moves initiated with G0, G1, G2, G3, G4, etc.

why is ENDSTOPS_ONLY_FOR_HOMING the default?

It's historical. No one knows especially why. But we can try to justify it. First, it saves a little bit of CPU to ignore the endstops during a print (and outside of homing), unless you need them for a feature, so why not leave them off? When enabling ABORT_ON_ENDSTOP_HIT_FEATURE_ENABLED then it makes more sense to disable ENDSTOPS_ONLY_FOR_HOMING.

And actually ENDSTOPS_ONLY_FOR_HOMING only determines the default (boot) condition.
You can override it with M120 / M121.

[tkbletsc]

Thanks for the feedback!

I can think of one reason to have the option disabled by default -- machines experiencing motion problems (missing steps, misconfiguration, etc.) can damage themselves if they blow past an end stop. I found it surprising because I tested my endstops extensively to avoid damage while I work on the machine, and I didn't notice the homing behavior until very late. It seems like a trap waiting to catch people doing a build, which is troubling since many people using Marlin are doing so on home-brew machines.

As for the argument in favor, it doesn't seem very strong to me. What are we saving CPU for? It's not as though avoiding endstop checks makes the machine behave better, and we're not trying to save energy or CPU time -- it's not a cellphone. To me, it seems like a realtime system -- either meeting deadlines or not, and it clearly can meet deadlines while checking endstops.

That said, I understand that changing a default option could impact machines everywhere in an unexpected way, so I'd understand if the default has to stay simply for historic compatibility for now. I just worry about new builds getting torn up...perhaps it could be considered for the next major version increment?

[thinkyhead]

That would be an entirely new feature, to have endstops limit motion generally, outside of SD printing. Of course we already have the feature to kill an SD print based on an endstop hit to deal with the unattended printer. The option is well known, and is disabled by default in a few of the example configurations according to vendor preference. To make the option more clear, at least, I am proposing #4306.

[Blue-Marlin]

why is ENDSTOPS_ONLY_FOR_HOMING the default?

It was default because several probe configurations did not work without it and because DELTAS react very allergic on unplanned detected endstop hits .
Nowadays the need tor ENDSTOPS_ONLY_FOR_HOMING should have been gone for the probes, because the probe-testing is only switched on when needed.
The DELTA problem can only be fought with working software endstops. Someone is working on that.
A extension for killing the machine for every unexpected hardware endstop hit is already around, but suffers from software endstops set at the hardware endstops trigger point - so the hardware endstops can trigger even if the too long moves are stopped by the software endstops.

There are several more issues with endstops, like

• inadequate reaction upon software endstop hits. (We are really interested in opinions what to do)
• total absence of working software endstops for DELTAs
• time consuming hardware endstop tests during the stepper interrupt, limiting the possible stepp rate.
• ...

For now activating ENDSTOPS_ONLY_FOR_HOMING by default, is the better choice.

[tkbletsc]

Thanks, this answers my question.

[thinkyhead]

I think one of the reasons we don't hear more about these things is that in general-use people print relatively small objects in the middle of the bed, so weird endstop triggers are very rare in the wild.

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