-
-
Notifications
You must be signed in to change notification settings - Fork 19.3k
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
fix pins postprocessing for Z_MULTI_ENDSTOPS #27137
Conversation
@thinkyhead When you come to review this please go over this with a fine tooth comb, Programmed very late at night on almost no sleep CI error is unrelated to this PR |
Thanks for catching this one. The architecture of this thing can be tedious with so many scattered elements, but I'm sure we'll get it all wrangled in time. Perhaps "Armlin" would be a good codename for a 32-bit-only codebase with a more sensible high-level architecture. |
"assume a shared pin" Why would you assume a shared pin when you enabled Z_MULTI_ENDSTOPS? This is the opposite of what Z_MULTI_ENDSTOPS is for. I do not think this is a desirable outcome when you set Z_MULTI_ENDSTOPS |
Yeah, it's a strange idea. I don't know what the original rationale was for that choice, but I didn't want to change it right away without looking further. I expect we'll go back to asserting separate endstop pin defines, but maybe we'll tweak the error to explain the use cases. … I'll review the history now and then apply whatever is most sensible. |
Couldn't find any specific misuse cases, but reading the history was good for a few chuckles. |
Description
Marlin/src/pins/pins_postprocess.h for Z_MULTI_ENDSTOPS doesn't work as desired
The Idea of pins_postprocess is to automatically juggle existing pins around as the features requires it.
In this case the feature is Z_MULTI_ENDSTOPS
Z Stop works:
(works) Use Z_MIN_PIN or Z_MAX_PIN when defined.
(works) If Z_STOP_PIN is defined automatically converted to Z_MIN_PIN or Z_MAX_PIN depending on your homing direction as needed
Z2 Stop does not work as it should:
(works) Use Z2_MIN_PIN or Z2_MAX_PIN when defined.
(works) If Z2_STOP_PIN exists it is automatically converted to Z2_MIN_PIN or Z2_MAX_PIN depending on your homing direction
(faulty) If Z2_STOP_PIN does not exist and a unused Z_MIN_PIN or Z_MAX_PIN is defined use that as Z2_STOP_PIN
Currently it can define Z2_STOP_PIN as Z_STOP_PIN even when this is in conflict
(faulty) error if there are no options left. No error in current code.
Z3 Stop does not work as it should:
(works) Use Z3_MIN_PIN or Z3_MAX_PIN when defined.
(works) If Z3_STOP_PIN exists it is automatically converted to Z3_MIN_PIN or Z3_MAX_PIN depending on your homing direction
(faulty) There is no standard pin to reuse as this pin, so error if there are no options left
Currently Z4_STOP_PIN will be defined as Z_STOP_PIN even when this is in conflict
Z4 Stop does not work as it should:
(works) Use Z4_MIN_PIN or Z4_MAX_PIN when defined.
(works) If Z4_STOP_PIN exists it is automatically converted to Z4_MIN_PIN or Z4_MAX_PIN depending on your homing direction
(faulty) There is no standard pin to reuse as this pin, so error if there are no options left
Currently Z4_STOP_PIN will be defined as Z_STOP_PIN even when this is in conflict
Updated to correct all of these
Added some sanity checks for commonly miss configured X2_STOP, X3_STOP and X4_STOP pins.
Requirements
Z_MULTI_ENDSTOPS
Benefits
Marlin auto selects correct stop pins
Related Issues
#27014 (comment)