Auto_Bed_Leveling: Enhanced G29 command

[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]

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.

[DarkAlchemist]

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.

Yeah, this may be a pronterface dealio and I only see that message you are talking about if I hit G29 first but in Pronterface you can home each axis individually via a button and homing X, and Y, that way still works but forget it with Z just does nothing.

[Roxy]

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.

Once the Bed Correction Matrix is generated by the G29 command, all coordinates are 'corrected' using that matrix. (Technically... This happens all the time, but initially, and after a G28 the Bed Correction Matrix is identity and so what you feed in is what you get out.) Z-Homing does move the nozzle around so it is possible to see a little bit of X & Y movement there after the G29. But it is going to be very minimal.

With that said... As you move the nozzle around in either the X or Y directions, the new coordinates get 'corrected' and the Z will move slightly up or down in an attempt to track the bed. It should be very small movements of Z if the bed is close to flat. The more unflat the bed is, the more you will see the Z move up or down as you tell PronterFace to move +/- X or +/- Y.


Go ahead and post those files and I'll see if I can spot what is causing the trouble.

[DarkAlchemist]

Here ya go but I really haven't changed anything and any idea why pronterface no longer will home Z via the button with ABL enabled? Btw, .7z was not an allowed filetype.

[Roxy]

Here ya go but I really haven't changed anything and any idea why pronterface no longer will home Z via the button with ABL enabled? Btw, .7z was not an allowed filetype.

One possibility is you have #define Z_SAFE_HOMING enabled. Unless you have homed both X & Y previously (and very recently), it won't let the Z axis go down.

How old is the Marlin_main.cpp you posted. It looks fairly recent. But the Configuration.h file looks fairly old? Can you give me your best guess on dates for those files? Part of the reason I'm asking is your G1 command will not fall through into the G2 code if Stopped==false but mine will. I suspect your version of Marlin_main.cpp has the logic correct. But it will take a little bit of time to figure out why it is different.