ABL Issue with Z raising between G29 probes, etc.

When I have #define Z_RAISE_BETWEEN_PROBINGS 5 defined I get:

SENDING:G29
Eqn coefficients: a: -0.00 b: -0.00 d: 14.55
planeNormal x: 0.00 y: 0.00 z: 1.00

Bed Level Correction Matrix:
1.000000 0.000000 -0.000000
-0.000000 1.000000 -0.000000
0.000000 0.000000 1.000000
echo:endstops hit: Z:14.55

when I change it to #define Z_RAISE_BETWEEN_PROBINGS 10 I get something more along what I would expect.

Eqn coefficients: a: 0.01 b: -0.00 d: 13.72
planeNormal x: -0.01 y: 0.00 z: 1.00

Bed Level Correction Matrix:
0.999956 0.000000 0.009345
0.000004 1.000000 -0.000378
-0.009345 0.000378 0.999956
echo:endstops hit: Z:15.16

In the first case it never raised the Z at all between probes, just dragged it across the bed, sort of tweaking the servo as it went.

On the second case I got more prob locations that lifted up and reprobed, but I am still getting some points where it drags the switch/servo and doesnt lift to reprobe.

Is that the expected movement?

Things I am noticing:

1. When the Z servo retracts, it physically lifts the X axis up and then drops it back down. Is there a way to raise Z before it retracts the servo?

2. When doing a G29, if the heatbed is always level or greater (as in the endswitch never gets free from being down) it does the entire G29 at the same height. Isnt it supposed to probe up and down on each point to see where level is?

i can not print until I get this figured out.

It looks like #define Z_RAISE_BETWEEN_PROBINGS 10 isnt actually doing anything until the bed is level is a negative way.

Quote:

---

Originally Posted by BgHurt

When I have #define Z_RAISE_BETWEEN_PROBINGS 5 defined I get:
...
On the second case I got more prob locations that lifted up and reprobed, but I am still getting some points where it drags the switch/servo and doesnt lift to reprobe.

Is that the expected movement?

---

No.

Quote:

---

Originally Posted by BgHurt

Things I am noticing:
1. When the Z servo retracts, it physically lifts the X axis up and then drops it back down. Is there a way to raise Z before it retracts the servo?

---

This is only an issue for a few people. People that have part of their switch further out than the switches trigger can run into this as it rotates back to the unengaged position. It is fixed in the Enhanced G29 code. Dabc has a fork of Marlin with all the enhanced bed leveling stuff at: https://github.com/beckdac/Marlin I suggest you load that up and see if you like it.

I am at a loss with ABL. I have tried both the dacb and the main Marlin packages.

I can not get Z to lift before z_probe retraction. The code comes with dacb (i have verified Roxy, comparing your code to do the Z_blocking_move_to to the dacb code) , yet doesn't work. I have inserted the code into the regular Marlin package, but both have the same results. The do_blocking_move_to runs. But does not actually move the Z axis. The servo just retracts, lifting the Z axis in the process, and at times blanking my LCD display, resetting the RAMPS due to too much power drain.

I guess I will have to go back to a traditional Z as I can not print at this time with an unreliable Z axis.

Also, a G28 on the dacb is unreliable. sometimes it homes the Z at 0,0, others its in the middle of the heated bed as expected.

Also in the dacb the Z never raises between probes in the 5x5 grid. Just hits Z, and skids across my glass to all locations unless the glass is so far unlevel that the Z gets "un triggered".

The main marlin package works fine for probing though. raises Z as expected between probes. Raises after G29 before retraction, just the G28 doesn't.

trying more things, it appears as though my Z axis will not move when the Z probe is down and the Z endpoint is engaged. So telling it to move does nothing as the Z endpoint is still triggered. When the Z probe retracts, it will then move the Z axis if needed. But by that time, the Z move has already passed by.

Is there a configuration.h setting that I messed up that will not allow the Z to move while the endpoint in triggered?

Quote:

---

Originally Posted by BgHurt

trying more things, it appears as though my Z axis will not move when the Z probe is down and the Z endpoint is engaged. So telling it to move does nothing as the Z endpoint is still triggered. When the Z probe retracts, it will then move the Z axis if needed. But by that time, the Z move has already passed by.

Is there a configuration.h setting that I messed up that will not allow the Z to move while the endpoint in triggered?

---

Good work figuring out it is something else causing the Z to not move!!! I'm wondering if you are taking too much power from your power supply when you have the Z-Probe engaged and that is keeping the Z motors from moving? But here is something that doesn't make sense to me: How can you be probing the bed if the Z axis won't move when the Z-Endpoint is engaged? As soon as it touches the bed, it will freeze and not go up any more? Is that correct?

Any way... I'm glad you figured out that extra information because for sure that is going to be helpful in getting you going.

OH! And there isn't a configuration option to keep the Z axis from moving while the endpoint is triggered. But I could imagine a situation where you have the wrong values for your Z offset and if you have #define DISABLE_MIN_ENDSTOPS commented out... It might not want to move after it sets the Zero point.

Quote:

---

Originally Posted by Roxy

...I'm wondering if you are taking too much power from your power supply when you have the Z-Probe engaged and that is keeping the Z motors from moving?

---

BgHrt, leveraging Roxy's comment a step further... I can't remember which of the ABL threads I've posted this in, but note that ABL printers cannot operate standalone. The lightweight 5V regulator on the MEGA2560 board can't handle the added 5V load of the ABL servo. Be sure you keep the printer connected to a USB source or wire in a dedicated 5V source for the servo to use. The MEGA2560 regulator is bypassed when the printer can get 5V from USB.

EDIT: Yeah, I realize going through the ABL process requires a computer connection anyway. Just trying to spread the knowledge that it's a good idea to keep the USB connection intact.

If I understand the above correctly, you can't do ABL without a computer connection? I understood that one would be necessary to set up the ABL, but thought that once set up, it could all run from the startup code with the computer disconnected. If the computer connection is required while printing, then ABL is probably off the table for me. I can't afford to have my computer sitting at the printer all day. That will be too bad too, as I already invested in the component parts to make it happen.

Quote:

---

Originally Posted by CalifDan

If I understand the above correctly, you can't do ABL without a computer connection? I understood that one would be necessary to set up the ABL, but thought that once set up, it could all run from the startup code with the computer disconnected. If the computer connection is required while printing, then ABL is probably off the table for me. I can't afford to have my computer sitting at the printer all day. That will be too bad too, as I already invested in the component parts to make it happen.

---

Oh, I could be wrong about how the commands are issued. I assumed people were doing the extra commands involved manually through host software. I don't have ABL on my printer - I'm just familiar with the designs of the RAMPS and MEGA2560 boards. What you could do is wire in a small 5V power supply (like an unused wall adapter) as a 5V source for the servo. I'd have to look into how that is done. FYI - details on the analysis of the MEGA2560 regulator limitations is discussed in my build thread at http://3dprintboard.com/showthread.p...ll=1#post28854. A discussion follows after that, including a link into the reprap wiki where this is also discussed.

You can do Auto Bed Level correction from an SD-Card. You just have to have a G28 followed by a G29 in your GCode file.

Roxy,

That was my plan. Is there a problem with running the servo without an additional 5volt circuit as Printbus indicates? I was hoping to clean things up with a Mean Well power supply. If the 5 volts is needed, can I do it with a tap off the Mean Well using a BEC to 5 volts?

I've had no problem. I may have gotten lucky with my servo, but I only have a 12v 30A power supply intended for LED strips (very similar to the MeanWell). No separate 5v available. I've not had any problems with my servo ABL blacking out the printer since I've started using it.

Quote:

---

Originally Posted by CalifDan

Is there a problem with running the servo without an additional 5volt circuit as Printbus indicates? I was hoping to clean things up with a Mean Well power supply. If the 5 volts is needed, can I do it with a tap off the Mean Well using a BEC to 5 volts?

---

FWIW, TopJimmyCrooks is the one that pointed out here that he needed USB power in order for his ABL servo to function properly. I subsequently just did the research to figure out why. Using an R/C type BEC to provide 5V should be fine. Another option would be to plug the printer's USB cable into a USB wall charger when not plugged into a computer. USB is rated for what, 500mA? A USB charger rated for at least that should work.

So i put the latest Dacb/Roxy Marlin on my machine. I added a different micro switch that moves out out of the way without lifting the Z axis as much.

I have a video that shows the first G28 through 3 or 4. Only #2 works properly with the Z_RAISE after the G28 and a M114 show the correct height. After all the others, there is no Z_RAISE, and an M114 still shows the height as if it actually did the Z_RAISE.

Also my G29 fails with a head crash because the Z thinks it is at 22.2 instead of at 7.2. So the servo trys to swing out, and down it goes to the glass.

Also this was a fresh boot up, starting with an M502, and an M500 to read the defaults, and write the defaults.

Not sure what else to try before I just go back to the original firmware.

http://youtu.be/QKvCKOubJgE