Auto_Bed_Leveling: Enhanced G29 command

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

[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

[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

[Roxy]

Sorry for needing the hand holding.

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

I apologize... I was intending to make that change a separate 'Enhancement' and did not get it done yet. I edited in yet-another small change to post #75. Marlin_main.cpp #include's the ConfigurationStore.h file and that is where the invalidate EEPROM command is declared (so Marlin_main.cpp can call it) It is just one extra line in the ConfigurationStore.h file.

Rob, do you know about the M851 command? It has to be turned on in Configuration.h but it lets you very quickly set the Z-Probe offset. It is kind of the opposite of the EEPROM_INVALIDATE stuff. But with that you could figure out the magic number each slicer needs and just have a table where you feed the printer the right number for the slicer you are using prior to starting the print. <---<<< Probably this can be ignored! I see your first layer height numbers were causing some issues.

[RobH2]

I apologize... I was intending to make that change a separate 'Enhancement' and did not get it done yet. I edited in yet-another small change to post #75. Marlin_main.cpp #include's the ConfigurationStore.h file and that is where the invalidate EEPROM command is declared (so Marlin_main.cpp can call it) It is just one extra line in the ConfigurationStore.h file.

Rob, do you know about the M851 command? It has to be turned on in Configuration.h but it lets you very quickly set the Z-Probe offset. It is kind of the opposite of the EEPROM_INVALIDATE stuff. But with that you could figure out the magic number each slicer needs and just have a table where you feed the printer the right number for the slicer you are using prior to starting the print. <---<<< Probably this can be ignored! I see your first layer height numbers were causing some issues.

No problem Roxy, just plugging along. No, I don't know about M851 but will read up on it. Might still be good to know about.

[RobH2]

Excellent Bruce. Doing it now. Will report back. Kudos...

[RobH2]

Nope, not working for me. After I do all the steps, adjust, flash, EEPROM commands and then go to print, my hotend is about 1.5 mm off of the bed in both Cura and Simplify3d. Slic3r in Pronterface is on the bed and preventing extrusion. Hmmmm... I'm at a loss now. I was hoping that Slic3r in Pronterface would be perfect. That's the host I used after I flashed the RAMPS to issue M502 and M500. I expected that it at least would be correct. If I now to into Slic3r in Pronterface, without a print running and do a G28 and then a G1 Z0, it's perfect. But, go to print and it's on the bed with no gap. I don't have an offset for Z in Slic3r. My setting in Slic3r for Z offset is 0mm.

Edit:

Here's a test. See anything odd?

SENDING:G29 n3 T V4
Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.01:
Bed x: 25.00 y: 30.00 z: 7.54
Bed x: 92.00 y: 30.00 z: 6.91
Bed x: 159.00 y: 30.00 z: 6.22
Bed x: 25.00 y: 95.00 z: 7.54
Bed x: 92.00 y: 95.00 z: 6.99
Bed x: 159.00 y: 95.00 z: 6.30
Bed x: 25.00 y: 160.00 z: 7.62
Bed x: 92.00 y: 160.00 z: 7.00
Bed x: 159.00 y: 160.00 z: 6.33
Eqn coefficients: a: -0.01 b: 0.00 d: 7.75
Mean of sampled points: 6.937500

Bed Height Topography:
--0.71750 --0.02950 +0.59850
--0.64125 +0.05500 +0.59825
--0.60875 +0.06675 +0.67850

planeNormal x: 0.01 y: -0.00 z: 1.00

Bed Level Correction Matrix:
0.999954 0.000000 -0.009559
0.000000 1.000000 0.000731
0.009559 -0.000731 0.999954
echo:endstops hit: X:-8.99 Z:6.33

Edit #2: (I manually releveled my bed with the corner bolts/springs and ran the grid again)

SENDING:G29 n3 T V4
Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.01:
Bed x: 25.00 y: 30.00 z: 7.10
Bed x: 92.00 y: 30.00 z: 7.12
Bed x: 159.00 y: 30.00 z: 7.07
Bed x: 25.00 y: 95.00 z: 7.05
Bed x: 92.00 y: 95.00 z: 7.16
Bed x: 159.00 y: 95.00 z: 7.29
Bed x: 25.00 y: 160.00 z: 7.17
Bed x: 92.00 y: 160.00 z: 7.19
Bed x: 159.00 y: 160.00 z: 7.30
Eqn coefficients: a: 0.00 b: 0.00 d: 6.99
Mean of sampled points: 7.159583

Bed Height Topography:
--0.08908 --0.04158 --0.05733
+0.12717 --0.00158 --0.11333
+0.13867 +0.03117 +0.00592

planeNormal x: -0.00 y: -0.00 z: 1.00

Bed Level Correction Matrix:
1.000000 0.000000 0.000850
0.000000 1.000000 0.000933
-0.000850 -0.000933 0.999999
echo:endstops hit: X:-8.96 Z:7.30

[brucehvn]

Ok, so in slic3r, what do you have your first layer height set to? Whatever that is, then look at the gcode generated and see what the first printing G1 command is that sets the Z height. It should be the same as your first layer height. In slic3r there is the regular layer height setting but a separate one for the first layer.

Bruce