Auto_Bed_Leveling: Enhanced G29 command

[Roxy]

Yeah done that, deleted and replaced code, origin already at front left. Still says too few arguments. Thank you for the fast response. I'll try and do the whole thing again in the morning, it's 2:25am here.

It's possible the code base has been updated... And if that is the case, I'll need to warm over the patch. I'll take a look at it in the morning. One way or the other, we'll get it going. Can you .ZIP up your Marlin directory with all the files and attach it to a post? I'll do a DIFF of all the files and figure out what is sick. And with a little luck, I'll be able to get it fixed. And then I'll upload that as a .ZIP file for you to grab.

Update:

I just took a quick look at the current code base on Erik Zalm's site. Not much has changed for 2 or 3 months. So, the easiest way to proceed is what I suggested up above. .ZIP up your code and attach it to your next post. I'll do a diff and probably be able to fix it pretty quickly.

[brainscan]

It's possible the code base has been updated... And if that is the case, I'll need to warm over the patch. I'll take a look at it in the morning. One way or the other, we'll get it going. Can you .ZIP up your Marlin directory with all the files and attach it to a post? I'll do a DIFF of all the files and figure out what is sick. And with a little luck, I'll be able to get it fixed. And then I'll upload that as a .ZIP file for you to grab.

Update:

I just took a quick look at the current code base on Erik Zalm's site. Not much has changed for 2 or 3 months. So, the easiest way to proceed is what I suggested up above. .ZIP up your code and attach it to your next post. I'll do a diff and probably be able to fix it pretty quickly.

Thank you so much for helping me so quickly, I just don't understand programming enough so it could be blatantly obvious what I've done wrong. I've probably deleted something I shouldn't have. Your instructions are really clear so i'm annoyed with myself that I haven't just got it going myself. I tried putting everything in a .zip but its still too big to upload. Ive added marlin_main.cpp and configuration.h I will try and upload a .zip of everything if i can get the file small enough. Thank you again.

Roxy Edit:
Just make a new directory somewhere on your hard disk and copy all the .h, .cpp, .pde and .py files to it. And then .ZIP that up. It is probably the .obj (or what ever they are called in Arduino) making things too big. But this is enough to get started. I'll see what I can find.

Roxy Edit #2:
I checked your Configuration.h file and it looked reasonable. You had a big block of bogus code at the end of the G29 code in the Marlin_main.cpp file. I commented it out so you can see what was there. I tried to compile it but there are some mismatches between the code base you have and what I have. I'll need your entire file set (as a .ZIP file) to go any further. Try the newly attached file: Marlin_Main-Brain_Scan.cpp and see if that helps. It should get rid of a lot of the errors, but I was having trouble getting through the RS232 code with your files in place. You can delete the old Marlin_Main.cpp and replace it with the Brain_Scan version that is attached. I also crossed over the M48 command so when you get it to compile you can check the accuracy of your Z-Probe.

Roxy Edit #3:
Just for kicks I tried to compile against my Configuration.h file. I don't have the problems with the RS-232 (serial) code that you do. I found one problem that needs to be changed in your Configuration.h file. At the end, there is a #define for the number of Servo's. You have it set at 1. I realize you only have one servo, but the software is looking at a table of X,Y and Z for the angle locations. This should be set at 3 because it is the third axis and you need to be able to mess with it. I've attached the new file with that too. It is possible this will compile cleanly on your machine with the rest of your files.

[brainscan]

Hi Roxy, wow, wasnt expecting you to have gone to so much trouble! I might have had problems with my configuration.h as i've been copying it from an older version so maybe something was changed. After you mentioned something was wrong with it I thought i'd try and start again from scratch and it has compiled now so something must be different. I had to split the files into 3 to get the .zip files small enough, sorry for being a pain. Im just about to try uploading and run some tests. The marlin_brain_scan.cpp wouldnt download so I cant try that yet but M48 was next on my list. I'll see how things go and report back, thank you so much again for your help.

Roxy Edit:
I just download the Marlin_main-Brain_Scan.cpp file with no problems. Maybe you should try again? I'll wait to hear from you before I do anything with the 3 .ZIP files.

[brainscan]

Hi I just tried again and its downloaded fine this time, weird. The new copy ive made seems to be working better as it compiles and uploads and now when I run a g29 it doesn't do the annoying servo retract every move but at the end the nozzle stays above the bed and cant be moved down to touch it, it actually raises the nozzle a fraction and shows as being at 0. Im using the probe as a z endstop so do I need to change M206 offset? The last code I tried using added the two together so if both had an offset it would double the distance.
The other thing is the n parameter doesn't seem to have any effect, it always does 3x3 although it moves around in a different pattern. Ive copied the output from the bed level matrix and topology map for you if that is of any help? Might be best to just leave the old copy alone as its a bit of a mash-up of different code. Sorry if i've wasted any of your time.

22:07:11.001 : Bed Level Correction Matrix:
22:07:11.009 : 0.999997 0.000000 0.002244
22:07:11.009 : 0.000000 1.000000 0.001029
22:07:11.009 : -0.002244 -0.001029 0.999997
22:07:11.312 : echo:endstops hit: Z:-0.40
22:08:14.532 : N180 G28 X0 *114
22:08:15.940 : N182 G28 Y0 *113
22:08:20.974 : N184 G28 Z0 *116
22:08:34.858 : N190 G29T0 *94
22:09:58.962 : Eqn coefficients: a: 0.00 b: 0.00 d: -1.02
22:09:58.962 :
22:09:58.966 : Bed Height Topography:
22:09:58.966 : --0.08199 +0.11606 +0.31254
22:09:58.970 : --0.27027 --0.05777 +0.11606
22:09:58.970 : --0.14293 --0.02691 +0.03520
22:09:58.970 :
22:09:58.974 : planeNormal x: -0.00 y: -0.00 z: 1.00
22:09:58.974 :
22:09:58.974 : Bed Level Correction Matrix:
22:09:58.978 : 0.999997 0.000000 0.002283
22:09:58.978 : 0.000000 1.000000 0.001003
22:09:58.982 : -0.002283 -0.001003 0.999997
22:09:59.285 : echo:endstops hit: Z:-0.40
22:10:43.899 : N213 M81 *58

p.s Is there anyway to have the nozzle lift before the servo retracts at the end of G28 and G29? A few other people wanted the same thing and i'd tried using some of their code which might have caused me these problems in the first place. Thank you again for all the help.

[Roxy]

Hi I just tried again and its downloaded fine this time, weird. The new copy i've made seems to be working better as it compiles and uploads and now when I run a g29 it doesn't do the annoying servo retract every move

Yes, that is intentional. But you can get it to E-ngage and retract the probe for each measurement if you want with the 'E' option. G29 E will give you back the annoying behavior.

but at the end the nozzle stays above the bed and cant be moved down to touch it, it actually raises the nozzle a fraction and shows as being at 0. Im using the probe as a z endstop so do I need to change M206 offset?

I suspect the reason you can't lower the nozzle is you have:

#define min_software_endstops true

It is trying to protect you. The Z-Axis height is computed as a result of all the probing and some points are measured higher than others. Where ever the zero point gets calculated, that #define keeps you from going lower. I don't use the software end stops. But before you turn this off, you might want to consider and try changing this line:

#define Z_MIN_POSITION -5 // (or how much you dare to allow it to violate the 0.00 mark on the Z-Axis)

I don't know about or use the M206 stuff. I doubt you need to mess with it. Let me know if these two things don't fix things for you. It is easy enough to add a couple lines of code to push the nozzle down some amount.

The last code I tried using added the two together so if both had an offset it would double the distance.
The other thing is the n parameter doesn't seem to have any effect, it always does 3x3

The n parameter doesn't have any effect??? Try G 29 n 99 and see if you get an error message. If not, we have some serious problems. But if so, it means the code is recognizing you gave it a number for one axis of the grid. If that gives you an error message, then G29 n 4 should do a 4 x 4 grid. Or G29 n 2 should give you a 2 x 2 grid.

although it moves around in a different pattern.

The order of the points is dependent on whether it is going to print a Bed Height Topology graph. If you set the V-erbosness level high enough or specify a T option, you will trigger the alternate path. The alternate path takes slightly longer (1 or 2 seconds) to accomplish, but it reduces the code complexity and code size dramatically.

Ive copied the output from the bed level matrix and topology map for you if that is of any help? Might be best to just leave the old copy alone as its a bit of a mash-up of different code. Sorry if i've wasted any of your time.

22:07:11.001 : Bed Level Correction Matrix:
22:07:11.009 : 0.999997 0.000000 0.002244
22:07:11.009 : 0.000000 1.000000 0.001029
22:07:11.009 : -0.002244 -0.001029 0.999997
22:07:11.312 : echo:endstops hit: Z:-0.40
22:08:14.532 : N180 G28 X0 *114
22:08:15.940 : N182 G28 Y0 *113
22:08:20.974 : N184 G28 Z0 *116
22:08:34.858 : N190 G29T0 *94
22:09:58.962 : Eqn coefficients: a: 0.00 b: 0.00 d: -1.02
22:09:58.962 :
22:09:58.966 : Bed Height Topography:
22:09:58.966 : --0.08199 +0.11606 +0.31254
22:09:58.970 : --0.27027 --0.05777 +0.11606
22:09:58.970 : --0.14293 --0.02691 +0.03520
22:09:58.970 :
22:09:58.974 : planeNormal x: -0.00 y: -0.00 z: 1.00
22:09:58.974 :
22:09:58.974 : Bed Level Correction Matrix:
22:09:58.978 : 0.999997 0.000000 0.002283
22:09:58.978 : 0.000000 1.000000 0.001003
22:09:58.982 : -0.002283 -0.001003 0.999997
22:09:59.285 : echo:endstops hit: Z:-0.40
22:10:43.899 : N213 M81 *58

I don't now what all that extra Nxxx stuff is. My suggestion is to just work off of the one I posted. Without the same source code, it is difficult to guess what is going on. But you have .5mm of difference between your lower left and upper right corner. The Auto_Bed_Leveling will correct for that, but you really ought to get that leveled out better. That is hugely excessive!

p.s Is there anyway to have the nozzle lift before the servo retracts at the end of G28 and G29? A few other people wanted the same thing and i'd tried using some of their code which might have caused me these problems in the first place. Thank you again for all the help.

Yes, that is not too hard to do. And in fact RegPye wanted the same thing. Let's get the first part working right... And I'll get a couple lines of code added to handle this request.

[brainscan]

The Nxxx is just the check sum/line number Repetier host uses, it can just be toggled on and off. G29 n99 just went through a normal 3x3 grid, no error message. Tried changing MIN_Z_POSITION to -8 (slightly more than my probe z offset) seems to have made the problem worse, now rather than moving up a fraction and reading 0 it moves up over 8mm and reads 0!!!! What the hell have i done wrong? You're right though, get this problem sorted first before wishing for more.

As soon as I get home I will try switching the max software endstop to false and see if that helps. I must have done something wrong if the n parameter isn't working. I haven't tried the e parameter as that's the main thing I wanted to stop, v does as you said and t works as it should, seems strange it's only the n parameter that's being ignored, plus it's a new copy of marlin so scratching my head at the moment.

I haven't tried to level my bed manually since last removal so it made me chuckle that .5mm difference from corner to corner is hugely excessive. Reminded me of a joke about accuracy. Cabinet makers work to the closest 1/16 inch, carpenters the closest 1/8 inch and joiners work to the closest pub. In this case you're the cabinet maker and I just need a drink .
I will try and level it out more each time I run a test.

[Roxy]

Are those 3 .ZIP files up above what your are using? Because the extra (incorrect) code at the end of the G29 command is back in there????

As part of the communication protocol PronterFace uses capital N's and those get lost from the command line. I'm wondering if Repetier eats all n's ??? I looked at the code and it has to produce an error message if it gets the 'n 99'. Here is something to try:

At the start of the G29, you will see this code:

if ( code_seen('n') ) {
n_points = code_value();
if (n_points<2 || n_points>AUTO_BED_LEVELING_GRID_POINTS ) {
SERIAL_PROTOCOLPGM("?Number of probed points not plausable.\n");
break;
}
}

Change the:

if ( code_seen('n') ) {

to

if ( code_seen('u') ) {

and give it a G29 u 99 command. With that change, even if Repetier is eating all the n's, you will be able to specify more points (and have it produce an error message). You can also use PronterFace and see if that allows you to specify the number of grid points and that would keep you from having to make the suggested firmware change and reflashing the electronics. If that is what is happening... It will probably make sense to update the code so people using Repetier don't hit this problem in the future.

[brainscan]

The 3 zip files are the old firmware I couldn't get to compile (so not using at all now) you've already seen the marlin main and config from it, that's why the duff code is still in there.
I started with a brand new version as previously I had just been copying my configuration, pins and thermistor table files over so one or all of those may have been old/corrupt and no longer compatible. I thought if I follow your instruction as though it's a fresh build with fresh copy of marlin we'd at least know the starting point is the same, does that make sense?
Once I get home I will try pronterface first and see what happens, if it works I will try the change and see if that helps Repetier or not. Hopefully it will fix the other problems. If not I will zip my new version that I'm using for you.
Thank you again, seriously you don't know how much I appreciate it.

[Roxy]

As soon as I get home I will try switching the max software endstop to false and see if that helps.

I edited that post up above... I screwed up and typed 'max' when it should have been 'min'.
Right now, you have the DISABLE_MIN_ENDSTOP's disabled...

//#define DISABLE_MIN_ENDSTOP

But I did a quick search of the code base and that isn't going to help your situation. That #define controls whether the hardware pins on the microprocessor are active and can be used to watch the switches. It isn't a software thing to enable going past the limits.

OK... With that all said... I ran a little test. I did a G28 and G29 and everytime it probed the bed I put my finger under the Z-Probe so it was thinking the bed was 1/2" higher than it really is. With my Configuration.h settings, I was able to use PronterFace to drive the nozzle well into negative Z space and go as far down as I wanted. This might be something else to test when you bring PronterFace up because it is possible the problem is with the Repetier client. And if not... I've attached my Configuration.h so you can compare the #defines and see what might help.

[brainscan]

I edited that post up above... I screwed up and typed 'max' when it should have been 'min'.
Right now, you have the DISABLE_MIN_ENDSTOP's disabled...

//#define DISABLE_MIN_ENDSTOP

But I did a quick search of the code base and that isn't going to help your situation. That #define controls whether the hardware pins on the microprocessor are active and can be used to watch the switches. It isn't a software thing to enable going past the limits.

OK... With that all said... I ran a little test. I did a G28 and G29 and everytime it probed the bed I put my finger under the Z-Probe so it was thinking the bed was 1/2" higher than it really is. With my Configuration.h settings, I was able to use PronterFace to drive the nozzle well into negative Z space and go as far down as I wanted. This might be something else to test when you bring PronterFace up because it is possible the problem is with the Repetier client. And if not... I've attached my Configuration.h so you can compare the #defines and see what might help.

Well we might be getting somewhere just not sure if its one forward two back. I installed pronterface and I can now move the nozzle down to the bed using the jogging control but it still moves away from the bed when issued a G1 command. I havent tried a test print to see if it will work on its own yet but not hopeful. I also tried to issue G29 n4 and G29 n5 and was given this error
>>>g29 n 5
SENDING:G29 N 5
Error:Line Number is not Last Line Number+1, Last Line: 0
[ERROR] Error:Line Number is not Last Line Number+1, Last Line: 0


Resend: 1
>>>g29 n 4
SENDING:G29 N 4
Error:Line Number is not Last Line Number+1, Last Line: 0
[ERROR] Error:Line Number is not Last Line Number+1, Last Line: 0

The v and t parameter still work.