Everyone here please tests out #27137 (or use my fork of bugfix https://github.com/ellensp/Marlin/tree/auto-endstops)

This fixes the auto allocation of Z2, Z3 and Z4 and adds some sanity checks looking for for impossible settings
eg With X homing to min and setting Z2_STOP_PIN to X_MIN_PIN, this is a pin conflict.
eg With Z homing to max and setting Z2_STOP_PIN to Z_MAX_PIN, this is also a pin conflict.

from marlin.

Firstly to reiterate:

There is a bug in 2.1.2.2 and 2.1.2.3 that stops the Z axis moving when there are two Z axis on two drivers and two endstops.
This bug is not present in Bugfix 2.1.x, it was introduced in creating Marlin 2.1.2.2 from Marlin 2.1.2.1 with snippets of code from bugfix

Found it!

After a full very long day of digging through the bowels of Marlin, looking at every nook and cranny, after making a physical test rig to test this without taking up to much space. I have homing working on Dual Z under 2.1.2.3 (same patch should fix 2.1.2.2 also)

My 'fake' dual Z axis test rig (yea its shaky cam, I'm not a youtuber!) https://youtu.be/SlSB4AEmQ_A

Details

It comes down to 1 line of Marlin/src/module/stepper.cpp

#define STEPTEST(A,M,I) TERN0(HAS_ ##A## ##I## _ ##M, !(TEST(endstops.state(), A## ##I## _ ##M) && M## DIR(A)) && !locked_ ##A## ##I## _motor)

This macro builds a string starting with "HAS_" but "HAS_" was replaced in cbaff4b with "USE_" Old examples being HAS_X_MIN etc, Ie it is making endstop related strings.

Since this are now USE_X_MIN, this macro fails to find the end stops

This line should be the following (taken from bugfix 2.1.x)

#define STEPTEST(A,M,I) TERN0(USE_##A##I##_##M, !(TEST(endstops.state(), A##I##_##M) && M## DIR(A)) && !locked_ ##A##I##_motor)

After this line is updated I can home dual Z with Z_MULTI_ENDSTOPS again

Here is a diff for those that want that format

diff --git a/Marlin/src/module/stepper.cpp b/Marlin/src/module/stepper.cpp
index 171fb7e2ee..9d30e3a479 100644
--- a/Marlin/src/module/stepper.cpp
+++ b/Marlin/src/module/stepper.cpp
@@ -274,7 +274,7 @@ xyze_int8_t Stepper::count_direction{0};
 #define MINDIR(A) (count_direction[_AXIS(A)] < 0)
 #define MAXDIR(A) (count_direction[_AXIS(A)] > 0)
 
-#define STEPTEST(A,M,I) TERN0(HAS_ ##A## ##I## _ ##M, !(TEST(endstops.state(), A## ##I## _ ##M) && M## DIR(A)) && !locked_ ##A## ##I## _motor)
+#define STEPTEST(A,M,I) TERN0(USE_##A##I##_##M, !(TEST(endstops.state(), A##I##_##M) && M## DIR(A)) && !locked_ ##A##I##_motor)
 
 #define DUAL_ENDSTOP_APPLY_STEP(A,V)             \
   if (separate_multi_axis) {                     \

I will create PR for this in a day or so.

from marlin.

Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.

from marlin.

Same problem exists for dual Y (and probably dual X).

Odd since this was working in the last release, and there's no obvious changes in the code around these.

Also odd since the firmware thinks it's moving the axes the whole time.

After doing some debugging, seems like the issue is any time 'set_separate_?_axis(true)' is active.

Ill see about fixing it this week and submit any fixes I find

from marlin.

2.1.2.2 is very buggy and should not be used. List of known 2.1.2.2 bugs and fixes https://github.com/MarlinFirmware/Marlin/issues?q=is%3Aissue+2.1.2.2+in%3Atitle+label%3A%22Bug%3A+Confirmed+!%22+

from marlin.

I need a stable version. Which one would you recommend?

from marlin.

isnt there an option to enable for dual Z stepper endstops, like G34? because doesn't the I3 use this to level the gantry?
https://marlinfw.org/docs/gcode/G034-zsaa.html

from marlin.

The bug (on my board) is still active. After the suggested fixes, the behavior did not change on my Octopus PRO board. bugfix-2.1.x (03.05.2024) did not affect the printer behavior.

from marlin.

Same here on Anycubic i3 Mega P.

2.1.2.1
works fine

2.1.2.2
wrong Z stepping (manual movement is doubled), G28 blocks Z axes and does not move

2.1.x with all proposed fixes applied (pending PRs)
manual movement is fine again, Z homing still blocks

bugfix-2.1.x
works fine (answer updated, did not work in previous tests)

from marlin.

@stklcode

with all proposed fixes applied

What proposed fixes are you referring to?

And please provide your bugfix configs if you also have this issue under bugfix

from marlin.

What proposed fixes are you referring to?

All currently open PRs für 2.1.x
#27020 #27021 #27022 #27023 #27024 #27025 #27026

from marlin.

All currently open PRs für 2.1.x #27020 #27021 #27022 #27023 #27024 #27025 #27026

Those are not for bugfix
Those are fixes for broken 2.1.2.2. ie Marln 2.1.x, not bugfix 2.1.x
Use bugfix code unmodified

from marlin.

Those are not for bugfix

I know. As I wrote before: "2.1.x with all proposed fixes applied" (not "bugfix-").

from marlin.

It was unclear, before you edited it.

from marlin.

Yep, sorry for the confusion.

Just re-tested my configuration and extracted the actual target (Anycubic i3 Mega P with BLTouch and case light - guess the latter is not of any relevance here 😉) on top of the current bugfix-2.1.x branch (eb781af).

=> bugfix-2.1.x works ✔️ (just had a minor config bug with the endstops)
=> 2.1.x still broken ❌

Configs attached:

• config_i3megap_2.1.x.zip
• config_i3megap_bugfix-2.1.x.zip

Console outputs with DEBUG_LEVELING_FEATURE enabled and M111 S32 (on the broken 2.1.x branch)

Home X (G28 X)
Lifts Z axis, and homes X. So far acting normally.

Send: G28 X
Recv: >>> G28  X2.00 Y2.00 Z0.00
Recv: Machine Type: Cartesian
Recv: Probe: BLTOUCH
Recv: Probe Offset X-2.00 Y-25.00 Z-0.40 (Left-Front & Below Nozzle)
Recv: Auto Bed Leveling: BILINEAR (disabled)
Recv: 
Recv: >>> set_bed_leveling_enabled  X2.00 Y2.00 Z0.00
Recv: <<< set_bed_leveling_enabled  X2.00 Y2.00 Z0.00
Recv: Raise Z before homing:
Recv: do_blocking_move_to_z(5.00, 10.00)
Recv: >>> do_blocking_move_to  X2.00 Y2.00 Z0.00
Recv: >  X2.00 Y2.00 Z5.00
Recv: <<< do_blocking_move_to  X2.00 Y2.00 Z5.00
Recv: BLTouch from 90 to 160
Recv: BLTouch from 160 to 90
Recv: >>> homeaxis(X)
Recv: Home Fast: -337.50mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(X, -337.50, [50.00])
[...]
Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: Move Away: 5.00mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(X, 5.00, [50.00])
Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: Re-bump: -10.00mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(X, -10.00, 25.00)
Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: >>> set_axis_is_at_home(X)
Recv: Axis X home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[X] = 0.00
Recv:   current_position= X0.00 Y2.00 Z5.00 :
Recv: <<< set_axis_is_at_home(X)
Recv:   current_position= X0.00 Y2.00 Z5.00 : sync_plan_position
Recv:   current_position= X0.00 Y2.00 Z5.00 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(X)
Recv:   current_position= X2.00 Y2.00 Z5.00 : sync_plan_position
Recv: X:2.00 Y:2.00 Z:5.00 E:0.00 Count X:0 Y:160 Z:2000
Recv: <<< G28  X2.00 Y2.00 Z5.00
Recv: ok

Home Y (G28 Y)
The same as for X, works as expected.

Home Z (G28 Z)

Absolutely no movement on any Z stepper at all. Neither before nor after endstop push.

Send: G28 Z
Recv: >>> G28  X2.00 Y2.00 Z5.00
Recv: Machine Type: Cartesian
Recv: Probe: BLTOUCH
Recv: Probe Offset X-2.00 Y-25.00 Z-0.40 (Left-Front & Below Nozzle)
Recv: Auto Bed Leveling: BILINEAR (disabled)
Recv: 
Recv: >>> set_bed_leveling_enabled  X2.00 Y2.00 Z5.00
Recv: <<< set_bed_leveling_enabled  X2.00 Y2.00 Z5.00
Recv: >>> homeaxis(Z)
Recv: Home Fast: -315.00mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(Z, -315.00, [4.00])

(no movement, just "busy: procwessing" messages)

(maually push Z endstops here)

Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: Move Away: 2.00mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(Z, 2.00, [4.00])
Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: Re-bump: -4.00mm
Recv: >>> do_homing_move  X2.00 Y2.00 Z5.00
Recv: ...(Z, -4.00, 1.00)
Recv: <<< do_homing_move  X2.00 Y2.00 Z5.00
Recv: >>> set_axis_is_at_home(Z)
Recv: *** Z HOMED TO ENDSTOP ***
Recv: Axis Z home_offset = 0.00 position_shift = 0.00
Recv: > home_offset[Z] = 0.00
Recv:   current_position= X2.00 Y2.00 Z0.00 :
Recv: <<< set_axis_is_at_home(Z)
Recv:   current_position= X2.00 Y2.00 Z0.00 : sync_plan_position
Recv:   current_position= X2.00 Y2.00 Z0.00 : > AFTER set_axis_is_at_home
Recv: <<< homeaxis(Z)
Recv: >>> move_z_after_homing  X2.00 Y2.00 Z0.00
Recv: >>> move_z_after_probing  X2.00 Y2.00 Z0.00
Recv: <<< move_z_after_probing  X2.00 Y2.00 Z0.00
Recv: <<< move_z_after_homing  X2.00 Y2.00 Z0.00
Recv:   current_position= X2.00 Y2.00 Z0.00 : sync_plan_position
Recv: X:2.00 Y:2.00 Z:0.00 E:0.00 Count X:160 Y:160 Z:0
Recv: <<< G28  X2.00 Y2.00 Z0.00
Recv: ok
Send: M113 S2
Recv: ok

Endstop detection with M119 looks okay.

from marlin.

same here on bugfix-2.1..x

Just migrated from an older Marlin version while moving Z-home positions from MIN to MAX, nothing in the wiring changed.

Left Z (Z) was using Z_MIN, Right Z (Z2) was using Z_MAX.

When I home Z, both motors spin as expected, only Z2 (aka Z_Max) triggers the home positions.

Enabling the Debug menu, reveals that Z2 endstop (aka Z_MAX) triggers both endstops in the debug display,
while Z_MIN does nothing !

I tripple checked config file, pin config, all seams ok.

Somewhere in the code Z_MIN and Z_MAX are mixed up, but I can not find where... (i mean deeper than the user config files, I dug trough a large portion of the code so far.)

from marlin.

The error only happens when Z -1 is set, on Z 1 both endstops register in the debugger normally.

from marlin.

Solved the problem for my self, Z is now homing using both ent stops and 'leveling' the Z axis.

The problem is when using "Z_Home_Dir 1", with the logical configuration to home_to_Max, it confuses
the end stop pins, by using both Z_Min and Z_Max on the same physical PIN. To circumvent this, I use
"Z_Home_Dir -1" but inverting the "INVERT_Z_DIR true". This is not ideal but seems to work.

I am somewhat confident the problem originates from pins_postprocess.h (around line 552 "HAS_Z_AXIS" and
onwards, but I did not dig deeper yet).

Dual Z-Endstops at Z-Max (Top, not like usual bottom),

Z -> Z_Min (plug)
Z2 -> Z_Max (plug)

Z_Home_Dir -1 (so it homes to Min, but using INVERT_Z_DIR true to achieve this)

Manually defined:
#define Z_MAX_PIN 19
#define Z_MIN_PIN 18

from marlin.

To all those who say they have the same issue. Please attach your Bugfix 2.1.x config files
There could be multiple issues here or just user errors, without configs there is no way to help those who have not provided config files..

Eg I suspect this is what is wrong with SaKiEQ But no configs to confirm

If your board has Z_MIN_PIN and Z_MAX_PIN changing Z homing from Z-Min to Z-Max then Z will use Z-Max and Z2 should be configured to use Z-Min.

I suspect simply defining Z2_STOP_PIN to Z_MIN_PIN in Configuration_adv.h will fix this for you.

While expecting Marlin to guess it for you currently does get it wrong.
Ie

#if HAS_Z_AXIS                                          // true
  #ifdef Z_STOP_PIN                                     // false
    #if Z_HOME_TO_MIN
      #define Z_MIN_PIN Z_STOP_PIN
    #elif Z_HOME_TO_MAX
      #define Z_MAX_PIN Z_STOP_PIN
    #endif
  #elif Z_HOME_TO_MIN                                   // false  
    #define Z_STOP_PIN Z_MIN_PIN
  #elif Z_HOME_TO_MAX                                   // true
    #define Z_STOP_PIN Z_MAX_PIN                        // Z_STOP_PIN is defined as Z_MAX_PIN
  #endif
  #if ENABLED(Z_MULTI_ENDSTOPS) && PIN_EXISTS(Z_STOP)   // true
    #ifndef Z2_STOP_PIN                                 // true
      #define Z2_STOP_PIN Z_STOP_PIN                    // error,  Z2_STOP_PIN should not be set to Z_MAX_PIN
    #endif

from marlin.

I have tagged this issue as bug confirmed for the above code issue, which is present in bugfix 2.1.x

from marlin.

My bad for not including the config. Will add shortly !

The rational of not including the config was, that it was an original config, with only the axis and endstops adjusted, so according to my self - nothing should interfere.

I am not currently on the machine that contains the used file, but will provide it to you as soon as I am back.

Furthermore I made a comparison of older version of Marlin's pins_postprocess.h, there are some minor discrepancies that I had no time to test yet.

from marlin.

Here we go,

Configuration.h
Configuration_adv.h

Comment out lines 1155 and 1556 in Configuration.h to replicate native error.

Hope this helps.

Archive.zip

from marlin.

@SaKiEQ Im confused

Line 1155 is " //#define ENDSTOPPULLDOWN_VMIN"
Line 1556 is " * to avoid collisions during probing."

from marlin.

@SaKiEQ Im confused

Line 1155 is " //#define ENDSTOPPULLDOWN_VMIN" Line 1556 is " * to avoid collisions during probing."

I think my bad - without verifying. My work file has all the heat bed and other features I do not use removed, just items
that would not trigger from a non exiting #define. This mainly so I can find my faster around the file when testing configs... Once completed I merge the work file with original.
It might be that I read by accident the line numbers from the 'redacted' file, not original.

from marlin.

May I suggest a modification to the configuration_adv.h ?

//********************************************************************************************************************
// Multi-Z steppers - your version
// Using X/Y/Z _MAX_PIN's ase _MAX Enstops for Z2, Z3 and Z4 respectively
//********************************************************************************************************************
#ifdef Z2_DRIVER_TYPE
//#define INVERT_Z2_VS_Z_DIR // Z2 direction signal is the opposite of Z

#define Z_MULTI_ENDSTOPS          // Other Z axes have their own endstops

#if ENABLED(Z_MULTI_ENDSTOPS)
	#define Z2_STOP_PIN X_MAX_PIN   // Z2 endstop pin override
	#define Z2_ENDSTOP_ADJUSTMENT 0   // Z2 offset relative to Z endstop
#endif

#ifdef Z3_DRIVER_TYPE
	//#define INVERT_Z3_VS_Z_DIR      // Z3 direction signal is the opposite of Z
		#if ENABLED(Z_MULTI_ENDSTOPS)
		//#define Z3_STOP_PIN Y_MAX_PIN // Z3 endstop pin override
		#define Z3_ENDSTOP_ADJUSTMENT 0 // Z3 offset relative to Z endstop
	#endif
#endif
#ifdef Z4_DRIVER_TYPE
			//#define INVERT_Z4_VS_Z_DIR      // Z4 direction signal is the opposite of Z
		#if ENABLED(Z_MULTI_ENDSTOPS)
			//#define Z4_STOP_PIN Z_MAX_PIN // Z4 endstop pin override
		#define Z4_ENDSTOP_ADJUSTMENT 0 // Z4 offset relative to Z endstop
	#endif
#endif

#endif

//********************************************************************************************************************
// Multi-Z steppers - my suggestion
//********************************************************************************************************************
#define Z_MULTI_ENDSTOPS // Other Z axes have their own endstops

#ifdef Z_MULTI_ENDSTOPS
	#ifdef Z2_DRIVER_TYPE
		#if ENABLED(Z_MULTI_ENDSTOPS)
			//#define INVERT_Z2_VS_Z_DIR        // Z2 direction signal is the opposite of Z
			#define Z2_STOP_PIN X_MAX_PIN   	// Z2 endstop pin override
			#define Z2_ENDSTOP_ADJUSTMENT 0  	// Z2 offset relative to Z endstop
	  	#endif

	#ifdef Z3_DRIVER_TYPE
			//#define INVERT_Z3_VS_Z_DIR      	// Z3 direction signal is the opposite of Z
		#if ENABLED(Z_MULTI_ENDSTOPS)
		  //#define Z3_STOP_PIN Y_MAX_PIN 	// Z3 endstop pin override
		  #define Z3_ENDSTOP_ADJUSTMENT 0 	// Z3 offset relative to Z endstop
		#endif
	  #endif

	  #ifdef Z4_DRIVER_TYPE
		//#define INVERT_Z4_VS_Z_DIR      	// Z4 direction signal is the opposite of Z
		#if ENABLED(Z_MULTI_ENDSTOPS)
		  //#define Z4_STOP_PIN Z_MAX_PIN 	// Z4 endstop pin override
		  #define Z4_ENDSTOP_ADJUSTMENT 0 	// Z4 offset relative to Z endstop
		#endif
	  #endif
	#endif
#endif //Multi Enstops

from marlin.

That wont work.

What if you don't want Z_MULTI_ENDSTOPS (a very common configuration) how can you invert INVERT_Z2_VS_Z_DIR

from marlin.

from marlin.

Everyone here please tests out #27137 (or use my fork of bugfix https://github.com/ellensp/Marlin/tree/auto-endstops)

It doesn't break anything for me on bugfix-2.1.x, but it does not resolve my issue on 2.1.x either. (2 Z steppers and 2 Z_MIN endstops - homing Z does just blocks the axis and does not move)

So I would guess we have two different problems here.

Relevant config excerpt:

#define Z_HOME_DIR -1
#define INVERT_Z_DIR false

#define Z_DRIVER_TYPE  A4988
#define Z2_DRIVER_TYPE A4988

#define Z_MULTI_ENDSTOPS

// Implicitly from TRIGORILLA_MAPPING_I3MEGA
#define Z_STOP_PIN  43
#define Z2_STOP_PIN 18

On bugfix-2.1.x I do not have the issue, even without your patch, so it's likely a different problem. Just need to explicitly add a second config line to invert both endstops.

#define Z_MIN_ENDSTOP_HIT_STATE LOW
#define Z2_MIN_ENDSTOP_HIT_STATE LOW

Trying the equivalent on 2.1.x unfortunately does not change anything.

#define Z_MIN_ENDSTOP_INVERTING true
#define Z2_MIN_ENDSTOP_INVERTING true

(until 2.1.2.1 it actually worked fine without the explicit Z2 line, to that's yet another regression with trivial workaround)

Full configs already attached in previous comment #27014 (comment)

from marlin.

from marlin.

I found out that you cant assign the pins manually in the never versions.

Well, my config works fine in 2.1.2.1 and also in latest bugfix-2.1.x without additional patches. So it’s broken in 2.1.2.2 and 2.1.2.3, but older or newer is okay.

Marlin begins to do odd things, like trigger the two stops at once while only one is actually active.

Triggering does not seem to be my problem. It’s the Z steppers that block, pushing both endstops manually ends the leveling process as expected.

Have you enables Endstop debugging, so you get the live menu or via the M43 command, to test wether the endstops are triggering correctly.

Yes, see previously referenced comment #27014 (comment)

Looks like both endstops are detected correctly, at least in M119 output.

Only difference in pin assignments after postprocessing between 2.1.x and bugfix-2.1.x is that Z_MAX_PIN is defined as -1 in the postprocessor. But commenting out this assignment or explicitly using -1 (either way pin assignments are exactly the same after postprocess) does not make any difference, so that’s not the point either.

I see some stuff going wrong in the endstop assignments (which are taken care of in #27137), but I don’t think we have the same problem.

from marlin.

from marlin.

For my eyes the endstop pins do look just fine. Debugging with M119 gives plausible values and also with pin debugging with M43 E1 seems to report correct behavior on my machine:

Send: M43 E1
Recv: endstop monitor enabled
Recv: ok
Recv:   X_MIN:1  Y_MIN:1  Z_MIN:1  Z2_MIN:1

# push left endstop
Recv:   Z_MIN:0
# release left endstop
Recv:   Z_MIN:1
# push right endstop
Recv:   Z2_MIN:0
# release right endstop
Recv:   Z2_MIN:1
# push both endstops
Recv:   Z_MIN:0  Z2_MIN:0
# release both endstops
Recv:   Z_MIN:1  Z2_MIN:1

(all endstop inputs are active low)

No misassignment, double trigger or similar.

I have tried various combinations of [Z,Z2]_STOP_PIN, [Z,Z2]_MIN_PIN and [X,Z]_MAX_PIN as well without any change.

Z axis just does not move anywhere when homing with G28 Z. I hear and feel Z steppers blocking and when I finally push both endstops, Marlin "thinks" that homing is done and sets Z position to 0.
I skimmed through endstops, motion and G28 routines, but I'm not very deep into this part of the code to see any obvious things here.

from marlin.

Do you have any BLtouch or other leveling sensors configured.

I had some confusing behavior at one point while using the standard config for probe pin.
I switched to a manual pin assignment for the probe pin (pin 40 in my case) and I even have bed leveling
working.

I saw some wild double and tripple engagement of the Z endstops, where one endstop triggered two or 3 in the monitor.
(Z_Max, Z2_Max and Probe), before moving the Z_Min probe outside of the standard config pin range.

Just to confirm, are you also using inverted positioning of the Z endstops, meaning on the top of the frame instead of
bottom ?

If it helps you and you have a similar setup. I am happy to post my config files.

I am running on a Arduino Mega2560, with Ramps 1.4 board. I am using the machine as mini CNC not Printer, but
that should not change anything.

from marlin.

Do you have any BLtouch or other leveling sensors configured.

Yes. I will check this config as well and see if it can be fixed that way.

Probe pins also behave as expected, but I’ll dig down little deeper into the internal assignments.

Just to confirm, are you also using inverted positioning of the Z endstops, meaning on the top of the frame instead of bottom ?

No, 2 Z endstops at the bottom.

If it helps you and you have a similar setup. I am happy to post my config files.

I am running on a Arduino Mega2560, with Ramps 1.4 board. I am using the machine as mini CNC not Printer, but that should not change anything.

You already did or is the previous file out of date?

I’m on an Anycubic i3 Mega P, also with a RAMPS Trigorilla 1.4 board.
1 stepper/endstop each for X/Y, 2 for Z, 1 hotend, 1 laser cutter and a BLTouch probe. (configs attached to some previous answer)

from marlin.

In case you want to see it actually working...
I made a custom bed probe, based on a steel pin (on the right of the spindle), with a magnet on top and hall effect sensor.
It is held in stow position by a magnet, a move to Z and X_Max releases the pin, from where the probing starts.
The sequence show the entire stop, then release, then probe some points.

https://youtu.be/R-i3s8p36n4?si=mPGl7WFlnIsNA3vD

from marlin.

Do you have any BLtouch or other leveling sensors configured.

Yes. I will check this config as well and see if it can be fixed that way.

Probe pins also behave as expected, but I’ll dig down little deeper into the internal assignments.

Just to confirm, are you also using inverted positioning of the Z endstops, meaning on the top of the frame instead of bottom ?

No, 2 Z endstops at the bottom.

If it helps you and you have a similar setup. I am happy to post my config files.
I am running on a Arduino Mega2560, with Ramps 1.4 board. I am using the machine as mini CNC not Printer, but that should not change anything.

You already did or is the previous file out of date?

I’m on an Anycubic i3 Mega P, also with a RAMPS 1.4 board. 1 stepper/endstop for X/Y, 2 for Z, 1 hotend, 1 laser cutter and a BLTouch probe. (configs attached to some previous answer)

My above config would be out of date, since I used the latest version pushed for testing and reconfigured everything to have a clean configuration to report on.

My config contains the cheapo LCD config and some Neopixels, the later should not get in the way, the LCD you might want to disregard since you are running on a different system.

My config with the home position on the top made things very confusing, since the coordinate system still has to remain with Z_MIN at zero on the bed level, so home position is not ZERO ! its in my case +60mm or so. Else bed level / probing would not work, since the probe need to run to ZERO.

Im not on the right computer at the moment, will post the up to date config when i get back.

from marlin.

Here we go. That is the current config that works for my particular setup.

Marlin-auto-endstops Rev_001.zip

from marlin.

Awesome, thank you!

Successfully tested on my machine (Anycubic i3 Mega P, Trigorilla 1.4 board with dual Z setup).
No additional changes required for the pin, seems to work like it should.

btw. nice test rig 😉

from marlin.