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

Y-Homing Crash #16

Closed
Kasperc88 opened this issue Dec 22, 2019 · 9 comments
Closed

Y-Homing Crash #16

Kasperc88 opened this issue Dec 22, 2019 · 9 comments
Labels
solved issue has been solved

Comments

@Kasperc88
Copy link

Sometimes when homing with G28 the printer can't detect the end of the y-axis and therefore the y-motor will keep crashing against the end for 2 - 3 seconds before it finds out its the end.

Turning the power off and on helps. But the issue keep coming back.

@pleumann pleumann mentioned this issue Dec 29, 2019
@michalxfanta
Copy link

Which firmware version (with build number) you use?

@michalxfanta michalxfanta added the awaiting response We need more data. label Jan 7, 2020
@Kasperc88
Copy link
Author

Kasperc88 commented Jan 9, 2020 via email

@mreynolds0404
Copy link

mreynolds0404 commented Jan 10, 2020

I am experiencing Y Axis crash during First Layer Calibration routine on 4.0.1. Video of it happening: https://youtu.be/tiEp1syC6us. Seems like something is also wrong with the second half of the mesh bed leveling (doesn't proceed beyond halfway point of bed). Checked for any physical issues and did not find any. Bed can be manually moved or via Settings through entire range without issue.

@JustAnother1
Copy link

@mreynolds0404 I agree there is something wrong when doing the bed levelling. For some reason the bed does not move after the second line of levelling.

These two issues can be connected. after the "normal" bed levelling the bed would need to move completely back to start printing. Due to the levelling issue the bed is already half way there. Therefore the end stop (or Trinamic sensor in this printer) triggers much too soon. If they have some kind a plausibility check that might override the end stop detection in this case. But that is just my guesswork, haven' t checked the code.

Would be interesting if @Kasperc88 also sees this issue in bed levelling.

@LuckyBenni
Copy link

LuckyBenni commented Jan 14, 2020

I assume the Mini uses less motor current during mesh bed leveling as such lost steps also occured on the X axis several times with my Mini - as well as with the Y axis, but more often with the X axis.

@JustAnother1
Copy link

@LuckyBenni Did you try to move your axis manually? can they be moved easily? If not try to fix that!

My understanding of the trinamic stepper drivers is that they give a feedback of how much current is needed. By adjusting the current to the feedback the motor should always turn and never overheat. But it could be that this signal does not work as well on slow moves.

But then again why would the movement on the bed levelling need that much current?

@LuckyBenni
Copy link

@JustAnother1 I tried moving the axes and apart from the motor resistance there was no special bumps or so that could be felt in both directions. I lubricated the X and Y axes with some machine oil - maybe that improves the situation a bit. But should not be the reason as my printer arrived just before Xmas and did not experience too many hours of printing.

michalrudolf added a commit to michalrudolf/Prusa-Firmware-Buddy that referenced this issue Mar 5, 2020
@ryanpriore
Copy link

I am experiencing Y Axis crash during First Layer Calibration routine on 4.0.1. Video of it happening: https://youtu.be/tiEp1syC6us. Seems like something is also wrong with the second half of the mesh bed leveling (doesn't proceed beyond halfway point of bed). Checked for any physical issues and did not find any. Bed can be manually moved or via Settings through entire range without issue.

I had the exact same issue as you showed in your video. I see that you checked the physical nature of your bed. For me, it was a seized bearing on the single bearing side of the y axis. It became worse in which the printer would try to probe off of the front of the bed so the head would crash.

@JohnnyDeer
Copy link

Hi, G28 is working correct on FW 4.1.0-RC1. MBL issue seem related to HW, please make sure that Y belt is tensed right. I´m closing this issue as solved, because main problem is fixed. If someone will find out more about MBL issue please comment it here #561. Thank you all.

@JohnnyDeer JohnnyDeer added solved issue has been solved and removed awaiting response We need more data. labels Jun 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
solved issue has been solved
Projects
None yet
Development

No branches or pull requests

7 participants