Bed auto leveling works, but x/y axis are off with correct offset

I'm hoping someone might have an idea or answer to this problem. I technically know what is wrong, but I have no idea how to fix it.

I got my bed auto leveling working about a month ago, but when I first got it going, I was experiencing some bad offset problems. My Z probe offsets were (and still are) throwing off my X and Y axis, however the Z axis is working perfectly. I inverted the figured exactly like I was supposed to, but after auto leveling was done and the print began, it was shifting my X and Y axis exactly the same amount that I had in my configuration.h file for the Z probe offsets in the X and Y axis.

This would make my X 0 actually become X 33 and the Y 0 to become Y -11. So a print that would use the entire 200mm x 200mm bed would cause serious issues. My X carriage was crashing into the X motor mount because of the 33 shift and when trying to print around Y 0, I would experience a crash too. A print that would start around X 2 would start at X 35 because of this 33 offset. I finally figured out the Z probe offsets in the X and Y axis were causing the shift, so to remedy this problem temporary I ended up changing my Z probe offsets in the configuration.h file to 0 for both the X and Y axis, but my -5.7 offset for the Z axis was working perfectly, so I left that alone.

Now my printer is using the entire bed space without the mechanical crashes, but I have noticed that although this has fixed the print offset problem, my auto leveling has been thrown off because of it. Prints are being squished too much around X0-X33, while X167 -X200 are being messed up because the hotend is too far away from the bed. The same problem goes for the Y axis. The auto leveling is not adjusting because it is calculating everything based on thinking that my hotend is in the X and Y position that the actual z probe is. This basically is rendering my bed auto leveling as useless.

If I change the Z probe offsets back to the correct values for the real offset of the X and Y axis my auto leveling becomes accurate, but then I am back to the problem of my bed coordinates being shifted and not being able to use the entire 200mm x 200mm or else face certain mechanical crashing.

Does anyone have any idea at all what could be causing them. I am even open to trying any suggestions that this point because I am out of ideas. Any help would be much appreciated

Attachment 2688.
I have included my configuration.h file just in case it might help. This is the current configuration I use to NOT experience the crashing but the auto leveling is bad off because of the 0 X and Y Z probe offset.

Almost forgot, the printer is an I3, not an I3V

So even though this issue has me stumped, I've still been trying to find a fix or way around this problem. Last night I reentered the correct z probe offsets which are X:32.6 Y:8.1 Z:-5.7. I noticed that when I enter a G28, the X and Y axis will home to 0,0 but as soon as the z probe lowers and touches the bed to zero, then those figures are changed from zero to the opposite of my z probe x/y offsets. After the G28, M114 gave me X:-33.00 Y:-8.00 Z:5.70. I can't seem to figure out why the Z offset works perfectly which is normally most peoples issue, but the x and y offsets are throwing everything off. So out of desperation, I tried doing G28 X0 Y0 and then afterwards a G28 Z0 and then G28 X0 Y0 again. A M114 confirmed afterwards X:0.00 Y:0.00 Z:5.70. I got super excited thinking I found a way around my problem...until I tried G29. As soon as the z probe was about to touch the bed it threw everything back off to X:-33 Y:-8.

I tried searching the web for anyone who has experienced x/y offset problems with bed auto leveling but all I could come up with is people experiencing z offset issues.

How many other changes do you have to the firmware? Would it make sense to start with a working, known good code base and move your values to that?

I do have a number of changes in the configuration.h file and I thought the same thing might be possible. I figured I could have messed up something in the configuration.h file while updating my firmware to one that had bed auto leveling, since the firmware version that came with my printer from Markerfarm did not include bed auto leveling. Last night I also downloaded the latest update for Marlin and tried to change the configuration.h file to the values that the stock Makerfarm firmware has, aside from enabling the bed auto leveling feature and enabling the servo. I got the same issues with trying that route. I'm not ruling out the possibility that I still messed something up though.

I wish i could get a hold someone's version of Marlin with working bed auto leveling and then just go in there and change the values for my servo retraction angle and my particular z probe offsets and see if that would work.

In this post, I have a diff file for my config with working auto bed level, calibrated to my extruder and Auto Bed Leveling (ABL) probing mechanism. This is for Marlin as cloned from GitHub on 9/7/14.

HOWEVER, don't use it without calibrating your E-steps (see ZennmasterM's video here: https://www.youtube.com/watch?v=w_Wb0i0-Qvo ) and some parameters for the ABL system, including the servo foot pulse width for extend and retract and the Z-offset from the probe-to-tip. Also, disable the software safe on travel beyond endstops. Really, see this ZennmasterM video ( https://www.youtube.com/watch?v=6msLOR_EfKc ) and read his blog.

This is an archive of my current Marlin including the Configuration.h. Use at your own risk!
Attachment 2696

Quote:

---

Originally Posted by Pronus

I wish i could get a hold someone's version of Marlin with working bed auto leveling and then just go in there and change the values for my servo retraction angle and my particular z probe offsets and see if that would work.

---

Dacb beat me to it. I just crossed all of my stuff over to the latest Marlin code base. There is a small bug in the current Marlin code base and some of the new Probe Sled stuff is missing a conditional #ifdef to turn it off. That is fixed in mine but if you grab the latest from GitHub you may hit that. Other stuff has changed too.

It is difficult to help somebody if you are not sharing an identical code base. Let's see if you can get your values crossed over to Dacb's code-base and see what happens. If that doesn't work out, we can try the same approach with my code base. But in the mean time, why don't you post your Configuration.h file so we can do a quick scan of it and see if anything obvious is wrong with it.

Actually... Why don't you .ZIP up the whole thing and post it. The problem you are talking about kind of feels like a few lines of code got accidentally deleted. It really doesn't feel like a Configuration.h file problem if that makes any sense.

Roxy is right, in the current Marlin clone, there were sled #ifdefs I had to add to get it to compile. They are included in my archive above.

Aside: Roxy, are your mods to raise the carriage before retracting the probe and leaving the probe down during leveling integrated back into the Marling main codebase? I'd really like those features.

Quote:

---

Originally Posted by dacb

Roxy is right, in the current Marlin clone, there were sled #ifdefs I had to add to get it to compile. They are included in my archive above.

Aside: Roxy, are your mods to raise the carriage before retracting the probe and leaving the probe down during leveling integrated back into the Marlin main code-base? I'd really like those features.

---

I do not believe they are. I was trying to get setup to submit the Enhanced G29 command and that was the reason for moving to the current code base. The only thing submitted and accepted so far is the M48 Z-Probe Repeatability Test.

Here is an archive file with my stuff moved to the current code base. If you use it, you will need to modify Pins.h and Configuration.h for your setup. If you have an UltiPanel, you will need to delete a couple of functions up at the top that facilitate the M600 filament change command. Other than that... I think it will compile and work. (Famous last words!!!) If Dacb decides to migrate to this code base, it would make sense for Pronus to move there also. That way we all would have the same code base and it would not be too difficult to get Pronus up and running.

I've printed a couple of parts and everything seems correct and working. However, I think there is an extra Raise Z After Probe at the end of the G29. I'm not sure. It doesn't hurt anything, but the updated Marlin code-base seemed to have some of those issues addressed and right now there might be an extra raise that needs to be pulled out. If so... I'm pretty sure it is just a matter of deleting 1 line of code but I haven't dealt with that yet.

I really appreciate all of the help.

Dacb, I guess I should have mentioned it, but I have been following Zennmaster's youtube videos and blog even before I had the printer and "thought" I followed everything in both his videos and blog to a T with the bed auto leveling. I've messed with the configuration.h file so many times that I'm actually understanding a large portion of it now which I guess is one of the positives of running into this issue :)

Dacb, I downloaded your version of Marlin and the only things that I changed in the configuration.h file was my extruder e-steps, bed size (I have an 8 inch), hotend max temp (I have a J-head), the probing points for auto leveling, my z-probe offsets, and my servo endstop angles.

I noticed however in that version of Marlin, that there was no Marlin.pde file that I normally use to upload the firmware with the Arduino software. I ended up just copying my .pde file over to compile it.(I hope that was ok because I'm not really sure how else to remedy that issue)

I noticed a few changes in the behavior of the printer like my servo shaking like crazy so I did go back and turn on #define PROBE_SERVO_DEACTIVATION_DELAY 300 like I had in my configuration.h file.

G28 worked great, and when I tried G29, right after the x carriage raised and dropped down the z-probe, I noticed on the LCD screen that I was right back to the same x-33 y-8 which are the values of my z-probe offsets to the hotend. The z-probe z axis offset however is still working great like it did in my version of Marlin and configuration. I confirmed this after the auto leveling was done with a G1 F1500 X0 Y0 and noticed same offset that I keep experiencing.

I'm going to try your version Roxy, but I was wondering if I could get some more information about how I should modify the pin.h because I have zero experience with messing with that. I'm going to go ahead and download your 9-15-2014-work copy.rar and see if I can't get that going. I was really hoping that Dacb's version was going to fix my issues because I was assuming it was a problem in my configuration.h. I feel more confused to why this I am experiencing this issue now more than ever lol.

Attachment 2701

I almost forgot, here is the version of Marlin that I was using with my configurations. I did notice a few differences with mine and Dacb's in the configuration.h file in regards to endstop pullups and a few other things, but they must not be the cause of my issue since Dacb's version and configuration is still creating the same offset issue for me.

Roxy, I've been working on the configuration.h file of your 9-15-2014-Work Copy.rar, but when I got to a certain area it was so different than any other configuration.h file that I have ever messed with, that it just completely when over my head.

the part that has me confused and/or confused is about I'll paste below
-----------------------------------------------------------------
//===========================CALIBRATION PARAMETERS==========================
//================================================== =========================
// Formula for X and Y steps per mm = [(Number of Motor Steps per Revolution)*(1/(microstepping ratio)]/(BeltPitch*ToothCount)
// Formula for Z steps per mm = (Motor Steps per revolution)*(1/(microstepping ratio)/(Vertical Movement per revolution) where Vert. Movement per revolution = 1.25mm for directly driven M8 rods on Prusa
// Formula for Extruder steps per mm = [(PackingDensity)*(Number of Motor Steps per Revolution)*(Gear Ratio of Extruder)*(1/(microstepping ratio)]/(pi*(Diamter of Hobbed Bolt or Pinch Wheel))
// -Equation based on: http://www.brokentoaster.com/blog/?p=358 and http://hydraraptor.blogspot.com/2011...flow-rate.html
// -The term ((NozzleDiameter^2)/(ExtrudedFilamentDiamter^2) from the above articles is consolidated to the term "PackingDensity"
// INSTRUCTIONS: ENTER PARAMETERS BELOW FOR YOUR EQUIPMENT.
#define MICROSTEPPING_RATIO 0.0625 // Enter microstepping ratio of electronics. Printrboard and Pololu = 1/16, Gen6 = 1/8, etc.
#define XY_MTR_STPS 200 // Enter number of steps per one revolution of the X and Y motors. See motor datasheet, 1.8degree = 200 steps, 0.9degree = 400 steps
#define Z_MTR_STPS 200 // Enter number of steps per one revolution of the Z motor(s). Print calibration cube of 10-20mm to compute xyz steps
//#define EXTRUDER_MTR_STPS 200 // Mark 100mm length on filament. Measure length needed in software to extrude 100mm. 110mm(software)/100mm(physical)*200=220steps

#define EXTRUDER_MTR_STPS 200 // EDN hack to get edges of fill to smoosh together.


#define PACKING_DENSITY 1.0 // Leave at 1.0 and adjust in Skeinforge 40+. Alternatively, leave at 1.0 in Skeinforge and calculate manually: Packing_Density = (NozzleDiameter^2)/(Measured_Extruded_Filament_Diamter^2)
#define BOLT_DIAMETER 8 // Enter measured diameter of hobbed bolt or pinch wheel



//#define EXTRUDER_GEAR_RATIO 49/15 // Enter gear ratio of extruder. Wade's Extruder: 39/11, Accessible Wade's by Greg Frost: 43/10, Adrian's Extruder: 59/11, etc.
#define EXTRUDER_GEAR_RATIO 75.0/9.0 // Hacked by Roxy for low gear ratio gears with 53mm spacing


#define BELT_PITCH 2.5 // Enter pitch of X and Y belts in millimeters (space from tooth to tooth). XL belts = 5.08mm
#define GEAR_TEETH 16 // Enter number of teeth on X and Y gears
#define Z_ROD_PITCH 1.05833333333 // Enter pitch of Z rods in millimeters. Pitch = 1.25mm for directly driven M8 rods, 1.41111111mm for directly driven 5/16-18 rods.
// ************* End MECHANICAL Calibration *************

// default settings

#define PI 3.14159265359
#define DEFAULT_AXIS_STEPS_PER_UNIT {((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((Z_MTR_STPS/MICROSTEPPING_RATIO)/Z_ROD_PITCH),((PACKING_DENSITY*EXTRUDER_MTR_STPS*E XTRUDER_GEAR_RATIO*(1/MICROSTEPPING_RATIO))/(PI*BOLT_DIAMETER))}


-------------------------------------------------------------------------

I'm completely a newb when it comes to motor stepping and motor specs/belt pithces and what not. Any idea what I could enter for these values or where I could teach myself in order to better understand how to configure this part?

Quote:

---

Originally Posted by Pronus

I really appreciate all of the help.
I noticed however in that version of Marlin, that there was no Marlin.pde file that I normally use to upload the firmware with the Arduino software. I ended up just copying my .pde file over to compile it.(I hope that was ok because I'm not really sure how else to remedy that issue)

---

The .ini and .pde files switched between Arduino v.022 and Arduino v1.05 If everything compiles clean, you are good to go. But I suggest you download and install the v1.05 because some compiler bugs have been fixed in that version and right now you don't need extra variables when things don't work.

Quote:

---

Originally Posted by Pronus

I'm going to try your version Roxy, but I was wondering if I could get some more information about how I should modify the pin.h because I have zero experience with messing with that. I'm going to go ahead and download your 9-15-2014-work copy.rar and see if I can't get that going. I was really hoping that Dacb's version was going to fix my issues because I was assuming it was a problem in my configuration.h. I feel more confused to why this I am experiencing this issue now more than ever lol.

---

Just take the stock, generic Pins.h from just about any Marlin release and replace that file in my version. I have a few extra things defined in my Pins.h and some stuff moved around to be on different GPIO pins. You don't want my changes. They are for my hardware setup. That is the only reason I pointed out that Pins.h was different so nobody would assume the generic #define's were there.

Quote:

---

Originally Posted by Pronus

I almost forgot, here is the version of Marlin that I was using with my configurations. I did notice a few differences with mine and Dacb's in the configuration.h file in regards to endstop pullups and a few other things, but they must not be the cause of my issue since Dacb's version and configuration is still creating the same offset issue for me.

---

This is valuable information!

Quote:

---

Originally Posted by Pronus

Roxy, I've been working on my configuration.h file for your 9-15-2014-Work Copy.rar, but when I got to a certain area it was so different than any other configuration.h file that I have ever messed with, that it just completely when over my head.

the part that has me confused and/or confused is about I'll paste below
-----------------------------------------------------------------
//===========================CALIBRATION PARAMETERS==========================
//================================================== =========================
...
#define DEFAULT_AXIS_STEPS_PER_UNIT {((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((XY_MTR_STPS/MICROSTEPPING_RATIO)/(BELT_PITCH*GEAR_TEETH)), ((Z_MTR_STPS/MICROSTEPPING_RATIO)/Z_ROD_PITCH),((PACKING_DENSITY*EXTRUDER_MTR_STPS*E XTRUDER_GEAR_RATIO*(1/MICROSTEPPING_RATIO))/(PI*BOLT_DIAMETER))}

---

Don't be scared of that stuff... Just delete it. All of that stuff is so that last line

#define DEFAULT_AXIS_STEPS_PER_UNIT

has the right numbers in it. I have symbolic values that get used in the calculation instead of just having final hard coded values there. Just put what ever your Configuration.h file's #define DEFAULT_AXIS_STEPS_PER_UNIT line is into the file to replace the stuff that is there.

Quote:

---

Originally Posted by Pronus

I'm completely a newb when it comes to motor stepping and motor specs/belt pithces and what not. Any idea what I could enter for these values or where I could teach myself in order to better understand how to configure this part?

---

Well... For now delete that stuff up above and replace it with your hard coded numbers. But if you print out that section, you can walk through the calculations and see how those numbers are generated. Probably, my final numbers are not too far off from what yours are. But the point is with my setup I can change any one component and the correct numbers will get generated. For example, I could change my belt pitch and put the new number in there and in theory, my printer will stay calibrated.

Ok, so I updated to Arduino v1.05. Swapped out the pin.h file. Finished up the configuration.h file like you said by just entering my hard coded numbers instead of the equations and then uploaded it to my board.

I can totally tell a difference in how the printer acts with a G28 and G29 (I actually like it's behavior better now) however, I'm still getting the exact same offset issues on the x/y axis. Of course though, the z axis is working great as it has been. I'm having a hard time understanding how I could be experiencing this problem especially after using someone elses code that is seemingly working.

BTW, I love the idea of changing one variable or component to generate the right numbers for the stepper motors. I definitely plan on educating myself further in order to better understand every little component of the printer and how it relates to axis steps per unit and etc. The plus side of having issues with the printer has granted me some much need knowledge about how it works.

Quote:

---

Originally Posted by Pronus

Ok, so I updated to Arduino v1.05. Swapped out the pin.h file. Finished up the configuration.h file like you said by just entering my hard coded numbers instead of the equations and then uploaded it to my board.

I can totally tell a difference in how the printer acts with a G28 and G29 (I actually like it's behavior better now) however, I'm still getting the exact same offset issues on the x/y axis. Of course though, the z axis is working great as it has been. I'm having a hard time understanding how I could be experiencing this problem especially after using someone elses code that is seemingly working.

BTW, I love the idea of changing one variable or component to generate the right numbers for the stepper motors. I definitely plan on educating myself further in order to better understand every little component of the printer and how it relates to axis steps per unit and etc. The plus side of having issues with the printer has granted me some much need knowledge about how it works.

---

OK, Please upload your Configuration.h and Configuration_adv.h file. Almost for sure the problem is there. And if it isn't we can start adding lines of debug code to figure out why things are going sour. But please be aware... If we have to go the debug code route... It maybe 3 or 4 days until you have closure.

Attachment 2702Attachment 2703
Ok, here are both of the files. I really hope it comes down to me just messing something out in the configuration.h file

Thanks again

I don't see anything crazy in the Configuration files. I do question if you should have the pull up resistors turned off. I think you should check into that. But that isn't the problem you are fighting right now.

Can you do a M502 and post what it says. And then do a M499 and reset your printer and see if it is still misbehaving.

If it is, then turn off these lines in the Configuration.h file:

//#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: c
omment this out:
// please keep turned on if you can.
//#define EEPROM_CHITCHAT

I realized when I put together the configuration.h to match your code base, that I enabled EEPROM_SETTINGS and adjusted my pull up resistors to be turned off because I was matching those of Dacb's configuration file since he had working auto bed leveling. Those were the only figures that I seemed to question that were different than my own configuration.h. (especially the pull up settings)well of course other than his different bed size, nozzle temps, servo endstop angles, and z-probe offsets. After enabling the EEPROM I did try to revert back to the default with a M502 just to see if it would make a difference.

Anyways, I just tried it again

>>>m502
SENDING:M502
echo:Hardcoded Default Settings Loaded

and am still experiencing the same issues, so after turning them off and trying to upload to the board with the Arduino software I recieved an error:

It highlighted: Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using

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

I can validate however, in the version I was previously using of Marlin I always had my EEPROM settings turned off and was still experiencing the issue.

Quote:

---

Originally Posted by Pronus

I realized when I put together the configuration.h to match your code base, that I enabled EEPROM_SETTINGS and adjusted my pull up resistors to be turned off because I was matching those of Dacb's configuration file since he had working auto bed leveling. Those were the only figures that I seemed to question that were different than my own configuration.h. (especially the pull up settings)well of course other than his different bed size, nozzle temps, servo endstop angles, and z-probe offsets. After enabling the EEPROM I did try to revert back to the default with a M502 just to see if it would make a difference.

---

I don't know what the correct settings are for the MakerFarm printers, but the Auto Bed Leveling should not factor into the end stop pull up resistors. (at least for the X & Y) They should be what ever other MakerFarm people are using. However, your printer is stopping at the end stops so what ever you have is not seriously wrong if it is wrong at all.

Quote:

---

Originally Posted by Pronus

Anyways, I just tried it again

>>>m502
SENDING:M502
echo:Hardcoded Default Settings Loaded

and am still experiencing the same issues, so after turning them off and trying to upload to the board with the Arduino software I recieved an error:

It highlighted: Invalidate_EEPROM_Settings(); // Roxy added function to guarintee we are using

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

I can validate however, in the version I was previously using of Marlin I always had my EEPROM settings turned off and was still experiencing the issue.

---

There was a small bug in the ConfigurationStore.h file. There is was a missing declaration for the case where EEPROM stuff is turned off. Please replace the existing ConfigurationStore.h file with this one. And then go back and see if you can do what the previous post requested.

Ok, I replaced the configurationstore.h file with the new one and everything compiled and uploaded good. I ran my same routine G28, then G29, and then G1 F1500 X0 Y0 and I'm still noticing the exact same offset problem. I was kind of hoping I just messed up my configuration.h file so I wouldn't take up anymore of your time, but it doesn't seem like I got that lucky. I know the problem isn't fixed yet but thank you so much for trying. Without help I would be more than lost at this point over it.

M502 currently says "Hard coded Default Settings Loaded." now?

What does M503 say? Can you cut and paste?

What happens when you press the X & Y home buttons on Pronterface? Does the nozzle end up in the corner of the bed where it belongs?

After doing the X & Y home using the PronterFace buttons, can you do a M114 and verify it thinks X & Y are at 0.00 ?

Yes M502 does respond with"Hard coded Default Settings Loaded"

When I use the x and y home buttons I can confirm with an M114 that it is in fact at X0 Y0.

Also the numbers are not thrown off after a G28. G1 F1500 X0 Y0 will bring the hotend back to the correct X0 Y0. It isn't until I run the G29 that things get thrown off.

Quote:

---

Originally Posted by Pronus

Also the numbers are not thrown off after a G28. G1 F1500 X0 Y0 will bring the hotend back to the correct X0 Y0. It isn't until I run the G29 that things get thrown off.

---

Is your origin in the back right now? I think it is from the Configuration.h settings. When you press X & Y home buttons, does it go to the back right of the bed?

How much are the numbers off? Are they off by the numbers declared in:

#define X_PROBE_OFFSET_FROM_EXTRUDER 32.6
#define Y_PROBE_OFFSET_FROM_EXTRUDER 8.1
#define Z_PROBE_OFFSET_FROM_EXTRUDER -5.7

I'm starting to think you have the negative of your X & Y offsets declared. And that is going to affect the quality of your bed leveling too because it is going to compensate the Z-Axis the wrong amount.

EUREKA!!! I figured it out but now I've got a bruised ego for sure. I don't know how I missed this. I must have just thought that it had to be more complex of a problem so I completely overlooked it.

So I finally realized that the problem IS in my configuration.h and it is the probing points. My first probing point was engaging the x endstop so it was throwing everything off. I don't know how I didn't realize that. As soon as I adjusted the probing points to keep it a good distance from the x endstop, it is performing perfectly now.

Good Deal! There is a lot of complexity here and simple mistakes can cause super confusing problems! I have mine just 2mm from the stops.

Thank you again for your time with trying to help me get things working properly and I'm sorry to put you through all that for such a rookie mistake. Now I've got to face my fiance and tell her the problem was me from the beginning. She is going to love it and my ego is having a field day today, which is ok because I think a man's ego needs to be humbled/bruised every so often so it doesn't become inflated.

yep you r right :)

Can you explain exactly how you fixed it. I think I am having the same trouble as you were.

Hey dollaz81,

So the issue I had was when I started bed leveling with G29, my first probing point was defined at zero (#define LEFT_PROBE_BED_POSITION 0) and my Z-probe offset for the X axis was 32.6. What would happen is the x carriage was making contact with the x endstop while trying to probe that first point. Since the x offset was 32.6, it was trying to put the z-probe even further than my endstop. What worked for me was changing that left probe bed position to #define LEFT_PROBE_BED_POSITION 35. This compensated for the z-probe x offset of 32.6 so when probing the point it would not make contact with the x endstop and throw everything off.

I know exactly what you mean though when you said in your other thread that when one problem is fixed, another arises. Although my auto bed leveling is working now, it's not exactly leveling in a way that I can use it. On the right size of the bed the hotend is getting too close to the bed and then on the very far left side, the hotend is lifting up too much. This is making large prints squished on the right side and stringy on the left. I've been told that this could be do to a warped bed or a twist in the Y rods, but I haven't been able to figure it out yet.

Quote:

---

Originally Posted by Pronus

I know exactly what you mean though when you said in your other thread that when one problem is fixed, another arises. Although my auto bed leveling is working now, it's not exactly leveling in a way that I can use it. On the right size of the bed the hotend is getting too close to the bed and then on the very far left side, the hotend is lifting up too much. This is making large prints squished on the right side and stringy on the left. I've been told that this could be do to a warped bed or a twist in the Y rods, but I haven't been able to figure it out yet.

---

Two comments. First, you have:

#define AUTO_BED_LEVELING_GRID_POINTS 2

4 points is really not enough. Try changing that 2 to a 3 or 4.

Secondly... If you installed the Enhanced G29, you get a Bed Level Topography report that is very very valuable for manually leveling the bed. It also tells you about imperfections so you can avoid those spots when you place parts.

I had the #define AUTO_BED_LEVELING_GRID_POINTS set to 2 previously when I was experiencing issues trying to get the first probe to probe right, but later switched the value to 3 when printing. I'll try changing the value to 4 and see if that makes a difference.

Also, when z-probing used to happen, each time a point was probed, pronterface would send back commands of the x/y/z location but since the change to your code base it is not relaying that back. This is completely ok though if I can access this Topography report. How do I access this report?


-------------------------------------------------------------------
I just changed the value from 2-4...but here is where things get weird. Changing the value is not changing how many probing points that G29 is performing anymore. A value of 2 probes 9 points...which should be what happens when the value of 3 is chosen. I switched to 4 and I am still only probing 9 points.

The actual probed point location is controlled by the Verbose setting. If you do a G29 n 4 v 4 T you will get full details.

Quote:

---

Originally Posted by Pronus

I just changed the value from 2-4...but here is where things get weird. Changing the value is not changing how many probing points that G29 is performing anymore. A value of 2 probes 9 points...which should be what happens when the value of 3 is chosen. I switched to 4 and I am still only probing 9 points.

---

Yes, that is correct. In the Enhanced G29 that value controls the max # of points you can have in the grid. Probably it should be set to 4 or 5. But the default value if you don't specify how many points to probe is a 3x3 grid.

Ahh I see. I got it all working great now. Wow...this Enhanced G29 is nice! The jury is in for sure now and my bed is warped :(

SENDING:G29 n 4 v 4 T
Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.01:
Bed x: 35.00 y: 35.00 z: 2.16
Bed x: 88.00 y: 35.00 z: 2.69
Bed x: 141.00 y: 35.00 z: 3.09
Bed x: 194.00 y: 35.00 z: 3.32
Bed x: 35.00 y: 88.00 z: 1.41
Bed x: 88.00 y: 88.00 z: 1.91
Bed x: 141.00 y: 88.00 z: 2.27
Bed x: 194.00 y: 88.00 z: 2.42
Bed x: 35.00 y: 141.00 z: 0.60
Bed x: 88.00 y: 141.00 z: 1.07
Bed x: 141.00 y: 141.00 z: 1.39
Bed x: 194.00 y: 141.00 z: 1.52
Bed x: 35.00 y: 194.00 z: -0.26
Bed x: 88.00 y: 194.00 z: 0.18
Bed x: 141.00 y: 194.00 z: 0.49
Bed x: 194.00 y: 194.00 z: 0.62
Eqn coefficients: a: 0.01 b: -0.02 d: 2.68
Mean of sampled points: 1.554672
Correct +.14 with one clockwise turn.

Bed Height Topography:
+1.77008 +1.53383 +1.14008 +0.60858
+0.86858 +0.71108 +0.35333 --0.14642
--0.03592 --0.16867 --0.48642 --0.95442
--0.93292 --1.06642 --1.37617 --1.81817
planeNormal x: -0.01 y: 0.02 z: 1.00

Bed Level Correction Matrix:
0.999980 0.000000 0.006283
0.000101 0.999870 -0.016116
-0.006282 0.016116 0.999850
-----------------------------------------------------------------
So here is where things get a little odd. I know for a fact that my laser cut wood bed IS warped. This unfortunately is a common problem on the Makerfarm I3 with the wooden bed warping over time and going through heat cycles. It is warped enough that I can visually see it and actually had to raise it up with some spacers to make it continue to clear the frame when going beyond Y180. I also am sure that my PCB heated bed is warped too due to some nasty hotend crashes when I first got the printer and had no idea what I was doing with the bed auto leveling. I ended up swapping out my X motor end and X idler to a system that will NEVER be able to crash the hotend into the bed again, but alias...the damage is done.

I am wondering, do you think I could get by with just buying a new PCB heat bed or should I also try and replace the warped laser cut wood bed? The pcb heat bed kind of floats on top of the wooden bed with the springs for adjustment except for one corner that has a solid spacer. I'm thinking because of the way the pcb heat bed sits on the wooden bed, that if I were to replace it with a new flat one, that the warping of the wooden bed should not translate to warping of the heat bed...

Quote:

---

Originally Posted by Pronus

Ahh I see. I got it all working great now. Wow...this Enhanced G29 is nice! The jury is in for sure now and my bed is warped :(

Bed Height Topography:
+1.77008 +1.53383 +1.14008 +0.60858
+0.86858 +0.71108 +0.35333 --0.14642
--0.03592 --0.16867 --0.48642 --0.95442
--0.93292 --1.06642 --1.37617 --1.81817
planeNormal x: -0.01 y: 0.02 z: 1.00

...

I am wondering, do you think I could get by with just buying a new PCB heat bed or should I also try and replace the warped laser cut wood bed? The pcb heat bed kind of floats on top of the wooden bed with the springs for adjustment except for one corner that has a solid spacer. I'm thinking because of the way the pcb heat bed sits on the wooden bed, that if I were to replace it with a new flat one, that the warping of the wooden bed should not translate to warping of the heat bed...

---

Opinions are going to vary... If it was me, I would put a new PCB heat bed with a thin glass layer mounted on springs on top of the existing and warped bed. There are problems with that for the purists. But for me it is a life saver because when I'm making firmware changes, they aren't always correct (Go Figure!) and it buys you a little bit of tolerance for nozzle crashes. Springs are very helpful for me!!!

Looking at that bed height topography report you have says the bed is warped. The amount of change varies as you go straight across left and right and straight up and down. My guess is you can print small things, especially in the front right corner (if I'm reading things correctly.) But anything of size is going to be difficult!

With that said... If you manually level it a little bit more, you will be able to see which areas are better and which are worse. It may not be as warped as you think. It certainly is not level. The two Kitty-Korners are 3.5mm different in height. That is way too much. If you manually level it so it is more flat, the bed height topography report will be able to tell you a lot more.