Auto_Bed_Leveling: Enhanced G29 command

[brainscan]

The problem is... I can't find that post with the step by step directions. And if I remember right, it was in some thread that was related, but not actually in one of these sticky threads.

Maybe if the person that typed in those steps sees this message, they can say "Its over here..." ????

Arrrggghhhh! It sucks when you know what you need is within grasp, but you can't quite grab it!!!

Is this it?

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

Page 8 near the bottom.

[Roxy]

SCORE!!! Thanks BrainScan!!!

[brucehvn]

Ha, I was just about to point that out. Brainscan beat me to my own post

[RobH2]

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!
}

If I go and find case 500 so I can put this new case 499 in front of it I'm not sure of the syntax.

I have:
/////////////////////////////////Code Start Paste///////////////////////////////////////////
#if defined(ENABLE_AUTO_BED_LEVELING) && defined(SERVO_ENDSTOPS)
case 401:
{
engage_z_probe(); // Engage Z Servo endstop if available
}
break;

case 402:
{
retract_z_probe(); // Retract Z Servo endstop if enabled
}
break;
#endif
case 500: // M500 Store settings in EEPROM
{
Config_StoreSettings();
}
break;
/////////////////////////////////Code End Paste///////////////////////////////////////////


Does is go like this?

/////////////////////////////////Code Start Paste///////////////////////////////////////////
#if defined(ENABLE_AUTO_BED_LEVELING) && defined(SERVO_ENDSTOPS)
case 401:
{
engage_z_probe(); // Engage Z Servo endstop if available
}
break;

case 402:
{
retract_z_probe(); // Retract Z Servo endstop if enabled
}
break;

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;

#endif
case 500: // M500 Store settings in EEPROM
{
Config_StoreSettings();
}
break;
////////////////////////////Code End Paste///////////////////////////////////////////////////


My reason for asking is it looks like each case gets a 'break;' at the end and your snippet didn't have that.

[Roxy]

Thank You for pointing that out. That was sloppy cutting & pasting.

Yes, each 'case ??:' gets a break normally. That keeps the code from falling through into the next 'case'. Usually (but not always) you want a 'break' after the code for a given case. And certainly for this invalidate code, you want to break after it finishes.

I put the 'break' in the correct place on that post.

[RobH2]

Thanks Roxy for confirming that. I assumed that it would be good to have the break; there. I know just enough code (but learning every day) to Frankenstein it together. I haven't studied programming and just don't understand how to write the logic.

I have autoleveling working well and have gone back over this long thread again. You and brainscan got into a very, very long tweak but for the most part, the very front end of the thread is all that matters for most of us. There is a bit on page 8 that is useful too.

The only problem I have is that once I get my RAMPS flashed from Arduino and I have the perfect offset for my head's Z coordinate (.2mm gap when I issue a G1 Z0), every different slicer treats it differently. I've started an Excel sheet just to track it. I have to adjust the Z offset manually in each and every slicer. In a way it negates the time savings of having autolevel as I now spend an hour with each slicer tweaking the Z offset, testing a print, quitting it, adjusting again, printing, cancelling....you see where I'm going...until I have it. I was wondering why they don't read the configuration.h file correctly?

I wish I could settle on one slicer and be done with it but they all just have behaviors that are beneficial from job to job. I recently bought Simplyify3D and like it but I still get a cleaner print out of KissSlicer, the cleanest printing slicer I've every configured. So, I had Simplify3D all configured and had my Z offset manually tweaked and perfect and I go to print. Well, the print just wasn't clean. So, I stop and go back to Kisslicer. I find that the Z offset is not not correct so I spend an hour to get it correct and get a good print.

Sorry to meander, but my point is, until I can figure out a way to have ALL slicers trust the Z offset from the configuration.h file and know that all slicers will respect it, I'm not garnering any time savings with autolevel. I hope I can solve this as autolevel seems like it can "be the bomb." But for now, it's just as tedious as hand leveling the bed with corner bolts.

[RobH2]

Sorry for needing the hand holding.

When I place the case 499 code in Marlin_main.cpp I get the following compile error:

Marlin_main.cpp: In function 'void process_commands()':
Marlin_main.cpp:3065: error: 'Invalidate_EEPROM_Settings' was not declared in this scope


When I place the void Invalidate_EEPROM_Settings() code in ConfigurationStore.cpp (I don't have Configuration_Store.cpp) I get the following error after the sample code below:

#include "Marlin.h"
#include "planner.h"
#include "temperature.h"
#include "ultralcd.h"
#include "ConfigurationStore.h"

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");
}
}



ERROR:
ConfigurationStore.cpp: In function 'void Invalidate_EEPROM_Settings()':
ConfigurationStore.cpp:11: error: 'EEPROM_OFFSET' was not declared in this scope
ConfigurationStore.cpp:13: error: 'EEPROM_WRITE_VAR' was not declared in this scope
ConfigurationStore.cpp:16: error: 'EEPROM_READ_VAR' was not declared in this scope

[brucehvn]

The only problem I have is that once I get my RAMPS flashed from Arduino and I have the perfect offset for my head's Z coordinate (.2mm gap when I issue a G1 Z0), every different slicer treats it differently. I've started an Excel sheet just to track it. I have to adjust the Z offset manually in each and every slicer. In a way it negates the time savings of having autolevel as I now spend an hour with each slicer tweaking the Z offset, testing a print, quitting it, adjusting again, printing, cancelling....you see where I'm going...until I have it. I was wondering why they don't read the configuration.h file correctly?

I wish I could settle on one slicer and be done with it but they all just have behaviors that are beneficial from job to job. I recently bought Simplyify3D and like it but I still get a cleaner print out of KissSlicer, the cleanest printing slicer I've every configured. So, I had Simplify3D all configured and had my Z offset manually tweaked and perfect and I go to print. Well, the print just wasn't clean. So, I stop and go back to Kisslicer. I find that the Z offset is not not correct so I spend an hour to get it correct and get a good print.

Sorry to meander, but my point is, until I can figure out a way to have ALL slicers trust the Z offset from the configuration.h file and know that all slicers will respect it, I'm not garnering any time savings with autolevel. I hope I can solve this as autolevel seems like it can "be the bomb." But for now, it's just as tedious as hand leveling the bed with corner bolts.

Ok, this doesn't sound right at all. Something else is going on with your system. How much do you need to tweak the Z offset? The slicer should just be setting the initial Z to whatever your first layer height is. So for instance, if your first layer height in slic3r is set to .4, then in the generated gcode, you should see it go to that height (G1 Z0.4) as the first G1 for printing. If you see that, then the slicer is doing what it is supposed to do. After flashing your ramps board, did you do the EEPROM commands to make sure you were using the firmware version of the settings, then save them to EEPROM again? If you don't do that, then the firmware won't automatically adjust your Z offset when issued G1 commands. I'm guessing you did the EEPROM thing, since you say you can issue a G1 Z0.

Also, usually we try to adjust for a .1mm gap (one paper sheet thickness)

Bruce

[RobH2]

Hi Bruce. Maybe I'm not doing the EEPROM commands. I think that's what I'm trying to set up with Roxy's directions on page 8 and my questions above. I suspect that that might be the culprit. Until I hear back from Roxy I'll go ahead and find those EEPROM commands and issue them.

For my normal workflow, what I do is I open my configuration.h file and then go to my printer and to a G29 and then a G28. That 'homes' everything and does an Autolevel. When the autolevel stops, my hotend is sitting there with the probe 'up' waiting to start a print. It should be at the perfect offset distance. I issue a G1 Z0 and the hot end will move down to the bed. If all is good with my configuration.h file, then the head will stop and I'll have that "sheet of paper gap." If it's a hair tight, I go to my configuration.h file and add 1/10th mm to it, do G29 and G28 Z0 again. Most of the time that's it. I close Arduino and I should be good to go. That's I do though. I haven't been issuing and EEPROM commands after the G1 Z0.

So continuing my standard workflow that I just mentioned, I now go to print with say Slic3r, and it's about 2mm high off of the bed. So, I switch to any other slicer, and they too will be off but not the same amount. So, I'm constantly now refining each slicer and it's just gotten way too tedious considering I have autoleveling going.

I think what you are suggesting is that I'm missing a step. Are you saying that I need to issue some EEPROM commands after I flash the RAMPS? I need to find those, I think they are in the 500's if I remember earlier comments in this thread. Let me try that and report back.

[brucehvn]

Hi Bruce. Maybe I'm not doing the EEPROM commands. I think that's what I'm trying to set up with Roxy's directions on page 8 and my questions above. I suspect that that might be the culprit. Until I hear back from Roxy I'll go ahead and find those EEPROM commands and issue them.

For my normal workflow, what I do is I open my configuration.h file and then go to my printer and to a G29 and then a G28. That 'homes' everything and does an Autolevel. When the autolevel stops, my hotend is sitting there with the probe 'up' waiting to start a print. It should be at the perfect offset distance. I issue a G1 Z0 and the hot end will move down to the bed. If all is good with my configuration.h file, then the head will stop and I'll have that "sheet of paper gap." If it's a hair tight, I go to my configuration.h file and add 1/10th mm to it, do G29 and G28 Z0 again. Most of the time that's it. I close Arduino and I should be good to go. That's I do though. I haven't been issuing and EEPROM commands after the G1 Z0.

So continuing my standard workflow that I just mentioned, I now go to print with say Slic3r, and it's about 2mm high off of the bed. So, I switch to any other slicer, and they too will be off but not the same amount. So, I'm constantly now refining each slicer and it's just gotten way too tedious considering I have autoleveling going.

I think what you are suggesting is that I'm missing a step. Are you saying that I need to issue some EEPROM commands after I flash the RAMPS? I need to find those, I think they are in the 500's if I remember earlier comments in this thread. Let me try that and report back.

The EEPROM command should only be necessary if you modify the z offset in the configuration.h file. It shouldn't be necessary every time you home the printer and try to print. The new z offset needs to get stored in EEPROM otherwise it won't be used the next time you start your host software which will read the old value from EEPROM.

So, after you've made modifications to the offset in Configuration.h and reflashed the Marlin firmware, go into your host program and issue a M502 command which resets all setting to what you actually have in Configuration.h. Then issue a M500 command to store the current values back to EEPROM. You don't need to do that again unless you modify the z offset in the Configuration.h (or any other parameters from Configuration.h that are stored in EEPROM).

You should also make sure that your bed or your z axis is not unstable. After you've tweaked your z offset, and you can get the G1 Z0 to be the paper sheet height, then move all your axes around for a bit (without homing), then move everything back to where it was when it homed, issue the G1 Z0 command again and check it. See if you have the same clearance. If that's all good, then maybe do Roxy's probe reliability test to see if your probe is giving you close to the same readings each time.

Bruce