Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

With my ABL I had to also go into Marlin_Main.cpp around line 3210 and do this
else it would not compile. My chit-chat has always been commented out though.

Yeah... It looks like you found a bug! Doing a quick cut & paste of that code was a mistake!

[DarkAlchemist]

Oh! Go search for: static void run_z_probe() {

That will be the function that does the actual Z Probe. There are 3 places in that function where it moves the Nozzle up and down. You will see 3 lines that have feedrate/60 in them. First it moves down to find the bed and then back up. Probably these can be made faster without a problem. But the last one (which is where it is doing the measurement) is definately more accurate at slow speed!

Delta or not didn't you notice that probing was not doing that find the bed first then go up then come back down very slowly? That is what I mean't by how fast it was. I wonder how it works without doing that?

As far as that feedrate I will not be going too low for fear it will crash into the glass since there is lag, however so slight, between a switch triggering and the software reacting to it then the motors reacting to the command to cease.

[Roxy]

Delta or not didn't you notice that probing was not doing that find the bed first then go up then come back down very slowly? That is what I mean't by how fast it was. I wonder how it works without doing that?

I didn't notice that until you mentioned it. They must have removed those first two moves....

As far as that feedrate I will not be going too low for fear it will crash into the glass since there is lag, however so slight, between a switch triggering and the software reacting to it then the motors reacting to the command to cease.

Agreed you want to be careful and not push things too close to the limit. But especially if you use a micro-switch with a roller lever, you get a lot of travel on that kind of switch. The switches fire an interrupt and while it takes time to de-accelerate the motors and reverse them, the point that it is being told to grab should happen pretty quickly. Let us know how much you speed it up and if you had to give up very much accuracy!

[DarkAlchemist]

I still have a weird issue and it is strictly due to 3d printers being so temperamental but I have been printing just fine with the -1.95 but not today as I could lift the print off with my breath so it was horrible. I went directly to the configuration.h file and changed it to -1.97 and no issues. .02mm made that much difference that I have to say that it is insane.

So, how do I get this to not matter as much because having to keep recompiling, and testing different Z probe to nozzle differences that is only off a couple of hundredth of a millimeter difference, is really sucky and just outright bad on the Arduino's flash memory?

[Roxy]

I still have a weird issue and it is strictly due to 3d printers being so temperamental but I have been printing just fine with the -1.95 but not today as I could lift the print off with my breath so it was horrible. I went directly to the configuration.h file and changed it to -1.97 and no issues. .02mm made that much difference that I have to say that it is insane.

Remember how I said "A piece of paper will get you close... But I need to watch it put down the first layer to know where to set things."

One thing I notice early with the Auto Bed Leveling is just having the bed and nozzle up to temperature affected things. So, if you don't already have the Start-Up GCode doing that, it might make sense to have the Bed Probing wait until at least the bed is up to temperature. And maybe it is worth trying waiting until everything is up to temperature.

So, how do I get this to not matter as much because having to keep recompiling, and testing different Z probe to nozzle differences that is only off a couple of hundredth of a millimeter difference, is really sucky and just outright bad on the Arduino's flash memory?

As it turns out... If you go towards the end of the Configuration.h file, there is this stuff:

#define CUSTOM_M_CODES
#ifdef CUSTOM_M_CODES
#define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851

You can turn on a M851 command that will let you just send a command to set the Z-Probe-Offset. And when you find the right number, if you choose to do it, you can save that number in your EEPROM. I just rebuild, and flash my electronics, but this command might make sense for you.

[DarkAlchemist]

My bed is always at full temp before I probe and the hotend gets there as it is probing but that would make no difference with this AFTER I initially did the 1.95 (both were at full temp for that). Remember 2.0 was my first with a paper test then 1.98 after it did a layer but 1.95 was a perfect layer.

My point was that I have been doing just fine until today when it magically shifted by .02mm. Having to do the m114 jog around as I first did but each time would make me throw the printer out the window. The nozzle didn't shift upward on its own so I am stumped.

As far as the m851 goes I am not understanding how that would solve this particular issue where it was all set perfectly but one day decides to change.

[Roxy]

My bed is always at full temp before I probe and the hotend gets there as it is probing but that would make no difference with this AFTER I initially did the 1.95 (both were at full temp for that). Remember 2.0 was my first with a paper test then 1.98 after it did a layer but 1.95 was a perfect layer.

OK. I just thought I would mention it. And really, I don't understand why it makes a difference. It would seem the probe should just measure it and where ever the surface is, it should find it. But I do know it makes a difference.

My point was that I have been doing just fine until today when it magically shifted by .02mm. Having to do the m114 jog around as I first did but each time would make me throw the printer out the window. The nozzle didn't shift upward on its own so I am stumped.

I don't know what to tell you. Did something else change? Like a different roll of filament?

As far as the m851 goes I am not understanding how that would solve this particular issue where it was all set perfectly but one day decides to change.

You expressed disatisfaction with having to re-create the firmware and upload it to make a change. This was an answer to that frustration. But I re-read your post and you were also concerned with harming your EEPROM memory. I kind of doubt that happens. It does wear out, but you get a life span of 10,000 cycles on the cheap EEPROMs. I could look it up, but I'm sure the Arduino is at least that. You are going to wear out your keyboard first!

[sprocket1597]

I have see in the arduino forums mention of 100000 writes

[printbus]

AFAIK, all AVR MEGA chips are spec'd at -
Write/Erase Cycles:10,000 Flash/100,000 EEPROM

[DarkAlchemist]

Good to know.