Marlin
Marlin copied to clipboard
MarlinFirmware
[BUG] Dual Z Stepper with dual endstop don't work
Did you test the latest bugfix-2.1.x code?
Yes, and the problem still exists.
Bug Description
Hello, I have configured Marlin 2.1.2.2. With 2 Z stepper motors and 2 endstops.
The steppers drive manually, but the homing function only works in X and Y. Nothing happens when homing Z.
The endstops respond with M119.
If you move the Z axis manually and press one of the two Z endstops, both steppers stop. But only one stepper should remain standing.
The problem can be found more often on the Internet.
Bug Timeline
Marlin 2.1.2.2
Expected behavior
Each stepper should stop with the corresponding limit switch and the homing function in Z and the homing function of all 3 axes should work
Actual behavior
Z Homing is not possible. When you press a Z endstop, both steppers stop
Steps to Reproduce
No response
Version of Marlin Firmware
2.1.2.2
Printer model
No response
Electronics
BTT SKR V1.3
LCD/Controller
BTT TFT 35
Other add-ons
No response
Bed Leveling
MBL Manual Bed Leveling
Your Slicer
Prusa Slicer
Host Software
OctoPrint
Don't forget to include
- [X] A ZIP file containing your
Configuration.handConfiguration_adv.h.
Additional information & file uploads
Please download bugfix-2.1.x to test with the latest code and let us know if you're still having this issue.
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
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+
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
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.
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)
@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
What proposed fixes are you referring to?
All currently open PRs für 2.1.x #27020 #27021 #27022 #27023 #27024 #27025 #27026
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
Those are not for bugfix
I know. As I wrote before: "2.1.x with all proposed fixes applied" (not "bugfix-").
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 :wink:) on top of the current bugfix-2.1.x branch (eb781afe7b01d510b58abc4f83b767ecc61d6b84).
=> bugfix-2.1.x works :heavy_check_mark: (just had a minor config bug with the endstops) => 2.1.x still broken :x:
Configs attached:
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.
console output
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.
console output
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.
| condition | z_min | z2_min | z_probe |
|---|---|---|---|
| no endstop pushed | open | open | triggered |
| left Z endstop pushed | triggered | open | triggered |
| right Z endstop pushed | open | triggered | triggered |
| both Z endstops pushed | triggered | triggered | triggered |
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.)
The error only happens when Z -1 is set, on Z 1 both endstops register in the debugger normally.
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
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
I have tagged this issue as bug confirmed for the above code issue, which is present in bugfix 2.1.x
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.
Here we go,
Configuration.h Configuration_adv.h
Comment out lines 1155 and 1556 in Configuration.h to replicate native error.
Hope this helps.
@SaKiEQ Im confused
Line 1155 is " //#define ENDSTOPPULLDOWN_VMIN" Line 1556 is " * to avoid collisions during probing."
Everyone here please tests out https://github.com/MarlinFirmware/Marlin/pull/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.
@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.
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
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
Hence you being the expert and me not :)I tested your new version and it seems to work, provided if one rewires the end stops to the given end stop pins. I haven't completed the testing on how probing with a simple switch probe on Z_Min works now.
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 https://github.com/MarlinFirmware/Marlin/issues/27014#issuecomment-2094680432
Ah, I found out that you cant assign the pins manually in the never versions. Marlin begins to do odd things, like trigger the two stops at once while only one is actually active. Provided you are using two endstops on MAX (top, not buttom), two independentMotors. For it to work you need to use:-Z_Endstop #1 on Z_Max_PIN-Z2_Endstop #2 on X_MAX_PINI tried the manual assign thingy, even with disabling the sanity checks. Its either wired the Marlin wants or it wont work. So far mine homes correctly to Z_MAX, reads both endstops and all. Have you enables Endstop debugging, so you get the live menu or via the M43 command, to test wether the endstops are triggering correctly.
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 https://github.com/MarlinFirmware/Marlin/issues/27014#issuecomment-2094680432
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.
I got mine working in the pre _bugfix version too with the manual pin assignment. But that is technically just a temporary and local fix, since I would not be able to update and accommodate future updates to the underlying system. While I am personally a bit sad to see the possibility of manually assigning or overriding pin assignments go, this is most likely what is required to incorporate so many new features and requirements flowing into Marlin.