Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

How does one set up Raise before Retract?

The updated code to do what you want is attached to the first post in this thread. However, depending upon how things work out, you may after do an extra 'optional' step in the directions to fix the G28 command. The G28 is guilty of the same bad behavior and there is a step towards the end of the directions to fix that also.

[wingnut1000]

Hey guys, I've been trying to get auto bed leveling working all day...
Running a Prusa i3v
Followed instructions in here for initial setup.
Got it working but was having the issue with the "Z probe bumping" the bed. Searches led me here.
Configured as I found on the first page and everything is moving now but having a few issues.
1. Initially was having Z probe serve jitters but eliminated this by enabeling PROBE_SERVO_DEACTIVATION_DELAY
2. Servo will occasionally over extend causing it not to line up with the bed. (eg. when deployed it will move to about a 98 degrees instead of 90)
3. Worst though is after I run G28, then G29, the extruder will rise above the bed quite a ways, retract the probe, then lower about half that distance. When the print starts, it is printing about 20mm off the print bed in the air. I cannot find a way to resolve this.
Config.h file is here
Marlin_main.ccp is here
Any help is appreciated.

[RobH2]

When the print starts, it is printing about 20mm off the print bed in the air. I cannot find a way to resolve this.

I had some odd offsets too so here is what I did.

1. Use G28 to 'Home' before autoleveling starts. The probe should extend, go down, touch the glass, tap it again and then move the head up where it will stop.
2. I then connect to the printer with Pronterface and use the 'Z' controls to move the head down manually to a piece of paper. I hit the '-1' button until it get really close and count them. Then I hit the '-.1' button and count those. Each time as I get closer I tug on the paper until it has a little drag. In my experiment I counted 7.4.
3. Put that number you just got into the following line as a negative number:

#define Z_PROBE_OFFSET_FROM_EXTRUDER -7.4

4. Upload that to Ramps
5. Do another G28 to 'Home'
6. Issue a 'G1 Z0' . This should send the head to the glass and leave that tiny "paper thickness" gap. Have your hand on the power switch in case the head goes too far. Now you'll have an idea of the offset.

My first test still left the gap too big so I increased the 7.5 number I counted up by .05. Now the line for me is: (yours will be different...don't use mine)

#define Z_PROBE_OFFSET_FROM_EXTRUDER -7.45

That gave me the perfect gap the next time I did 'G28' followed by 'G1 Z0' . Since then I've been getting perfect 1st layers.

Maybe this will work for you too.

[brainscan]

Hey guys, I've been trying to get auto bed leveling working all day...
Running a Prusa i3v
Followed instructions in here for initial setup.
Got it working but was having the issue with the "Z probe bumping" the bed. Searches led me here.
Configured as I found on the first page and everything is moving now but having a few issues.
1. Initially was having Z probe serve jitters but eliminated this by enabeling PROBE_SERVO_DEACTIVATION_DELAY
2. Servo will occasionally over extend causing it not to line up with the bed. (eg. when deployed it will move to about a 98 degrees instead of 90)
3. Worst though is after I run G28, then G29, the extruder will rise above the bed quite a ways, retract the probe, then lower about half that distance. When the print starts, it is printing about 20mm off the print bed in the air. I cannot find a way to resolve this.
Config.h file is here
Marlin_main.ccp is here
Any help is appreciated.

I had problems with mine air printing after G28/29, my printer thought it was lower than it actually was. When I ran G28/29 then M114 it would report my Z position as -0.78 even though it was 10mm above the bed. After lots of help from Roxy (s)he worked out I had some strange offset stored in my EEPROM. I just had to connect and issue M502 followed by M500 and problem solved. If you've got the same problem I had this might work for you. Good luck.

[Roxy]

As a result of that experience, I wrote a small piece of firmware to invalidate the EEPROM so the setting are not taken from it unless you actually do an implicit store to the EEPROM. I think the original authors of Marlin were trying to save a little firmware space and did not include it. But if you are making changes to your Configuration.h file, it gets annoying having to load the default settings and save them each time. Its easier to just invalidate the EEPROM (with a M499) command:

In Marlin_Main.cpp:

case 499: // Invalidate the M500 Store settings in EEPROM command
{
Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using
// the default values defined in the firmware!
}
break;

In ConfigurationStore.cpp:

void Invalidate_EEPROM_Settings()
{
char bogus_ver[4] = "xyz";
char confirmation[4] = "???";
int i=EEPROM_OFFSET;

EEPROM_WRITE_VAR(i,bogus_ver);

i=EEPROM_OFFSET;
EEPROM_READ_VAR(i,confirmation); //read stored version

if (strncmp(bogus_ver, confirmation,3) == 0)
SERIAL_PROTOCOLLNPGM("EEPROM Settings invalidated.");
else {
SERIAL_PROTOCOLLNPGM("EEPROM Settings not invalidated.");
SERIAL_PROTOCOLPGM("Read Version: [");
SERIAL_PROTOCOL(confirmation);
SERIAL_PROTOCOLLNPGM("]\n");
}
}

In ConfigurationStore.h:
#ifdef EEPROM_SETTINGS
void Invalidate_EEPROM_Settings(); // Roxy routine to guarantee we are using default firmware values
void Config_StoreSettings();
void Config_RetrieveSettings();
#else
FORCE_INLINE void Config_StoreSettings() {}
FORCE_INLINE void Config_RetrieveSettings() { Config_ResetDefault(); Config_PrintSettings(); }
#endif

[brucehvn]

Roxy,

Do you plan on making this a pull request to Marlin so it gets into the codebase permanently?

[Roxy]

Roxy,

Do you plan on making this a pull request to Marlin so it gets into the codebase permanently?

I don't know how to do that. Probably that would be a good thing to do. Can you explain the steps?

[brucehvn]

I don't know how to do that. Probably that would be a good thing to do. Can you explain the steps?

Well, I haven't actually done it myself, but it appears the steps would be:

First you need to have a github account and be signed in.

Next, on the Marlin firmware main page (https://github.com/ErikZalm/Marlin), there's a button in the upper right of the page that says "Fork". Hit this and it will fork a copy of the firmware to your github account.

Make your changes in your copy, commit them, and verify everything works as it should.

Back on the Marlin main page, on the right hand side, there's a link for "Pull Requests" Click on that.

You will see a button "New Pull Request". Hit that.

It gets a little fuzzy at this point because I have nothing to submit, but you should be able to select your fork in your account and make that the pull request.

After that, it's up to the Marlin developers as to when and if they merge your pull request into the main branch.

Bruce

[AbuMaia]

Does anyone have any idea why my Y axis moves a small distance during the "Z lift before homing"? Is the firmware trying to ensure that the Z probe is over the bed instead of in the air? This has been offsetting my Y axis by 10-15 mm each time, making it more likely a large print would go off the other side.

[Roxy]

Does anyone have any idea why my Y axis moves a small distance during the "Z lift before homing"? Is the firmware trying to ensure that the Z probe is over the bed instead of in the air? This has been offsetting my Y axis by 10-15 mm each time, making it more likely a large print would go off the other side.

It would be helpful for you to post your Configuration.h file. It might have something to do with the Z_SAFE_HOMING stuff:

//If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing,
//it is highly recommended you let this Z_SAFE_HOMING enabled!!!

#define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area.
// When defined, it will:
// - Allow Z homing only after X and Y homing AND stepper drivers still enabled
// - If stepper drivers timeout, it will need X and Y homing again before Z homing
// - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
// - Block Z homing only when the probe is outside bed area.

#ifdef Z_SAFE_HOMING

#define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2) // X point for Z homing when homing all axis (G28)
#define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2) // Y point for Z homing when homing all axis (G28)

#endif