Auto bed level Z offset inconsistent

[DBFIU]

Oh Wait! The Z_PROBE_OFFSET is only used at the end of the G29 when it 'Corrects' the nozzle position. That M851 command won't do anything unless you do a G29 also. And of course, you don't want to do that in a middle of a print.

Yea I was wondering why it wasnt actually adjusting mid print.

Can you take a look at my pre gcode script and tell me if it somehow fudges something up before a print?

I use simplify3D exclusively.

G21 ;metric values
G90 ;absolute positioning
G28 ;move to endstops
G29 ;allows for auto-levelling
G1 X150 Y5 Z15.0 F3000 ;center and move the platform down 15mm
G92 E0 ;zero the extruded length
G1 F300 E30 ;extrude 30mm of feed stock
G92 E0 ;zero the extruded length again
G1 X175 Y25 Z0 F3000 ;remove bugger
G1 X200 F3000 ;remove bugger
G1 X150 Y150 Z15 F3000 ;recenter and begin
G1 F3000

[Roxy]

I think that GCode is all ok. Can you try disconnecting PronterFace, doing a reset of the board, re-connecting and see if it prints OK? If it does, that will give you a work-around for the next couple of weeks until the problem gets fixed for real. Oh! I also shut down and restart PronterFace but I'm not sure that is really doing anything.

[DBFIU]

I think that GCode is all ok. Can you try disconnecting PronterFace, doing a reset of the board, re-connecting and see if it prints OK? If it does, that will give you a work-around for the next couple of weeks until the problem gets fixed for real. Oh! I also shut down and restart PronterFace but I'm not sure that is really doing anything.

Hi Roxy,

I did all of the above and it seems to be more repeatable. But the air prints still show up, eventually. It's unpredictable, strange.

[DBFIU]

Hi Roxy,

I think I figured something out. I dont know if this is the sole root cause of my inconsistency, or if it is just an addition that makes the inconsistency worse, or the sum of many problems this being just one of them, not sure.

Anyway, I noticed that when my machine is configuring to probe a G29, the servo arm extending is not in the same place every time. Since this is a digital signal, a PWM being sent to the servo, this is odd to me. I know my angles in config.h, I set them up, the repeatability of the angles should be quite good in fact not even discernible to the human eye. In my case, the extend angle is so off, I can tell by eye.

Even a cheap 8 dollar servo should have repeatability closer then 1 degree or less, which is hard to see with the naked eye.

I do have this uncommented out,


//If defined, the Probe servo will be turned on only during movement and then turned off to avoid jerk
//The value is the delay to turn the servo off after powered on - depends on the servo speed; 300ms is good value, but you can try lower it.
// You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile.


#define PROBE_SERVO_DEACTIVATION_DELAY 300




and maybe this is the root cause of this issue, perhaps the servo arm is flying past its target and the inertia of the arm is allowing it to continue to move just a little bit. I remember this being an issue with a very large servo setup that I used a while back, the inertia of the extension arm being too much, so I went back to a micro servo. Maybe the problem is still there with the micro servo, albeit not as much but still there?? Or is there something else causing the overshoot?

[Roxy]

Unfortunately... I can't test this. I designed my probe to be stopped at the 'correct' location and my angles tell it to go just past that point. And the way the switch gets pressed, it kind of (very gently) tries to make the probe leg continue past the stop but it can't. As a result, that part of my mechanics is very consistent.

But even so... If your probe ends up in slightly different positions... If you don't have the probe going up and down for each point it should produce pretty consistent results. Going up and down for each point would not be ideal. Do you have the probe retracting and re-engaging for each point? If so, I think you want to put a stop to that!

[DBFIU]

Unfortunately... I can't test this. I designed my probe to be stopped at the 'correct' location and my angles tell it to go just past that point. And the way the switch gets pressed, it kind of (very gently) tries to make the probe leg continue past the stop but it can't. As a result, that part of my mechanics is very consistent.

But even so... If your probe ends up in slightly different positions... If you don't have the probe going up and down for each point it should produce pretty consistent results. Going up and down for each point would not be ideal. Do you have the probe retracting and re-engaging for each point? If so, I think you want to put a stop to that!

Hi Roxy,

The probe only goes up and down once. After it finishes the G28 it retracts, and then extends right before G29. This is unnecessary, how do I stop this from happening?

I think you are right, even if it overshoots a little bit, it shouldnt account for a change 3 or 4mm in offset. It is so strange.

[DBFIU]

I really need to figure out why this is happening. I have literally replaced everything, my ramps, mega, stiffined up my ABL system 3 times. Redesigned brackets to position everything as close to the nozzle as possible for minimal error. Brought my bed as close to level as possible, although that doesnt make a difference to finding z home.

I just dont know why the z offset that I load up in there, works one time and then its a different z offset another time. And I have to switch back and forth between these two values, they are over 3 mm apart, it cant be servo and brackets... I am worried about it, I have 3 machines with this problem and I am getting 4 more machines and I cant afford to re-upload firmware everytime I need to print.

It has to be software related, just has to be...

Is it a version of marlin that is doing this? What about the EEPROM thingy you were talking about? I have no idea how to verify or what to do to confirm if it is that. I need some more detailed guidance, thank you!

[Roxy]

Hi Roxy,
The probe only goes up and down once. After it finishes the G28 it retracts, and then extends right before G29. This is unnecessary, how do I stop this from happening?

It is that way because the G28 and G29 should be self contained and do everything they each need. But if you want to change it, you can just call the routine to probe the point in the G28 and tell it not to retract the probe.

It has to be software related, just has to be...

Is it a version of marlin that is doing this? What about the EEPROM thingy you were talking about? I have no idea how to verify or what to do to confirm if it is that. I need some more detailed guidance, thank you!

You already said up above that the line:

//#define EEPROM_SETTINGS

is commented out. If that is what you are really building, the EEPROM isn't the source of your problem. But the problems you are having sure sound like the kind of thing you would experience if you had a bad value in the EEPROM that was getting used.

Arduino can be very confusing about what project it is loading and compiling. Are you sure you are building the code in the directory you think you are? It might not hurt to go edit a file there so it has a syntax error and then bring up Arduino and verify that the compiler says you have an error where you changed things.

[DBFIU]

It is that way because the G28 and G29 should be self contained and do everything they each need. But if you want to change it, you can just call the routine to probe the point in the G28 and tell it not to retract the probe.



You already said up above that the line:

//#define EEPROM_SETTINGS

is commented out. If that is what you are really building, the EEPROM isn't the source of your problem. But the problems you are having sure sound like the kind of thing you would experience if you had a bad value in the EEPROM that was getting used.

Arduino can be very confusing about what project it is loading and compiling. Are you sure you are building the code in the directory you think you are? It might not hurt to go edit a file there so it has a syntax error and then bring up Arduino and verify that the compiler says you have an error where you changed things.

I "think" it is loading and compiling the marlin.ino file from the directory I am working in. I don't see it loading any other way? How would I verify if it is compiling other code?

I am pretty sure it is compiling and uploading the code I am telling it. If I change my z offset in marlin.ino, and upload it, I immediately see the new Z offset on my LCD display once it is finished uploading. It all seems to work just fine until I go to print and then the z offset, although numerically the same, is physically off by a few millimeters.

Yes //#define EEPROM_SETTINGS is commented out. So I am not sure where the bad value is coming from, if it is that at all. Could this be something else? Have we looked at all possible ways for this to happen?

[DBFIU]

I am looking through the config.h file of the new firmware zip file. There seems to be a few things that are different, not much, just a few lines of code that are extra and a few missing when compared side by side with my other version of marlin.