Endstops ignored on G0

[marcio-ao]

• Description: End stops are ignored on G0 commands
• Expected behaviour: Hitting an endstop should halt whatever motion is taking place in order to avoid
  damage to printer
• Actual behaviour: Endstops are being ignored, except during G28
• Steps to reproduce:
  • Install Marlin 1.1.4 stable
  • Home printer (G28)
  • Issue motion command (G0 X200)
  • While head in motion, manually depress x-max switch (head will continue moving)

M119 reports that all endstops are configured and responding correctly.

The incorrect behavior of hitting the endstops can be mitigated by setting the travel limits X_MAX_POS and Y_MAX_POS to avoid a collision, but if the end stops are never read during the motions, it begs the question as to why these endstops exist at all.

[benlye]

configuration_adv.h, line 243:

// 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

My understanding is that this is expensive on the processor, and should ideally be used with ENDSTOP_INTERRUPTS_FEATURE (configuration.h, L485).

[marcio-ao]

@benlye: Ah, thank you. I overlooked that option.

[fiveangle]

Marcio- Double-check your MCU pin usage against datasheet to ensure each endstop pin is interrupt capable before implementing both of the above. Printriboard RevF for example has 1 axis that is not.

[marcio-ao]

@fiveangle: We use RAMBO boards which do not do interrupts on the [XYZ]_MAX, so we would need to use ENDSTOPS_ALWAYS_ON_DEFAULT without the ENDSTOP_INTERRUPTS_FEATURE.

Our older branch of Marlin would check the endstops continuously and as far as I know this had never caused an issue. What would be the symptom of an overworked CPU? Slower prints?

[fiveangle]

Probably studdering of prints at best, MCU reset at worst.

There was discussion of ability to break out the interrupts feature per axis, but Scott said that if checking even just one, it is about the same as checking all of them so not much value.

If it worked well before, it will probably be fine unless you've added a bunch of cycle-hungry features. I also wonder what performance hit (if any) having WORKSPACE_OFFSETS enabled by default incurs, because for hard-coded bots like yours (a commercial bot with known and specific sizes/offsets/etc,) I don't quite understand what value it offers.

[marcio-ao]

@fiveangle: Actually, I disabled WORKSPACE_OFFSETS for other reasons (to restore the old behavior of G92), so that is probably buying us some CPU cycles. So far I haven't seen any issues with performance, so I may leave the endstop polling featured enabled for now.

It does bring up an interesting question of whether printers need the max endstops at all. It sounds like the general idea is that if the printer is homed correctly, checking endstops should not be needed during the course of a print? Wouldn't it be a good idea to enable HOME_AFTER_DEACTIVATE in Configuration_adv.h, though? I can see a situation where someone would disable the steppers, move the print head around, and then crash an axis. How come this isn't enabled by default?

[fiveangle]

I believe the thought is that if there is precedence where a feature was not historically enabled, and enabling it would then result in unexpected movement, the feature not be changed.

I agree that it is a smart feature and I have it enabled on my own printer.

Regarding checking max endstops, while anecdotal evidence isn't usually useful, I can state that I've never had them and not once in 3 years of pretty active printing have I had a problem of accidentally moving beyond them. Moving beyond mins (homing direction) however is another story...

[marcio-ao]

So, I we have been considering whether we could get rid of the hardware XMax and YMax endstops and compile our firmware without ENDSTOPS_ALWAYS_ON_DEFAULT. However, it seems like Marlin allows motion in the X or Y direction, even before homing has happened. For this to be safe for our user, we would need to have the ability to prohibit all motion until a G28 had been executed. Does such a feature exist?

It seems like the current default behavior of not checking endstops and allowing the user to arbritarily move the axis is inherently unsafe. Any thoughts?

[fiveangle]

I beleive:

//#define HOME_AFTER_DEACTIVATE // Require rehoming after steppers are deactivated

Should do what you want, but I've not tested it myself.

[marcio-ao]

@fiveangle: I did. It did not do what I hoped. All it does is require homing after the steppers are deactivated due to inactivity timeout. But at startup, it does not prevent the user from moving (and potentially crashing) their print head.

[fiveangle]

Sounds like we need to extend/rename the feature to HOME_AFTER_ACTIVATE then make it cover the case after startup as well.

@thinkyhead - it looks like HOME_AFTER_DEACTIVATE is getting checked during runtime here: https://github.com/MarlinFirmware/Marlin/blob/1.1.x/Marlin/Marlin_main.cpp#L1781-L1815

But where would be the best place to inject this same check at startup before movement ? Do you anticipate any problem with this ?

[fiveangle]

@marcio-ao - as this issue is closed, it will be on the lowest rung in Scott's notification list. If you agree that above proposal would resolve for you, I suggest opening new issue re: HOME_AFTER_DEACTIVATE proposal and refer to this thread, so that it won't be buried in the closed items.

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