Skip to content
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

[BUG] Movement direction issues (Z2 and X) #25785

Closed
1 task done
rondlh opened this issue May 5, 2023 · 13 comments
Closed
1 task done

[BUG] Movement direction issues (Z2 and X) #25785

rondlh opened this issue May 5, 2023 · 13 comments

Comments

@rondlh
Copy link
Contributor

rondlh commented May 5, 2023

Did you test the latest bugfix-2.1.x code?

Yes, and the problem still exists.

Bug Description

After the updates of 2023-05-05 I see different movement direction for Z2 and my X axis doesn't reverse direction anymore.
There might be more issues, but I gave up when I saw this.
It's an IDEX system with i3 design.

Bug Timeline

2023-05-05, 2023-05-03 worked as expected

Expected behavior

Behave like before, correct/unchanged axis movement direction

Actual behavior

Z2 is reversed, X can only move in 1 direction

Steps to Reproduce

Move the axis with G-code, G0 X10, G0 Z1

Version of Marlin Firmware

Lateset bugfix 2023-05-05

Printer model

Custom

Electronics

MKS Monster8 V1.0

Add-ons

BL Touch V3.1, BTT TFT35 V3.0

Bed Leveling

ABL Bilinear mesh

Your Slicer

None

Host Software

None

Don't forget to include

  • A ZIP file containing your Configuration.h and Configuration_adv.h.

Additional information & file uploads

Configuration_adv.zip

@RV-from-be
Copy link

@thinkyhead
I can only confirm this disastrous bug that led to me to the destruction of my belt in X!
The Commit in question is 2538a7c4d6148d8249f5418a76c58ec483343D2B. He takes up the famous PR where we have already told you about major problems of axes control.
On an Ender3 V427, the X and Y axis rides must on the endstops without populations arrest them, stop or reversed the directions. I came back before this commit and everything has become normal again!

@thisiskeithb
Copy link
Member

thisiskeithb commented May 5, 2023

Looks like some changes were reverted: 8425ab0

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

edit: The above commit was force-pushed out of existence, but it'd still be useful to test the latest bugfix since there's been some code changes.

@thinkyhead
Copy link
Member

Sorry about that bug. I pushed the changes from the wrong branch, which still had a union bug in the AxisBits type. I have since pushed the corrected AxisBits from my test setup where the union was fixed, after going through similar axis grinding fun … but thankfully no broken belts.

@thinkyhead thinkyhead added Bug: Confirmed ! Needs: Testing Testing is needed for this change labels May 5, 2023
@rondlh
Copy link
Contributor Author

rondlh commented May 6, 2023

Sorry about that bug. I pushed the changes from the wrong branch, which still had a union bug in the AxisBits type. I have since pushed the corrected AxisBits from my test setup where the union was fixed, after going through similar axis grinding fun … but thankfully no broken belts.

I tested the code after the AxisBits update was undone. X movement now works, but my Z2 is still reversed.
I added:
#define INVERT_Z2_DIR true
Which solved the issue. I previously only had "#define INVERT_Z_DIR true".

Not sure what happened, but if now an undefined INVERT_2Z_DIR defaults to false (I think it should default to INVERT_Z_DIR), then this will cause lots of bend lead screws.

Also homing for (IDEX system) doesn't work correctly, E1 tries to home to the left (should home to the right, to X-max). Again I can correct that by adding INVERT_X2_DIR. Then the direction is correct, but the X2 endstop is not processed correctly and the carriage just slams into the side. I triggered the X1 endstop while homing E1, which also didn't work.
I checked the endstop with M119, which works fine.

UPDATE: X-axis homing issue is solved with update #25780
I did a 3 hour print (2 color IDEX) without issues.

!!! BE CAREFUL, TEST ALL AXIS WITH 0.1MM STEPS FIRST!!!

@thisiskeithb thisiskeithb changed the title [BUG] Latest updates (2023-05-05) cause changed movement direction issues (Z2 and X) [BUG] Movement direction issues (Z2 and X) May 6, 2023
@thisiskeithb
Copy link
Member

thisiskeithb commented May 6, 2023

X movement now works, but my Z2 is still reversed.

Behavior was a bit different for me when I flashed the latest bugfix-2.1.x (4528fde).

Ender-3 with an SKR V3

Independent, dual-Z drivers & motors

After the initial flash, X & Y moved in the correct direction, but all Z movements were reversed (at the same time, so one motor wasn't reversed compared to the other like rondlh).

Biqu B1 SE Plus with an SKR V2

Independent, dual-Z drivers & motors

After the initial flash, X & Y moved in the correct direction, but all Z movements were reversed (at the same time, so one motor wasn't reversed compared to the other like rondlh).

Prusa MK3S+ Bear with a BTT002

Dual-Z motors connected to a single driver

After the initial flash, X & Y moved in the correct direction, but all Z movements were reversed (at the same time, so one motor wasn't reversed compared to the other like rondlh).

In all cases, Z movement is reversed until you home.

After some more reboots, only the initial Z movement is reversed. If you tell Z to go up, it goes down. Then if you tell Z to go down, it goes down and all future Z moves are correct. Homing not required.

@thisiskeithb
Copy link
Member

I've been chatting with thinkyhead and he just pushed 🐛 Apply direction bits at startup / d93aa0c which solves my particular Z movement issues, so maybe they'll help?

@Theo9909
Copy link

Theo9909 commented May 6, 2023

SKR3 Dual Z motors on separate drivers. After initial power on, the Z-axis steppers go in opposite direction. After initial move, they then move in sync. I'll pull the pushes to my git and see what happens. Finger crossed.

@thinkyhead
Copy link
Member

I found two issues that could affect the DIR state and patched them both. If everything is solved, you can go ahead and close this issue.

Mea culpa! Going forward I'll be doing more testing of the upcoming motion and endstop patches and will be sure to refrain from pushing "simple cosmetic updates" when I'm lacking sleep. 💤

@rondlh
Copy link
Contributor Author

rondlh commented May 7, 2023

I found two issues that could affect the DIR state and patched them both. If everything is solved, you can go ahead and close this issue.

Mea culpa! Going forward I'll be doing more testing of the upcoming motion and endstop patches and will be sure to refrain from pushing "simple cosmetic updates" when I'm lacking sleep. 💤

No worries, Marlin has become a very powerful, flexible and complex firmware, issues are bound to happen, that's why there is a bugfix branch. Your efforts are very appreciated!

@thisiskeithb
Copy link
Member

@rondlh: Can this issue be closed?

@Theo9909
Copy link

Theo9909 commented May 7, 2023

Tested on my machine and it works as it should. No more issues with Z right after the machine is first powered on. X and Y function as they should. I second closing it.

@github-actions github-actions bot removed the Needs: Testing Testing is needed for this change label May 7, 2023
@rondlh
Copy link
Contributor Author

rondlh commented May 8, 2023

@rondlh: Can this issue be closed?

Yes!

@github-actions
Copy link

github-actions bot commented Jul 7, 2023

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.

@github-actions github-actions bot locked and limited conversation to collaborators Jul 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants