ABL Issue with Z raising between G29 probes, etc.

[BgHurt]

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?

[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?

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.

[Roxy]

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.

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.

[BgHurt]

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.

[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?

[Roxy]

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.

[printbus]

...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.

[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.

[printbus]

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.

[Roxy]

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.