Marlin-bugfix-2.0.x: Z_DUAL_STEPPER_DRIVERS, Z_DUAL_ENDSTOPS PROBLEM

[maar1201gh]

When homing and one of Z is triggered, the steppers stop, assuming homing Z is complete.

regards

[thinkyhead]

With recent changes to endstops code, we are seeing a number of glitches. Hopefully we will solve these issues soon.

CC: @ejtagle

[boelle]

i have used this for a while and have never had an issue

maybe @maar1201gh should attach configuration.h and configuration_adv.h as a zip file

[maar1201gh]

My Printer: Corexy D-Bot
board: MKS SBASE 1,3.
This problem exist compiling last version of Marlin 2.0.

I'm using z_dual_endstops for long time even in SMART RAMPS Board with Arduino DUE and everything Ok
I picked version of Marlin from midle of April this year (i think), compile and working very good.
Tomorrow i'll send the files configuration.h and configuration_adv.h, They are in another computer

[maar1201gh]

The configuration.h and configuration_adv.h

configuration files.zip

[thinkyhead]

Thanks, @maar1201gh — I believe your issue does represent a real bug, likely introduced due to recent changes in the endstop code. Perhaps @boelle can also test the latest code to confirm.

I’m looking at probe and endstop issues generally, and perhaps as I track down other issues this one will get fixed as a side-effect. I’ll keep you posted.

[boelle]

I can do so yes. I have an older copy of bugfix 2.0 and i want that working first (should have it done by end of tomorrow)

then i will download latest code and just port over the 2 config files and my ramps pin file as i have done some modding to that

i should be able to report back no later than sunday

[crzcrz]

I can confirm that since May 14 or so this is also broken in _bugfix-1.1.x_. Both Z-motors stop if any of the two endstops is activated. In addition, with PINS_DEBUGGING enabled, the M43 E1 command does not report endstops at all.
I will be glad to do more testing if this is helpful, at the very least I could find the particular commit that broke things.

[boelle]

well i just had to change the stepper on the extruder as the pancake was to weak.

will do a few test prints and then try with latest snapshot of firmware

@thinkyhead what file could tell what date or commit the version i have now is from? or does it not matter that much?

[ejtagle]

@boelle : What is the expected behaviour ? ... Each switch should stop just one motor, and the machine should detect as homed when both endstops are triggered ?

[boelle]

@ejtagle i think you should ask @maar1201gh that instead, he is after all the OP

[ejtagle]

@boelle , @maar1201gh , @crzcrz : I have checked the previous implementation (before the commit 16f92dca445ced48219344bfb4a0dece48941dc5), Previously, the Z axis stopped ONLY when BOTH switches were pressed.

I assume that there is an independant switch for each Z axis. I don´t have a dual Z axis printer, that is why I am asking. Maybe any of you know what is the proper expected behaviour.

So, i am guessing both the previous behaviour and the new one are wrong.

I assume that what it should happen is that only the motor that has its endstop switch triggered has to stop. And the limit must be reported as triggered when both switches are pressed ..,

If there is confirmation of that expected behaviour that i am assuming, i could fix it ... 👍

[maar1201gh]

@ejtagle : Expected behaviour: "Each switch should stop just one motor, and the machine should detect as homed when both endstops are triggered." As you said and i confirm.
I attached foto of my printer. Red circle : Z-endstops, rods 1 per stepper motor

[boelle]

@ejtagle previous behaviour is what i have and that is how @maar1201gh describes it and its the whole idea with dual endstop and dual drivers ie when homing each switch control its stepper. and when both are triggered the machine is homed.

i use it as i got tired of sync'ing the 2 steppers... now its done automatic and far more precise than i can do myself

[boelle]

@ejtagle i asked @thinkyhead if there are any way i can figure how old my copy is so we can figure where things did go wrong

[ejtagle]

I know exactly what happened, and it is my fault. When refactoring the endstop handling code, i found out the strange implementation that said that endstop limits would only trigger if both switches where pressed, but motors would only stop if any were pressed. The strange thing is that ALL motors would be stopped if any switch were pressed.
That did not make sense at all. I changed it to stop on any switch. I know it was not right, but the previous implementation of stopping all motors on any switch press was leading to the conclusion that the reimplementation i did was right
I assume that the previous implementation worked --by accident-- (tm) 👍 , or to be more precise, worked because there was a bug in the code somewhere that made it work... That bug is not there anymore, so a PROPER IMPLEMENTATION must be done now (And i happy to be forcing such change here!) - I will implement the proper behaviour. Probably will be done in a few hours.. 👍

[GMagician]

I'm not completely sure but previous double z motor implementation let have only 1 switch. In that case both stepper stop.
I don't use such cnf, I don't see in which situation it can be useful, but maybe someone does.

[ejtagle]

@maar1201gh : Let´s hope PR #10911 fixes it

[crzcrz]

I will test tonight and let you know.

[maar1201gh]

@ejtagle: Thank you

[crzcrz]

@maar1201gh Why exactly did you close the issue if I may ask?

[crzcrz]

@ejtagle There's an improvement, but it's still not quite right in my opinion. During homing each endstop stops only its respective stepper -- as before things broke a few weeks back -- but then the gantry does not bounce back and re-home as it did before.

To be absolutely clear, I made two very short videos.

This is where it worked for me last, before breaking, bugfix-1.1.x@2ce8047adb30cf70a58f39d828f6804e47a7feb6: https://www.youtube.com/watch?v=VH3alXle4yg
Each axis bounces back after homing and re-homes.

This is PR #10914: https://www.youtube.com/watch?v=CoJGudDf84A
X and Y bounce, Z does not.

(You'll need to watch with sound on to hear the endstops clicking.)

In both cases I have skewed the gantry a bit by turning the right stepper by hand. That's why two clicks in quick succession can be heard when the Z-axis homes.

P.S. M43 E1 still produces no output besides "endstop monitor enabled", which is explainable, as there were no changes in this area in the PR.

[thinkyhead]

@crzcrz — We're seeing a number of side-effects after the endstop code was modified around May 20 - 21, and the issue you're seeing is certainly related to those changes. Can you confirm that your Z dual homing is also broken with 5bb295ef6a71b948eed75c02d71540ebf3664553 from May 21?

I've looked over the dual-Z homing code, and at the lower levels it hasn't changed much. It's supposed to lock the first Z stepper when one endstop is triggered, and then wait until the other endstop has triggered before it considers the homing move to have been completed. Then it's supposed to behave like normal homing procedures, raise up and do a bounce move to re-home. It looks like your Z homing is stopping on the first endstop trigger, and then the firmware is getting confused. At the very least, I would expect the bump logic to continue from there.

To figure out what's going on, let's do some extra logging.

• Download Marlin bugfix-1.1.x or bugfix-2.0.x to test with the latest code.
• Enable DEBUG_LEVELING_FEATURE and re-flash the firmware.
• Connect to your printer from host software such as Cura, Printrun or Repetier Host.
• Issue the command M111 S247 to enable maximum logging.
• Perform a G28 to do your standard homing procedure.
• Copy the log output into a .TXT file and attach it to your next reply.

Hopefully from that we'll get some clue about where Marlin is getting confused.

[crzcrz]

@thinkyhead 5bb295ef6 does not build. There are some warnings and finally a linking error.

Marlin/endstops.cpp:616:0: warning: "TEST_ENDSTOP" redefined
#define TEST_ENDSTOP(ENDSTOP) (TEST(validated_live_state, ENDSTOP))
^
Marlin/endstops.cpp:39:0: note: this is the location of the previous definition
#define TEST_ENDSTOP(ENDSTOP) (TEST(live_state, ENDSTOP))
^

/var/folders/rp/mhg9lnms55z1c36mlj4x6jsr0000gn/T//ccHLpsOT.ltrans18.ltrans.o: In function `TIMER0_COMPB_vect_bottom':
ccHLpsOT.ltrans18.o:(.text+0xbe0): undefined reference to `Endstops::monitor_flag'
ccHLpsOT.ltrans18.o:(.text+0xbf6): undefined reference to `Endstops::monitor()'

I tried M111 S247 with the latest HEAD, but it starts to spit out what looks like a memory dump, stops reacting to commands and completely overflows any terminal I have tried.

Then I did M111 S38. Results are attached.

log.txt

[GMagician]

I tested current 2.0 and double stepper, double switches is working as expected. Down fast, disengage and down slow. Each micro stop its own stepper

[thinkyhead]

@crzcrz — The log seems to indicate that the bump move in your case is stopping without any movement, since the Z position isn't changing (it remains at 0.0).

Move Away:
>>> do_homing_move(Z, 2.00, 0.00 [4.00])
  current_position=(-5.00, 0.00, 0.00) : sync_plan_position
<<< do_homing_move(Z)

Since bugfix-2.0.x seems to be working for @GMagician can you test bugfix-2.0.x to see if it works for you? Maybe there's a discrepancy between the two branches.

[crzcrz]

I just tried bugfix-2.0.x and everything seems to work - Z-axis bounces back and re-homes slowly, M43 E1 correctly reports endstop state changes.

[crzcrz]

@thinkyhead should I create a bug against bugfix-1.1.x?

[thinkyhead]

Should I create a bug against bugfix-1.1.x?

No need. This issue covers it. We'll just do a comparison between the two branches and correct bugfix-1.1.x where it differs from bugfix-2.0.x.

[github-actions[bot]]

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.