Auto_Bed_Leveling: Enhanced G29 command

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

[sprocket1597]

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 ???

Repetier does seem to eat n's.. It changes "n" to "N" I couldnt figure out how to turn off check sum, but changing the code to use "u" does the trick.

[Roxy]

So is everything working?

[DarkAlchemist]

So is everything working?

Is it? I am unsure what the next step is supposed to be. It compiled and uploaded just fine.

[DarkAlchemist]

Repetier does seem to eat n's.. It changes "n" to "N" I couldnt figure out how to turn off check sum, but changing the code to use "u" does the trick.

*HIGH-FIVE* as I stuck a U/u there as well because Pronterface eats the n and N as well.

[Roxy]

*HIGH-FIVE* as I stuck a U/u there as well because Pronterface eats the n and N as well.

This is going to have to be changed. N is a nice symbol to use for the number of probe points, but it is causing too much pain.

[DarkAlchemist]

This is going to have to be changed. N is a nice symbol to use for the number of probe points, but it is causing too much pain.

I agree but I also find it alarming that these host programs are eating anything.

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