Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

So you understand what was wrong? And you have a fix for the bad behavior? If so, that is good!!!

[AbuMaia]

No, it was a separate problem I noticed and fixed. The Y move on Z lift still occurs.

[brainscan]

Why does your z lower before extending probe? Mine always goes up during homing before extending it to give clearance. From your video it seems if the nozzle was at 1mm when you home it would crash straight away, or am I missing something. Sorry I know you're trying to fix the y axis but I just thought it looked odd.

**Edit - Also I was reading through your posts again and am confused why you switched safe homing off again. Earlier when it was switched on AbuMaia said it no longer had the bad y movement (this is good isn't it?) and that it now probed at the correct place (187 not 197) the only problem was trying to home each axis individually which also seemed to work but not how AbuMaia expected. If I home x then y then z I get the same error but if I home all axis together, x and y go first then probe moves diagonally to centre with 10 mm lift extends probe and homes. It just seemed like you made some progress then possibly got mixed up. Sorry if I've totally misread things.

[AbuMaia]

I turned off safe homing because of a problem I noticed where both X and Y were being offset too much. I thought it was caused by safe homing, but later figured out it was a problem with the numbers I gave the bed leveling grid. I have safe homing on again.

As for the Z lowering before extending the probe, I have it set to raise 13mm before homing Z, so I assume that if the printer knows Z is higher than 13mm, it will lower to that point then extend the probe. I think it was doing this because the printer was left on between homing runs. If I turn the printer off and back on, and home again, it will raise then extend the probe. Likewise, if Z is below 13mm, it will raise to that point then extend the probe.

[brucehvn]

As for the Z lowering before extending the probe, I have it set to raise 13mm before homing Z, so I assume that if the printer knows Z is higher than 13mm, it will lower to that point then extend the probe. I think it was doing this because the printer was left on between homing runs. If I turn the printer off and back on, and home again, it will raise then extend the probe. Likewise, if Z is below 13mm, it will raise to that point then extend the probe.

Hmm, that's not the way it works for me. I have my raise before homing set to 10mm and it always goes up 10mm no matter where it started from.

[brainscan]

Sorry it's me getting confused then about the safe homing.
With regards to the printer already knowing it's above 13mm so drops down then extends kind of makes sense but I'm pretty sure that's not what mine does. Mine will always raise before it extends the probe even if it knows it's at z 100. I haven't printed anything close to my z max but if I did I would have to manually move the nozzle down to avoid it maxing out and crashing so it seems strange. I don't know enough about all this stuff yet but I assumed a homing command would erase the current location and would just look to hit an endstop. The exception being safe homing but that still needs to start from x0 y0 it doesn't use the current position to do a move. I'm probably just getting in the way so I apologise if this isn't helping. Roxy is definitely the one who knows what she's talking about so hopefully you guys will sort this thing out pretty quickly.

[Roxy]

I'm probably just getting in the way so I apologise if this isn't helping. Roxy is definitely the one who knows what she's talking about so hopefully you guys will sort this thing out pretty quickly.

No! Jump in! What ever is wrong with his firmware is not very serious. But finding the root cause is going to take some effort. And the problem is, we are pretty much stuck looking for the problem by adding debug code to give us extra information.

AbuMaia: I think the thing to do is take those 4 lines of debug code we had inserted in the G28 and litter them through out the G29. That way we will see exactly when the Y-Axis is starting to move and we can print out values of important variables. Also, if you can do that, we won't have to go back and forth until we know exactly where unexpected behavior starts.

Another approach might be to just send you my code base with your Configuration.h, Configuration_adv.h & pins.h crossed over to it. That is kind of brute force but almost for sure that puts an end to the problem. If you want to try that approach, post those three files when you get a chance.

[brainscan]

I know this probably isn't related to what's happening with AbuMaia but I noticed when you were saving me that you very cleverly define your bed area using X_MAX, Y_MAX etc (sorry I'm not at my computer/printer and can't remember exactly how you have it) hope you know what I'm talking about? Anyway your method works much better than defining each offset with a number to define the rectangle. Before I stole your way of doing it my x axis would zig zag at each side of the rectangle, because everything worked okay I didn't think anything about it (didn't even notice to begin with as it was such a small move). Now that I'm using your way of defining the rectangle this doesn't happen, so all the probe points line up on each side. I just thought it might be worth mentioning.

[AbuMaia]

Another approach might be to just send you my code base with your Configuration.h, Configuration_adv.h & pins.h crossed over to it. That is kind of brute force but almost for sure that puts an end to the problem. If you want to try that approach, post those three files when you get a chance.

I think I'll go this route. For some reason I don't yet understand, I'm no longer able to print from the SD card. The printer recognises it, I can see the files on the SD card listed on the LCD screen, but when I select one, nothing happens. That's more serious than the Y movement, and I have no idea why it's happening.

[Roxy]

We have to do this in two steps. The reason is I have conflicting code in my Marlin_main.cpp file because I don't have an LCD Panel.

First, get and install Arduino v1.05 if you are not already using it. You can get it at: http://arduino.cc/en/Main/Software#toc2 Put a shortcut on your desktop for it so we can drag and drop files onto it. This will be much safer than trying to open a file from within the Arduino environment. You can check to make sure this was successful by double clicking the shortcut and seeing if it starts up and assumes it should load a previous build environment.

Next, make a copy of your existing code base so you don't lose anything. In the new folder with what is going to be your new code, drill down into the Marlin directory. Delete all .c, .cpp, .h, .ino and .pde files. Mostly, we are deleting them just to make sure the new files really got put back in place. Download the attached file and change its extension to .ZIP. (The .Zip files can not be as big as we need so I had to use a file extension that can be bigger.) Unzip the attached file and verify you have a directory full of .cpp and .h files in the Marlin folder. This is the current Marlin code base with all of your critical values being used by it. Auto Bed Leveling is turned on and configured however, the Enhanced Auto Bed Leveling is not in it yet. We will do that after we confirm this works as expected.

Go into the Marlin directory and drag and drop the Marlin.pde file onto your Arduino v1.05 shortcut. You should see all the files get loaded. Go to the Tools tab and set the appropriate board type for your printer. It would not compile for my system because the LCD panel has a lot of bloat code. I had to change it to an Atmega-256 type chip.

Do a Sketch / Verify & Compile. If it compiles clean you should be ready to see if this build will work on your printer as expected. As soon as we get this working correctly, we will cross the Enhanced code base into it.