[BUG] Dual Z Stepper with dual endstop don't work #27014
Comments
|
Please download |
|
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+ |
|
I need a stable version. Which one would you recommend? |
|
isnt there an option to enable for dual Z stepper endstops, like G34? because doesn't the I3 use this to level the gantry? |
|
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 2.1.2.2 2.1.x with all proposed fixes applied (pending PRs) bugfix-2.1.x |
What proposed fixes are you referring to? And please provide your bugfix configs if you also have this issue under bugfix |
I know. As I wrote before: "2.1.x with all proposed fixes applied" (not "bugfix-"). |
|
It was unclear, before you edited it. |
|
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) Configs attached: Console outputs with Home X ( console outputHome Y ( Home Z ( Absolutely no movement on any Z stepper at all. Neither before nor after endstop push. console outputEndstop detection with
|
thisiskeithb
changed the title
|
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, 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 I am somewhat confident the problem originates from pins_postprocess.h (around line 552 "HAS_Z_AXIS" and Dual Z-Endstops at Z-Max (Top, not like usual bottom), Z -> Z_Min (plug) Z_Home_Dir -1 (so it homes to Min, but using INVERT_Z_DIR true to achieve this) Manually defined:
|
|
To all those who say they have the same issue. Please attach your Bugfix 2.1.x 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. #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 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" |
|
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 |
|
I think my bad - without verifying. My work file has all the heat bed and other features I do not use removed, just items |
|
May I suggest a modification to the configuration_adv.h ? //******************************************************************************************************************** #endif //******************************************************************************************************************** |
|
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.
|
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 18On 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 LOWTrying 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) |
|
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.
|
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.
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.
Yes, see previously referenced comment #27014 (comment) Looks like both endstops are detected correctly, at least in Only difference in pin assignments after postprocessing between 2.1.x and bugfix-2.1.x is that 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.
|
|
For my eyes the endstop pins do look just fine. Debugging with (all endstop inputs are active low) No misassignment, double trigger or similar. I have tried various combinations of Z axis just does not move anywhere when homing with |
|
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 saw some wild double and tripple engagement of the Z endstops, where one endstop triggered two or 3 in the monitor. Just to confirm, are you also using inverted positioning of the Z endstops, meaning on the top of the frame instead of 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 |
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.
No, 2 Z endstops at the bottom.
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. |
|
In case you want to see it actually working... |
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. |
|
Here we go. That is the current config that works for my particular setup. |
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. 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 DetailsIt 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. |
|
Awesome, thank you! Successfully tested on my machine (Anycubic i3 Mega P, Trigorilla 1.4 board with dual Z setup). btw. nice test rig 😉 |
|
cool, will also try against my more complicated setup with the inverted Z. I never went into stepper.cpp, since I thought it was handled in endstops.h I think this is the curse of the macros vs. code, its very hard to dissect and understand for |
|
@ellensp I applied your change and my config still works, so nothing breaks ! Which is great news :). Thanks very much. |
|
This issue has actually not been resolved yet. #27137 is a good start, but the homing misbehavior in 2.1.x still remains until the fix from #27014 (comment) is applied. |
|
Correct #27137 was just some sanity checking and fix bad reallocation of pin when homing to max for bugfix 2.1.x It did not fix Marlin 2.1.2.2 or Marlin 2.1.2.3 or Marlin 2.1.x as It was not meant to. |
|
Marlin 2.1.x has now has this patch applied. 9e02be4 |
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Did you test the latest
bugfix-2.1.xcode?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
Configuration.handConfiguration_adv.h.Additional information & file uploads
Config.zip
The text was updated successfully, but these errors were encountered: