ABL Problems on i3v 8"

[mwyrick]

I have an i3v 8" that I have added clough42's (thingiverse 335632) onto and now I am working on the code. Like most other I ran into problems and have a few questions.
Using a RAMPS with Mega 2560.

The code I am using is https://github.com/beckdac/Marlin on the Marlin_V1 branch checked out a few days ago. I made a few changes as shown in the attached configuration.h file.

EEPROM is disabled
SAFE_HOME is turned on, It can't be off due to the same problems others have that when it is turned off the Y axis will move with the initial Z upwards movement throwing the Y axis off.

This part only deals with G28, Not a following G29.

My first question is should the Z_PROBE_OFFSET_FROM_EXTRUDER have any real world meaning or it it just set to a value that will put the print head where it needs to be. I ask this because I have measured with calipers the real offset from the print nozzle to the switch as 3.9mm (nozzle is higher than the switch). But when following what others do I have to put -7.9 into the configuration.h file to bring it back down to the bed height. I have watched that the G28 code once done finding the "zero" position will raise the Z axis higher than the 5 mm it thinks it was told to move. This is confirmed by measurement after the move and by the number of rotations the Z motors due. The move is 9 mm up, but the code thinks it only moved 5 mm (the Z_RAISE_BEFORE_PROBING) value so after the homing it sets Z to 5mm then adds the -Z_PROBE_OFFSET_FROM_EXTRUDER to that value. The extra 4mm I have to put into the OFFSET lets things "work". I have traced the code and found it does think it is told to move 5mm but looks like the plan_buffer_line code is messing that up. This same code also seems to be what is causing the Y axis to move when the G28 code has not told it to.

So does anyone's offset match the real world offset? After the G28 command, if I raise the Z Axis by 10mm it does indeed go 10mm.

--------

That is only using the G28 command. If I do a G28, then a G29 the 4mm is no longer a problem and my offset matches real world. I would prefer to get the G28 command working on its own so I don't always have to level.

- M

Still working on cleaning this up a little.

[INFO] SENT: G29 V4 T
[INFO] RECV: Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.81:
[INFO] RECV: Full support at http://3dprintboard.com
[INFO] RECV: Bed x: 20.00 y: 20.00 z: 3.44
[INFO] RECV: Bed x: 97.00 y: 20.00 z: 3.62
[INFO] RECV: Bed x: 174.00 y: 20.00 z: 3.65
[INFO] RECV: Bed x: 20.00 y: 97.00 z: 3.56
[INFO] RECV: Bed x: 97.00 y: 97.00 z: 3.70
[INFO] RECV: Bed x: 174.00 y: 97.00 z: 3.69
[INFO] RECV: Bed x: 20.00 y: 174.00 z: 3.63
[INFO] RECV: Bed x: 97.00 y: 174.00 z: 3.70
[INFO] RECV: Bed x: 174.00 y: 174.00 z: 3.66
[INFO] RECV: Eqn coefficients: a: 0.00 b: 0.00 d: 3.49
[INFO] RECV: Mean of sampled points: 3.628222
[INFO] RECV:
[INFO] RECV: Bed Height Topography:
[INFO] RECV: +0.02253 --0.00897 --0.18622
[INFO] RECV: +0.06628 +0.06853 --0.06797
[INFO] RECV: +0.03028 +0.07153 +0.00403
[INFO] RECV:
[INFO] RECV: planeNormal x: -0.00 y: -0.00 z: 1.00
[INFO] RECV:
[INFO] RECV: Bed Level Correction Matrix:
[INFO] RECV: 1.000000 0.000000 0.000799
[INFO] RECV: -0.000000 1.000000 0.000603
[INFO] RECV: -0.000799 -0.000603 1.000000
[INFO] RECV: ok
[INFO] RECV: echo:endstops hit: Z:3.66

[beerdart]

I am experiencing the same issue. I have a few ideas on whats happening but have not investigated yet. My suspicion is the G29 offsets are being storied in the EEPROM and then used for the G28 command until the EERPOM is reset. Again this is just my speculation at this point. I have disabled the ABL and the G28 works as it should for manual leveling.

[mwyrick]

I figured the might be in the EEPROM but I have it turned off. My prints are working as long I do a G28 and G29. I just can't use G28 alone. I am working on fixing it and I am also thinking of putting a goto 0,0,0 at the end of the G28. I feel a HOME should always leave the head at the HOME position which is 0,0,0 like it did before I moved to ABL.

[beerdart]

I agree it would be nice to just use G28 and the stock frame switch in addition to the ABL it would come in handy for many applications. Let me know if you find a solution and ill do the same.

Oh welcome to the boards.

[beerdart]

I would also like to have the frame mounted switch as a fail safe for the servo switch. Not sure if i can use it as Z max on the board or just wire it in series with the Z min.

[mwyrick]

I was thinking the same thing. After crashing the print head several times I will be wiring it in series and the very least but also had the idea of repurposing the Z-Max input pins for the failsafe. I am having an interesting time debugging right now, if I put in SERIAL debug statements I get different behavior from the motors. At one point I got both X and Y to move with the initial Z up movement similar to the extra Y movement when SAFE_HOME is off. Lots of small things are smelling like memory issues. It may take a while to track down. Both my current problems (extra Y movement, and wrong G28 Z position) seem to have been around for the last year based on other posts I have been reading.

[mwyrick]

Making Progress. I have found the G28 command leaves the print head 2*home_retract_mm(axis) too high. If I change Z_HOME_RETRACT_MM I can confirm it is off by 2* the new value. What is interesting is that the last move done to find the final switch close position is:

destination[axis] = 2*home_retract_mm(axis) * axis_home_dir;

It should clear the current_position and destination after this move so I still have to find out why it is moving incorrectly but at least I now have set the Z position to the correct location so my G28 now works.

[beerdart]

Interesting.

[mwyrick]

If you want to give it a try for me, in Marlin_main in the homeaxis function:

FIND:
axis_is_at_home(axis);
destination[axis] = current_position[axis];
feedrate = 0.0;
endstops_hit_on_purpose();
axis_known_position[axis] = true;

Then ADD right after those lines:
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);

The plan_buffer_line move command was thinking it was at -2*Z_HOME_RETRACT_MM and calculated a delta from that location so it always moved the Z up too much. This clears the plan position to match the new homed position. You should see the G28 won't raise the extra 4mm now and for me a G28 then G1 Z0 puts me right back on the bed.

Off to see if this also fixes the extra Y move during non SAFE HOME, My guess is it will.

[mwyrick]

Yup, It also fixes the Y movement while moving the Z Axis during when Z_SAFE_HOME is disabled. Two problems fixed with the one line. Please let me know if it fixes it for you as well and I will create a pull request for it.

- Michael