Auto Leveling Crashes Print Head at Third Sample Spot
When doing a nine point auto leveling at the start of a print the print head crashes into the bed after successfully sampling the first two spots. I use Repetier firmware and host on a Tronxy P802MA.
I'm using G28; home all axes (works fine)
Followed by G29; auto level (samples first 2 of 9 spots fine, then drives head into bed at third spot until I hit emergency stop.)
This started after I tried printing from an sd card for the first time (unsuccessfully). I've had no problems printing via usb up to now. I don't need to use the sd card, so I'm trying to get back to using the usb as I did before.
This seems like a software problem. Any suggestions?
I'm using G28; home all axes (works fine)
Followed by G29; auto level (samples first 2 of 9 spots fine, then drives head into bed at third spot until I hit emergency stop.)
This started after I tried printing from an sd card for the first time (unsuccessfully). I've had no problems printing via usb up to now. I don't need to use the sd card, so I'm trying to get back to using the usb as I did before.
This seems like a software problem. Any suggestions?
Comments
Repetier firmware uses G32 for bed levelling or G33 for mesh levelling
Here is my current Configuration.h
From what I see it should have tested -60/60 as thirs point.
Can you post a log of the leveing so we see what printer was doing/trying and make comments on difference to what is says and what it does.
First a bit more information on my hardware. My Mega 2560 is connected via USB to and is powered by my Raspberry PI Zero/W running Repetier Server 0.94.2. My RAMPS 1.4 is connected separately
Here is what I did during the logs.
I plugged in the power supply.
G32
First two touches went well and the third touch did not stop as we expected in this issue.
I pulled the power power to the power supply to stop the nozzle crash and then plugged it back in.
I clicked Home.
G30
First two touches went well and the third touch did not stop as we expected in this issue.
I pulled the power power to the power supply to stop the nozzle crash.
Here are the logs from that time.
19:11:49.963 : wait
Thank you!
7 seconds is not even enough to do the first homing for G32 or am I wrong here?
I expect to see homing then z probe results from 2 points and hopyfully the positions tried by third point that is way off as you say.
Please also check if eeprom has stored same positions as your configuration file. If not that also explains the problem.
https://drive.google.com/file/d/1du95y3XKktyZkjn15kOKR0EmiCtVNSb-/view?usp=sharing
I then set Z_PROBE_REPETITIONS to 1 and made another video. You can see it does not crash the nozzle to the bed till the 3rd point.
https://drive.google.com/file/d/1HOb1OkNIJC6LaZlEY7LiK2VlYMFnCEBc/view?usp=sharing
Here are the logs from the second video. Please let me know if this helps or if you have some other questions that would help.
Also you should reduce z probe speed to increase precision.
I hope that the probe then correctly triggeres on touch.
My wife came up with a great Idea to get more information for troubleshooting this. I tried a different Mega 2560 board. I switched my fake Arduino Mega 2560 R3 for my son's Elegoo Mega 2560 R3 clone. It made the issue worse by making the nozzle crash on the second touch dependably instead of the third touch. This is the first time I have been able to make a change to the issue. Now what we need to figure out is what is different in the two boards and then what we can change in the firmware settings to tolerate a complete G32 auto-level without crashing the nozzle into the bed on any of the touches. What do you think I should try changing? I really appreciate your help!
The thing that troubles me about this issue is that the first two touches work and then it suddenly either it cannot see the signal or it ignores the signal from the BL Touch on the third touch. In most cases I would think either none of the touches would work or all of the touches would fail. My gut feeling is that this is some unexpected hardware limitation of my 2560 boards. But, I cannot prove it nor can I figure out how to work around it. ....yet. What are your next ideas? .... and again, thank you for your help!
M111 S71
first. This enables endstop debugging so every time a end stop change is detected it writes a line. Might crash firmware if it changes too often. But with that you should see when a signal gets detected and that maybe shows that our current assumption that it does not trigger is correct or not. It might also be that the bltouch goes into error mode. It happens if after triggering you go not up fast enough. If you have multiple repetitions make sure it goes up high enough to untrigger the sensor - maybe 10mm. Low values only work with optical or magnetic switches.
I think it has to do with the voltage level which is not that exactly the same each time the probe hits ( tolerance) an this is why your printhead crashes when the level is too low ( on mine it was around 2,9V ) and is not recognized. With the oscilloscope this get visible. Also tried the delay etc.
I checked you config too an I'm not sure if this command is necesssary or causes "something", because I do not use it and it works :
Yours:
#define Z_PROBE_RUN_AFTER_EVERY_PROBE "M340 P0 S2194"
Mine:
#define Z_PROBE_RUN_AFTER_EVERY_PROBE ""
My HW is also 2560 ( recently replaced by original ) with Ramps 1.6 and BL-Touch 3.1 Repetier FW and Server Pro.