Skip to content

🧑‍💻 Unify DIAG endstop pins aliasing #27839

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

Merged

Conversation

thinkyhead
Copy link
Member

@thinkyhead thinkyhead commented May 5, 2025

Background

In the distant past the presence of an endstop pin define was used to determine if the endstop was monitored, and later we added defines to indicate which endstop plugs were in use to preserve the needed endstop pin defines. We then refactored endstops and removed those defines, using configuration alone to determine whether endstop pins are needed, enabled, monitored, and reported.

Physical Endstop Pins

  • RAMPS-style boards have 6 pins labeled XYZ "MIN" and "MAX" endstops. Typically these are wired as-labeled, leaving the unused pins for other uses (e.g., other end safety). Some OEM printer boards may use other default arrangements (e.g., to shorten wires).
  • At minimum boards with endstop headers for switch/opto endstops will have three, XYZ, labeled as "STOP."
  • DIAG pins are wired on a per-stepper-driver basis, named in correspondence with axes "E0", "E1", etc. So any number of endstops can be be pre-designated to certain axes based on configuration. When auto-mapping extra axis steppers these specific endstops must automatically correspond when sensorless homing is being used for the given axis stepper.

Endstop Pin Defines

Our ideal is to have all endstop pin defaults defined at the board level based on standard patterns:

  • If there are 3 endstop pins, they are named STOP (later aliased as MIN/MAX/SAFETY etc.)
  • If there are 6 endstop pins, they are named MIN/MAX (later aliased as STOP/SAFETY etc.)
  • Extra endstop pins should be defined in Config examples but boards can also provide layouts.
  • Even standard endstop pins should be overridable on boards with pin headers.
  • Unused endstop pin names are not #undef so they can be used by name for other functions.
  • As for active DIAG pins, they:
    • Route to a specific pin header (usually STOP/MIN);
    • Can alias to all of MIN/MAX/STOP/SAFETY at once;
    • May include En_DIAG, allowing repurposing as sensorless homing steppers (e.g., Z2);
    • Leave "the OTHER XYZ endstop pins" free to become MIN, MAX, SAFETY.

It all makes for an interesting challenge to account for DIAG pins that may require a jumper, may include the E axes, on boards with variable numbers of exposed headers for wired endstops….


Most boards should aim to keep the labeled "MIN" and "MAX" pins on the board from flipping around —at the board pins definition level— because we need to consider future repurposing on top of the board's original intended use. For that it's good to have pin names match the silk-screen whenever possible.

Boards with DIAG pins are unique –some of them– in having DIAG route to pin labeled "MIN" when it could be either end. So there is no set MIN/MAX for either pin in that configuration. One is "STOP" and the other is –well– "OTHR" I suppose.


This PR aims to move redundant handling of DIAG aliases to pins_postprocess.h and to clarify how DIAG pins and other endstop pins are aliased in different endstop configurations. Boards that have DIAG pins routed to one pin can define the "*_OTHR_PIN" and that will be automatically aliased to MIN/MAX (the other end of the axis).

There are some boards (Einsy Retro) that pick different "OTHR" endstop pins depending on the homing direction, but this is not needed for most cases.

Overall the result is a simpler set of pin definitions in the board pins files, centralized definition of DIAG pin aliasing, and a stage for future standardization of this important facet.

@thinkyhead thinkyhead force-pushed the bf2_endstop_pin_unify_PR branch from eb92bbe to bdd3b08 Compare May 6, 2025 03:19
@thinkyhead thinkyhead merged commit 4a0b3d1 into MarlinFirmware:bugfix-2.1.x May 14, 2025
67 checks passed
@thinkyhead thinkyhead deleted the bf2_endstop_pin_unify_PR branch May 14, 2025 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant