Auto Bed Levelling Glitches

[Roxy]

I'm starting to lean towards the Sled Docking stuff having a bug in it in that Fork.... I need to keep looking at things...

[MiniMadRyan]

Isn't your origin in the back right of the printer? If so, you have it specified wrong in the Configuration.h file.

Do you have a reason to have your Z axis movement so slow? It is at 2 right now. I'm thinking you can bump that

#define DEFAULT_MAX_FEEDRATE {250, 250, 2, 22} // (mm/sec)

up to 5 or 6 very safely. And you have the Z acceleration very low also.

#define DEFAULT_MAX_ACCELERATION {1000,1000,5,1000}

and similarly, on the

#define HOMING_FEEDRATE {50*60, 50*60, 50, 0} // set the homing speeds (mm/min)

That Z being at 50 can be bumped up to maybe 300. I think you can go up to 100 here safely. That will make the video's much less painful to watch!!!

But here is the first stuff I question. You have:

#define LEFT_PROBE_BED_POSITION 50
#define RIGHT_PROBE_BED_POSITION 150
#define BACK_PROBE_BED_POSITION 150
#define FRONT_PROBE_BED_POSITION 50

But you have your bed size set at:

#define X_MAX_POS 250
#define X_MIN_POS 0
#define Y_MAX_POS 250
#define Y_MIN_POS 0
#define Z_MAX_POS 235
#define Z_MIN_POS 0

I think you should spread out your xxx_PROBE_BED POSITION's to use nearly the full range of the bed. I have mine defined as:

#define LEFT_PROBE_BED_POSITION (X_PROBE_OFFSET_FROM_EXTRUDER+2)
#define RIGHT_PROBE_BED_POSITION X_MAX_POS
#define BACK_PROBE_BED_POSITION Y_MAX_POS
#define FRONT_PROBE_BED_POSITION (Y_PROBE_OFFSET_FROM_EXTRUDER+2)

lets see if I can answer this in order haha. Regarding the z-speed, I left it how it originally came when I flashed the firmware. I haven't customized much in this firmware, aside from what was noted to get the levelling to work, as I intended to play around with things after it was working successfully.

Regarding the bed size, I had read previously that there could be issues if the probe was placed too close to the outer limits of the bed, for testing purposes, I just set the values to be somewhere closer to the middle. Thank you though, I will be flashing those changes tonight

So do you think there is something amuck with that particular fork from dacb? I wonder where else G28 is defined in the firmware......

[Roxy]

So do you think there is something amuck with that particular fork from dacb? I wonder where else G28 is defined in the firmware......

I'm thinking the Sled Docking is at the root of this. Sled Docking got added to the main Marlin release. And there were errors in the #ifdef's that caused a lot of compilation issues. The way Dacb dealt with the errors and what I have are different. So I'm going to go through those differences and see if I can find something that explains this behavior.

I have a post outstanding to Dacb on another issue in the G29 related to the declared bed size. I don't think that is your problem but it should be dealt with.

I'm not sure how to proceed, but depending upon what I find, it might make sense to make the changes to your Marlin_main.cpp and upload it here for you to try.

[MiniMadRyan]

I'd be willing to do that! I was just going through the the docking code in marlin_main. I didn't realize that it was a newer addition to the release. I find it interesting that essentially the same command can have two different outcomes. Hmm...

[AbuMaia]

I have two G28s in my start gcode, automatically added when I slice a part. The first one "resets" the printer after a potentially tall previous print, then the bed heats, then the second G28 preparatory to a G29. I've not had any issues with where homing happens. I have the safe homing set to home Z at X10 Y10 instead of the middle, though.

I'm using the latest "main" Marlin from EricZalm, with some of the changes from becdac's fork merged across.

[AbuMaia]

Do you have a reason to have your Z axis movement so slow? It is at 2 right now. I'm thinking you can bump that

#define DEFAULT_MAX_FEEDRATE {250, 250, 2, 22} // (mm/sec)

up to 5 or 6 very safely. And you have the Z acceleration very low also.

#define DEFAULT_MAX_ACCELERATION {1000,1000,5,1000}

and similarly, on the

#define HOMING_FEEDRATE {50*60, 50*60, 50, 0} // set the homing speeds (mm/min)

That Z being at 50 can be bumped up to maybe 250. That will make the video's much less painful to watch!!!

On my printer, any Z max feedrate above 2 makes an odd sound, even at 2.25. Anything above 3 stalls the motors completely. Z homing feedrate of250 seems to be working, though a little buzzy on the slow drop to re-click.

[Roxy]

MiniMadRyan, I changed the Sled Docking stuff (and a few other things) to how I have my code. Be sure to save your current file set, but then replace your Marlin_main.cpp with the attached file. I took some amount of care, but there are a lot of changes so I'm not positive it will compile clean. Please try it and let us know what you see.

[MiniMadRyan]

Hi Roxy, thank you for your help! I will try it tonight when I get home from work! Mind me asking, how did you wrap your head around working with the Firmware files? I write apps for a living, but frankly, looking through some of the code yesterday made my head hurt....maybe I just didn't have enough coffee yet!

[Roxy]

When I built my printer, I had some problems with it doing crazy things... I spent a lot of time understanding how the firmware worked so I could add debug code to it. I don't understand all parts of it. But I do understand most of the stuff I have enabled. One thing about this firmware is there is no operating system sitting under you to provide support. What ever it needs, it provides. So, that does complicate things from one perspective. But from another view point, everything is there and only stuff it needs is in the code. So from that stand point it simplifies things.

The Marlin firmware is really just one big loop that reads in GCode commands and processes them one by one. So, from that stand point, it is pretty simple.

[MiniMadRyan]

Thanks Roxy, like always I really appreciate your help! The new marlin_main compiled fine against my existing firmware. Manually running G28 like before homes the x and y and then repositions at the middle of the bed to home the z. Subsequent G28's do the same. G29 then probes from the beginning of the bed and then returns the probe once done.

I was a bit excited, and loaded up a test cube and sliced it and clicked print after that G29. low and behold it crashed the y axis, which after crashing proceeded to extrude at the same offset distance. I chalked it up to me being a dummy and not putting the g28 and G29 code into my start gcode.

My existing start code looks like so:

G21 ; set units to millimeters
M107
M190 S55 ; wait for bed temperature to be reached
M104 S190 ; set temperature
G28 ; home all axes
G1 Z5 F5000 ; lift nozzle
M109 S190 ; wait for temperature to be reached
G90 ; use absolute coordinates
G92 E0
M82 ; use absolute distances for extrusion
G1 F600.000 E-1.00000
G92 E0

And I'm believing then that my new code should look like this?

G21 ; set units to millimeters
M107
M190 S55 ; wait for bed temperature to be reached
M104 S190 ; set temperature
G28 ; home all axes
G29; auto level
M109 S190 ; wait for temperature to be reached
G1 F600.000 E-1.00000
G92 E0

I've removed the G1 Z5, G90, G92, M82 and added in the G29 after the G28.

Would I also have to then adjust anything else in slic3r or otherwise then? I was a bit worried with effectively having the print head starting from the middle of the bed, which caused the Y crash, but it could be just cause I never had g28 and g29 in my start code...

I just wanted to say thank you again too, especially for some of my dumb questions. I've admittedly been rushed with so many projects on the go, that I've probably over looked things I shouldn't have!