Auto bed leveling fails

AstroBox Troubleshooting
#1

Upgraded to v0.92, printer will not run auto bed level routine before prints. Before the upgrade, the gcode steps would:

G28 ; Home extruder (in X and Y, Z at the center of the bed.)
G1 Z20 F100 ; Raise Extruder by 20mm
G29 ; Level Bed

This would normally work and the Z-probe servo would kick the probe arm down and move to first level position (50,50), then proceed to read bed elevations at each of the four points. (pt1 50,50 pt2 100,50 pt3 100,100 pt4 50,100).

What happens now though, The printer homes X and Y, then the Z-probe tries to kick down at 0,0 without moving up the requisite 200mm upward move. Then the printer tries to run the bed level routine all at the same location, 0,0. This would be partially acceptable except for after the pseudo bed level, the extruder then tries to bury itself in the x-endstop.

If I connect the printer to my computer, the auto bed leveling works just fine. All steps are carried out just as normal.

Any help would be appreciated.
Thanks,
Ryan.

#2

Does the GCode file you’re trying to print contain those commands? The box is simply sending what’s on the file to the printer

#3

Thank you for responding Daniel,

The GCode does have those commands. That’s the part that doesn’t make sense to me. Before the v0.92 upgrade the auto bed leveling worked. The same GCode works when the printer is connected to my computer running Repetier-Host V1.6.2.

I also had this printer working like normal last week with this release, but I decided to turn off both the printer and the Pi since I knew I wasn’t going to be printing for a few days. When I turned them back on last night, the bed leveling issue started to happen. I was able to get the printer and the Pi to work before by disconnecting from the Pi and printing from my computer once, then reconnecting to the Pi. It worked like it should until I turned it off and tried last night. I tried that first, but no luck.

An unusual other quirk that I had a workaround for with the previous release.

With Repeteier-Host, when you click the home X or Y axis buttons, the printer will go to either endstop and then back off a few millimeters and then hit the endstop a second time. I’ve called this “bouncing”. Even if you’re at 0,0 the printer will back up a few millimeters and hit the endstop again. With Astrobox, when I click the home X and Y button, the printer just goes to the X and Y endstops. If the printer is at the endstop already, then it will do nothing. This should be fine, but after the printer has buried itself past the X endstop, I have to manually move the X axis back so that it’s not past the endstop.

I know that it’s a minor difference, and it maybe nothing, but I’ve found that when homing X and Y the firmware seems to need the change in endstop state it gets from the “bounce” it gets from hitting the endstop and not just being there.

Before I could start a print, I had to make sure the printer was at least 10mm X 10mm away from 0,0. If I didn’t do that, then the printer wouldn’t home the X and Y axis and what’s happening now would happen then. I added a line to the end of all my GCode to move the print head to 10,10 at whatever elevation the print finished. This way the printer was ready for my next print.

I found out that I also needed to make the print head at least 15mm above the bed and no more than 25mm. For some reason when the printer tried to home the Z-axis before the bed leveling started, the time it took to travel from greater than 25mm caused the bed leveling to not start.

Astrobox works fine with my other printers. They don’t have auto bed leveling, but their beds don’t seem to need the constant re-leveling. I’ve been thinking about re-flashing back to one of the previous releases of Astorbox, but I really like some of the improvements to this release.

Thanks,
Ryan.

#4

Ive seen some of this on my Repetier firmware based delta. Particularly the home bounce thing you mention and it happens not only with astro print.

Any chance you recently updated the printer firmware or tweaked an eeprom value?

My fix as always been to go back through the repetier confiurator starting with a prior working version and then reset the eeprom. I do alot of eeprom tweaking trying to get my delta to run how i like so i usually assume I somehow entered a value that just makes no sense or causes a firmware glutch Possibly careful examination would reveal the tweak that causes the problem but I have been too lazy to do the work.

#5

I’m not using Repetier firmware, Marlin V1.0 I’ve been thinking about upgrading the firmware to the latest, but haven’t had the time to compare all the changes.