Closed jamesgao closed 9 years ago
I had the exact same issue, but apparently not everybody encounter it. I fixed the issue and send a pull request.
I tried the latest development branch yesterday and the hotend hits the bed pretty hard still. I know my Z-min sensor works because it's fine with the braddo99 1.0.4 branch. On my printer, G30 pushes pretty hard on the bed to the point of tilting the bed when probing.
I feel your pain, I broke an effector this way. Just to make sure we are talking about the same issue: my hothead was not hitting the bed hard on the first hit but on the second one. The issue was coming from a buffer overflow in the z_probe() function.
My patch fixing it was merged with the Master branch not the Development one so that may explain your issue, and I also got a message that there is one more potential buffer overflow: https://github.com/VisualFox/Marlin/commit/7b101bd76b7d0d954c45a24638ba48d06b705c29#commitcomment-9123376 So that something you may want to check too.
I never used braddo99 fork, but I will give it a try.
Mine is different. On mine it hits the bed hard from the first probe and then pushes so hard at the subsequent points that it actually lifts the bed out of the holders a few millimeters. It's almost as if it is not detecting Z-Min until it pushes a bit past.
@WZ9V then I think that a different issue. I have a Cherry pi III and I use AndyCart's method before running the auto calibration: http://forums.reprap.org/read.php?178,361141,429462#msg-429462 I make sure to do send M502 to reset the printer to its original value, then I set the initial height based on AndyCart's methodology and finally I ran G30 A
Hope that helped
I am currently making some changes to the development build and as a result it may not work correctly at the moment..
I will be releasing a new "Test" build within the next few days based on the dev build, hopefully with most of the bugs fixed :-)
I would advise against using the development build as it may be broken at any point in time as i make changes to it.
I just got impatient and tried it anyway hoping the latest push would work. I'll wait till you say your done. It definitely didn't like my FSR/JohnSL Board for Z-Min. If you need someone with that combo to test I'll give it a shot when your ready.
Sent from my iPad
On Jan 5, 2015, at 11:50 AM, RichCattell notifications@github.com wrote:
I am currently making some changes to the development build and as a result it may not work correctly at the moment..
I will be releasing a new "Test" build within the next few days based on the dev build, hopefully with most of the bugs fixed :-)
I would advise against using the development build as it may be broken at any point in time as i make changes to it.
— Reply to this email directly or view it on GitHub.
I finally got around to trying this out again, and I'm happy to say that the exact bug here is fixed. No more head crashes!
This hasn't converged on a solution yet though, so I'll have to see if it actually fixes my calibration issues. By the way, how does the system decide on the final print scale? It seems like adjusting both the radius and the rod will mess up the print scale.
I'm trying to get autocalibration working, and G30 is causing very nasty head crashes with my machine. Currently, G30 causes this sequence:
Home -> Lower head -> tap once near center -> move positive y -> touch bed multiple times -> move positive y -> smash head into bed and break effector.
I'm pretty sure the endstop switch is working, since it successfully taps the bed multiple times without causing any problems. What is causing these head crashes?