Auto_Bed_Leveling with positive Z_PROBE_OFFSET_FROM_EXTRUDER

[Roxy]

I screwed up again. I hit Edit Post instead of reply... And then vBulletin didn't think I should change it back... ARGGHHHH.....


If your configuration.h setting for Z_PROBE_OFFSET_FROM_EXTRUDER is not in the range of 0 to -1 mm you are going to have issues! That's just my gut hunch telling me that!

[regpye]

I screwed up again. I hit Edit Post instead of reply... And then vBulletin didn't think I should change it back... ARGGHHHH.....


If your configuration.h setting for Z_PROBE_OFFSET_FROM_EXTRUDER is not in the range of 0 to -1 mm you are going to have issues! That's just my gut hunch telling me that!

I am using the second to last hardware change with the same software settings. I have a negative offset and it is working fine.

// these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
#define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
#define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
#define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4//

I have the hardware built for the next version with a modified head bracket that uses even less pressure to trigger the probe. I will wire the machine up over the weekend and test again. All the printers to date I am keeping with their own setup so that I can compare the differences. When I find the best of them all I will modify them all to be the same (just a matter of building a new head for them)

What I have noticed is that the nozzle will not lift before homing when I hit a G28. I have overcome that by adding a lift in the slicing code. Lifts OK between probings.

[Roxy]

I am using the second to last hardware change with the same software settings. I have a negative offset and it is working fine.

// these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
#define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
#define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
#define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4//

I have the hardware built for the next version with a modified head bracket that uses even less pressure to trigger the probe. I will wire the machine up over the weekend and test again. All the printers to date I am keeping with their own setup so that I can compare the differences. When I find the best of them all I will modify them all to be the same (just a matter of building a new head for them)

What I have noticed is that the nozzle will not lift before homing when I hit a G28. I have overcome that by adding a lift in the slicing code. Lifts OK between probings.

I believe if you have Z_RAISE_BEFORE_HOMING set to some positive number (in configuration.h) , it will raise that much prior to doing anything. But if we can't get that going the way you want it with Configuration.h settings, we can do a one line patch to make it how you want it.

[regpye]

I believe if you have Z_RAISE_BEFORE_HOMING set to some positive number (in configuration.h) , it will raise that much prior to doing anything. But if we can't get that going the way you want it with Configuration.h settings, we can do a one line patch to make it how you want it.

This is how it bis set now, but I have to lift for homing in the sliced code, it wont lift if I just use a G28.

// these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
#define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
#define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
#define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4// -1.8 -9 -12.35


#define Z_RAISE_BEFORE_HOMING 10 // (in mm) Raise Z before homing (G28) for Probe Clearance.
// Be sure you have this distance over your Z_MAX_POS in case


#define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min


#define Z_RAISE_BEFORE_PROBING 10 //How much the extruder will be raised before traveling to the first probing point.
#define Z_RAISE_BETWEEN_PROBINGS 5 //How much the extruder will be raised when traveling from between next probing points

[Roxy]

OK... I'll take a look at the various G28 code paths in the morning. Do you have SAFE Z HOMING turned on? If you can send your current Configuration.h file that would speed things up for me. The G28 code has a million code paths depending on what is enabled.

[regpye]

OK... I'll take a look at the various G28 code paths in the morning. Do you have SAFE Z HOMING turned on? If you can send your current Configuration.h file that would speed things up for me. The G28 code has a million code paths depending on what is enabled.

I have attached the configuration.h file that I am using/

Configuration.h

[Roxy]

Well... I'm surprised! This isn't the way it is supposed to be. With your options, it is true. It homes the X & Y before it messes with the Z. We need to add a do_blocking_move_relative() to lift the Z at the right time. Please search for the following code block (ignoring the first line which needs to be added). Insert the 1st line you see in front of the code block. That should fix the issue for you.

------------------------

do_blocking_move_relative( 0.0, 0.0, 5.0); <----<<< Add this line just in front of this code block!

if((home_all_axis) || (code_seen(axis_codes[X_AXIS])))
{
#ifdef DUAL_X_CARRIAGE
int tmp_extruder = active_extruder;
extruder_duplication_enabled = false;
active_extruder = !active_extruder;
HOMEAXIS(X);
inactive_extruder_x_pos = current_position[X_AXIS];
active_extruder = tmp_extruder;
HOMEAXIS(X);
// reset state used by the different modes
memcpy(raised_parked_position, current_position, sizeof(raised_parked_position));
delayed_move_time = 0;
active_extruder_parked = true;
#else
HOMEAXIS(X);
#endif
}

if((home_all_axis) || (code_seen(axis_codes[Y_AXIS]))) {
HOMEAXIS(Y);
}

[regpye]

Well... I'm surprised! This isn't the way it is supposed to be. With your options, it is true. It homes the X & Y before it messes with the Z. We need to add a do_blocking_move_relative() to lift the Z at the right time. Please search for the following code block (ignoring the first line which needs to be added). Insert the 1st line you see in front of the code block. That should fix the issue for you.

------------------------

do_blocking_move_relative( 0.0, 0.0, 5.0); <----<<< Add this line just in front of this code block!

if((home_all_axis) || (code_seen(axis_codes[X_AXIS])))
{
#ifdef DUAL_X_CARRIAGE
int tmp_extruder = active_extruder;
extruder_duplication_enabled = false;
active_extruder = !active_extruder;
HOMEAXIS(X);
inactive_extruder_x_pos = current_position[X_AXIS];
active_extruder = tmp_extruder;
HOMEAXIS(X);
// reset state used by the different modes
memcpy(raised_parked_position, current_position, sizeof(raised_parked_position));
delayed_move_time = 0;
active_extruder_parked = true;
#else
HOMEAXIS(X);
#endif
}

if((home_all_axis) || (code_seen(axis_codes[Y_AXIS]))) {
HOMEAXIS(Y);
}

OK, I have done done that and this is what happens now:

G28
Nozzle raises about 10mm
X homes and then moves + about 10mm while Z is moving down at the same time a few mm.
Then X returns back to home position.
Y then homes, Z moving down a few mm at the same time. Z touches the bed briefly and then rises up a few mm, Y homes again (just a few mm to travel)
Z rises a few mm (maybe 5mm) and goes to centre position of bed and then homes, bounces and homes again, lifting to about 10mm.


G29 works perfectly.

[Roxy]

OK, I have done done that and this is what happens now:

G28
Nozzle raises about 10mm
X homes and then moves + about 10mm while Z is moving down at the same time a few mm.
Then X returns back to home position.
Y then homes, Z moving down a few mm at the same time. Z touches the bed briefly and then rises up a few mm, Y homes again (just a few mm to travel)
Z rises a few mm (maybe 5mm) and goes to centre position of bed and then homes, bounces and homes again, lifting to about 10mm.


G29 works perfectly.

I think we better take that new line out of the firmware and just use the manual G-Code command to raise the Z-Axis prior to doing the G28 in the start up code. The current_position[] array is supposed to have everything the do_blocking_move() routines need but it is possible stuff isn't initialized that early in the process.

I've run into this type of behavior before and had to use plan_set_position(), plan_buffer_line() and st_synchronize() together to work around the problem. I'll keep looking at it, but it is safest not have that extra line of code in the firmware until we know why it isn't working.

How disruptive for your users would it be to have a G-Code command to lift the nozzle prior to a G28 command ? I know we can fix the firmware to handle this if we have to, but the problem is it is very difficult to debug these kind of issues when you don't have the actual machine in front of you.

[regpye]

I think we better take that new line out of the firmware and just use the manual G-Code command to raise the Z-Axis prior to doing the G28 in the start up code. The current_position[] array is supposed to have everything the do_blocking_move() routines need but it is possible stuff isn't initialized that early in the process.

I've run into this type of behavior before and had to use plan_set_position(), plan_buffer_line() and st_synchronize() together to work around the problem. I'll keep looking at it, but it is safest not have that extra line of code in the firmware until we know why it isn't working.

How disruptive for your users would it be to have a G-Code command to lift the nozzle prior to a G28 command ? I know we can fix the firmware to handle this if we have to, but the problem is it is very difficult to debug these kind of issues when you don't have the actual machine in front of you.

I am able to add some code when slicing to do the lift, that works fine. Just that everyone would have to use this front end code when slicing each part. If using just the G28 it will drag on the bed before homing and that throws all the calculations out a mile.
I will remove that line and wait for some feedback from you.