Auto_Bed_Leveling: Enhanced G29 command

[RobH2]

Still getting an error when I compile. From Post #75 I'm not real sure where to put this:

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

I put it after:

29: #define EEPROM_READ_VAR(pos, value) _EEPROM_readData(pos, (uint8_t*)&value, sizeof(value))

Here's the error:

Arduino: 1.5.6-r2 (Windows 7), Board: "Arduino Mega or Mega 2560, ATmega2560 (Mega 2560)"

ConfigurationStore.cpp: In function 'void Invalidate_EEPROM_Settings()':
ConfigurationStore.cpp:35: error: 'EEPROM_OFFSET' was not declared in this scope

Edit: I put the snippet for ConfigurationStore.cpp at the end after everything else and it seems to compile. So for now disregard this post.

[Tachout]

I just watched a Solidoodle video and the Autobed Leveling on that checked the bed in 9 places. I watched a video on You Tube stating to check in 3 places. I am going to be putting this in on my Marker Farms i3V and wondered if there was an advantage to taking the numbers in multiple places? I would think it would be more accurate. Opinions?

[Roxy]

3 points is really not enough. The problem is the corner of the bed you did not probe is going to magnify any error in the three points you did measure. Probing 3 x 3 works well, but I do get slightly better results doing a 4 x 4 matrix. I think part of the reason is any error gets more of a chance to be averaged out.

I would suggest printing one of those calibration prints that puts a few large squares down close to the edges of your print bed. You will be able to see if the amount of measurement error you have makes a difference between doing a 3 x 3 or a 4 x 4 probe matrix. If the first layers go down fine either way, it may not be worthwhile to do a 4 x 4 probe on most stuff.

[Roxy]

Rob,

I apologize once again... It shouldn't be this difficult for you! Obviously, the directions aren't good enough!!!

Here are my ConfigurationStore files. You should be able to just lay these down on top of your files and have the same code as me. Let me know if any hiccups happen.

And actually.... The ConfigurationStore.cpp file (that is attached) has an extra line of code that really should be in there. When you print the values using an M503 command, somehow, nobody figured the Z-Probe_Offset needed to be in the displayed data. It really should be there because without that display of data you have no idea what the printer is using. The attached file has that extra variable displayed.

[RobH2]

Hey Roxy. Thanks for this. I'll work on it tonight. No need to apologize. The good will and work you do here is amazing. Don't worry about it all.

[RobH2]

Roxy, files merged. My 'ConfigurationStore.h' was identical and only a few modifications in 'ConfigurationStore.cpp' were necessary. It helped to have yours to analyze. Best part, it compiled perfectly. Will do some tests now and report back. Thanks...


Edit (Reporting Back):
Working perfectly. Very, very nice...!

[DarkAlchemist]

I am not sure what is going on but my G29 is screwy and I only just found it out. I can do a G28 or even a G30 but only with G29 does this happen. What happens is it will go scanning my bed then finish. Alright, but from then on any direction I tell the head to move, via pronterface, makes all axis move simultaneously by that much. When I do a G28, or a G30, the issue disappears. Almost acts as if something is left on that shouldn't be. Any ideas what is going on?

[brucehvn]

I am not sure what is going on but my G29 is screwy and I only just found it out. I can do a G28 or even a G30 but only with G29 does this happen. What happens is it will go scanning my bed then finish. Alright, but from then on any direction I tell the head to move, via pronterface, makes all axis move simultaneously by that much. When I do a G28, or a G30, the issue disappears. Almost acts as if something is left on that shouldn't be. Any ideas what is going on?

Did you install Roxy's enhanced bed levelling code, or are you just using the standard ABL changes to the Configuration.h? If you are using Roxy's code, did ABL work properly before you added the enhancements?

[DarkAlchemist]

Did you install Roxy's enhanced bed levelling code, or are you just using the standard ABL changes to the Configuration.h? If you are using Roxy's code, did ABL work properly before you added the enhancements?

I spotted this issue after I installed his code so I fell back to the original code and it did the exact same thing. Something funky in the G29 coding, that I can't find, and that is not in the G28 or the G30. I went looking to see if could spot something that was possibly left out of G29 from 28 and 30 but no go.

[brucehvn]

I spotted this issue after I installed his code so I fell back to the original code and it did the exact same thing. Something funky in the G29 coding, that I can't find, and that is not in the G28 or the G30. I went looking to see if could spot something that was possibly left out of G29 from 28 and 30 but no go.

Hmm, very strange. You mentioned this issue in Pronterface. Have you actually tried to start a print (that does G29) and does it also move all the axes instead of just one?