Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uniform 'G34' to 'G28 O' to decide when homing is required or not #18753

Closed
wants to merge 1 commit into from
Closed

Conversation

GMagician
Copy link
Contributor

@GMagician GMagician commented Jul 23, 2020

I think that G34 should behave like G28 O to decide when home is required or not.

If position change due to stepper de-energization is not considered to home axes, should not be considered as well for G34

I think that G34 should behave like G28 O to decide when home is reguired or not.

If position change due to stepper de-energizingis is not considered to home axes, should noty be considered as well for G34
@thisiskeithb
Copy link
Member

So unless you manually home first, this procedure now has the potential to slam your bed or hotend into the frame if they were moved after steppers timed out, correct?

I think it’d be a good idea to keep the check for !all_axes_known() since it’s safer and ensures G34 won’t slam into anything.

I did something similar for M600/filament change to make it safer since it would slam into the frame if XYZ position was unknown: #17681

@GMagician
Copy link
Contributor Author

So unless you manually home first, this procedure now has the potential to slam your bed or hotend into the frame if they were moved after steppers timed out, correct?

More or less what may happens if you home your axes using G28 O

@thisiskeithb
Copy link
Member

I do not understand how this change would be safer than before, or a wanted feature by anyone. Documentation for G34 would need to be updated to alert users to the change at the very least.

And how far do we take it? Do we "fix" other features like M48/Probe Accuracy Test? It homes automatically before starting the procedure if XYZ position is unknown.

@ManuelMcLure
Copy link
Contributor

I have honestly never understood the desire to save a few dozen seconds (the time taken to home) at the expense of precision and safety. The time taken to do a home is negligible in comparison to the time spent in almost any print.

@Vertabreak
Copy link
Contributor

Vertabreak commented Jul 23, 2020

if you ask me the stepper idle time out should be totally removed they should never be disabled for being idle only if the user does it intentionally or its part of some other function. i always found the idle time out to be extremely annoying and it has been totally turned off in my fork for years.

@GMagician
Copy link
Contributor Author

I do not understand how this change would be safer than before, or a wanted feature by anyone. Documentation for G34 would need to be updated to alert users to the change at the very least.

I have honestly never understood the desire to save a few dozen seconds

That's not safer, nor done to save time! This is only a standardization. If HOME_AFTER_DEACTIVATE means home is needed also when stepper are disabled, in my option, this should be applied everywhere (also in M600 to be honest). Do you want to be safer, you're welcome to use above flag, otherwise I really wonder why above flag has been created just to be used in G28 O?

@GMagician
Copy link
Contributor Author

GMagician commented Jul 23, 2020

@Vertabreak the problem with "disable" stepper is just temperature...stepper tend to warm up.
It's also true that, when de-energized, position is no more "known" so home should always be done after such event.
My proposed PR is only to give a common sense to HOME_AFTER_DEACTIVATE, if its meaning is to discriminate if de-energization determine a home "needed" state, then it should be used everywhere, not in some parts and not in other.
The wrong "assumpion" has been to not follow this idea. Then, to give reason to @thisiskeithb, yes, maybe now is too late to do that

@thinkyhead
Copy link
Member

if its meaning is to discriminate if de-energization determine a home "needed" state, then it should be used everywhere

G-code handlers and feature implementations may —according to their own discretion— warn the user that they should home first, and they can either refuse to proceed or they can do the homing and then go forward.

If the author of a G-code procedure feels strongly that the procedure will be best-served by homing whenever the position is untrustworthy, they can be more strict about it and they are free to ignore the HOME_AFTER_DEACTIVATE setting if they want.

For this reason @GMagician of the past submitted #15127.

@thisiskeithb
Copy link
Member

For this reason @GMagician of the past submitted #15127.

I think leaving the feature as-is per that linked PR would be the safest option.

@GMagician
Copy link
Contributor Author

For this reason @GMagician of the past submitted #15127.

ops, its me! But I really wonder now what the meaning of HOME_AFTER_DEACTIVATING if it's not used everywhere it's supposed to discriminate if homing is needed or not... G34 doesn't use it, G28 O is in discussion, M600 doesn't use it...is there a place where it is used beyond to blink position?

@GMagician GMagician closed this Jul 24, 2020
@GMagician GMagician deleted the G34-as-G28 branch July 24, 2020 08:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants