Auto_Bed_Leveling: Enhanced G29 command

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

[AbuMaia]

A few problems. I use Ubuntu Linux, so I haven't yet figured out how to make a shortcut for Arduino ( I do have 1.0.5), which I start from the terminal (command line). Second, When opening your Marlin.pde file, *only* the Marlin.pde file is loaded, none of the others.

[Roxy]

OK, instead of a drag & drop to open the sketch... Almost for sure the Linux version of Arduino will let you open it by browsing to it. This will sound a little bit paranoid but I would delete a semi-colon or something to cause a syntax error in one of the files. I've had problems with Arduino using what ever I last opened and having it build the wrong thing. If you cause a syntax error in one of the files, and it complains about it during the build, at least you will know its working on the right code base.

[AbuMaia]

I got Arduino working, got all the files loaded properly. Fixed the baud rate setting, and uploaded to the printer. Y axis still moves when the Z axis raises. The problem of not being able to print from an SD card is now fixed, however.

[Roxy]

The baud rate is not supposed to matter on the USB-to-Serial interface. I saw that was different but left it at the stock value. Are you saying it didn't work at that value?

If the SD card is working correctly now, most likely that is because of the pin definitions in Pins.h There are some conflicts on some of the controller boards with the duplicate usage of the SD card pins.

What you have right now is a totally stock and unaltered version of Marlin. Just to be clear, you are saying the Y-Axis is OK at the end of the G28 but when the G29 starts the Y-Axis moves as the Z-Axis raises? Knowing that exact answer will help limit the places we are looking for the problem. If this is true, I've attached the current Marlin_Main.cpp file you are using with some debug printouts in the relevant areas. It would be helpful to rebuild and post what it says. And it will pause after every print out so you should be able to determine at what point the Y-Axis starts moving. I think this will give us almost all the information we need to understand what is going on with your machine.

But before you do that:

Can you do a G28 and check that it behaves as you think it should. And then issue a M114 ? You have the following values:

#define FRONT_PROBE_BED_POSITION 30
#define Y_PROBE_OFFSET_FROM_EXTRUDER -7.7

If the M114 is reporting Y to be equal to 0.0 at the end of the G28 I would expect it to move the nozzle 30+7.7 mm before doing the first probe. Is there something wrong with what I'm thinking?