# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  Auto Bed Levelling Glitches

## MiniMadRyan

I apologize for creating a new thread about auto levelling...I hesitated in posting several different threads about my quarrels, so I thought it would be best if I started a new thread.

I've just finished installing and updating my printer with the auto bed levelling set up, and was wondering if this is normal

On a cold startup, entering G28 homes all my axis's like it normally does (goes to 0,0,0 and then the arm comes down on the servo and gets the z-end-stop)
I then run a G29, which then starts it's first probe at 0,0 like G28 and continues in its grid probe from the 0,0 origin. 

However, if I run G28, and then a second G28, once it homes the X,Y it goes to the middle of the bed. Running a G29 after this from the middle of the bed, the gird is much more centred on the bed vs only running g28 once. 

My question is, is this to be expected, and obviously, it's wise to run the G28 command twice before G29 so that it begins its probe from the centre of the bed? 

Secondly, I'm noticing a weird glitch in my servo itself. It seems that whenever the printer is powered, no matter which position the servo is in, it will twitch ever so slightly every few seconds. This becomes even more so when one of the axis' moves (for instance, during the levelling procedure( the servo twitches back and forth about 2 degrees. I thought maybe it was interference or maybe my wires were crossed, but everything appears to be working fine. Any ideas on the cause of that one?


Cheers

Ryan

----------


## Roxy

> I apologize for creating a new thread about auto levelling...I hesitated in posting several different threads about my quarrels, so I thought it would be best if I started a new thread.


Given how long and how chaotic most of the Auto Bed Leveling threads have become...   I suspect everybody is on-board for creating new threads for individual support issues.




> I've just finished installing and updating my printer with the auto bed leveling set up, and was wondering if this is normal
> 
> On a cold startup, entering G28 homes all my axis's like it normally does (goes to 0,0,0 and then the arm comes down on the servo and gets the z-end-stop)
> I then run a G29, which then starts it's first probe at 0,0 like G28 and continues in its grid probe from the 0,0 origin. 
> 
> However, if I run G28, and then a second G28, once it homes the X,Y it goes to the middle of the bed. Running a G29 after this from the middle of the bed, the gird is much more centred on the bed vs only running g28 once. 
> 
> My question is, is this to be expected, and obviously, it's wise to run the G28 command twice before G29 so that it begins its probe from the center of the bed?


From what you are saying, my guess is you have safe homing turned on.  Can you upload you Configuration.h file?    And it would be really helpful to upload a short video of it doing what you asking about.   




> Secondly, I'm noticing a weird glitch in my servo itself. It seems that whenever the printer is powered, no matter which position the servo is in, it will twitch ever so slightly every few seconds. This becomes even more so when one of the axis' moves (for instance, during the leveling procedure( the servo twitches back and forth about 2 degrees. I thought maybe it was interference or maybe my wires were crossed, but everything appears to be working fine. Any ideas on the cause of that one?


Most likely you can stop this by defining:

#define PROBE_SERVO_DEACTIVATION_DELAY 500

----------


## MiniMadRyan

Thanks Roxy, I appreciate the help! I've included my config.h and I will see if I can get a video tonight of the jerk. Looking at the comments though in config.h I think you're right about the deactivation delay....whoops, I should have looked more closely at the code!

Edit, I threw together a quick animation to illustrate what I mean since I'm away from my printer, check it out here! http://minimadryan.com/i3v_example.swf

Ryan

Configuration.h

----------


## Roxy

I would like to see an actual video...  But with that said, EXACTLY which version of Auto Bed Leveling are you running?   Are you running the Dacb fork of the Marlin firmware?  Or maybe the enhanced version at this thread:   http://3dprintboard.com/showthread.p...ed-G29-command

Because, that is not normal.   I could believe something like this is happening if you are running the Dacb Marlin Fork because there is code in there to limit the probing to the size of the object that is going to be printed.   If that is the case, we need to do some more work to make sure the coordinates between the GCode post-processing match the printers probe locations.

Tell you what....  Can you also post your Marlin_main.cpp ?    Between the Configuration.h and the Marlin_main.cpp it should not be too hard to figure out why bad things are happening.

----------


## jtice

I have noticed something sorta like this with mine.
I have safe homing turned on, and most the time, it all works just as it should.
But, there are random times when it goes to home with the 28 command, that it will not goto the center of the bed, it will home the Z axis at the X-Y home.
When it does this, it effects the locations where it does its 9 auto leveling readings. The first row of readings will be in the far back, where it homed Y.
It still works, but once it starts the print, it will also be effected, and prints it off center, toward the X-Y home corner.

----------


## MiniMadRyan

Thanks guys, sorry for not uploading the video's earlier, I was at work, and all I really had access to was creating that animation. 

Anyways, here's the videos. The first link here is powering the printer, and then a single G28 followed by a G29. The second video is the same cold start with G28 then a secondary G28 followed by a G29. 

Video 1: https://www.youtube.com/watch?v=HPX7U34GF2I
Video 2: https://www.youtube.com/watch?v=D3AJEj16r1U

Interestingly, as long as Repeater Host is kept running through out, any secondary G28 command will behave like it does in the second video. That is to say that I can disconnect, power cycle and reconnect the printer, and as long as I've kept RH open, the second or any subsequent G28 commands will zero the axis and then return to centre.

I'm running Dacb's firmware mod as at the time it had everything I needed in there, and pretty much configured already for me. I've included my Marlin_main.cpp as well  :Smile: 

Marlin_main.cpp

----------


## jtice

Hmm mine acts a bit differently than that.
Like I said, sometimes it safe homes, other times it just homes in the corner.
If it homes just in the corner, the 9 location grip that it tests for leveling will start more toward that back corner.
If it safe homes in the middle of the bed as it should, then the 9 location pattern is centered along the bed.
I have never tried running 2 G28 commands before the G29 command though.

----------


## Roxy

> I'm running Dacb's firmware mod as at the time it had everything I needed in there, and pretty much configured already for me. I've included my Marlin_main.cpp as well


I looked at the Marlin_main.cpp vs. my Marlin_main.cpp.   I have some questions about the sled docking but I think that is OK.   I'll know more in a bit.
Did you run the Post Processing GCode script to limit the size of the probed area?   

Are you giving it the G28 and G29 commands via the keyboard?  Or are they coming from a GCode file?  It would be helpful to see the GCode file you are trying to print also.

----------


## MiniMadRyan

No, can't say I have. Just followed along with the notes on Github and ZennMaster's notes for it on his blog too. I haven't run a print with it yet, or processed any gcode, just what you've seen in the video

----------


## Roxy

Isn't your origin in the back right of the printer?  If so, you have it specified wrong in the Configuration.h file.   

Do you have a reason to have your Z axis movement so slow?  It is at 2 right now.   I'm thinking you can bump that 

#define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec)

up to 5 or 6 very safely.  And you have the Z acceleration very low also.   

#define DEFAULT_MAX_ACCELERATION      {1000,1000,5,1000}   

and similarly, on the

#define HOMING_FEEDRATE {50*60, 50*60, 50, 0}  // set the homing speeds (mm/min)

That Z being at 50 can be bumped up to maybe 250.     That will make the video's much less painful to watch!!!   :Smile: 

But here is the first stuff I question.  You have:

    #define LEFT_PROBE_BED_POSITION 50
    #define RIGHT_PROBE_BED_POSITION 150
    #define BACK_PROBE_BED_POSITION 150
    #define FRONT_PROBE_BED_POSITION 50

But you have your bed size set at:

#define X_MAX_POS 250
#define X_MIN_POS 0
#define Y_MAX_POS 250
#define Y_MIN_POS 0
#define Z_MAX_POS 235
#define Z_MIN_POS 0

I think you should spread out your xxx_PROBE_BED POSITION's to use nearly the full range of the bed.   I have mine defined as:   

    #define LEFT_PROBE_BED_POSITION (X_PROBE_OFFSET_FROM_EXTRUDER+2)
    #define RIGHT_PROBE_BED_POSITION X_MAX_POS
    #define BACK_PROBE_BED_POSITION Y_MAX_POS
    #define FRONT_PROBE_BED_POSITION (Y_PROBE_OFFSET_FROM_EXTRUDER+2)

----------


## Roxy

I'm starting to lean towards the Sled Docking stuff having a bug in it in that Fork....    I need to keep looking at things...

----------


## MiniMadRyan

> Isn't your origin in the back right of the printer?  If so, you have it specified wrong in the Configuration.h file.   
> 
> Do you have a reason to have your Z axis movement so slow?  It is at 2 right now.   I'm thinking you can bump that 
> 
> #define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec)
> 
> up to 5 or 6 very safely.  And you have the Z acceleration very low also.   
> 
> #define DEFAULT_MAX_ACCELERATION      {1000,1000,5,1000}   
> ...


lets see if I can answer this in order haha. Regarding the z-speed, I left it how it originally came when I flashed the firmware. I haven't customized much in this firmware, aside from what was noted to get the levelling to work, as I intended to play around with things after it was working successfully. 

Regarding the bed size, I had read previously that there could be issues if the probe was placed too close to the outer limits of the bed, for testing purposes, I just set the values to be somewhere closer to the middle. Thank you though, I will be flashing those changes tonight  :Smile:  

So do you think there is something amuck with that particular fork from dacb? I wonder where else G28 is defined in the firmware......

----------


## Roxy

> So do you think there is something amuck with that particular fork from dacb? I wonder where else G28 is defined in the firmware......


I'm thinking the Sled Docking is at the root of this.   Sled Docking got added to the main Marlin release.  And there were errors in the #ifdef's that caused a lot of compilation issues.    The way Dacb dealt with the errors and what I have are different.   So I'm going to go through those differences and see if I can find something that explains this behavior.

I have a post outstanding to Dacb on another issue in the G29 related to the declared bed size.   I don't think that is your problem but it should be dealt with.

I'm not sure how to proceed, but depending upon what I find, it might make sense to make the changes to your Marlin_main.cpp and upload it here for you to try.

----------


## MiniMadRyan

I'd be willing to do that! I was just going through the the docking code in marlin_main. I didn't realize that it was a newer addition to the release. I find it interesting that essentially the same command can have two different outcomes. Hmm...

----------


## AbuMaia

I have two G28s in my start gcode, automatically added when I slice a part. The first one "resets" the printer after a potentially tall previous print, then the bed heats, then the second G28 preparatory to a G29. I've not had any issues with where homing happens. I have the safe homing set to home Z at X10 Y10 instead of the middle, though.

I'm using the latest "main" Marlin from EricZalm, with some of the changes from becdac's fork merged across.

----------


## AbuMaia

> Do you have a reason to have your Z axis movement so slow?  It is at 2 right now.   I'm thinking you can bump that 
> 
> #define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec)
> 
> up to 5 or 6 very safely.  And you have the Z acceleration very low also.   
> 
> #define DEFAULT_MAX_ACCELERATION      {1000,1000,5,1000}   
> 
> and similarly, on the
> ...


On my printer, any Z max feedrate above 2 makes an odd sound, even at 2.25. Anything above 3 stalls the motors completely. Z homing feedrate of250 seems to be working, though a little buzzy on the slow drop to re-click.

----------


## Roxy

MiniMadRyan,    I changed the Sled Docking stuff (and a few other things) to how I have my code.    Be sure to save your current file set, but then replace your Marlin_main.cpp with the attached file.    I took some amount of care, but there are a lot of changes so I'm not positive it will compile clean.    Please try it and let us know what you see.

----------


## MiniMadRyan

Hi Roxy, thank you for your help! I will try it tonight when I get home from work! Mind me asking, how did you wrap your head around working with the Firmware files? I write apps for a living, but frankly, looking through some of the code yesterday made my head hurt....maybe I just didn't have enough coffee yet!

----------


## Roxy

When I built my printer, I had some problems with it doing crazy things...   I spent a lot of time understanding how the firmware worked so I could add debug code to it.   I don't understand all parts of it.   But I do understand most of the stuff I have enabled.   One thing about this firmware is there is no operating system sitting under you to provide support.  What ever it needs, it provides.   So, that does complicate things from one perspective.  But from another view point, everything is there and only stuff it needs is in the code.   So from that stand point it simplifies things.

The Marlin firmware is really just one big loop that reads in GCode commands and processes them one by one.   So, from that stand point, it is pretty simple.

----------


## MiniMadRyan

Thanks Roxy, like always I really appreciate your help! The new marlin_main compiled fine against my existing firmware. Manually running G28 like before homes the x and y and then repositions at the middle of the bed to home the z. Subsequent G28's do the same. G29 then probes from the beginning of the bed and then returns the probe once done. 

I was a bit excited, and loaded up a test cube and sliced it and clicked print after that G29. low and behold it crashed the y axis, which after crashing proceeded to extrude at the same offset distance. I chalked it up to me being a dummy and not putting the g28 and G29 code into my start gcode. 

My existing start code looks like so:




> G21 ; set units to millimeters
> M107
> M190 S55 ; wait for bed temperature to be reached
> M104 S190 ; set temperature
> G28 ; home all axes
> G1 Z5 F5000 ; lift nozzle
> M109 S190 ; wait for temperature to be reached
> G90 ; use absolute coordinates
> G92 E0
> ...


And I'm believing then that my new code should look like this? 




> G21 ; set units to millimeters
> M107
> M190 S55 ; wait for bed temperature to be reached
> M104 S190 ; set temperature
> G28 ; home all axes
> G29; auto level
> M109 S190 ; wait for temperature to be reached
> G1 F600.000 E-1.00000
> G92 E0


I've removed the G1 Z5, G90, G92, M82 and added in the G29 after the G28. 

Would I also have to then adjust anything else in slic3r or otherwise then? I was a bit worried with effectively having the print head starting from the middle of the bed, which caused the Y crash, but it could be just cause I never had g28 and g29 in my start code...

I just wanted to say thank you again too, especially for some of my dumb questions. I've admittedly been rushed with so many projects on the go, that I've probably over looked things I shouldn't have!

----------


## Roxy

> Thanks Roxy, like always I really appreciate your help! The new marlin_main compiled fine against my existing firmware. Manually running G28 like before homes the x and y and then repositions at the middle of the bed to home the z. Subsequent G28's do the same. G29 then probes from the beginning of the bed and then returns the probe once done.


The G29 should leave the probe over the last point measured.   If you do the G28 and G29 by hand you will know if that is what happens.

You have:

 #define Z_SAFE_HOMING

Enabled, so the G28 will move to where ever you specified (some where near the center of the bed) to make its measurement.




> I was a bit excited, and loaded up a test cube and sliced it and clicked print after that G29. low and behold it crashed the y axis, which after crashing proceeded to extrude at the same offset distance. I chalked it up to me being a dummy and not putting the g28 and G29 code into my start gcode. 
> 
> My existing start code looks like so:
> ...


For most people, the G28 should be followed immediately by the G29.   There may be a reason to do something different.  But in general, most people do a G28 and then a G29.




> Would I also have to then adjust anything else in slic3r or otherwise then? I was a bit worried with effectively having the print head starting from the middle of the bed, which caused the Y crash, but it could be just cause I never had g28 and g29 in my start code...


I suggest you do what ever startup GCode you want to put into your slicer by hand, one command at a time.   Do a G28 and then a G29.   And then a M114 to see if it is at the location that look reasonable given where the probe is.  If it is... You should be ok telling it to start a print.   It is troublesome that it crashed your Y Axis.  But if you do these three commands by hand, we will know a lot more about what is going on. 




> I just wanted to say thank you again too, especially for some of my dumb questions. I've admittedly been rushed with so many projects on the go, that I've probably over looked things I shouldn't have!


This stuff is really hard.  And it is a shame to wreck all the hard work it takes to get a printer going just because nobody is there to answer 'simple' questions.   Its only simple after you have been through it a few times.

----------


## MiniMadRyan

Thanks Roxy, to answer your questions, my routine has been connect printer, load repetier and then manually enter g28 and then g29. Like you said, doing so, after the sequence is done, the head remains roughly at the center of the bed. I then loaded a test cube, sliced it and hit print. 

I will give it another shot tomorrow, add the g28 and g29 to my start code and see what happens. Interestingly, when the y axis crashed it did so for a few seconds, it was very strange as it was definitely triggering the end stop. Then it just kept printing. The only odd thing was after the crash and killing the print, any subsequent g28 and g29 commands resulted in it homing at 0,0 and not the middle of the bed. It wasn't until I cycled power did it correct back to the middle of the bed.

----------


## MiniMadRyan

Looking at my start gCode for my print last night, I'm leaning towards the g28 in my start code as part of the culprit. As I had run G28 and a G29 manually before starting the print, I assume then that the G28 that was included in the start code of the print erased any data collected by the g29 manually. Thinking that's what probably led to the crash and issues I experienced. Will definitely be fixing that tonight!

----------


## Roxy

> Looking at my start gCode for my print last night, I'm leaning towards the g28 in my start code as part of the culprit. As I had run G28 and a G29 manually before starting the print, I assume then that the G28 that was included in the start code of the print erased any data collected by the g29 manually. Thinking that's what probably led to the crash and issues I experienced. Will definitely be fixing that tonight!


Yes, normally the G28 resets the bed level correction matrix to unity.   But that shouldn't cause the Y-Axis to crash.   The change in how far the nozzle travels in the X and Y distance should be very very small.    One thing you can do besides the G28, G29 and M114 is to actually issue a command to move.  You could say G1 X50 Y50 and see if it goes towards the origin.   If that is OK, do a G1 X20 Y20 and see if gets even closer.   And you can also just move one axis and say G1 Y5

----------


## MiniMadRyan

Alright, I'm losing my mind here....this is weird...

I fired up the printer again tonight, having not modified or changed anything from last night. Connected it, and my first command was a G28. The X and Y zero'd out, and then the Z took its probe, so after it was finished, the printer was at 0,0. It did not return to the centre of the bed like before. I then ran a G29, and it ran its probing from 0,0. I ran a few more G28 and they all homed at 0,0 without returning to the centre.

I then unplugged the printer, closed Repetier and started again. the first G28 did the same thing, 0,0. A second G28 then moved the head to the centre, and homes the Z axis there. G29 Probes from roughly the middle like what was intended.

So last night I reported that it was always returning to the middle of the bed, well...I guess it's not...it still always homes at 0,0 on the first G28, and only does it return to centre on subsequent G28's.


Edit.....CSI: Bed Levelling Edition is getting stranger...here's my output from Repetier....let's have a look:

In the screenshot, you can see i've connected the printer, and it's online at 7:52:45

Screen Shot 2014-11-06 at 7.54.07 PM.jpg

At 7:52:52 I issue an G28 command. The G28 Homes to 0,0 and takes the Z probe from that location. It does not return to centre at any point.
I issue a M114 at 7:53:14, and the results are: X:93 Y:131 Z:10.00

Another G28 is run after this at 7:53:27, this time, the X,Y go to 0,0 and then return to the centre of the bed where it takes the Z probe. The G28 completes and the extruder is in the middle of the bed. 
My last M114 is taken at 7:54:01 with the results of X:93 Y:131 Z:10.00

Summary?....two identical commands, two completely different results on the physical printer, and yet the output are both identical.....WEIRD!


For fun, I then ran a G29 followed by a M114, the results being X:118 Y: 156 Z:4.95, This correlates with the position of the extruder after it's done it's final probe
I ran one last G28 and M114 after that G29, the results then being the same X:93 Y:131 Z:10

Screen Shot 2014-11-06 at 8.00.28 PM.jpg

So, I think I can understand why my Y crashed last night. When the print ran, it ran a G28 as usual, the resulting physical position of the extruder was 0,0. I can only assume that the values returned were in fact X93 and Y131, which, with the bed physically being at 0, would have caused the grinding crash when it attempted to move the bed. 

Last Edit.....I'm an moron...I assumed that a single G28 command was the same as manually homing each axis, either through code or Repetier's on screen controls. Apparently I was oh so wrong....I can't believe I over looked that!.....well it no longer crashes, but when it prints, the head is still far too high above the print bed.....time to play some more!

----------


## Roxy

> Last Edit.....I'm an moron...I assumed that a single G28 command was the same as manually homing each axis, either through code or Repetier's on screen controls. Apparently I was oh so wrong....I can't believe I over looked that!.....well it no longer crashes, but when it prints, the head is still far too high above the print bed.....time to play some more!


Ah...   I think it should be the same.   I couldn't read the attached screen shots because they were so small.  So I bumped up the size.  

   But if it is working except for the height of the nozzle, that is easy to dial in and get correct.




> At 7:52:52 I issue an G28 command. The G28 Homes to 0,0 and takes the Z probe from that location. It does not return to centre at any point.
> I issue a M114 at 7:53:14, and the results are: X:93 Y:131 Z:10.00


So you issue the G28, it moves to (0,0), measures a point and then without moving any where else, a M114 claims it is at (93,131,10)  ?
It kind of looks like it isn't moving to the right place for the G28 ????

----------


## AbuMaia

If he has safe Z homing enabled, and G28 does not move to the middle (or to his specified coordinates) then something is wrong. It should move prior to Z homing on every G28, not just a second command.

----------


## Roxy

> If he has safe Z homing enabled, and G28 does not move to the middle (or to his specified coordinates) then something is wrong. It should move prior to Z homing on every G28, not just a second command.


Agreed...    I'm hoping he can confirm that.   If so, I'll start looking at the code he is running and see if I can figure out a way that is happening.

----------


## MiniMadRyan

I'm just working on some welding projects in between the snow here so I will post a video later today, but here's what I've observed

Power the printer and connect to repetier. At this point the head is in a random position on the bed. 
I type in a single g28 and it goes to 0,0 and homes thru read at 0,0 and then retracts the probe and stops. It does not return to Centre of the bed

Any additional g28 will then return to the Centre of the bed. 

What I observed last night was that after I connected, if I used repetiers controls to home the x and y axis first and then run my initial g28, it would then return to the Centre. 

I assumed that a g28 command was the same as homing each of thru axis manually, when in reality I still needed to home the x and y axis before issuing a g28...if that makes sense!

----------


## Roxy

We might have to add some debug code so we know what it is thinking during the G28 process.   It might take a few iterations of loading firmware but I suspect this isnt too difficult of a problem to isolate.

----------


## MiniMadRyan

Well here is my quick recap showing what happens with g28. I didn't include a g29 in it, but I'm sure you know what happens by now. Aside from this behavior, my z height is way off. When the print starts, the head is about 12mm off the bed. I re did the measurements and had an offset of roughly 8.60, but still it was way put of whack. I will try a few little things and see if it fixes it. I wonder if the g28 glitch had anything to do with it...

https://www.youtube.com/watch?v=Yi5dZ453f4Y

https://www.youtube.com/watch?v=krgCB0PZdtw


Ryan

----------


## AbuMaia

I had the problem of my print head being too high off the bed after a G28, too. I would do a G28, then a G1 Z0, then manually in Pronterface lower the head until the nozzle just gripped a piece of paper. This showed me it was 4mm too high. To fix it, I modified this line in marilin_main.cpp: 



```
      #ifdef ENABLE_AUTO_BED_LEVELING
        if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
          current_position[Z_AXIS] += zprobe_zoffset;  //Add Z_Probe offset (the distance is negative)
```

to be



```
      #ifdef ENABLE_AUTO_BED_LEVELING
        if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
          current_position[Z_AXIS] += zprobe_zoffset+4;  //Add Z_Probe offset (the distance is negative)
```

It was mainly just a feel-good fix, as I don't run G28 without a G29 afterwards, and G29 always got the Z offset correct.

----------


## Roxy

> Well here is my quick recap showing what happens with g28. I didn't include a g29 in it, but I'm sure you know what happens by now. Aside from this behavior, my z height is way off. When the print starts, the head is about 12mm off the bed. I re did the measurements and had an offset of roughly 8.60, but still it was way put of whack. I will try a few little things and see if it fixes it. I wonder if the g28 glitch had anything to do with it...
> 
> https://www.youtube.com/watch?v=Yi5dZ453f4Y
> 
> https://www.youtube.com/watch?v=krgCB0PZdtw
> 
> 
> Ryan


Wow...  That is really weird.   One more question before we dig in.   If you reset the printer with the nozzle somewhere in the middle of the bed:   What happens if you do a M114 prior to do the first G28?   The G28 should home regardless , but it is very strange that it doesn't head out to the center of the bed after the home.

The G28 code is complicated because of all the different conditional code in there.   But I see where we need to put the debug code.  We should be able to get a handle on this pretty quickly.  I'll try to get a version of your Marlin_main.cpp posted with debug code in it in the morning.   And maybe we can figure out where it is making the bad decisions.   Probably, it will take a couple of iterations because we will want to put debug code in the various paths to make sure it is going the right places.  But then, with that information, we will need more detailed debug information and have to add some extra print outs.

Incidentally, the code paths do vary significantly depending upon whether you home just one axis or all of them.   So even though it should behave the same, it is understandable that you see different results.

----------


## MiniMadRyan

Thank you both for helping, I can't tell you how much I appreciate it! 

I ran a M114 before anything else, the head in the middle of the bed, it returned 0,0,0. The first G28 then returned X93 and Y131 (when the head was actually 0,0 and then the second G28 which moves to the center of the bed, and yet still has thru same values.... weird....

----------


## AbuMaia

Question for Ryan, what happens if you run Auto Home from the LCD?

----------


## MiniMadRyan

Hmm.... so is it something in my Repetier then?... auto homing from the LCD panel works perfectly fine. Goes to 0,0 then returns to Centre and probes the 7

I haven't changed any settings on RH in ages... it's printed perfectly for my MakerFarm, and Printrbot too....

----------


## AbuMaia

I have no experience with Repetier, but I thought it'd be good to find a way to remove it from the chain, to see if it may be a contributing factor.

----------


## Roxy

> Hmm.... so is it something in my Repetier then?... auto homing from the LCD panel works perfectly fine. Goes to 0,0 then returns to Centre and probes the 7
> 
> I haven't changed any settings on RH in ages... it's printed perfectly for my MakerFarm, and Printrbot too....


I doubt this is being caused by Repetier...  But I don't use it.  Would you mind switching to PronterFace until we get this resolved?   I have never seen this kind of weird behavior and it might be best to remove any variable we can.    With that said...  Once we start running the debugging version of the code, we are going to be able to figure out what is causing the bad code paths to be taken.

----------


## Drone

I'm not experienced enough to really be of any help here, but thought I would mention I stopped using Repetier because of many inconsistencies I had similar to this. Since I switched to Pronterface I have not had the same types of issues. So I agree it would be very interesting to see if a different control software shows different results. I really like the UI of Repetier, but I just couldn't work through the issues. It looks to me that either Repetier or the hardware buffer is holding and reporting old values.

----------


## Roxy

> Thank you both for helping, I can't tell you how much I appreciate it! 
> 
> I ran a M114 before anything else, the head in the middle of the bed, it returned 0,0,0. The first G28 then returned X93 and Y131 (when the head was actually 0,0 and then the second G28 which moves to the center of the bed, and yet still has thru same values.... weird....


As always....  Save your existing file set!!!!   Then replace Marlin_main.cpp with the attached file.  It is going to be fairly verbose.  But we should get a clue of where things are going sideways.   Hopefully it compiles clean the first time.

----------


## orionthunter

I had a problem with my offsets not working correctly because I calibrated incorrectly the first time, and wrote them to the EPROM, then I fixed it in the firmware, but forgot to clear the EPROM.  So it kept using the old value.   This is probably not your issue,  but I thought I would mention it just in case.

----------


## Roxy

> I had a problem with my offsets not working correctly because I calibrated incorrectly the first time, and wrote them to the EPROM, then I fixed it in the firmware, but forgot to clear the EPROM.  So it kept using the old value.   This is probably not your issue,  but I thought I would mention it just in case.


A lot of people are falling into this trap.   And that is why there is an Invalidate EEPROM thread to give your firmware an extra command:

http://3dprintboard.com/showthread.p...lidate-Command

----------


## MiniMadRyan

Hmm thanks guys I will try the updated firmware tonight. I originally loaded Dacb's firmware shortly after building the printer,  and honestly never checked much else into it.... Will have to get a third printer just to write and learn custom firmware on  :Smile:

----------


## MiniMadRyan

So i've flashed the updated script you included Roxy, and switched over to Pronterface/Printrun, and the problem still exists, like it was previously. I've included the output of a cold start, M114, G28, M114, G28, M114, G29, M114 below. 

Here's an interesting tid-bit, as you're aware, from a cold start, with the head at a random position on the bed, the first G28 does not centre for the z probe. However, I power cycled the printer, leaving the head at 0,0 (with the end stops triggered) and the first G28 then actually returned to the middle of the bed to probe the Z...it's almost as if there's an if statement or something somewhere in the G28 that is stating "if x=0, y=0 then return to centre" but that it's only being called when the command is first initiated, and not after the triggers are actually triggered...

Hmm, here's something weird. I just ran a G28 after a power cycle, the G28 homed to 0,0. For giggles, I ran a G28 Z:0, and it probed and ran like it does normally. I then moved my x and y axis, and manually homed each one, then ran another G28 Z, and got the error that the probe was out of area...interesting!


Power on, connect and M114 before doing anything else:




> Connecting...
> start
> Printer is now online.
> echo: External Reset
> Marlin1.0.0
> echo: Last Updated: Nov  8 2014 17:55:19 | Author: (MakerFarm Inc, 10" i3v Prusa, dacb)
> Compiled: Nov  8 2014
> echo: Free Memory: 3519  PlannerBufferBytes: 1232
> echo:Stored settings retrieved
> ...



Initial G28 and M114, the head is at 0,0 and the Z is probed from there as well



> >>>G28
> SENDING:G28
> Starting G28
> 1 G28 home_all_axis
> G28 homing X axis.
> 0.00 = position of X axis.
> G28 homing Y axis.
> 0.00 = position of Y axis.
> G28 doing home of Z axis towards bed.
> ...


2nd G28, Homes to 0,0 then returns to centre and probes Z



> >>>G28
> SENDING:G28
> Starting G28
> 1 G28 home_all_axis
> G28 homing X axis.
> 0.00 = position of X axis.
> G28 homing Y axis.
> 0.00 = position of Y axis.
> G28 doing home of Z axis towards bed.
> ...


G29 after second G28, all probes are done around the middle of the bed



> >>>G29
> SENDING:G29
> Eqn coefficients: a: -0.00 b: -0.00 d: 1.33
> planeNormal x: 0.00 y: 0.00 z: 1.00
> 
> 
> Bed Level Correction Matrix:
> 0.999997 0.000000 -0.002513
> -0.000001 1.000000 -0.000342
> ...

----------


## Roxy

I'm on the way out the door...  Can you edit your post and high light which G28 is good.  And which is bad?    Or if you don't have both a good one and a bad one, go generate the output of a good and bad one?   I'll look through them in the morning and compare the code paths that are being taken.

----------


## MiniMadRyan

I've updated it Roxy, I hope that makes sense and is what you're looking for, even weirder, the output of the first two G28's are identical.......

----------


## Fri

Roxy,
I inserted your marlin main with debug code into my fw. I acts the same way. I had to comment out the G28 matrix deletion though to simulate my issue. 
What should I be looking for?

----------


## AbuMaia

Wait, why are you telling it to not reset the bed level matrix after a G28? If you have to do that in order to recreate your issue, then that's where your problem seems to be coming from.

----------


## Fri

This is how I had it setup before it started to act strange. It worked great. One abl per reset or whenever you think it is necessary. If I am uncommenting the G28 plan bed leveling, the z stop is not causing x and y to think they are home.
And yes, this is where it is coming from or is related to, without G29, all works fine.

----------


## Roxy

> Roxy,
> I inserted your marlin main with debug code into my fw. I acts the same way. I had to comment out the G28 matrix deletion though to simulate my issue. 
> What should I be looking for?


The initial line of the G28 to reset the bed level correction matrix to unity should be there unless you are saving the matrix to EEPROM.     Are you saving (and restoring) your matrix  to (and from) the EEPROM?

----------


## Fri

No I am not. I commented this out to not have to do g29  each print. It worked great.

----------


## AbuMaia

Well I'm utterly lost. I don't think I understand what you've told your printer to do enough in order to help figure out why it's not doing what you tell it to do.

----------


## Fri

> Well I'm utterly lost. I don't think I understand what you've told your printer to do enough in order to help figure out why it's not doing what you tell it to do.


Sorry, I started this a few days ago over in a different thread. What's happening in brief is that after I adjusted the z offset on a viki lcd the machine is acting up. It was working perfectly before, but I am not certain if the lcd offset change is in anyway related, it may well not be
but after I hit the offset change here is what it is doing.
After G28, G29 the z endstop (which is triggered at the last abl position) is triggering (not showing on M119) the x and y stops. So if you hit x home after the g29 x will not travel towards the x home switch, it will move away. If I raise z so the z endstop is not triggered anymore, x travels home fine and bounces of the stop as normal. If I trigger the z endstop while x is moving to its home position, x will bounce of that location. In other words, where ever on the bed z stop is triggered, the machine thinks x & y are home. Even though an M114 shows the right coordinates. I also have to say that every once in a while, when I hit x home with the machine being at the last abl point , x will travel to its home position, without a bounce.

I got the matrix deletion turned off in marlin main g28, but that was turned off before when it all worked perfectly.
Other than that it's a pretty normal fw.

----------


## AbuMaia

Sounds like it might be profitable to start from a completely fresh firmware file. Make only your necessary adjustments for your printer, then if it still happens, it may be a hardware issue.

----------


## Roxy

> Sounds like it might be profitable to start from a completely fresh firmware file. Make only your necessary adjustments for your printer, then if it still happens, it may be a hardware issue.


Agreed.   And I would suggest leaving the LCD panel turned off initially.  I was looking at the code for that and they are stuffing commands into the GCode buffer.  I can believe flakey things could happen.

----------


## Roxy

MiniMadRyan, do you have an LCD Panel on your printer?   Can you turn it off and see how it behaves?

I think you do have one???  I see this line in your Configuration.h file:

#define REPRAP_DISCOUNT_SMART_CONTROLLER

We definitely don't have enough facts to conclude this yet.   But it almost feels like something changed in the main Marlin code base that makes LCD Panels have trouble and act flakey.   If this is true, it will get fixed, but until it does, you probably don't want to use your LCD Panel for important things.   And one of the problems is the LCD Panels are all supported by the companies that make the panels.  It might take a while for them to get things back to where they should be.

In the short term, can you turn off the LCD Panel and see how your printer behaves?  If the problem goes away, it might be worth while calling up the support line for your LCD Panel and see if they are hearing other reports of bad behavior.

----------


## MiniMadRyan

> MiniMadRyan, do you have an LCD Panel on your printer?   Can you turn it off and see how it behaves?
> 
> I think you do have one???  I see this line in your Configuration.h file:
> 
> #define REPRAP_DISCOUNT_SMART_CONTROLLER
> 
> We definitely don't have enough facts to conclude this yet.   But it almost feels like something changed in the main Marlin code base that makes LCD Panels have trouble and act flakey.   If this is true, it will get fixed, but until it does, you probably don't want to use your LCD Panel for important things.   And one of the problems is the LCD Panels are all supported by the companies that make the panels.  It might take a while for them to get things back to where they should be.
> 
> In the short term, can you turn off the LCD Panel and see how your printer behaves?  If the problem goes away, it might be worth while calling up the support line for your LCD Panel and see if they are hearing other reports of bad behavior.



Hmmm, now that is odd. My kit is just the stand panel. I will comment out that line in my config.h as well as physically unplugging it. You think these issues could be related to the panel just like that?!?!

----------


## Roxy

> Hmmm, now that is odd. My kit is just the stand panel. I will comment out that line in my config.h as well as physically unplugging it. You think these issues could be related to the panel just like that?!?!


I don't know the answer.  I don't have an LCD Panel so I haven't looked much at that code.  I did write some stand alone routines to fake out a LCD Button Click so I could leverage and use the LCD Panel Filament change.  But that is the extent of my LCD Panel knowledge.   I did look at how they make things move using an LCD Panel and they are stuffing GCode commands into the command buffer.   I'm not entirely comfortable with that approach.   And sure enough, people with LCD Panels are starting to have unpredictable behavior of their Printers.

If I was going to bet, I would bet that unplugging your LCD Panel and commenting out the code for it will be successful. And that is just based on the fact that everybody with this weird behavior has an LCD Panel.    We won't know until you get that done and have a chance to mess around with your printer.

----------


## Fri

> I don't know the answer.  I don't have an LCD Panel so I haven't looked much at that code.  I did write some stand alone routines to fake out a LCD Button Click so I could leverage and use the LCD Panel Filament change.  But that is the extent of my LCD Panel knowledge.   I did look at how they make things move using an LCD Panel and they are stuffing GCode commands into the command buffer.   I'm not entirely comfortable with that approach.   And sure enough, people with LCD Panels are starting to have unpredictable behavior of their Printers.
> 
> Thanks guys for all the info and help. If I was going to bet, I would bet that unplugging your LCD Panel and commenting out the code for it will be successful. And that is just based on the fact that everybody with this weird behavior has an LCD Panel.    We won't know until you get that done and have a chance to mess around with your printer.


I did test and try it without the LCD and yes I agree with you to start with a new/clean firmware, and that is exactly what i have done. I will be trying this again when I am back next weekend. But the last tests over the last four days did not show any difference 
with or without LCD. What's really weird is that I am having a similar issue with another machine now. As if my pc is causing it.

Please send all your suggestions and stuff my way I try asap.

I am 3d printing since 4year and have never come across something quite like that, a working machine and fw, suddenly acting differently repeatably.

----------


## AbuMaia

I have an LCD on my machine, and haven't experienced these oddities. Though lately I have been running almost exclusively from my OctoPi setup. I cannot recall the last time I printed from the LCD's SD card, or even twiddled the knob.

I just downloaded today's EZ Marlin update and copied over the changes to my local file. All there was was a new comment about commenting out a line I already had commented out.

----------


## Roxy

> I am 3d printing since 4year and have never come across something quite like that, a working machine and fw, suddenly acting differently repeatably.


Well, some bad code has snuck into the Marlin code base.  We know that for a fact.  Certain main line configurations would not compile cleanly because of the sled docking stuff.  And most people don't have sled docking.    So...   It is hard to say.   The big problem is it is difficult to debug this kind of stuff without a machine doing the bad stuff in front of you.

----------


## MiniMadRyan

> I don't know the answer.  I don't have an LCD Panel so I haven't looked much at that code.  I did write some stand alone routines to fake out a LCD Button Click so I could leverage and use the LCD Panel Filament change.  But that is the extent of my LCD Panel knowledge.   I did look at how they make things move using an LCD Panel and they are stuffing GCode commands into the command buffer.   I'm not entirely comfortable with that approach.   And sure enough, people with LCD Panels are starting to have unpredictable behavior of their Printers.
> 
> If I was going to bet, I would bet that unplugging your LCD Panel and commenting out the code for it will be successful. And that is just based on the fact that everybody with this weird behavior has an LCD Panel.    We won't know until you get that done and have a chance to mess around with your printer.


Just commented out the lcd panel and physically disconnected it, recompiled, and uploaded. Ran the same G28. Now the printer will only probe the Z at 0,0, it never returns to the centre to probe the Z. Reloaded my previous firmware and reconnected the lcd panel, and the g28 performed like it did before...

so in short, with the lcd panel disconnected and commented out, the g28 never returns to centre, it always stays at 0,0 :/

----------


## MiniMadRyan

Hmm...on line 1573 of marlin_main.cpp




> if((home_all_axis) || (code_seen(axis_codes[Z_AXIS])))


I've removed the OR statement, and revised it to simply 




> if((code_seen(axis_codes[Z_AXIS])))


I'm wondering, even though this function controls the Z homing if the Z safe mode is disabled, I'm thinking it may be conflicting still. It shouldn't cause any serious issues unless I disable the Z safe homing, and as its still defined for G28 Z command, it shouldn't worry me as prior to this I never really used a home all axis command....will see what this does tonight! 

Thoughts?

----------


## Roxy

Just a simple G28 with no extra parameters will trigger the home_all_axis flag.   That is what most people do.  They put a G28 (followed by a G29) in their startup GCode for the slicer they are using.   If you specify nothing else on the G28 command, you are doing a home_all_axis.

----------


## MiniMadRyan

Hmm...well, I'm all out of ideas, that's the only place I've seen where there could maybe be a conflict. 

My only idea was that line 1573 is the statement for what to do when safe homing is disabled. Maybe in some weird alternate universe, it is somehow being called and functioning even though safe homing is enabled. My thought was that if i removed the or statement for the home_all_axis, that i could make it so that, that function is only called via  G28 Z, and not a global G28.

----------


## Roxy

In the debug print out...  These lines indicate the nozzle moved to the center of the bed and performed the Z-Home operation there.

G28 done Z Home towards bed.
93.00  131.00

Is this not true?  It might be valuable to add a few more lines of debug code in this area:


```
SERIAL_PROTOCOLPGM("G28 doing Z Home towards bed.\n");
SERIAL_PROTOCOL(current_position[X_AXIS]);
SERIAL_PROTOCOLPGM("  ");
SERIAL_PROTOCOL(current_position[Y_AXIS]);
SERIAL_PROTOCOLPGM("  \n");

            plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
            plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate, active_extruder);
            st_synchronize();

SERIAL_PROTOCOLPGM("G28 should be at center of bed.\n");
SERIAL_PROTOCOL(current_position[X_AXIS]);
SERIAL_PROTOCOLPGM(" ");
SERIAL_PROTOCOL(current_position[Y_AXIS]);
SERIAL_PROTOCOLPGM(" \n");

            current_position[X_AXIS] = destination[X_AXIS];
            current_position[Y_AXIS] = destination[Y_AXIS];

            HOMEAXIS(Z);
```

----------


## MiniMadRyan

Well that is the odd thing. I think I noted it before, but on my first G28 (where the head returns to 0,0 and does not move after that) the outputs stayed exactly that. it was only on the subsequent G28 did the head actually move to the centre of the bed, and even then the read outs were still the same. 

I will add in that debug code as well and see what happens


Ryan

----------


## MiniMadRyan

Right, here's my latest debug code, no change operationally....maybe I might just have to live with it as it is....though I guess I will have to figure out why my Z is more than 12mm off...

Initial G28, Head at 0,0, Z probe done at 0,0




> >>>M114
> SENDING:M114
> echo:SD init fail
> X:0.00 Y:0.00 Z:0.00 E:0.00 Count X: 0.00 Y:0.00 Z:0.00
> >>>G28
> SENDING:G28
> Starting G28
> 1 G28 home_all_axis
> G28 homing X axis.
> ...


Second G28, Homes X and Y then goes to middle of bed for Z




> >>>G28
> SENDING:G28
> Starting G28
> 1 G28 home_all_axis
> G28 homing X axis.
> 0.00 = position of X axis.
> G28 homing Y axis.
> 0.00 = position of Y axis.
> G28 doing home of Z axis towards bed.
> ...

----------


## MiniMadRyan

Here's a quick video of it in action

https://www.youtube.com/watch?v=3Bw4Oufiob0

----------


## Roxy

This really doesn't make sense.   Unless interrupts are getting turned off or something.   Let's add a couple of delay's().   Because you said the 2nd one went to the center of the bed, but it is claiming it is at (0,0).   Adding the delay's() might give the servos time to wake up and move.  But right now, I'm just guessing.



```
          if(home_all_axis) {
            destination[X_AXIS] = round(Z_SAFE_HOMING_X_POINT - X_PROBE_OFFSET_FROM_EXTRUDER);
            destination[Y_AXIS] = round(Z_SAFE_HOMING_Y_POINT - Y_PROBE_OFFSET_FROM_EXTRUDER);
            destination[Z_AXIS] = Z_RAISE_BEFORE_HOMING * home_dir(Z_AXIS) * (-1);    // Set destination away from bed
            feedrate = XY_TRAVEL_SPEED;
            current_position[Z_AXIS] = 0;
SERIAL_PROTOCOLPGM("G28 doing Z Home towards bed.\n");
SERIAL_PROTOCOL(current_position[X_AXIS]);
SERIAL_PROTOCOLPGM("  ");
SERIAL_PROTOCOL(current_position[Y_AXIS]);
SERIAL_PROTOCOLPGM("  \n");

delay(5000);

            plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
            plan_buffer_line(destination[X_AXIS], destination[Y_AXIS], destination[Z_AXIS], destination[E_AXIS], feedrate, active_extruder);
            st_synchronize();
            current_position[X_AXIS] = destination[X_AXIS];
            current_position[Y_AXIS] = destination[Y_AXIS];

delay(5000);

SERIAL_PROTOCOLPGM("G28 should be at center of bed.\n");
SERIAL_PROTOCOL(current_position[X_AXIS]);
SERIAL_PROTOCOLPGM(" ");
SERIAL_PROTOCOL(current_position[Y_AXIS]);
SERIAL_PROTOCOLPGM(" \n");

            HOMEAXIS(Z);

SERIAL_PROTOCOLPGM("G28 done Z Home towards bed.\n");
SERIAL_PROTOCOL(current_position[X_AXIS]);
SERIAL_PROTOCOLPGM("  ");
SERIAL_PROTOCOL(current_position[Y_AXIS]);
SERIAL_PROTOCOLPGM("  \n");
```

----------


## MiniMadRyan

I'll give that a shot tomorrow. I truly wonder what is going on. The firmware is the stock from Dacbs release, minus the changes we've made here, and my printer itself is pretty stock, so ī wonder if others are experiencing this too....

----------


## AbuMaia

Why not give the EricZalm Marlin a try? It is the "true stock", the one Dacb's is forked from. 

https://github.com/ErikZalm/Marlin#

----------


## Roxy

> Why not give the EricZalm Marlin a try? It is the "true stock", the one Dacb's is forked from. 
> 
> https://github.com/ErikZalm/Marlin#


That may not be a bad idea.   I'm trying to get moved over to Dacb's fork, but I haven't had time to do the port.  The other thing that may make sense is to upload the entire source tree for your Marlin and do a diff of every file.  Something small is wrong, but who knows where it is?   Moving to the original Eric Zalm branch of the tree would tell us where the problem is.   But we still do need to find the root cause of this.

The more I think about it...  I think it makes sense to .ZIP up your entire Marlin source tree.  I've got the tools to quickly go through looking at every change.  If some line of code got accidentally deleted (or changed for no reason), I'll be able to find it pretty quickly.   (But go ahead and add those delay's()  that is going to be interesting either way)

----------


## MiniMadRyan

Thanks guys, I will do that. I was just in the process of downloading EricZalm's Marlin. Obviously I will have to edit my config.h to suite our Prusa's, but I will give that a shot and see how it goes. Anything else to look out for?

Here's my last Marlin, with the delay code. I'm finally getting around to switching back to Visual Studio with Visual Micro, the Arduino IDE is giving me a headache haha!

Marlin.zip

----------


## Roxy

> Thanks guys, I will do that. I was just in the process of downloading EricZalm's Marlin. Obviously I will have to edit my config.h to suite our Prusa's, but I will give that a shot and see how it goes. Anything else to look out for?
> 
> Here's my last Marlin, with the delay code. I'm finally getting around to switching back to Visual Studio with Visual Micro, the Arduino IDE is giving me a headache haha!
> 
> Marlin.zip


You and I are running almost identical code bases.  I have the M600 filament change patched to work without an LCD Panel.   And I have the M499 EEPROM Invalidate command.  But other than that...   We have identical code bases.   I checked every source file for differences.   There is nothing that would explain this strange behavior.   I hate to say this...  But I doubt switching to Erik Zalm's code base is going to rectify anything.  It is still worth trying...  But if I had to bet, I think you will see the same thing.

----------


## AbuMaia

Well, I don't see anything too different from my Marlin. At least nothing I wouldn't expect to be different, except for one place. Marlin_main.cpp, line 1219, you have the if (axis==Z_AXIS) retract_z_probe(); commented out. Why?  

From what I see here comparing our firmware, it looks like it's a hardware issue. Maybe some switches are plugged into the wrong pins.

----------


## Roxy

> From what I see here comparing our firmware, it looks like it's a hardware issue. Maybe some switches are plugged into the wrong pins.


I did notice he has his switches inverted from mine.  But I don't think it would even home if that was wrong.

----------


## MiniMadRyan

Hmmm, well that's what I can't believe to begin with, aside from the changes Roxy has suggested, I haven't modified the firmware in any way, aside from the obvious to enable auto levelling etc. I'm curious thought about the (axis==Z_AXIS) retract_z_probe(); being commented out, as I don't think I ever came across that or would comment that out. 

Roxy, you mentioned my end stops were inverted? How so?

----------


## Roxy

> Hmmm, well that's what I can't believe to begin with, aside from the changes Roxy has suggested, I haven't modified the firmware in any way, aside from the obvious to enable auto levelling etc. I'm curious thought about the (axis==Z_AXIS) retract_z_probe(); being commented out, as I don't think I ever came across that or would comment that out.


Ever since the Auto Bed Leveling came out... Different people have had trouble with their Z-Probes banging into the bed during retraction.  Also, there was problems with the probe staying down and rubbing as the nozzle is positioned somewhere else on the bed.   So there have been various attempts to 'fix' the problem.  And there is some baggage in the code because of that.   I wouldn't be too concerned about that unless you are having troubles with your Z-Probe staying down when you don't want it down.   And the Enhanced G29 is pretty hard core about making sure the Z-Probe is in a good state.  So if you care, you might want to move over to the Enhanced G29 code.




> Roxy, you mentioned my end stops were inverted? How so?


I didn't look at it carefully enough.  It turns out it is a "don't care" because I don't think you have Max End Stops wired up.  You don't home towards Max.    But here is what I was referring to:

Inverted.jpg

----------


## AbuMaia

My endstops are set up the same way, Roxy. I wouldn't worry about it.

----------


## MiniMadRyan

Hmm...well, I guess maybe I'll have to live with it. I may just put an extra G28 in my start gcode then, which would correct that issue. I will test it again tonight and run a print. My only outstanding issue was that even after re-calibrating my offset, my extruder was still about 12mm above the bed when it started printing. I thought perhaps this was related to this issue as well, but I guess not!

----------


## AbuMaia

Did you read my post about how I fixed my extruder being too high after a G28?

----------


## MiniMadRyan

Ahhhh awesome just saw what you wrote.  That will work perfectly I think! Thank you!

----------


## AbuMaia

It would be line 1668 in your marlin_main.cpp

current_position[Z_AXIS] += zprobe_zoffset+Z_RAISE_BETWEEN_PROBINGS ;  //Add Z_Probe offset distance and extra from  HOMEAXIS(Z);

Replace the "Z_RAISE_BETWEEN_PROBINGS" with how high your nozzle is when it thinks it's at Z0

----------


## MiniMadRyan

Well this is just messed up now....

With my original untouched code, after a G28 command, my Z was reported at 10. After a G1 Z0, my actual offset to the bed was 7.8. I then ran  G29, after which my Z returned a 4.52...I then calculated my actual offset to be -8.92.  I decided to  run a print, which does a second G28 then G29. After the G29, the actual print begins, with the head well above the print surface. Killing the print doesn't move the z axis, so I take another M114. The Z is reported at 0.04. That's acceptable, as the first layer of my print should be 0.350. A second G1 Z0, and subsequent offset shows that my true value should be: -9.01. 

My only thinking is that my Z_RAISE_BEFORE_PROBING is set to 15, and my Z_RAISE_BETWEEN_PROBINGS is set to 5, but these numbers don't correlate. My only "ah-hah!" moment was that after a G28 and then  G1 Z0, I realized that as per your comments, my adjusted code would be:

current_position[Z_AXIS] += zprobe_zoffset + 12.80;  

The 12.80 coming from the RAISE_BETWEEN_PROBINGS (5) plus the actual difference (7.8)

I'm truly at a loss as for what's going on here tonight. Maybe I'm just cursed when it comes to auto levelling, or maybe there's not enough coffee in my system, The numbers just don't make sense!


Ohh, and as a follow up to my previous issue, I had a strange occurrence tonight, that my G28 would always home to 0,0 and not back to the centre, unless I entered an M114 at some point. It did it on two occasions, and restarting everything fixed it...but, man...wow....weird!

----------


## AbuMaia

Let's see if we can't make this make sense. According to the marlin you uploaded, your Z_PROBE_OFFSET_FROM_EXTRUDER is 8.60. Adding your Z_RAISE_BETWEEN_PROBINGS gives us 13.6.

Fresh start of the printer. Run G28. Do it twice so it homes in the middle of the bed. What does M114 say? Z should be 13.6.
Then do G1 Z0. Extruder not touching the bed?
Lower Z until the extruder touches the bed. What does M114 say?

----------


## Roxy

> Well this is just messed up now....
> 
> With my original untouched code, after a G28 command, my Z was reported at 10. After a G1 Z0, my actual offset to the bed was 7.8. I then ran  G29, after which my Z returned a 4.52...I then calculated my actual offset to be -8.92.  I decided to  run a print, which does a second G28 then G29. After the G29, the actual print begins, with the head well above the print surface. Killing the print doesn't move the z axis, so I take another M114. The Z is reported at 0.04. That's acceptable, as the first layer of my print should be 0.350. A second G1 Z0, and subsequent offset shows that my true value should be: -9.01. 
> 
> My only thinking is that my Z_RAISE_BEFORE_PROBING is set to 15, and my Z_RAISE_BETWEEN_PROBINGS is set to 5, but these numbers don't correlate. My only "ah-hah!" moment was that after a G28 and then  G1 Z0, I realized that as per your comments, my adjusted code would be:
> 
> current_position[Z_AXIS] += zprobe_zoffset + 12.80;  
> 
> The 12.80 coming from the RAISE_BETWEEN_PROBINGS (5) plus the actual difference (7.8)
> ...


There is a difference between where the G28 leaves the nozzle and what the G29 does with it.   This needs to get unified.  But right now, they do things differently.  If you care to look at the code and see what I'm talking about, they use different routines and methodologies to probe the bed.  And as a result of that, you get different numbers at the completion (and during the middle) of each.   Don't get too hung up on that right now.  Let's focus on your problem.

What I do is start with extra space between the nozzle and bed.  I print in the air the first couple of times.   Assuming the Z_RAISE_????  settings are not causing any problems, you only need to mess with the Z_PROBE_OFFSET_FROM_EXTRUDER number.   How ever much it is above the bed, lower that number by half of that amount to get the error less.   (Realize that lowering that number, means making the number bigger because it is negative!!!!)   Take your time zero-ing it in. If you go to far, you will crash the nozzle into the bed and drag it across the glass. You can damage things by moving this number to far.  

  Once it is not printing in the air.  Start deciding if you want it to squish out the line more or less to make a good first layer.    A couple more iterations of changing the Z_PROBE_OFFSET_FROM_EXTRUDER number by .1mm or .05mm will get you there.

Once you get the Z_PROBE_OFFSET_FROM_EXTRUDER dialed in...  Your first layer will go down nice and clean every time regardless of the differences you are seeing with G28 and G29.




> Ohh, and as a follow up to my previous issue, I had a strange occurrence tonight, that my G28 would always home to 0,0 and not back to the center, unless I entered an M114 at some point. It did it on two occasions, and restarting everything fixed it...but, man...wow....weird!


This issue is under investigation.   There are only a few people reporting it.  But it is clear that it is real.   This should be better understood within a couple of weeks.  (So, if you can, or work around it, just ignore it...  It will get resolved and fixed.)

PS.  I'm not saying we shouldn't investigate and resolve your issue.  But I feel like we should get you up and running and do the rest as convenient.  You really do need to see how nice the Auto Bed Leveling is.   And I suspect just getting the Z_PROBE_OFFSET_FROM_EXTRUDER  number right will do that.

----------


## MiniMadRyan

Thanks Roxy, I really appreciate it! I've been meddling around the code, and frankly, I'm kinda surprised at some of the complexity of it. You're right though, it would seem logical and beneficial if those values were unified, In my haste last night I assumed they were, hence my shock and confusion with the values and what was going on.

I think you're right though, in that I will just need to end up adjusting my Z_PROBE_OFFSET distance. While it seems absurd, it makes sense. Really I was expecting a value similar to what others have had, in the 7-8 range, though with doing that, my numbers will be probably around the 15-16...but I guess what works, works!

AbuMaia, after two G28, my M114 Z reports back at 10. I believe you can see that in my previous outputs I've posted. A further G1 Z0 brings the head down a bit, but I still need to manually adjust the head down a further -7.9 until the nozzle is at a good height for printing. As my RAISE_BEFORE_PROBING is 5, if I modify my code per your suggestion, my offset is actually 12.9. That works great then for any G28 then G1 Z0, however the offset is still way off after the G29.

----------


## AbuMaia

My fix wasn't for adjusting the Z probe offset, it was for correcting some bad math that's done somewhere in Marlin I can't find, that caused my hotend nozzle to be too high after a G28. It's separate from the offset. That's where we're getting confused. My fix adjusts where Marlin *thinks* the hotend is to be where it really is.

----------


## MiniMadRyan

Ahh, thank you for that AbuMaia. I guess its a matter of just tweaking and playing with numbers now. I find it rather intriguing, that, most of our units are relatively the same, in terms of electronics, and hardware design, yet the differences between each of our firmwares can be so great, but I'm thankful for yours, Roxy's and everyone else's help and patience for all the silly questions and comments I've had, this has been the most challenging, yet rewarding printer I've owned or built yet!

----------


## Fri

Attached is my current firmware.

----------


## old man emu

Just an aside having nothing to do coding.

Has anyone noticed that the probe servo hits the Z-axis Carrier when you try to move the extruder to the limit of travel in the X direction?

Crash (Medium).jpg

This is the plate that needs modification. It needs a slot cut in the right hand edge to allow to servo motor to move more to the left.

Plate to modify.jpg

Old Man Emu

----------


## AbuMaia

Here you go OME. http://www.thingiverse.com/thing:335632 This is the one I use on the i3v.  

I used this one http://www.thingiverse.com/thing:167440 with the i3.

----------


## Roxy

> Attached is my current firmware.


I don't see it attached???

----------


## MiniMadRyan

well I'm back to fiddling again after a short holiday and some more pressing projects. 

Fiddled with the Z probe offset values quickly, and was just wondering, would I only see the effects of this change after starting a print? What I did was changed that variable, then ran a G28 followed by a G29 and then lastly a G1 Z0...all values were the same prior to modifying it. I understand that my G28 wouldn't be affected, but I always assumed the following commands above would simulate the start of a print.... oh well, will try some prints later this week when I get more time!

----------


## MiniMadRyan

Well this is weird. So as Roxy suggested, I modified my Z_PROBE_OFFSET_FROM_EXTRUDER and then ran some prints. 

My real offset difference was -8.60, so what I did was change this to -10.60 thinking that, since I know the extruder is more than 4mm off of the surface when it prints, this would be fine. 

Ran the print, and still too high. Killed the print, and manually measured the difference between the extruder and bed. -9.60mm. I then changed my Z_PROBE_OFFSET_FROM_EXTRUDER to 12.60, theoretically then, on my next print it should bring the head down to -7.60 difference....but to my surprise, the second print, still too high, when cancelled and measured is still almost exactly -9.60 difference. 

Right, I haven't a clue where this is all going wrong now.... puzzled!

----------


## MiniMadRyan

Alright, I removed my Z_RAISE_BEFORE_HOMING thinking maybe that would help. No change in the outcome though.

Most interestingly though, with the Z_RAISE_BEFORE_HOMING set to 0, when the printer moves to the centre of the bed, the X &Y Motion is much much quicker, so much so that I believe I heard the y motor jump a bit, and confirmed it did, when after I killed the print, the bed return crashed slightly.....

----------


## MiniMadRyan

That's it, I give up. I've tried everything I can think of and everything that's been suggested here. I used AbuMaia's suggestion and have my Z Height half decent after running a G28, G1 Z0.

Everything else though, what the heck!??!!!! I modified my Z_PROBE_OFFSET_FROM_EXTRUDER  a FULL 4MM from what it actually is (8.60 to 12.60) looking for any change, and yet my head is still 9mm too high....I don't ******* get it!!!

----------


## AbuMaia

MMR: in your marlin_main.cpp, find this code:



```
      #ifdef ENABLE_AUTO_BED_LEVELING
        if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
          current_position[Z_AXIS] += zprobe_zoffset;  //Add Z_Probe offset (the distance is negative)
        }
```

Take the distance you found after doing a G28 then G1 Z0, then moving the nozzle to the print bed, and add it to the zprobe_zoffset, like so:



```
      #ifdef ENABLE_AUTO_BED_LEVELING
        if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {
          current_position[Z_AXIS] += zprobe_zoffset+4;  //Add Z_Probe offset (the distance is negative) *added +4 since my Z0 was too high*
        }
```

That should help keep the G28 Z0 where it is supposed to be. This should not affect the G29, however.

----------


## MiniMadRyan

Thanks AbuMaia, that's what I ended up doing earlier. My g28 z0 works beautifully but like you said, g29 is still out to lunch. 

After a g29 my z height is reported as 4.52, and even after a z0, the head is a good 9mm too high...

----------


## Roxy

> Thanks AbuMaia, that's what I ended up doing earlier. My g28 z0 works beautifully but like you said, g29 is still out to lunch. 
> 
> After a g29 my z height is reported as 4.52, and even after a z0, the head is a good 9mm too high...


Reset your printer...   Connect to it with PronterFace.   And give it a M114 command.   What does it say?   Does the Z_PROBE_OFFSET_FROM_EXTRUDER match what is declared in your Configuration.h file?

----------


## MiniMadRyan

I don't have the printer in front of me at the moment, but after adjusting my code per AbuMaia's suggestion, after a cold start and not touching the printer in any other way, an M114s declares my z at 15. My offset in my config is still the actual 8.60 however....

----------


## MiniMadRyan

I should add, I even started afresh using Dab's most recent firmware release, and still the same effects too...

----------


## Roxy

> I don't have the printer in front of me at the moment, but after adjusting my code per AbuMaia's suggestion, after a cold start and not touching the printer in any other way, an M114s declares my z at 15. My offset in my config is still the actual 8.60 however....


The reason for the question is the version of Configuration.h I have from you has the EEPROM turned on.   You need to load the 'default settings' into memory, and then save them to EEPROM using a M500.    The reason is Marlin takes all it's settings from the EEPROM if the EEPROM is turned on.    

Hence the question:   What does M114 and specifically the M851 command say?

----------


## MiniMadRyan

Crap, I completely forgot about eeprom, I wll check it this afternoon...maybe that's my issue all along hmm...

----------


## MiniMadRyan

Here's my startup code from pronterface, cold start, haven't moved or touched anything else.




> Connecting...
> start
> Printer is now online.
> echo: External Reset
> Marlin1.0.0
> echo: Last Updated: Dec  5 2014 21:48:19 | Author: (MakerFarm Inc, 10" i3v Prusa, dacb)
> Compiled: Dec  5 2014
> echo: Free Memory: 3519  PlannerBufferBytes: 1232
> echo:Stored settings retrieved
> ...


And here's it after a G28




> >>>G28
> SENDING:G28
> >>>M114
> SENDING:M114
> X:93.00 Y:131.00 Z:15.00 E:0.00 Count X: 93.00 Y:131.00 Z:15.00
> >>>M851
> SENDING:M851
> echo:Z Offset :
> 0.00

----------


## MiniMadRyan

Well I think we can lay this thread to rest  :Smile:  

I can't believe I was so dumb, as to never in this entire event issued a M502 to default the settings and load the values from the config.h and not what was in the EEPROM. I did so, and everything now looks great, my G28, and G29 now work correctly and my Z height is correct too (some small tweaking, but its in the ballpark)

I guess my lesson learned here, and to all those who have any issues is, to always run  M502 after changing your configs.... I'll also include this link to Roxy's amazing code to invalidate the EEPROM automatically as well: http://3dprintboard.com/showthread.p...lidate-Command



I just want to say thank you to Roxy, AbuMaia and everyone else who's been so kind and helpful the last few weeks in working with me on my glitches and user-issues I've had. You're all top marks in my books, and I can't thank you enough for your help, and this entire amazing forum too  :Smile:  


Ryan

----------


## Roxy

> I guess my lesson learned here, and to all those who have any issues is, to always run  M502 after changing your configs.... I'll also include this link to Roxy's amazing code to invalidate the EEPROM automatically as well: http://3dprintboard.com/showthread.p...lidate-Command


That is why that code was written...   Bad EEPROM values have been causing all kinds of grief.

----------


## AbuMaia

> Well I think we can lay this thread to rest


  I'm glad you got it working (closer) to your satisfaction.  :Smile:

----------


## printbus

Has anyone ever looked into tweaking how the Arduino IDE uses the avrdude programming utility?  There's no reason why avrdude can't reprogram EEPROM values when reflashing the firmware.  I do that all the time with avrdude in my non-Arduino AVR projects.  Not always since sometimes I do want to retain the old EEPROM data, but it's a simple command line option with avrdude to go either way.

----------


## printbus

> Has anyone ever looked into tweaking how the Arduino IDE uses the avrdude programming utility?  There's no reason why avrdude can't reprogram EEPROM values when reflashing the firmware.  I do that all the time with avrdude in my non-Arduino AVR projects.  Not always since sometimes I do want to retain the old EEPROM data, but it's a simple command line option with avrdude to go either way.


I looked into this a bit.  Apparently the Arduino IDE doesn't give you the flexibility to tailor the avrdude command line. At least not until Arduino v1.5. I did see a forum post mentioning how the avrdude commands could be modified in the <arduino folder>/hardware/arduino/avr/platform.txt file, but you have to be at v1.5 or higher on the IDE to have that file.

----------


## Roxy

> I looked into this a bit.  Apparently the Arduino IDE doesn't give you the flexibility to tailor the avrdude command line. At least not until Arduino v1.5. I did see a forum post mentioning how the avrdude commands could be modified in the <arduino folder>/hardware/arduino/avr/platform.txt file, but you have to be at v1.5 or higher on the IDE to have that file.


However...   There would be a software hack around to get around that.   If you were willing to wipe the EEPROM any time you changed the firmware, you could store some information in the EEPROM so you know its time to change it.   For example, if the CRC of the firmware image doesn't match the CRC of the firmware that wrote the EEPROM, you wipe it.   But....   There is already a version # stored in the EEPROM of the format of the EEPROM data.  If the data format changes, it 'invalidates' the EEPROM data.   Perhaps, part of the directions for getting Auto Bed Leveling up and running is to change your EEPROM data format version???

----------

