Auto_Bed_Leveling: Enhanced G29 command

[DarkAlchemist]

Well, I did but I wasn't looking for this issue and the problem I had was that my print was jacked up by a lot so all it did was ooze and this may be why. I have printed numerous times just never with auto bed leveling.

[brucehvn]

Well, I did but I wasn't looking for this issue and the problem I had was that my print was jacked up by a lot so all it did was ooze and this may be why. I have printed numerous times just never with auto bed leveling.

Can you post a copy of your Configuration.h file before and after modifying it for ABL (the stock version of ABL). Maybe we can see something that's not quite right.

[DarkAlchemist]

Can you post a copy of your Configuration.h file before and after modifying it for ABL (the stock version of ABL). Maybe we can see something that's not quite right.

I never touched the configuration file just Marlin_Main.cpp. The defines (only define was which corner was home) I temporarily left inside the Marlin_Main.cpp right before G29 but here is my Configuration.h for ABL

Configuration.h

[brucehvn]

I never touched the configuration file just Marlin_Main.cpp. The defines (only define was which corner was home) I temporarily left inside the Marlin_Main.cpp right before G29 but here is my Configuration.h for ABL

Configuration.h

Well, I certainly don't see anything obvious in there. You have this line:

#define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min

8000 seems a little high. Maybe try reducing that to something like 4000, but it doesn't seem like that would be the issue. Are you using the latest Marlin?

[DarkAlchemist]

Well, I certainly don't see anything obvious in there. You have this line:

#define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min

8000 seems a little high. Maybe try reducing that to something like 4000, but it doesn't seem like that would be the issue. Are you using the latest Marlin?

I have 8000 because that is my max as my system will allow without skipping.

I was hoping Roxy would chime in on this since they know this code so very well because I know sort of what it is doing but not how it is doing it. Thing is, as I said, they are leaving something opened, or not flushed, and when I do a g28, or a g30, it closes, or flushes, everything so it works right again.

edit: As far as the latest Marlin I am not sure but I don't think so as I am frankly afraid of it because I have this Marlin so tweaked for my purposes.

For instance I was beating my head on the table for a couple of hours because ABL would not work with multiple points and why? Because the Config file says one thing and Marlin is looking for another. So, I was always defaulting to 3 point due to it. This is why you see
#define AUTO_BED_LEVELING_GRID_POINTS 2

I have now updated everything and it still does it.

After the g29 it makes the printer unusable but if you move Z the other axis will not move but move X or Y and they all move by the same amount.
#define ACCURATE_BED_LEVELING_POINTS 2
in the configuration file.

After looking at the repository I am going to upgrade my version as 2, or three files are newer but luckily the configuration.h is the same so I can just drop mine in but I doubt this issue was fixed.

After looking I see this version has at least named the ACCURATE_BED_LEVELING_POINTS to the newer AUTO_BED_LEVELING_GRID_POINTS so that is a plus.

[DarkAlchemist]

Same issues after upgdating to the latest and I can tell you g29 makes the printer worthless. Move Z no issues but move X, or Y, after doing a G29 and they all move by the amount you tell it.

Well, I just started really digging into the code and it suddenly dawned on me that this is exactly how it should work.

What I did to verify was add plan_bed_level_matrix.set_to_identity(); //Reset the plane ("erase" all leveling data) at the end of G29 and that confirmed that the bed is now "leveled" and anytime you move Y or X Z is going to move as well (in the newer code not all axis moved when I manually did moved it).

So, thank you as being able to talk about this outloud and dig dig dig in the code solved an issue that it turns out was not really an issue.

So, for anyone else out there don't get alarmed, like I was, if you hit your movement buttons in Pronterface and they all seem to move.

[Roxy]

I was hoping Roxy would chime in on this since they know this code so very well because I know sort of what it is doing but not how it is doing it. Thing is, as I said, they are leaving something opened, or not flushed, and when I do a g28, or a g30, it closes, or flushes, everything so it works right again.

edit: As far as the latest Marlin I am not sure but I don't think so as I am frankly afraid of it because I have this Marlin so tweaked for my purposes.

I'm here now... I've been out and about all weekend. But I should be here a lot for the next few days. Can you please post the following files from your setup and I'll take a look at things:

- Configuration.h
- Configuration_adv.h
- Pins.h
- Marlin_main.cpp

Most likely, what ever is causing your problem is not a big deal. But of course we still have to find what is doing it...

[Roxy]

Same issues after upgdating to the latest and I can tell you g29 makes the printer worthless. Move Z no issues but move X, or Y, after doing a G29 and they all move by the amount you tell it.

Well, I just started really digging into the code and it suddenly dawned on me that this is exactly how it should work.

What I did to verify was add plan_bed_level_matrix.set_to_identity(); //Reset the plane ("erase" all leveling data) at the end of G29 and that confirmed that the bed is now "leveled" and anytime you move Y or X Z is going to move as well (in the newer code not all axis moved when I manually did moved it).

So, thank you as being able to talk about this outloud and dig dig dig in the code solved an issue that it turns out was not really an issue.

So, for anyone else out there don't get alarmed, like I was, if you hit your movement buttons in Pronterface and they all seem to move.

Does this mean everything is behaving as it should now?

[DarkAlchemist]

Does this mean everything is behaving as it should now?

I am not sure because is it supposed to act like that? For instance home Z in pronterface is DOA with ABL. When I move the head in the X, or the Y, direction is Z, and the other axis, suppose to move too?

I don't know the answers to the above questions and maybe you do or could try it with your setup and tell me? I can't print with it yet as I am waiting for my new switches (my old switch required just too much pressure to activate) and assorted hardware or I would try to print again.

[brucehvn]

I am not sure because is it supposed to act like that? For instance home Z in pronterface is DOA with ABL. When I move the head in the X, or the Y, direction is Z, and the other axis, suppose to move too?

I don't know the answers to the above questions and maybe you do or could try it with your setup and tell me? I can't print with it yet as I am waiting for my new switches (my old switch required just too much pressure to activate) and assorted hardware or I would try to print again.

Well, I've never seen that behavior. For homing Z, I will see the message coming from the firmware that I have to home X and Y before Z if I haven't homed X and Y first. But I've never seen the thing with all axes moving. I use Repetier Host though.