# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > MakerFarm Forum >  Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

## dacb

I have been frustrated with having to dig through lots of places to get all the bits and pieces for the most recent code for the Marlin firmware for the i3v.  I also note that the trunk is slow to incorporate pulls.

So, I have setup a fork of the Marlin trunk with the Type 6 therm. table modified, auto bed leveling enabled (this is easy to turn off) and Roxy's enhanced G29 (and G28) commands with the debugging info on.  For a better description of the therm table stuff, see this post.

*If you don't have ABL,* there is an example Configuration.h that should get you started: Configuration.h.without_ABL .  Rename this to Configuration.h and rebuild.  The ABL enhanced Gcodes will be disabled. 

I am trying to keep this current against the Marlin trunk, e.g. it includes the 9/14 fix for the vector calculations and the fixes for the defines related to the sleds.

Here is the repo:
https://github.com/beckdac/Marlin

It isn't necessary to use the Git tools or to *clone* the above repository if you don't plan on ever making changes that you will want to push back to the community.  Instead, just use the *Download Zip* button on the right hand side of the page.

*Make sure you update your E-steps and set the ABL servo angle before using!

*Updates:
Fix: Moved do_blocking_move_relative call from retract_z_probe to homeaxis.
Feature: Added a modified version of the dynamic ABL probe area code from here: https://github.com/ErikZalm/Marlin/pull/1022
Option: Added example for non ABL Configuration.h

----------


## printbus

Sounds good. Safe to assume updates would be noted here?

----------


## AbuMaia

What do we do with the configuration.h.makerfarm?

Also, I'm getting this error when compiling:

Marlin_main.cpp: In function ‘void prepare_arc_move(char)’:
Marlin_main.cpp:4166:49: error: ‘hypot’ was not declared in this scope
   float r = hypot(offset[X_AXIS], offset[Y_AXIS]); // Compute arc radius for mc_arc

I do not know why, it's the same as the line in the old Marlin_main.cpp.

----------


## dacb

> Sounds good. Safe to assume updates would be noted here?


Definitely.




> What do we do with the configuration.h.makerfarm?
> 
> Also, I'm getting this error when compiling:
> 
> Marlin_main.cpp: In function ‘void prepare_arc_move(char)’:
> Marlin_main.cpp:4166:49: error: ‘hypot’ was not declared in this scope
>    float r = hypot(offset[X_AXIS], offset[Y_AXIS]); // Compute arc radius for mc_arc
> 
> I do not know why, it's the same as the line in the old Marlin_main.cpp.


The *.makerfarm could be removed from the repo, I suppose.  They are from the MakerFarm firmware source ball I downloaded from MakerFarm's Google Drive.  They are for reference only.

As for your compilation problem... I just went to a new machine and did a git clone into a new directory.  Then I opened the Marlin.ino in Marlin/Marlin in the Arduino IDE (1.05) and hit Verify.  Does this differ from your protocol?  Make sure you are in a new directory.  I will add that this also builds under 1.5.2 (both on a Mac).

----------


## AbuMaia

I downloaded the .zip file, otherwise it's the same as I did, after I migrated my settings across.

I just compared the modified files with a new set fresh out of the zip file. I can't find any missing hypot declaration anywhere.

----------


## printbus

I believe hypot is an Arduino function.  It wouldn't be defined in the Marlin files.

----------


## AbuMaia

Well, I solved the hypot problem. The /* -*- c++ -*- */ at the top of  marlin_main got replaced by some other text somehow. I've restored it,  now I get

Marlin_main.cpp: In function ‘void retract_z_probe()’:
Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
         if (axis==Z_AXIS)

That would be line 1091 in the zipped file. I'm stumped this time.

----------


## ctcwhexdx

Go into configuration.h around line 455 or so, do you have #define PROBE_SERVO_DEACTIVATION_DELAY 300 enabled, if so put a // in front of it and see if it compiles.

I just ran into the same thing.....




> Well, I solved the hypot problem. The /* -*- c++ -*- */ at the top of  marlin_main got replaced by some other text somehow. I've restored it,  now I get
> Marlin_main.cpp: In function ‘void retract_z_probe()’:
> Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
>          if (axis==Z_AXIS)
> 
> That would be line 1091 in the zipped file. I'm stumped this time.

----------


## AbuMaia

I don't have to check, I know I have it enabled and set to 1000. All commenting it out will do is cause Marlin to skip that part, as the "if" will no longer match. The unmodified version from the zip file compiles properly. It's something to do with my settings somehow.

Oh, I see, the unmodified version has that line commented out, too. Hmm. Yes, if I activate that line, it throws that error.

I'm reverting back to my old Marlin. My servo jitters constantly without the deactivation delay, and I don't trust it to be accurate when homing or bed level probing.

----------


## ctcwhexdx

I just wanted to say Thank You for doing this, i've been going crazy trying to get my setup running until now!!!




> I have been frustrated with having to dig through lots of places to get all the bits and pieces for the most recent code for the Marlin firmware for the i3v.  I also note that the trunk is slow to incorporate pulls.
> 
> So, I have setup a fork of the Marlin trunk with the Type 6 therm. table modified, auto bed leveling enabled (this is easy to turn off) and Roxy's enhanced G29 (and G28) commands with the debugging info on.  For a better description of the therm table stuff, see this post.
> 
> I am trying to keep this current against the Marlin trunk, e.g. it includes the 9/14 fix for the vector calculations and the fixes for the defines related to the sleds.
> 
> Here is the repo:
> https://github.com/beckdac/Marlin
> 
> ...

----------


## printbus

> ...now I get
> 
> Marlin_main.cpp: In function ‘void retract_z_probe()’:
> Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
>          if (axis==Z_AXIS)


I don't have the code with the retract_z_probe function in it. BUT, looking at the number of other places in marlin_main.cpp that where similar code exists in the older version, I'll bet the 'void retract_z_probe()' should really be 'void retract_z_probe(int axis)'.

----------


## ctcwhexdx

Something else to look at in the configuration.h, right about that line it says :
//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.






> I don't have to check, I know I have it enabled and set to 1000. All commenting it out will do is cause Marlin to skip that part, as the "if" will no longer match. The unmodified version from the zip file compiles properly. It's something to do with my settings somehow.
> 
> Oh, I see, the unmodified version has that line commented out, too. Hmm. Yes, if I activate that line, it throws that error.

----------


## AbuMaia

> Jeez. Looks like I'll be needing to download the newer code to help out where I can.  I don't have the code with the retract_z_probe function in it. BUT, looking at the number of other places in marlin_main.cpp that where similar code exists in the older version, I'll bet the 'void retract_z_probe()' should really be 'void retract_z_probe(int axis)'.


I tried that, it threw many more errors which I can't remember well enough to quote right now.




> Something else to look at in the configuration.h, right about that line it says :
> //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.


Yes, I saw that too. I used the deactivation delay before this fork came out, so it was working properly before. I have it set up properly.

Comparing the new version with what I was using yesterday, that whole "Retract Z Servo endstop if enabled" section is new. I commented it all out for now.

----------


## Roxy

> I'll bet the 'void retract_z_probe()' should really be 'void retract_z_probe(int axis)'.


I don't remember retract_z_probe() ever having any arguments.   I have a different theory.   If you go find the declaration: 

void retract_z_probe()

and then search for the first occurrence of 

if (axis==Z_AXIS)

because that is what that error message:

Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
if (axis==Z_AXIS)

is complaining about...  You find this stuff just before the       *if (axis==Z_AXIS)*


#ifndef Z_PROBE_SLED
  engage_z_probe();   // Engage Z Servo endstop if available
#endif // Z_PROBE_SLED
  run_z_probe();
  float measured_z = current_position[Z_AXIS];
#ifndef Z_PROBE_SLED
  if (retract_probe) {
      do_blocking_move_to(current_position[X_AXIS], current_position[Y_AXIS],current_position[Z_AXIS]+Z_RAISE_BETWEEN_PROBINGS );
      retract_z_probe();
  }
#endif // Z_PROBE_SLED


I bet those Z_PROBE_SLED #ifdef problems are biting you!

----------


## AbuMaia

That section with the Z_PROBE_SLED is about 64 lines after the line throwing the error for me.

----------


## Roxy

> Here is the repo:
> https://github.com/beckdac/Marlin


I pulled this down...  And it compiled clean.  This must not be the code base you guys are having trouble with ????

----------


## AbuMaia

It is. I downloaded the zip file, and merged my settings into it. If you compile it without changing anything, it will compile clean, but if you uncomment the servo deactivation delay line in configuration.h, it will not compile.

----------


## dacb

Thanks to everyone who has tried a build.  

I can confirm that if I clone the repo and open the "Marlin-Marlin_v1/Marlin/Marlin.ino" and do a build without altering anything else, it does build cleanly.  

*BUT:* As with AbuMaia, uncommenting line 454 on Configuration.h (#define PROBE_SERVO_DEACTIVATION_DELAY 300) does cause a build failure.

*SO:* I pushed a fix: https://github.com/beckdac/Marlin/co...d5ba1a103c1f64

*DO:* You can reclone the repo or do a git pull.  Modify your Configuration.h to reflect the DELAY you want and build.

*NOTE:* I'm pretty wedded to the command line.  However, I'm trying to convert as many people as possible to "open source and open science & engineering" and I just discovered the GitHub desktop app.  I'm on OS/X, but I see there is a windows version.  It is pretty intuitive to use and has a nice visual of the history of a repo.  Once you have cloned a repo locally, you can use an app like this in order to have a GUI into your local work.

Edit: For those of you who have "localized" this to your specific printer, would you mind posting a diff or a description of what you changed so that others may have some direction?

----------


## AbuMaia

> For those of you who have "localized" this to your specific printer, would you mind posting a diff or a description of what you changed so that others may have some direction?


Here is mine, set up for an 8 inch i3v with auto bed levelling and an end-of-filament detection switch.

https://dl.dropboxusercontent.com/u/...ia-Marlin.diff

----------


## printbus

> I don't remember retract_z_probe() ever having any arguments.


That was exactly my point.  All of a sudden in the retract_z_probe function an attempt to use variable axis shows up and the compiler errors because it doesn't know what it is. It's evidently not a global, so it should be passed to retract_z_probe as an argument.  

The number of ifdefs in the Marlin code is incredible.

----------


## Roxy

> That was exactly my point.  All of a sudden in the retract_z_probe function an attempt to use variable axis shows up and the compiler errors because it doesn't know what it is. It's evidently not a global, so it should be passed to retract_z_probe as an argument.  
> 
> The number of ifdefs in the Marlin code is incredible.


So...  I don't know...   But my thinking is a little different.    What happened is the compiler thought it was in the retract_z_probe() function.   But it wasn't.  It got out of sync with the code and it was missing a curly brace or a semicolon somewhere.    It was reporting the error the best it could.     Even though where the axis==Z_AXIS stuff was clearly outside and beyond the retract_z_probe() function to you and me...    To the compiler it never closed out and finished doing the work for that function.   It thought it was still in that function.  So it reported that it found an error while compiling that function.

That function isn't that long, but its got all those #ifdef's in it.    I don't know... My guess would be somehow those turned off a closing curly brace that was needed to close out the function and the compiler got confused.

But like I said...  Short of actually seeing the code causing it to happen, and finding the fix, it is hard to say for sure.   But that is kind of how my thought process works and where I would start.

Its kind of like when the compiler complains I'm missing a semicolon and tells me where it should be.   If it knows where it should be, just put it there for me!!!!

----------


## clough42

I have my own set of auto-bed-leveling code changes that I've been using, but I've been planning to switch over and try Roxy's.  Mine have some...oddities if you run the bed leveling a second time without cycling the power.

Thanks for setting up the fork.

I'm sure it has been discussed before, but what's the story on the possibility of getting Roxy's changes merged into the main Marlin distribution?  Has that conversation taken place?  Feel free to just point me to the flamewar thread if there is one.

----------


## Roxy

> I'm sure it has been discussed before, but what's the story on the possibility of getting Roxy's changes merged into the main Marlin distribution?  Has that conversation taken place?  Feel free to just point me to the flame war thread if there is one.


I started the process of doing a 'Push' of the Enhanced G29 but ran into trouble with GitHub.   I managed to get the G48 Z-Probe-Repeatability test Pushed and merged into the code base.   But what ever I did that time doesn't work now.      I might need help doing that.   I was thinking of getting an up to date version of the code base with just the Enhanced G29 code in it.   Literally...  Take the most current code base off of GitHub and make the changes for Enhanced G29 to it with nothing else.    And then see if somebody else can get it to 'Push' back.    (Because I don't seem to be able to do that!)

But now, somebody might be merging another nice G29 enhancement into the mix.   Somebody else did some work where the n x n grid that is probed is limited to the size of the print being done.  That will help accuracy.   If that can be merged with my G29 stuff, it would make sense to get that all working and do a single 'Push' of everything.    There is some post-processing of the Slicer GCode that has to be done.   Somehow that has to be done so it is fully automatic for the user.   I haven't seen what or how that is done.   So that actual status isn't clear right now.

Check out the start of the discussion at:

http://3dprintboard.com/showthread.p...ll=1#post27876

And then Sly20 says he has merged the two code bases:

http://3dprintboard.com/showthread.p...ll=1#post28002

----------


## dacb

I'm really interested in incorporating other peoples pieces into this fork, so if you have something valuable, pass it on.  I do plan on adding in my changes to prevent moves to unsafe positions on the X and Y axes soon.

----------


## Roxy

> I'm really interested in incorporating other peoples pieces into this fork, so if you have something valuable, pass it on.  I do plan on adding in my changes to prevent moves to unsafe positions on the X and Y axes soon.


Have you taken a look at this fork:  https://github.com/ErikZalm/Marlin/pull/1022)

Sly20 said: 




> 3 files have been changed. Is there a way to merge the code ?


And later Sly20 said he had them merged.  I suspect it was fairly straight forward to merge them.   Can you attempt the same merge so we have everything in one place and common code base for everybody to work off of?

If we can make that happen, I bet we can get people to figure out what changes in the Starting GCode to automatically get a print's dimensions communicated to the printer.  It would be a fun group project to do here!

----------


## dacb

OK, I integrated those changes into our fork: https://github.com/beckdac/Marlin/co...7dc766f4e76575

Unfortunately, that code set also has a parameter (A) for supplying the number of points to probe and those changes break Roxy's code and conflict with that enhanced G29 parameter (n).  So I created an additional patch to reconcile these two: https://github.com/beckdac/Marlin/co...e9d3bcc49fd4de

I decided to keep the (n) parameter to G29 from Roxy and remove the (A) parameter.  So an example G29 command could be:


```
G29 V4 T n3 L95 F95 R105 B105
```

Where the highest level of verbosity is used, the topography is printed, the number of points is 3 in X and Y (3x3) and the print/ABL area is from 95,95 to 105,105.

----------


## dacb

Did some basic testing and it looks like it works.  I ran through some combinations of arguments from the full blown to the original (see below) and didn't find any problems.  Then I started a print and it setup fine and is working away.

E.g. G29 V4 T n3 L95 F95 R105 B105


```
Send: G28 X0 Y0 Z0
Recv: ok
Send: G29 V4 T n3 L95 F95 R105 B105
Recv: Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.01:
Recv: Bed x: 95.00 y: 95.00 z: 7.95
Recv: Bed x: 100.00 y: 95.00 z: 7.90
Recv: Bed x: 105.00 y: 95.00 z: 7.92
Recv: Bed x: 95.00 y: 100.00 z: 7.84
Recv: Bed x: 100.00 y: 100.00 z: 7.86
Recv: Bed x: 105.00 y: 100.00 z: 7.93
Recv: Bed x: 95.00 y: 105.00 z: 7.89
Recv: Bed x: 100.00 y: 105.00 z: 7.88
Recv: Bed x: 105.00 y: 105.00 z: 7.89
Recv: Eqn coefficients: a: 0.00 b: -0.00 d: 8.09
Recv: Mean of sampled points: 7.895500
Recv: 
Recv: Bed Height Topography:
Recv:  --0.00600 --0.01700 --0.00500
Recv:  --0.05700 --0.03425 +0.03325
Recv:  +0.05875 +0.00400 +0.02325
Recv: 
Recv: planeNormal x: -0.00 y: 0.00 z: 1.00
Recv: 
Recv: 
Recv: Bed Level Correction Matrix:
Recv: 0.999998 0.000000 0.001858
Recv: 0.000007 0.999993 -0.003800
Recv: -0.001858 0.003800 0.999991
Recv: ok
Recv: echo:endstops hit:  Z:7.89
```

E.g. G29 V4 T n2


```
Send: G29 V4 T n2
Recv: Roxy's Enhanced G29 Auto_Bed_Leveling Code V1.01:
Recv: Bed x: 75.00 y: 50.00 z: 8.01
Recv: Bed x: 175.00 y: 50.00 z: 8.19
Recv: Bed x: 75.00 y: 175.00 z: 7.80
Recv: Bed x: 175.00 y: 175.00 z: 7.96
Recv: Eqn coefficients: a: 0.00 b: -0.00 d: 7.97
Recv: Mean of sampled points: 7.986500
Recv: 
Recv: Bed Height Topography:
Recv:  --0.19100 --0.03075
Recv:  +0.01850 +0.20325
Recv: 
Recv: planeNormal x: -0.00 y: 0.00 z: 1.00
Recv: 
Recv: 
Recv: Bed Level Correction Matrix:
Recv: 0.999999 0.000000 0.001725
Recv: 0.000003 0.999998 -0.001774
Recv: -0.001725 0.001774 0.999997
Recv: ok
Recv: echo:endstops hit:  Z:7.96
```

----------


## Roxy

> I decided to keep the (n) parameter to G29 from Roxy and remove the (A) parameter.  So an example G29 command could be:
> 
> 
> ```
> G29 V4 T n3 L95 F95 R105 B105
> ```


Holy Cow!    That is great if you merged things that easily!   And actually...   I have a request.   I think 'n' makes sense but because Repetier can't tolerate either n or N and Pronterface can't use a capital N, we need to accommodate something else.   I'll look at the merge (and re-read these posts in detail) in the morning, but I already added :

    if ( code_seen('n') || code_seen('U') || code_seen('u') ) {
        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;
        }
    }

to my code base to help with a transition.   Can we fold that into the merge?   I was thinking an upside down 'N' would be easy to remember if you are using broken software that can't tolerate an 'N'.

----------


## clough42

Thanks.  Keep up the good work.

I think the community benefits the most when valuable changes like these can be merged back and made available to everyone.

----------


## dacb

Thanks, clough42.  I'd love to get this merged back into Marlin trunk.

Here is the 'U'/'u' addition: https://github.com/beckdac/Marlin/co...85c9019b53b9e4

----------


## Roxy

> Thanks, clough42.  I'd love to get this merged back into Marlin trunk.
> 
> Here is the 'U'/'u' addition: https://github.com/beckdac/Marlin/co...85c9019b53b9e4


Who knows how to do the 'Post Processing' so the correct Front, Back, Left, Right parameters can be filled in on the G29 line?   Specifically...  What I'm asking is can this be done with the Slicer Start GCode?    My guess is "No!"  but I don't know that.      

I hope I'm wrong but most likely, we will need to write a program that parses through the GCode that gets generated and look for the coordinates that get used by the print.  And from that information go update the G29 line early in the print.   In the comments for the region updates to G29* bonm014 * said
In my slic3r I have set this code in the custom start gcode G29 L[G29XMIN] F[G29YMIN] R[G29XMAX] B[G29YMAX] A3  With a postprocessor I change the parameters based on the extrusion points.
My suggestion is to consider these questions.   And maybe we can debate whether my initial answers make sense:   



Can we as a group agree which Slicer's we want to support initially?
I would like to see Slicer directly supported.  Probably a lot of people want Cura supported.  Is there other slicing software we need to accommodate? 



Can we as a group agree which OS's we want to support initially?
If this can't be done within the Slicers themselves, initially we need Windows, and we would want Linux and Mac to be fast followers.   Depending upon how cleanly the Post-Processing code is written, it might be trivial for an expert on each of those platforms to port the Post-Processing code to the new OS platform. 



Can we find volunteers to help complete the important sections of this matrix and test it?
If we restrict the development & test matrix to something reasonable, I bet we get plenty of people helping to both develop and test the missing pieces.   Especially if we have a Support thread dedicated to get this idea fully mature and usable by the community. 



Can we get *bonm014*'s post processing code to use as a starting point for the pieces we need?
Almost for sure he would be willing to offer up his post processing code.  After all, he offered up his version of the G29 to help the community.    It is possible he could help fill in some of the spots in our Development and Test matrix.Can somebody reach out to him and see if we can get him to join this thread and offer his $.02 ? 





> Thanks, clough42.  I'd love to get this merged back into Marlin trunk.


I'm very excited and pleased by this effort!    But I think it would be really cool to keep the above mentioned work contained in this branch of the tree until we get most of the Development & Test matrix completed.   And when everything is pretty solid and working correctly for everybody, merge it back into the main tree.    The reason I'm suggesting we consider this idea is because it takes so long to get things formally merged.   I think it was 3 or 4 weeks when I submitted the fully polished M48 Z-Probe-Repeatability-Test code for it to be finally accepted.    

If we (you) have control of this branch of the tree, we can move much faster with future enhancements, tweaks and bug fixes.    And however we do the Post-Processing, that needs to be well documented for each OS & Slicer and included so people can get it setup and working in their environment.

I realize I threw a lot out on the table for discussion.    And for sure there are going to be other perspectives on this stuff.   If  somebody has an opinion or extra points to add or clarification....  Please... Please... Throw it into the mix!!!!

----------


## AbuMaia

I have a question that is probably best saved for later when things are more settled, but the idea of dynamic probe points came to mind. I print a lot of 25mm3 cubes to test my printer when I change something in firmware. It seems to me that for objects like these that have a small printbed footprint, one doesn't need 4x4 probe points, or even 3x3. My question is, is it feasible to have the post-processing script also control the number of probe points along with probed area?

----------


## Roxy

> I have a question that is probably best saved for later when things are more settled, but the idea of dynamic probe points came to mind. I print a lot of 25mm3 cubes to test my printer when I change something in firmware. It seems to me that for objects like these that have a small printbed footprint, one doesn't need 4x4 probe points, or even 3x3. My question is, is it feasible to have the post-processing script also control the number of probe points along with probed area?


I would guess this makes sense.   But just for the sake of discussion....   On a small 25mm 3D-Cube,  what would be the right set of points to probe?  Maybe a grid with a 100mm on a side with the cube at the center?   Would any accuracy be picked up by making the grid either larger or smaller?

----------


## dacb

For Cura, there are plugins that can be used to postprocess the G-Code, e.g. http://wiki.ultimaker.com/How_to_write_a_Cura_plugin
Similarly for Slic3r: http://manual.slic3r.org/advanced/post-processing

You probably know that I'm a Cura user, primarily, and I like the way the the Cura plugins can get arguments passed to them.  This is particularly useful for providing arguments like the one you just mentioned which is the "bounding box extension" for the print, i.e. the extra 100mm.

I think OS support maybe less of an issue for Cura than Slic3r.  The plugins execute within the Cura framework and don't require any additional support, unlike the Slic3r which have to execute in their own environment and such would require that a python, perl, sed/awk, cygwin, whatever, be installed.

----------


## Roxy

> I think OS support maybe less of an issue for Cura than Slic3r.  The plugins execute within the Cura framework and don't require any additional support, unlike the Slic3r which have to execute in their own environment and such would require that a python, perl, sed/awk, cygwin, whatever, be installed.


Or maybe just a C program that produces a .EXE file?    I was thinking about it...  It may not be that hard because it might be just a matter of looking for the G1 commands that have an E component.

----------


## dacb

I just pushed a prototype Cura plugin that finds the bounding box for the first layer and prints it out.  This is not a complete module, but a proof of concept.  To be complete, this plugin needs to patch the G29 command for the print area parameters (LRFB) and then to write it instead of the current G29.  Here is the commit: https://github.com/beckdac/Marlin/co...24eee24170a640

And a screenshot of the interface in Cura:
plugin.jpg

And the debug output:


```
Bounding Box: L155.91 F71.69 R77.26 B148.53
G29 line before modification: G29 V4 T n3;do auto bed level
```

Then I moved the maple leaf around the print bed and here is the revised output:


```
Bounding Box: L154.03 F56.8 R75.38 B133.63
G29 line before modification: G29 V4 T n3;do auto bed level
```

It is this Thing: http://www.thingiverse.com/thing:3461

----------


## clough42

Hmm...I'm most interested in just having the Z axis lift before retracing the probe so it doesn't strike the bed.

Are we talking here about requiring a post processor for the gcode just to do auto leveling?  Or can you still use basic (3 or 4 fixed point) leveling without the processor?

----------


## printbus

> Can we as a group agree which Slicer's we want to support initially?
> I would like to see Slicer directly supported.  Probably a lot of people want Cura supported.  Is there other slicing software we need to accommodate?


I'd personally like to see Cura Engine via Repetier-Host supported.  It's not evident that supports the plug-in stuff unless it's supported behind the scenes.

----------


## dacb

> Are we talking here about requiring a post processor for the gcode just to do auto leveling?  Or can you still use basic (3 or 4 fixed point) leveling without the processor?


Like you, I have no real interest in using the dynamic ABL code and I am using the basic 3/4 point leveling.  In that case, there is no need to use a postprocessor.  Just keep your starting Gcode the same, e.g. G29 V4 T n3

----------


## Roxy

Very Good!   I just had a chance to look around on the web. 

I think it is going to be fairly straight forward to do the Slic3r version.    I don't know Python so probably C would make the most sense.   If I made a small C .exe program the user would just have to put its name in the 'Post-Processing Script' box and it could tear through the GCode file.

What is your thinking on packaging up the Post-Processing scripts?   I'm kind of thinking it is like the stuff to build the SpeedLookupTable and TemperatureLookupMarlin table.   They have a couple of .py files to do the work that nobody ever looks at.   The post processing scripts (programs) could be there in both source form and executable form with instruction on how to get them into the slicer program the user is using.

----------


## Roxy

> Hmm...I'm most interested in just having the Z  axis lift before retracing the probe so it doesn't strike the bed.
> Are we talking here about requiring a post processor for the gcode just  to do auto leveling?  Or can you still use basic (3 or 4 fixed point)  leveling without the processor?





> Like you, I have no real interest in using the dynamic ABL code and I am using the basic 3/4 point leveling.  In that case, there is no need to use a postprocessor.  Just keep your starting Gcode the same, e.g. G29 V4 T n3


Right!  If the user does nothing, the Auto Bed Leveling code would do the default case of doing the whole bed.  But if the user cared, they would just tell their Slicer to post process the GCode and the area being probed would shrink.

----------


## Roxy

Dacb:

May I ask for a couple more changes to your fork?   There are 3 items.   First, can we put this in the Configuration.h file?



```
    
// set the max number of grid points per dimension
// The G29 command defaults to 3 if nothing is specified.  But setting the number of probed 
// points higher is very useful when getting a Bed Topology Report  (G29 n 5 T)
#define AUTO_BED_LEVELING_GRID_POINTS 5

// Uncomment one of the following four lines so the Bed Topology Report can produce a map
// that relates accurately to your bed orientation.  

#define ORIGIN_FRONT_LEFT
//#define ORIGIN_BACK_LEFT
//#define ORIGIN_FRONT_RIGHT
//#define ORIGIN_BACK_RIGHT
```

That is where it really belongs.   (And of course, it needs to be deleted out of Marlin_main.cpp) I just put it with the C code in Marlin_main.cpp to make it easy on people.  But if this is going to be merged back into the main tree, this option should be in the Configuration.h file.    And also note the  #define AUTO_BED_LEVELING_GRID_POINTS 5 and the explanation for it.   Because of the change in what it does, probably that explanation is important so people can get full functionality.

The other change I'm hoping you can paste into your fork is a comment block in front of the G29 command.   It will help people understand how to use it.  Unfortunately, this isn't complete.   We will probably want to add some more comments about getting the post processing setup for different slicers but I guess that can wait until we have that done.



```
#ifdef ENABLE_AUTO_BED_LEVELING
      
//
// Enhanced G29 Auto Bed Leveling Probe Routine
// 
// This updated code provides a Bed Topology Report, Ability to control engagement and retraction of
// Z-Probe and varying levels of verboseness.   It also allows the selection of the n x n grid at 
// print time instead of being fixed at the time the firmware is built. It also handles probe retraction
// issues for probes that require clearance much more gracefully.
//
// Parameter usage:
//
//    n (u & U)    Controls the size of the grid that will be probed.  Typical usage would be of 
//            the form  G29 n 4   u & U were added because of deficiencies in the Repetier client
//            not being able to use even a lower case n
//            
//    V        Controls the verbose level.  Typical usage would be of the form   G29 V 3
//
//    T        Controls generation of the Bed Topology Report.  Typical usage would be of the
//            form   G29 n 5 T    to get a detailed map of your bed.   This is very useful
//            for manual bed leveling as well as knowing where imperfections exist on your
//            bed (to assist with part placement)
//
//    E        Controls engagement and retraction of the Z-Probe.  It Defaults to leaving the
//            probe engaged during the probing of the n x n grid.  This helps the repeatability
//            of the Z-Probe and produces better Auto Bed Leveling results.  Typical usage 
//            would be of the form   G29 E
//
//  These following 4 parameters are typically generated by a Post Processing script 
//  configured within your slicer to process the generated GCode.   Currently Curra and 
//  Slic3r are supported.   The Post Processing scripts for these slicers will determine the 
//  size of the print on the bed and limit the Grid Probe to the required region in order to
//  increase the bed leveling accuracy.  Please not that these position parameters assume
//  Left is the smallest X-Axis coordinate, Right is the larger X-Axis coordinate and Front is
//  the smallest Y-Axis coordinate and Back is the larger Y-Axis coordinate.
//
//    L      Controls left side grid probe position.  If unspecified, will use  LEFT_PROBE_BED_POSITION
//
//    R      Controls the right side grid probe position.   If unspecified, will use  RIGHT_PROBE_BED_POSITION
//
//    F      Controls front side grid probe position.  If unspecified, will use  FRONT_PROBE_BED_POSITION
//
//    B      Controls the back side grid probe position.   If unspecified, will use  BACK_PROBE_BED_POSITION
//
//
    case 29: // G29 Detailed Z-Probe, probes the bed at 3 or more points.
        // Example Syntax:  G29 n 4 V 2 E T L 50 R 150 F 25 B 125
        {
```

And soon...  I think I'm going to have a few more lines of code to paste into the G29 that does range checking of the post processing parameters.  The reason is I'm noticing Slic3r actually generates X & Y coordinates that are outside of the specified bed size.    My Y goes from 0mm to 180mm but for some stupid reason Slic3r is generating G1 commands with a slightly negative Y number for the skirt under certain conditions.    I need to finish getting my Post Processor going, and run it on some Slic3r generated GCode files to figure out how to handle it in a reasonable manner.


THANKS!!!!

----------


## dacb

> Dacb:
> 
> May I ask for a couple more changes to your fork? ...


Nice work... Comments / documentation is super important.  Here is the commit: https://github.com/beckdac/Marlin/co...32f725c23ab670

----------


## AbuMaia

Roxy, that comment block explaining the different arguments passed to G29, the one for E is not clear to me. If one uses E, what should they expect to see? From what I've seen in your Probe Repeatability test, E caused the servo to lift the probe each time. In this comment block, though, it sounds like it's used to keep the probe extended for the duration of probing.

----------


## Roxy

> Roxy, that comment block explaining the different arguments passed to G29, the one for E is not clear to me. If one uses E, what should they expect to see? From what I've seen in your Probe Repeatability test, E caused the servo to lift the probe each time. In this comment block, though, it sounds like it's used to keep the probe extended for the duration of probing.


So I can't speak definitely!  I haven't run this code yet.  I'm going to have to port it back to my machine.   But the Enhanced G29 is supposed to leave the probe down while taking all the points by default.   Specifying the E option should make it go back to the original behavior and 'E'ngage the probe and un-'E'ngage the probe for each point.

The comment says:



```
                Controls engagement and retraction of the Z-Probe.  It Defaults to leaving the
                probe engaged during the probing of the n x n grid.
```

So specifying the 'E' would Control engagement and retraction of the Z-Probe.      

With nothing specified, the default behavior is to leave the probe engaged.    

Please feel free to help make the documentation clearer!  For sure people writing code make assumptions about what is obvious and what is not obvious.    And if you do make the comments better...   Maybe you can make the Left, Right, Front, Back comments better!  The big problem with that is it assumes the origin for the person's bed is at the left front.   That is not always the case. (I'm exactly opposite to that because of early flaws in the G29 code where it could not take negative offsets)    But what can be done (either by switching the option names or by a different explanation) to make that better?

----------


## dacb

> ... The big problem with that is it assumes the origin for the person's bed is at the left front.   That is not always the case. (I'm exactly opposite to that because of early flaws in the G29 code where it could not take negative offsets)    But what can be done (either by switching the option names or by a different explanation) to make that better?


Yes, this is the biggest problem right now.  It won't affect anyone in the MakerFarm family, so far as I know, but it does prevent the change from being pushed back to trunk without further consideration. I think it will also have an impact on any post-processing scripts.  This really makes me want to rename or reannotate the L, F, R, B parameters to reflect that they are really Xmin, Ymin, Xmax, Ymax.

*BTW,* if anyone wants to get added as a contributor to the repo, just drop me a private message.

----------


## AbuMaia

> Please feel free to help make the documentation clearer!


  I would say



```
//    E        Causes the Z-Probe to Engage and retract with every probe point.  Do not use if you want to leave the 
//            probe Engaged during the probing of the n x n grid.  Leaving the probe Engaged helps the repeatability 
//            of the Z-Probe and produces better Auto Bed Leveling results.  Typical usage 
//            would be of the form   G29 E
```




> Maybe you can make the Left, Right, Front, Back comments better!  The big problem with that is it assumes the origin for the person's bed is at the left front.   That is not always the case. (I'm exactly opposite to that because of early flaws in the G29 code where it could not take negative offsets)    But what can be done (either by switching the option names or by a different explanation) to make that better?


Could the L, R, F, B arguments be tied to the #define ORIGIN setting? If the user sets the origin as #define ORIGIN_BACK_RIGHT, we know where the larger and smaller coordinates will be. What I mean is, with #define ORIGIN_BACK_RIGHT, we know that F will be the larger Y coordinates, L will be the larger X coordinates, and so forth.

----------


## dacb

> Could the L, R, F, B arguments be tied to the #define ORIGIN setting? If the user sets the origin as #define ORIGIN_BACK_RIGHT, we know where the larger and smaller coordinates will be.


Perhaps, but what if you have a delta or a SCARA?  What is the front?  What is the left?

----------


## AbuMaia

Would Delta and SCARA machines even use the G29 code?

----------


## Roxy

> Would Delta and SCARA machines even use the G29 code?


Yes!  Absolutely!  It is actually probably more important on those machines than Cartesian machines because of how the nozzle platform also needs to be level.

----------


## Roxy

> Yes, this is the biggest problem right now.  It won't affect anyone in the MakerFarm family, so far as I know, but it does prevent the change from being pushed back to trunk without further consideration. I think it will also have an impact on any post-processing scripts.  This really makes me want to rename or reannotate the L, F, R, B parameters to reflect that they are really Xmin, Ymin, Xmax, Ymax.


Actually, my machine was originally setup with the origin in the front left.  But there were problems with the least square fit of the Auto Bed Leveling in the early versions where they could not handle negative coordinates.   The easiest answer was to rotate my origin to the back right.  Then my probe was always in positive space.   What I'm arguing is the type of machine may not insulate you from the issue.

I think having the parameters named Xmin, Ymin, Xmax, Ymax is much clearer.   The big problem is none of the other GCode commands use long parameter names.   And there is no support for the longer parameter names.    The support code would not be difficult to do.  But....

One idea would be to change the Code_Seen(char ) function to be Code_Seen(char *).  It would be very quick to go through the code base (and probably it is just Marlin_main.cpp) to put double quotes around all the existing characters in Code_Seen() functions.   We could leave everything else the same where it leaves a pointer looking at the numeric value for the hunted parameter.   If we did that...  Xmin, Ymin, Xmax, Ymax would work nicely and avoid a lot of confusion for people.

Right now, Code_Seen() is pretty trivial:


```
bool code_seen(char code)
{
strchr_pointer = strchr(cmdbuffer[bufindr], code);
return (strchr_pointer != NULL); //Return True if a character was found
}
```


If we went that way...  It would turn into something like this.  But we may want to desensitize the comparison to upper and lower case.  I don't know.



```
bool code_seen(char *code)
{
strchr_pointer = strstr(cmdbuffer[bufindr], code);
return (strchr_pointer != NULL); //Return True if the specified parameter was found
}
```

----------


## printbus

> ...This really makes me want to rename or reannotate the L, F, R, B parameters to reflect that they are really Xmin, Ymin, Xmax, Ymax.


The idea of Xmin, Ymin, Xmax, and Ymax seems so much clearer. EDIT: Stated before I read Roxy's post on limitations. 

In tune with calling things really what they are, I'd recommend using n-by-n text in lieu of n x n in the comments.  Those unfamiliar could think x is a variable, or an axis...




> ...So, I have setup a fork of the Marlin trunk with the Type 6 therm. table modified, auto bed leveling enabled (this is easy to turn off) and Roxy's enhanced G29 (and G28) commands with the debugging info on.  For a better description of the therm table stuff, see this post.


To facilitate merging the updates back into the Marlin trunk, I'd reconsider whether the fork uses the MakerFarm changes to the Type 6 thermistor.  The Marlin trunk isn't going to want the Type 6 table changed - there could be people out there used to how it measures temperatures.  Your configuration.h file also still contains the now incorrect comment about Type 6 not being as accurate as Type 1 and being created with a Fluke thermocouple. My vote would be to revert thermistortables.h back to the Marlin Type 6 data and change configuration.h to use Type 1 thermistors.  Beyond what I concluded in the referenced thread, I think someone said zennmasterM has also said it's OK for MakerFarm people to use Type 1 when they update their firmware as part of his video on auto leveling. 

EDIT: BTW - I've been using Type 1 just fine the last week or so.  If, for some reason, we're uncomfortable switching to Type 1, the MakerFarm thermistor table could at least be defined as a new thermistor type that is used rather than modifying the Marlin type 6 table.

----------


## Roxy

Dacb:   Random new topic here:    You modified the code to allocate space this way:
(I might have already added this code to your branch of the Marlin tree...  But I could not Sync it)



```
// "A" matrix of the linear system of equations
double* eqnAMatrix = (double*)malloc(sizeof(double) * (n_points*n_points*3));
// "B" vector of Z points
double* eqnBVector = (double*)malloc(sizeof(double) * (n_points*n_points))
```

This really is a better way of doing it than assumming the stack is deep enough to handle those large arrays.   But we probably should check that the memory was available on the heap.  We might want to add right after the malloc()'s something like:



```
if ( eqnAMatrix==NULL || eqnBVector==NULL) {
            SERIAL_PROTOCOLPGM("?Memory not available for Auto Bed Leveling.\n");
            if (eqnAVector)
                 free(eqnAVector);
            if (eqnBVector)
                 free(eqnBVector);
            break;
}
```

and the memory isn't free()'ed at the end.   At some point, the Arduino board won't be able to do Auto Bed Leveling any more!   :Frown: 



```
#endif  // ORIGIN_FRONT_RIGHT
}
            set_bed_level_equation_lsq(plane_equation_coefficients);

            free(plane_equation_coefficients);
            free(eqnAVector);
            free(eqnBVector);
#else // AUTO_BED_LEVELING_GRID not defined
```

Mean while....   I've got my post processing script for Slic3r finding the print's size and modifying the G29 in the GCode file. I guess I'll use F, B, L, R for right now...   But I think my vote is for using XMIN, YMIN, XMAX and YMAX.

----------


## TopJimmyCooks

Forgive me if this is already addressed, I did not read every post thoroughly.  I really need to be able to set a small Z raise before retracting the Z probe during ABL.  At each point of bed probing, the probe is lowered and then retracts before moving again.  The bottom of the switch housing sometimes hits the bed and sometimes hangs up. This could be fixed differently/mechanically but it seems like something pretty easy.  

I also have a problem sometimes where if I have done a print that is only 2-3 layers tall, such as a business card, and then home Z, the nozzle is too low to allow the Z probe to extend.  My ABL z offset is 5.6 mm currently, so this could happen on any print that ends at less than that height.  It would be wonderful if this code could address raising Z by the probe offset plus a bit to avoid this.  

I expect that if Roxy's keep probe extended setting is still an option this has already been considered.  Again, thanks for all the work guys, it is appreciated greatly by us non-coders.

----------


## Roxy

> Forgive me if this is already addressed, I did not read every post thoroughly.  I really need to be able to set a small Z raise before retracting the Z probe during ABL.  At each point of bed probing, the probe is lowered and then retracts before moving again.  The bottom of the switch housing sometimes hits the bed and sometimes hangs up. This could be fixed differently/mechanically but it seems like something pretty easy.  
> 
> I also have a problem sometimes where if I have done a print that is only 2-3 layers tall, such as a business card, and then home Z, the nozzle is too low to allow the Z probe to extend.  My ABL z offset is 5.6 mm currently, so this could happen on any print that ends at less than that height.  It would be wonderful if this code could address raising Z by the probe offset plus a bit to avoid this.  
> 
> I expect that if Roxy's keep probe extended setting is still an option this has already been considered.  Again, thanks for all the work guys, it is appreciated greatly by us non-coders.


 Yes, that is already handled in the Enhanced G29 code.   And that can be obtained here: http://3dprintboard.com/showthread.p...ed-G29-command

But my suggestion is for you to wait a few days, because we are very close to having some other enhancements in place in the G29 and a specific version for the MakerFarm.

----------


## TopJimmyCooks

Again, thanks. I'll eagerly look forward to that update.

----------


## printbus

What? Somebody doing a malloc in Arduino code?  Man, my respect for dacb just went up a few notches.

----------


## Roxy

Dacb:   I might have successfully cloned your latest branch of the Marlin code on my machine.  I made the malloc() changes.  But it would not let me sync them.   The sync fails because I do not have permissions.  Can you grab the code I added?

Also, I attempted to push my Slic3r G29 Post Processing script up into your PlugIns directory.   I don't know if that worked either.  Can you see it and grab it?

----------


## dacb

> ...I think having the parameters named Xmin, Ymin, Xmax, Ymax is much clearer. The big problem is none of the other GCode commands use long parameter names. And there is no support for the longer parameter names. The support code would not be difficult to do. But....
> 
> 
> One idea would be to change the Code_Seen(char ) function to be Code_Seen(char *). It would be very quick to go through the code base (and probably it is just Marlin_main.cpp) to put double quotes around all the existing characters in Code_Seen() functions. We could leave everything else the same where it leaves a pointer looking at the numeric value for the hunted parameter. If we did that... Xmin, Ymin, Xmax, Ymax would work nicely and avoid a lot of confusion for people...



I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit.  I would propose I, J, K, and L.  These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B).  Each of these followed by a value in mm.





> To facilitate merging the updates back into the Marlin trunk, I'd reconsider whether the fork uses the MakerFarm changes to the Type 6 thermistor. The Marlin trunk isn't going to want the Type 6 table changed - there could be people out there used to how it measures temperatures. Your configuration.h file also still contains the now incorrect comment about Type 6 not being as accurate as Type 1 and being created with a Fluke thermocouple. My vote would be to revert thermistortables.h back to the Marlin Type 6 data and change configuration.h to use Type 1 thermistors. Beyond what I concluded in the referenced thread, I think someone said zennmasterM has also said it's OK for MakerFarm people to use Type 1 when they update their firmware as part of his video on auto leveling. 
> 
> 
> EDIT: BTW - I've been using Type 1 just fine the last week or so. If, for some reason, we're uncomfortable switching to Type 1, the MakerFarm thermistor table could at least be defined as a new thermistor type that is used rather than modifying the Marlin type 6 table.



I have to agree with this. Going back to master on thermistors just makes sense, here is the commit: https://github.com/beckdac/Marlin/co...f473eed821097b





> Dacb: Random new topic here: You modified the code to allocate space this way:...


I can't actually take credit for that code, it is from https://github.com/ErikZalm/Marlin/pull/1022


*Good catch on the missing free.
*




> What? Somebody doing a malloc in Arduino code? Man, my respect for dacb just went up a few notches.



I'm a die hard 'avr-gcc/avr-libc and nice tight hand crafted libs on a Tiny' kind of guy, so I have to confess I don't use the Arduino environment for my AVR projects (but I love AVRs!). Hate the idea of loosing timers and the overhead.  I guess with the 2560, this isn't really a problem.





> Dacb: I might have successfully cloned your latest branch of the Marlin code on my machine. I made the malloc() changes. But it would not let me sync them. The sync fails because I do not have permissions. Can you grab the code I added?
> Also, I attempted to push my Slic3r G29 Post Processing script up into your PlugIns directory. I don't know if that worked either. Can you see it and grab it?



Can you PM me your github username?  I'll add you as a collaborator so your commits give you the recognition you deserve!

----------


## Roxy

> I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit. I would propose I, J, K, and L. These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B). Each of these followed by a value in mm.


I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )




> Can you PM me your github username? I'll add you as a collaborator so your commits give you the recognition you deserve!


I don't need credit...  But being able to make updates is helpful.   I sent you a Private Message.    But isn't all that stuff public anyways?   Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?

What are your thoughts on the Post Processors?   The problem is even though I'm a big proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around.   I put the whole Slic3r Post Processor 'MSVC Solution' into your PlugIn folder.   I deliberately made the thing very straight forward C code that uses nothing but generic library functions.  It doesn't even have a header file.   So it will compile with just about anything.   But with that said...  I'm wondering if the Open Source fans are going to be hostile about that?   I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.

----------


## Roxy

> I looked through a bunch of documents about G-code and "standards" and I don't feel that multi-letter parameters is in the spirit. I would propose I, J, K, and L. These are clearly an array but not overly misleading in specificity (e.g. L,F,R,B). Each of these followed by a value in mm.


I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )

And perhaps we are worrying too much about the confusion.   Anybody that uses this feature is going to be using the slicer (either Cura or Slic3r) Post Processors.  The Post Processors will know the correct parameter name for each of the values.  So everything will magically work for the user.   Right????  (I think and hope so!)




> Can you PM me your github username? I'll add you as a collaborator so your commits give you the recognition you deserve!


Thanks!   Mostly I do this just for fun and I don't need credit... However, being able to make updates is helpful.   I sent you a Private Message.    But isn't all that stuff public anyways?   Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?

What are your thoughts on the Post Processors?   The problem is even though I'm back proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around.   I put the whole 'MSVC Solution' into your PlugIn folder.   I deliberately made the thing very straight forward C code that uses nothing but generic library functions.  It doesn't even have a header file.   So it will compile with just about anything.   But with that said...  I'm wondering if the Open Source fans are going to be hostile about that?   I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.

----------


## dacb

> I understand your thoughts! And I 3/4 agree. The big problem is these one letter variable names cause all kinds of problems. And given the code cost is so minimal to support long parameter names, I'm actually thinking it makes sense to make a transition. After all... If somebody doesn't want to have a longer, clearer variable name in the G29 command, they don't need to use it. But with that said, I'm perfectly fine moving to some parameter names that mean nothing and add no confusion. It will be easy to document that I is the minimum X-Axis coordinate to probe. J is the maximum X-Axis coordinate to probe, etc, etc. What we really are trying to do is set this up so people aren't pulling their hair out trying to get it working. (and longer parameter names would do that just as going with I,J,K & L will do it. )


I totally understand your frustration about the parameters.  I think your approach of using solid documentation like you have done in the past will be the way to signal the correct usage of more generic parameters like I, J, K, L.  




> Thanks!   Mostly I do this just for fun and I don't need credit... However, being able to make updates is helpful.   I sent you a Private Message.    But isn't all that stuff public anyways?   Anybody that is using a fork in the tree can trace it back to every change that is made and who made it, right?


Yes.  I am a big proponent of github, but with this instance I was very frustrated.  I spent a good half an hour trying to search through the master Marlin pull requests and I couldn't come up with your github username.  I know you had the repeatability pull request accepted, but I just couldn't find a good way to search the history.  WTF github?!!?  I'd love for someone to tell me how to make that search work.




> What are your thoughts on the Post Processors?   The problem is even though I'm back proponent of Open Source, I do use MSVC Studio for most of my C code when I'm playing around.   I put the whole 'MSVC Solution' into your PlugIn folder.   I deliberately made the thing very straight forward C code that uses nothing but generic library functions.  It doesn't even have a header file.   So it will compile with just about anything.   But with that said...  I'm wondering if the Open Source fans are going to be hostile about that?   I guess if they don't like it, they can spend the time to take the single .C file and set up a GCC environment for it.


Emphatically: no problem. If you put your stuff in a repo, you are tacitly agreeing to the license that is already in place?  I see now reason why your solution can't be considered open source. Open source is about making the source open, not about making it compile on everyone's OS.  Can't wait to have your commits!

----------


## Roxy

> Yes.  I am a big proponent of github, but with this instance I was very frustrated.  I spent a good half an hour trying to search through the master Marlin pull requests and I couldn't come up with your github username.  I know you had the repeatability pull request accepted, but I just couldn't find a good way to search the history.  WTF github?!!?  I'd love for someone to tell me how to make that search work.


I have TortoiseGit installed and I can see changes in Windows Explorer to the files.   They seem to track the status in the Git help as I commit and do things.   But when I try to Push the changes  (I'm right clicking on the top directory of your cloned branch in Explorer, selecting TortoiseGit and then saying Push) I get this window:

pict1.jpg

And when I say 'OK' it does this:

pict2.jpg

But it depends on the way I try to do the Push.   Other paths produce a box saying this message:

fatal: Unable to find remote helper for 'https'

And of course...  searching on the web doesn't really help.  It seems like everybody getting this message is on a Linux machine and I'm using Windows.   They want me to rebuild Git.  They want me to switch to a different version of Ubuntu Linux.  They want me to run a configure script and then do a Makefile with some options.       Aaaargggghhhhh.....

This Git stuff is *NOT* easy to use!    


And one more thing....   I did a revision graph of your fork.    Can it be 'Re-Based' off of something higher up so it doesn't fall behind?


pict3.jpg

----------


## dacb

I really wish I could offer more support for using the git clients. I am mostly on the command line, but I have found the "official" github clients work well, I know there is a windows one: https://windows.github.com




> ...And one more thing.... I did a revision graph of your fork. Can it be 'Re-Based' off of something higher up so it doesn't fall behind?...


I will periodically pull against the upstream master and resolve conflicts, but for right now we should be current.  Is that what you mean?

----------


## Roxy

> I really wish I could offer more support for using the git clients. I am mostly on the command line, but I have found the "official" github clients work well, I know there is a windows one: https://windows.github.com


OK!   That sort of worked.   I think I got the memory leak update pushed up.   And I think I got the Slic3r Plug-In uploaded.  But I'm not sure they are 'Committed'.   I can view them on GitHub's web page and it shows your name in the fork so I think they are there.    But then going any further up the list of changes I get conflicts and can't resolve them.  There isn't anything that is worth resolving...   I just made a couple of changes to the Configuration.h file to test if I could sync and commit this morning.

Maybe the thing to do is have you check if everything is still good and working...   If you publish a link I'll re-clone starting at that point?    That would get rid of all my conflicts and let me start fresh.




> I will periodically pull against the upstream master and resolve conflicts, but for right now we should be current.  Is that what you mean?


Well, it looks like Erik Zalm has made a couple of releases since you branched off.   I was mostly wondering if I interpreted that right, and was curious why you didn't branch from a higher level.

----------


## dacb

> OK! That sort of worked. I think I got the memory leak update pushed up. And I think I got the Slic3r Plug-In uploaded. But I'm not sure they are 'Committed'. I can view them on GitHub's web page and it shows your name in the fork so I think they are there. But then going any further up the list of changes I get conflicts and can't resolve them. There isn't anything that is worth resolving... I just made a couple of changes to the Configuration.h file to test if I could sync and commit this morning.


* The memory leak fix committed fine: https://github.com/beckdac/Marlin/co...46120e33f10927
* as did the Slic3r script: https://github.com/beckdac/Marlin/co...87c5bb8b292614
* It looks like you didn't do a git pull before starting the changes to Configuration.h and the termistor table stuff reverted: https://github.com/beckdac/Marlin/co...87c5bb8b292614
I dropped your changes to Configuration.h (too hard to discern from the log, sorry) and reverted to the type 1 thermistor: https://github.com/beckdac/Marlin/co...21af567a295c68
Maybe you can do a git pull and then restore you Configuration.h changes?
* Finally, I noticed that your awesome missing free fix referenced the wrong variable name, I fixed this and it compiles great.  I'm testing this on my machine right now. Commit: https://github.com/beckdac/Marlin/co...306c106ceaf9b6




> Well, it looks like Erik Zalm has made a couple of releases since you branched off.   I was mostly wondering if I interpreted that right, and was curious why you didn't branch from a higher level.


I've pulled all those and incorporated them so we are good to go there.




> If you publish a link I'll re-clone starting at that point? That would get rid of all my conflicts and let me start fresh.


That is certainly a possibility.  In your web browser, click the fork link on my repo and get started. Issue a pull request when you have something to incorporate. Personally, I'd rather we were all operating on the same repo vs. another merge set, but open source works many ways and a fork of a fork is absolutely fine.  Let me know which way you choose.

Thanks for all your hard work.

----------


## Roxy

> * The memory leak fix committed fine: https://github.com/beckdac/Marlin/co...46120e33f10927
> * as did the Slic3r script: https://github.com/beckdac/Marlin/co...87c5bb8b292614


Great!   I'm starting to figure out the process!   The Slic3r one has more stuff in it, right?  It has the both the Memory Leak fix and the Slic3r G29 Post Processor stuff?   If so, that will be the one I should start from next.




> * It looks like you didn't do a git pull before starting the changes to Configuration.h and the termistor table stuff reverted: https://github.com/beckdac/Marlin/co...87c5bb8b292614
> I dropped your changes to Configuration.h (too hard to discern from the log, sorry) and reverted to the type 1 thermistor: https://github.com/beckdac/Marlin/co...21af567a295c68


I don't understand.   I got the whole code base.   Can't I just make changes to test stuff and send it back when it is right?   I guess I don't understand this Push and Pull stuff.    When I did the clone, doesn't that 'Pull' everything from the branch so I have it too?   Or is the problem the fact that other changes were made in the mean time?   If that is the case, my guess is there is a way to merge the two divergent paths back together again.   But right now...  I'm not advanced enough to do that.




> Maybe you can do a git pull and then restore you Configuration.h changes?


I'll do a diff but I suspect there is hardly anything there to preserve.   I was unable to make the Push work so I wanted to just have a simple change to the Configuration.h file to see if I could make it happen.   I cleaned up some wording on a comment.  It was a worth while fix but nothing that will be noticed if it isn't done.




> * Finally, I noticed that your awesome missing free fix referenced the wrong variable name, I fixed this and it compiles great.  I'm testing this on my machine right now. Commit: https://github.com/beckdac/Marlin/co...306c106ceaf9b6


Oooops!   I went back and looked at my post.   (And I cut and pasted that into the cloned image I grabbed.)   I didn't have any way to compile it or I probably would have found that mistake.   Sorry!




> I've pulled all those and incorporated them so we are good to go there.
> 
> That is certainly a possibility.  In your web browser, click the fork link on my repo and get started. Issue a pull request when you have something to incorporate. Personally, I'd rather we were all operating on the same repo vs. another merge set, but open source works many ways and a fork of a fork is absolutely fine.  Let me know which way you choose.


I certainly don't need to Fork!   The reason I said that is that is the only experience I have for getting a code base.    Is a Clone and a Pull the same thing?   If so, then I understand why you said what you did.   It would make sense to just Pull the current code base and use that as a new starting point.   But I still don't understand why I needed to Pull the Configuration.h file to make a small change when I already had it.   Maybe the answer is I didn't have the most recent version.  The code base had already moved on from what I had???

----------


## dacb

> I don't understand. I got the whole code base. Can't I just make changes to test stuff and send it back when it is right? I guess I don't understand this Push and Pull stuff. When I did the clone, doesn't that 'Pull' everything from the branch so I have it too? Or is the problem the fact that other changes were made in the mean time? If that is the case, my guess is there is a way to merge the two divergent paths back together again. But right now... I'm not advanced enough to do that.



You know, the lingo takes some getting used to.  Here are my simplified thoughts... When you *clone* a repository, you make a local copy.  As you work in there, you can *commit* changes to your local copy.  Periodically, you can *push* those changes back up to the main repository from where you cloned the repo.  Periodically, while working with your local copy, you want to *pull* down any changes from the main repository to your local so that you are current.  I almost always do this before a commit on a group project so that I can resolve any _conflicts_ beforehand.  The idea of a local copy that only syncs with the main when you do a push is different from other source control tools.

When I *fork* someone's main repository, we branch off on separate development paths.  When the repository that I forked from changes in, I can do an _upstream pull_ where I sync changes in the main repository to my fork.  You can also do this on a commit by commit basis so that you can test out each change from the main in the context of your fork.  If I think I have some good changes in my fork that the main repository could use, I can issue a *pull request*. This is one thing that confuses people because you think of it as a push request from your fork, but the logic is the main repository maintainer has to issue the pull, not the fork maintainer issuing a push which could wreak havoc on the main repo's possibly unwilling recipient.

There are some canonical names (that can be overridden) for different pieces of a source tree.  One of them is master which refers to the main branch that I sometimes call trunk because I also use subversion, sorry for that.  There are also branches which can be given a name, e.g. RoxysAwesomeFeatureBranch. This is sort of a mini fork within a repository.  One way to manage multiple people working on the same repository is to give them each a branch for development and then periodically after code review, the branches are merged back into the master.

For good software hygiene, I try to monitor commits and pull early and often.  This way I can be proactive about dealing with conflicts, before I commit.

Hurray for software jargon!

I don't know if that helped or was just telling you stuff you already know.

----------


## Roxy

> Hurray for software jargon!
> 
> I don't know if that helped or was just telling you stuff you already know.


Yes!  Thank You for spending the time to explain that.    That helped a lot.    I need to get this latest code working with my printer so I can test out (and probably improve) the Slic3r Post Processor.

Note to DACB:   I'm swamped with other things...   But I'm going to be working on this when I get some time.   The Slic3r Post Processor needs to be shaken out before it gets checked in.

----------


## AbuMaia

Roxy, in the Mechanical Calibration section of your firmware, for the hobbed bolt, which part is the measurement? The bolt itself, or the hobbed part?

----------


## Roxy

I believe that is the inner diameter of the 'hobbled' part of the bolt.   I inherited those settings (or definitions) when I got the kit.   I modified some of the things like the gear ratio on that line.  But I did not create the original version of that definition.   I did do a calibration early on in the build process and the extruder did put out the correct amount of filament, so until I changed the gear ratio, I left well enough alone.

----------


## AbuMaia

I've found that 900 works for me for extruder steps, so I just played with the bolt diameter number until the equation gave as close to 900 as I could get. I really don't want to disassemble my extruder to be able to measure the bolt. I emailed Colin for a measurement, but that'll have to wait until tomorrow.

----------


## TopJimmyCooks

I am using the G-29 enhancements.  I have a problem with the servo continuing to move during the print.  it tries to rotate past the retracted position during printing and gets stopped by the X carriage.  one time it went so hard it was stuck and I had to move it manually to get it working again.  

I have the line
#define PROBE_SERVO_DEACTIVATION_DELAY 500 
in config/h, so it's not the chattering thing.  

Appreciate any help/ideas.  Thanks.

----------


## Roxy

> I am using the G-29 enhancements.  I have a problem with the servo continuing to move during the print.  it tries to rotate past the retracted position during printing and gets stopped by the X carriage.  one time it went so hard it was stuck and I had to move it manually to get it working again.  
> 
> I have the line
> #define PROBE_SERVO_DEACTIVATION_DELAY 500 
> in config/h, so it's not the chattering thing.  
> 
> Appreciate any help/ideas.  Thanks.


If the servo really is deactivated, it shouldn't move.   So that is one thing we will have to explore.    The other thing we should check out is if your angles are correct for engaging the servo and retracting it.

Is it possible to post a picture of your Z-probe (and as much of the servo as possible) in both the up and down position?   And can you post your Configuration.h file?    What I'm thinking is we can give you some simple commands to verify that the angles are correct.   And that the servo is being powered (and unpowered) at the correct times.

----------


## AbuMaia

"This branch is 20 commits ahead, 34 commits behind ErikZalm:Marlin_v1"

Any news on what's going on with this fork?

----------


## jtice

I am in the process of setting up Auto Bed Level and ran into a few issues.
I used this set of videos to help me through the process...
http://www.youtube.com/watch?v=YpiOsetkIRg

When I went to run the G28 command to home the printer, it now homes near the center of the bed, and not the very back right corner like it used to.
How do i change this back? I am afraid to run the auto level command, cuz I think it will try to go off the bed too far now sense its starting in the middle.

This is probably due to the home position being different in the firmware linked in the first post here.

EDIT
Just went ahead and tried the G29 command to have it run auto level.  (still cant figure out how to get home back to 0,0,0)
That seemed to work fine, it took 6 readings and stopped at the last position.
But, if I have the printer start a print, it does not autolevel first.
Is this something that will have to be added to all my gcode?
I see in Cura I can put commands at start and end.
Should I add the G29 command that? Or should I remove the 2 lines that have the G28 command and put G29 there?
I pasted my start code below.
And if I do, I assume it will run autolevel before the print, and store those readings, and proceed to do the print with those readings?

;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
;M190 S{print_bed_temperature} ;Uncomment to add your own bed temperature line
;M109 S{print_temperature} ;Uncomment to add your own temperature line
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F200 E3              ;extrude 3mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...

*EDIT.......................*
OOOOOOOOOOOK, well taking out the 2 G28 lines and adding G29 was baaaaaaaad

Extruder moved RIGHT, hard crashing X and tried to go even further, slipping the belt, had to flip the power switch !!

Should the G29 line have anything after it? Or just G29?

*EDIT..........................*
Well this is odd, now G29 doesnt even work in Pronterface.
Printer does nothing, Proterface reads...

SENDING:G29
echo:Home X/Y before Z

It also says that if I try to home just Z
X and Y will home seperately just fine.

G28 seems to work, though it homes Z in about the middle of the bed.
The printer moves to the X and Y end stops,
then moves to about the middle of the bed, lowers the probe and end stops it, raises the probe, and stays there.


Now if I try to do a print, and have the original G28 commands in the gcode like before I started all this autolevel stuff,
the printer will home X and Y, then just start printing, without homing Z
It starts to print, and it too low, touching the bed.
So, I am basically stuck at this point and cant print till I get something working right  :Frown:

----------


## AbuMaia

You need to have a G28 in your start GCODE, followed by the G29. You need both.

G28 X0 Y0  ;move X/Y to min endstops
G28 Z0     ;move Z to min endstops

You can change those lines to one "G28", it'll do all three axes if none are specified. Then put a G29 after them.




> G28 seems to work, though it homes Z in about the middle of the bed.


Yes, it'll do that if you have Safe Z Homing enabled. It's a feature, not a bug.  :Smile:

----------


## jtice

OK, I see now that G28 has to be done befor eyou run G29,
that works fine in Pronterface, but when I tried to do a print the extruder homed X and Y, but then started to lower itself to home Z like it always does...
but it didnt lower the prob. And I killed the power just before it hard crashed into the bed.

So, do I need to put the prob extend command in my start code before I tell it to home Z with the G28 Z0 command?
Its odd that running the G28 command in proterface, the printer knows to lower the probe, but not when it was starting a print.


Just tried a print with this code....
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28 X0 Y0  ;move X/Y to min endstops
M280 P0 S68
G28 Z0     ;move Z to min endstops
M280 P0 S155
G29

it acted very odd, it went through all the motions, even doing the auto bed level....
But never put the probe down at ALL.
Yet, it still lowered Z down and would stop, as if it had hit an endstop, then raised, and went to the next place, etc.

ahhhh, WTF?   lol

----------


## AbuMaia

Why are you calling M280 in the start GCODE?

Here's my start code:

M117 Resetting Printer...
G28 ; home all axes
M117 Heating Print Bed...
M190 S[first_layer_bed_temperature] ; set bed temperature, wait for it to reach target before proceeding
M117 Homing...
G28
M104 S[first_layer_temperature] ; set hotend temperature. Use M109 to set and wait
M117 Auto Bed Leveling...
G29 n 4 ; auto level
G1 X99 Y99 Z1 F1500; reposition extruder
M117 Printing...

----------


## jtice

I added the M280 to try to get the probe to extend, but it has no effect.

What is the n 4 you have after G29?

Also, if I use the Prusa LCD control and tell it to Auto Home,
when it moves to the center of the bed to home Z, it does not extend the probe.

----------


## AbuMaia

The n4 tells the printer to run the G29 routine with a 4x4 probe point grid. It's from the enhanced G29 code found here: http://3dprintboard.com/showthread.p...ed-G29-command If you're using the firmware fork from this topic, you should already have it installed.

----------


## jtice

hmmmmm, no I think I used the firmware from this thread actually.

----------


## AbuMaia

That's what I meant. So you should already have the enhanced G29 code installed.

----------


## jtice

Thanks for the help guys, I have it working fairly well now.

Still need to tweak a few things. But it does at least seem to be working, just have to get it dialed in, like anything else for printers.
One thing that messed it up was under the RC Servo section, where you set if an axis endstop uses a servo or not, 
-1 is off, anything else is true. Well instead of 0 I had a 1 there. It should have been fine, but apparently not, at least with my setup.
Little concerning though, since I want to add the feature of disabling the servo when not in use (its fine, but makes a bunch of noise as you are printing)
I saw that you need to have that value set to something other than 0. I hope the combo of changing it to a 1 and enabling that feature doesnt bring back my issue. (wasnt lowering the probe at any time)

Only other odd thing it did once was when it started a print, and it was already Homed, it went to put the servo down and didnt have room.
This has only happened once, must have been a glitch. All other times it has Homed X and Y, then raised up, went to the center of the bed, lowered the probe, and homed Z.

I do need to add the feature of making it raise after homing Z, before it retracts the probe.

----------


## Roxy

> I added the M280 to try to get the probe to extend, but it has no effect.
> 
> What is the n 4 you have after G29?


He is using the Enhanced Bed Leveling with extra options.    If you are not using that, the extra information will be ignored.




> Also, if I use the Prusa LCD control and tell it to Auto Home,
> when it moves to the center of the bed to home Z, it does not extend the probe.


Two questions.   First do you ever see or have a way to get the Z-Probe to engage?   

Second, in your configuration.h file, have you enabled 'Safe Homing' ?     There is a code block that looks like this:


```
  #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with probe outside the bed area.
                          // When defined, it will:
                          // - Allow Z homing only after X and Y homing AND stepper drivers still enabled
                          // - If stepper drivers timeout, it will need X and Y homing again before Z homing
                          // - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
                          // - Block Z homing only when the probe is outside bed area.

  #ifdef Z_SAFE_HOMING

    #define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2)    // X point for Z homing when homing all axis (G28)
    #define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2)    // Y point for Z homing when homing all axis (G28)

  #endif

#endif // ENABLE_AUTO_BED_LEVELING
```

If this is enabled, this is why your nozzle is going to the middle of the bed.  I think this was put in place to help Delta printers not destroy themselves.  But it is still useful for Cartesian machines.    I have this turned on for my printer.

----------


## Roxy

> Little concerning though, since I want to add the feature of disabling the servo when not in use (its fine, but makes a bunch of noise as you are printing)
> I saw that you need to have that value set to something other than 0. I hope the combo of changing it to a 1 and enabling that feature doesnt bring back my issue. (wasnt lowering the probe at any time)


Be careful here.   If you are talking about the 

#define PROBE_SERVO_DEACTIVATION_DELAY 500

line, 1 will be 1 millisecond.   That won't be enough time and almost guarantees you will have problems.  If you don't set this at zero, be sure to make it enough that the time is noticeable.  Like at least one half of a second.




> Only other odd thing it did once was when it started a print, and it was already Homed, it went to put the servo down and didnt have room.
> This has only happened once, must have been a glitch. All other times it has Homed X and Y, then raised up, went to the center of the bed, lowered the probe, and homed Z.
> 
> I do need to add the feature of making it raise after homing Z, before it retracts the probe.


The Enhanced Auto Bed Leveling handles this naturally.  But you can add start up GCode to handle this.

----------


## jtice

I am happy to report that I have Auto Leveling working very well now !!!!!
Thanks to all the great info and helpful people here. !

I have the G28 and G29 commands added to my Cura profiles now, and they seem to be working perfectly.
I had to make a couple adjustments to the Z offset to get the first layer printing at just the right height, 
but I have done 4 prints now, and the first layer is going down beautifully. Very even and consistent, even once the bed is warm from printing all day.

I have it setup to take readings that cover almost all of the print area, takes a 3x3 grid or readings.
I may tweak a few things to make it go a bit quicker, like raising up a bit less, etc. but its not a big deal, its saving me time just to not adjust the bed or first layer height each print!

One thing I want to do next though is to disable the servo when its not in use, thats what I mentioned above.
When I mentioned setting it to something other than 0, 1 in my case, I was referring to...
#define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1

As you can see, I have it set to 0, before, I had it set to 1, and I think thats what caused it to not lower the probe at all, at any time.
I had it set to 1 based on this statement in the code....
//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

What is it referring to when it says "You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile."
The only place I could find SERVO_ENDSTOPS was the section of code I mentioned above, that I had set to 1 before.
I had it set to one, thinking this was the place it meant not to set to 0

Alittle clarification on this would be appreciated.
The servo twitches alittle while it is taking readings, but its not too bad, I mainly want to enable this feature so that the servo is disabled during printing.
It makes noise as it maintains its retracted position, since the printer shakes it around a bit.

----------


## TopJimmyCooks

> If the servo really is deactivated, it shouldn't move.   So that is one thing we will have to explore.    The other thing we should check out is if your angles are correct for engaging the servo and retracting it.
> 
> Is it possible to post a picture of your Z-probe (and as much of the servo as possible) in both the up and down position?   And can you post your Configuration.h file?    What I'm thinking is we can give you some simple commands to verify that the angles are correct.   And that the servo is being powered (and unpowered) at the correct times.


configuration.h included below.
start up gcode below.  
I don't have pic's of the Z probe positions however the positions listed in the configuration.h are correct and work correctly.  127 is extended and 44 is retracted.  it looks like it tries to go to 0 degrees at times during printing. 
As mentioned the servo turnoff timeout is set at 300 or 500 ms.
I searched through some recent gcode files for any stray m280 commands just in case but did not find them.  

thanks!



```
;this was startup gcode from a recent file using cura.  same problem happens under slicer as well.  


M140 S60.000000
M109 T0 S150.000000
T0
M190 S60.000000
;Sliced at: Tue 14-10-2014 21:03:36
;Basic settings: Layer height: 0.2 Walls: 1 Fill: 20
;Print time: #P_TIME#
;Filament used: #F_AMNT#m #F_WGHT#g
;Filament cost: #F_COST#
;M190 S60 ;Uncomment to add your own bed temperature line
;M109 S190 ;Uncomment to add your own temperature line
G21        ;metric values
G90        ;absolute positioning
M82        ;set extruder to absolute mode
M107       ;start with the fan off
G28      ;auto home
G29             ;Automatic Bed Leveling
M109 T0 S190.000000
G1 Z15.0 F9000 ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F200 E3              ;extrude 3mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F9000
;Put printing message on LCD screen
M117 Printing...
;Layer count: 55
;LAYER:0
M107
G0 F9000 X39.290 Y61.175 Z0.300
;TYPE:SKIRT
G1 F1800 X40.961 Y60.732 E0.04065
G1 X42.336 Y60.759 E0.07298
G1 X42.818 Y60.873 E0.08463
G1 X43.258 Y60.116 E0.10522
G1 X44.292 Y59.033 E0.14043
G1 X45.863 Y58.182 E0.18244
```



```
//configuration.h
#ifndef CONFIGURATION_H
#define CONFIGURATION_H


// This configuration file contains the basic settings.
// Advanced settings can be found in Configuration_adv.h
// BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration


//===========================================================================
//============================= DELTA Printer ===============================
//===========================================================================
// For a Delta printer replace the configuration files with the files in the
// example_configurations/delta directory.
//


// User-specified version info of this build to display in [Pronterface, etc] terminal window during
// startup. Implementation of an idea by Prof Braino to inform user that any changes made to this
// build by the user have been successfully uploaded into firmware.
#define STRING_VERSION_CONFIG_H __DATE__ " 8/27/14" __TIME__ // build date and time
#define STRING_CONFIG_H_AUTHOR "(David Kanoy/Makerfarm I3v changes/Z auto leveling)" // Who made the changes.


// SERIAL_PORT selects which serial port should be used for communication with the host.
// This allows the connection of wireless adapters (for instance) to non-default port pins.
// Serial port 0 is still used by the Arduino bootloader regardless of this setting.
#define SERIAL_PORT 0


// This determines the communication speed of the printer
// This determines the communication speed of the printer
#define BAUDRATE 250000


// This enables the serial port associated to the Bluetooth interface
//#define BTENABLED              // Enable BT interface on AT90USB devices




//// The following define selects which electronics board you have. Please choose the one that matches your setup
// 10 = Gen7 custom (Alfons3 Version) "https://github.com/Alfons3/Generation_7_Electronics"
// 11 = Gen7 v1.1, v1.2 = 11
// 12 = Gen7 v1.3
// 13 = Gen7 v1.4
// 2  = Cheaptronic v1.0
// 20 = Sethi 3D_1
// 3  = MEGA/RAMPS up to 1.2 = 3
// 33 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Bed)
// 34 = RAMPS 1.3 / 1.4 (Power outputs: Extruder0, Extruder1, Bed)
// 35 = RAMPS 1.3 / 1.4 (Power outputs: Extruder, Fan, Fan)
// 4  = Duemilanove w/ ATMega328P pin assignment
// 5  = Gen6
// 51 = Gen6 deluxe
// 6  = Sanguinololu < 1.2
// 62 = Sanguinololu 1.2 and above
// 63 = Melzi
// 64 = STB V1.1
// 65 = Azteeg X1
// 66 = Melzi with ATmega1284 (MaKr3d version)
// 67 = Azteeg X3
// 68 = Azteeg X3 Pro
// 7  = Ultimaker
// 71 = Ultimaker (Older electronics. Pre 1.5.4. This is rare)
// 72 = Ultimainboard 2.x (Uses TEMP_SENSOR 20)
// 77 = 3Drag Controller
// 8  = Teensylu
// 80 = Rumba
// 81 = Printrboard (AT90USB1286)
// 82 = Brainwave (AT90USB646)
// 83 = SAV Mk-I (AT90USB1286)
// 84 = Teensy++2.0 (AT90USB1286) // CLI compile: DEFINES=AT90USBxx_TEENSYPP_ASSIGNMENTS HARDWARE_MOTHERBOARD=84  make
// 9  = Gen3+
// 70 = Megatronics
// 701= Megatronics v2.0
// 702= Minitronics v1.0
// 90 = Alpha OMCA board
// 91 = Final OMCA board
// 301= Rambo
// 21 = Elefu Ra Board (v3)
// 88 = 5DPrint D8 Driver Board


#ifndef MOTHERBOARD
#define MOTHERBOARD 33
#endif


// Define this to set a custom name for your generic Mendel,
// #define CUSTOM_MENDEL_NAME "This Mendel"


// Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines)
// You can use an online service to generate a random UUID. (eg http://www.uuidgenerator.net/version4)
// #define MACHINE_UUID "00000000-0000-0000-0000-000000000000"


// This defines the number of extruders
#define EXTRUDERS 1


//// The following define selects which power supply you have. Please choose the one that matches your setup
// 1 = ATX
// 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC)


#define POWER_SUPPLY 1


// Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it.
// #define PS_DEFAULT_OFF


//===========================================================================
//=============================Thermal Settings  ============================
//===========================================================================
//
//--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table
//
//// Temperature sensor settings:
// -2 is thermocouple with MAX6675 (only for sensor 0)
// -1 is thermocouple with AD595
// 0 is not used
// 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup)
// 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup)
// 3 is Mendel-parts thermistor (4.7k pullup)
// 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !!
// 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup)
// 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup)
// 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup)
// 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup)
// 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup)
// 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup)
// 10 is 100k RS thermistor 198-961 (4.7k pullup)
// 11 is 100k beta 3950 1% thermistor (4.7k pullup)
// 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed)
// 20 is the PT100 circuit found in the Ultimainboard V2.x
// 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950
//
//    1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k
//                          (but gives greater accuracy and more stable PID)
// 51 is 100k thermistor - EPCOS (1k pullup)
// 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup)
// 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup)
//
// 1047 is Pt1000 with 4k7 pullup
// 1010 is Pt1000 with 1k pullup (non standard)
// 147 is Pt100 with 4k7 pullup
// 110 is Pt100 with 1k pullup (non standard)
// 70 is 500C thermistor for Pico hot end


#define TEMP_SENSOR_0 1
#define TEMP_SENSOR_1 0
#define TEMP_SENSOR_2 0
#define TEMP_SENSOR_BED 1


// This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted.
//#define TEMP_SENSOR_1_AS_REDUNDANT
#define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10


// Actual temperature must be close to target for this long before M109 returns success
#define TEMP_RESIDENCY_TIME 10  // (seconds)
#define TEMP_HYSTERESIS 3       // (degC) range of +/- temperatures considered "close" to the target one
#define TEMP_WINDOW     1       // (degC) Window around target to start the residency timer x degC early.


// The minimal temperature defines the temperature below which the heater will not be enabled It is used
// to check that the wiring to the thermistor is not broken.
// Otherwise this would lead to the heater being powered on all the time.
#define HEATER_0_MINTEMP 5
#define HEATER_1_MINTEMP 5
#define HEATER_2_MINTEMP 5
#define BED_MINTEMP 5


// When temperature exceeds max temp, your heater will be switched off.
// This feature exists to protect your hotend from overheating accidentally, but *NOT* from thermistor short/failure!
// You should use MINTEMP for thermistor short/failure protection.
#define HEATER_0_MAXTEMP 235
#define HEATER_1_MAXTEMP 275
#define HEATER_2_MAXTEMP 275
#define BED_MAXTEMP 125


// If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the
// average current. The value should be an integer and the heat bed will be turned on for 1 interval of
// HEATER_BED_DUTY_CYCLE_DIVIDER intervals.
//#define HEATER_BED_DUTY_CYCLE_DIVIDER 4


// If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS
//#define EXTRUDER_WATTS (12.0*12.0/6.7) //  P=I^2/R
//#define BED_WATTS (12.0*12.0/1.1)      // P=I^2/R


// PID settings:
// Comment the following line to disable PID and enable bang-bang.
#define PIDTEMP
#define BANG_MAX 255 // limits current to nozzle while in bang-bang mode; 255=full current
#define PID_MAX 255 // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current
#ifdef PIDTEMP
  //#define PID_DEBUG // Sends debug data to the serial port.
  //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX
  #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature
                                  // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max.
  #define PID_INTEGRAL_DRIVE_MAX 255  //limit for the integral term
  #define K1 0.95 //smoothing factor within the PID
  #define PID_dT ((OVERSAMPLENR * 8.0)/(F_CPU / 64.0 / 256.0)) //sampling period of the temperature routine


// If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it
// Ultimaker
    #define  DEFAULT_Kp 22.2
    #define  DEFAULT_Ki 1.08
    #define  DEFAULT_Kd 114


// MakerGear
//    #define  DEFAULT_Kp 7.0
//    #define  DEFAULT_Ki 0.1
//    #define  DEFAULT_Kd 12


// Mendel Parts V9 on 12V
//    #define  DEFAULT_Kp 63.0
//    #define  DEFAULT_Ki 2.25
//    #define  DEFAULT_Kd 440
#endif // PIDTEMP


// Bed Temperature Control
// Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis
//
// Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder.
// If your PID_dT above is the default, and correct for your hardware/configuration, that means 7.689Hz,
// which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating.
// This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater.
// If your configuration is significantly different than this and you don't understand the issues involved, you probably
// shouldn't use bed PID until someone else verifies your hardware works.
// If this is enabled, find your own PID constants below.
//#define PIDTEMPBED
//
//#define BED_LIMIT_SWITCHING


// This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option.
// all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis)
// setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did,
// so you shouldn't use it unless you are OK with PWM on your bed.  (see the comment on enabling PIDTEMPBED)
#define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current


#ifdef PIDTEMPBED
//120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+)
//from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10)
    #define  DEFAULT_bedKp 10.00
    #define  DEFAULT_bedKi .023
    #define  DEFAULT_bedKd 305.4


//120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+)
//from pidautotune
//    #define  DEFAULT_bedKp 97.1
//    #define  DEFAULT_bedKi 1.41
//    #define  DEFAULT_bedKd 1675.16


// FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles.
#endif // PIDTEMPBED






//this prevents dangerous Extruder moves, i.e. if the temperature is under the limit
//can be software-disabled for whatever purposes by
#define PREVENT_DANGEROUS_EXTRUDE
//if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately.
#define PREVENT_LENGTHY_EXTRUDE


#define EXTRUDE_MINTEMP 170
#define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances.


/*================== Thermal Runaway Protection ==============================
This is a feature to protect your printer from burn up in flames if it has
a thermistor coming off place (this happened to a friend of mine recently and
motivated me writing this feature).


The issue: If a thermistor come off, it will read a lower temperature than actual.
The system will turn the heater on forever, burning up the filament and anything
else around.


After the temperature reaches the target for the first time, this feature will 
start measuring for how long the current temperature stays below the target 
minus _HYSTERESIS (set_temperature - THERMAL_RUNAWAY_PROTECTION_HYSTERESIS).


If it stays longer than _PERIOD, it means the thermistor temperature
cannot catch up with the target, so something *may be* wrong. Then, to be on the
safe side, the system will he halt.


Bear in mind the count down will just start AFTER the first time the 
thermistor temperature is over the target, so you will have no problem if
your extruder heater takes 2 minutes to hit the target on heating.


*/
// If you want to enable this feature for all your extruder heaters,
// uncomment the 2 defines below:


// Parameters for all extruder heaters
//#define THERMAL_RUNAWAY_PROTECTION_PERIOD 40 //in seconds
//#define THERMAL_RUNAWAY_PROTECTION_HYSTERESIS 4 // in degree Celsius


// If you want to enable this feature for your bed heater,
// uncomment the 2 defines below:


// Parameters for the bed heater
//#define THERMAL_RUNAWAY_PROTECTION_BED_PERIOD 20 //in seconds
//#define THERMAL_RUNAWAY_PROTECTION_BED_HYSTERESIS 2 // in degree Celsius
//===========================================================================




//===========================================================================
//=============================Mechanical Settings===========================
//===========================================================================


// Uncomment the following line to enable CoreXY kinematics
// #define COREXY


// coarse Endstop Settings
#define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors


#ifndef ENDSTOPPULLUPS
  // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined
  // #define ENDSTOPPULLUP_XMAX
  // #define ENDSTOPPULLUP_YMAX
  // #define ENDSTOPPULLUP_ZMAX
  // #define ENDSTOPPULLUP_XMIN
  // #define ENDSTOPPULLUP_YMIN
  // #define ENDSTOPPULLUP_ZMIN
#endif


#ifdef ENDSTOPPULLUPS
  //#define ENDSTOPPULLUP_XMAX
  //#define ENDSTOPPULLUP_YMAX
  //#define ENDSTOPPULLUP_ZMAX
  #define ENDSTOPPULLUP_XMIN
  #define ENDSTOPPULLUP_YMIN
  #define ENDSTOPPULLUP_ZMIN
#endif


// The pullups are needed if you directly connect a mechanical endswitch between the signal and ground pins.
const bool X_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Y_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
const bool Z_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop.
//#define DISABLE_MAX_ENDSTOPS
//#define DISABLE_MIN_ENDSTOPS


// Disable max endstops for compatibility with endstop checking routine
#if defined(COREXY) && !defined(DISABLE_MAX_ENDSTOPS)
  #define DISABLE_MAX_ENDSTOPS
#endif


// For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1
#define X_ENABLE_ON 0
#define Y_ENABLE_ON 0
#define Z_ENABLE_ON 0
#define E_ENABLE_ON 0 // For all extruders


// Disables axis when it's not being used.
#define DISABLE_X false
#define DISABLE_Y false
#define DISABLE_Z false
#define DISABLE_E false // For all extruders
#define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled


#define INVERT_X_DIR true    // for Mendel set to false, for Orca set to true
#define INVERT_Y_DIR false    // for Mendel set to true, for Orca set to false
#define INVERT_Z_DIR true     // for Mendel set to false, for Orca set to true
#define INVERT_E0_DIR false   // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E1_DIR false    // for direct drive extruder v9 set to true, for geared extruder set to false
#define INVERT_E2_DIR false   // for direct drive extruder v9 set to true, for geared extruder set to false


// ENDSTOP SETTINGS:
// Sets direction of endstops when homing; 1=MAX, -1=MIN
#define X_HOME_DIR -1
#define Y_HOME_DIR -1
#define Z_HOME_DIR -1


#define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS.
#define max_software_endstops true  // If true, axis won't move to coordinates greater than the defined lengths below.


// Travel limits after homing
#define X_MAX_POS 200
#define X_MIN_POS 0
#define Y_MAX_POS 200
#define Y_MIN_POS 0
#define Z_MAX_POS 190 //changed from 200 due to 10mm z raise on homing just in case.
#define Z_MIN_POS 0


#define X_MAX_LENGTH (X_MAX_POS - X_MIN_POS)
#define Y_MAX_LENGTH (Y_MAX_POS - Y_MIN_POS)
#define Z_MAX_LENGTH (Z_MAX_POS - Z_MIN_POS)
//============================= Bed Auto Leveling ===========================


#define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line)


#ifdef ENABLE_AUTO_BED_LEVELING


// There are 2 different ways to pick the X and Y locations to probe:


//  - "grid" mode
//    Probe every point in a rectangular grid
//    You must specify the rectangle, and the density of sample points
//    This mode is preferred because there are more measurements.
//    It used to be called ACCURATE_BED_LEVELING but "grid" is more descriptive


//  - "3-point" mode
//    Probe 3 arbitrary points on the bed (that aren't colinear)
//    You must specify the X & Y coordinates of all 3 points


  #define AUTO_BED_LEVELING_GRID
  // with AUTO_BED_LEVELING_GRID, the bed is sampled in a
  // AUTO_BED_LEVELING_GRID_POINTSxAUTO_BED_LEVELING_GRID_POINTS grid
  // and least squares solution is calculated
  // Note: this feature occupies 10'206 byte
  #ifdef AUTO_BED_LEVELING_GRID


    // set the rectangle in which to probe
    #define LEFT_PROBE_BED_POSITION 25
    #define RIGHT_PROBE_BED_POSITION 140
    #define BACK_PROBE_BED_POSITION 150
    #define FRONT_PROBE_BED_POSITION 50


     // set the number of grid points per dimension
     // I wouldn't see a reason to go above 3 (=9 probing points on the bed)
    #define AUTO_BED_LEVELING_GRID_POINTS 5




  #else  // not AUTO_BED_LEVELING_GRID
    // with no grid, just probe 3 arbitrary points.  A simple cross-product
    // is used to esimate the plane of the print bed


      #define ABL_PROBE_PT_1_X 15
      #define ABL_PROBE_PT_1_Y 180
      #define ABL_PROBE_PT_2_X 15
      #define ABL_PROBE_PT_2_Y 20
      #define ABL_PROBE_PT_3_X 170
      #define ABL_PROBE_PT_3_Y 20


  #endif // AUTO_BED_LEVELING_GRID




  // these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
  //  place nozzle 0.1mm above glass at set point.  enter G92 X0 Y0 Z0 to set this as zero point.  
  // place z probe at same point and lower just to point of triggering the switch.  Enter M114 to get offsets.  Enter offsets with reversed pos/neg here.
  #define X_PROBE_OFFSET_FROM_EXTRUDER 31
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 7
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -5.57


  #define Z_RAISE_BEFORE_HOMING 10       // (in mm) Raise Z before homing (G28) for Probe Clearance.
                                        // Be sure you have this distance over your Z_MAX_POS in case


  #define XY_TRAVEL_SPEED 9000         // X and Y axis travel speed between probes, in mm/min


  #define Z_RAISE_BEFORE_PROBING 10    //How much the extruder will be raised before traveling to the first probing point.
  #define Z_RAISE_BETWEEN_PROBINGS 2  //How much the extruder will be raised when traveling from between next probing points




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




//If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing,
//it is highly recommended you let this Z_SAFE_HOMING enabled!!!


  #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with probe outside the bed area.
                          // When defined, it will:
                          // - Allow Z homing only after X and Y homing AND stepper drivers still enabled
                          // - If stepper drivers timeout, it will need X and Y homing again before Z homing
                          // - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
                          // - Block Z homing only when the probe is outside bed area.


  #ifdef Z_SAFE_HOMING


    #define Z_SAFE_HOMING_X_POINT (0)    // X point for Z homing when homing all axis (G28)  default is (x_max_length/2)
    #define Z_SAFE_HOMING_Y_POINT (0)    // Y point for Z homing when homing all axis (G28)  default is (y_max_length/2)


  #endif


#endif // ENABLE_AUTO_BED_LEVELING




// The position of the homing switches
//#define MANUAL_HOME_POSITIONS  // If defined, MANUAL_*_HOME_POS below will be used
//#define BED_CENTER_AT_0_0  // If defined, the center of the bed is at (X=0, Y=0)


//Manual homing switch locations:
// For deltabots this means top and center of the Cartesian print volume.
#define MANUAL_X_HOME_POS 0
#define MANUAL_Y_HOME_POS 0
#define MANUAL_Z_HOME_POS 0
//#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing.


//// MOVEMENT SETTINGS
#define NUM_AXIS 4 // The axis order in all axis related arrays is X, Y, Z, E
#define HOMING_FEEDRATE {50*60, 50*60, 100, 0}  // set the homing speeds (mm/min)


// default settings


#define DEFAULT_AXIS_STEPS_PER_UNIT   {80,80,4000,902}  // default steps per unit for Ultimaker
#define DEFAULT_MAX_FEEDRATE          {250, 250, 2, 22}    // (mm/sec)
#define DEFAULT_MAX_ACCELERATION      {9000,9000,20,10000}    // X, Y, Z, E (David: defaults were 9000,9000,20, 10000) set to the makerfarm stock numbers. maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot.


#define DEFAULT_ACCELERATION          3000    // X, Y, Z and E max acceleration DAVID makerfarm was 500 in mm/s^2 for printing moves
#define DEFAULT_RETRACT_ACCELERATION  3000   // X, Y, Z and E max acceleration DAVID makerfarm was 500 in mm/s^2 for retracts


// Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing).
// The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder).
// For the other hotends it is their distance from the extruder 0 hotend.
// #define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis
// #define EXTRUDER_OFFSET_Y {0.0, 5.00}  // (in mm) for each extruder, offset of the hotend on the Y axis


// The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously)
#define DEFAULT_XYJERK                20.0    // (mm/sec)
#define DEFAULT_ZJERK                 0.4     // (mm/sec)
#define DEFAULT_EJERK                 5.0    // (mm/sec)


//===========================================================================
//=============================Additional Features===========================
//===========================================================================


// Custom M code points
#define CUSTOM_M_CODES
#ifdef CUSTOM_M_CODES
  #define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851
  #define Z_PROBE_OFFSET_RANGE_MIN -15
  #define Z_PROBE_OFFSET_RANGE_MAX -5
#endif




// EEPROM
// The microcontroller can store settings in the EEPROM, e.g. max velocity...
// M500 - stores parameters in EEPROM
// M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily).
// M502 - reverts to the default "factory settings".  You still need to store them in EEPROM afterwards if you want to.
//define this to enable EEPROM support
#define EEPROM_SETTINGS
//to disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out:
// please keep turned on if you can.
#define EEPROM_CHITCHAT


// Preheat Constants
#define PLA_PREHEAT_HOTEND_TEMP 190
#define PLA_PREHEAT_HPB_TEMP 60
#define PLA_PREHEAT_FAN_SPEED 255   // Insert Value between 0 and 255


#define ABS_PREHEAT_HOTEND_TEMP 240
#define ABS_PREHEAT_HPB_TEMP 100
#define ABS_PREHEAT_FAN_SPEED 255   // Insert Value between 0 and 255


//LCD and SD support
//#define ULTRA_LCD  //general LCD support, also 16x2
//#define DOGLCD  // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family)
//#define SDSUPPORT // Enable SD Card Support in Hardware Console
//#define SDSLOW // Use slower SD transfer mode (not normally needed - uncomment if you're getting volume init error)
//#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication
//#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder
//#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking
//#define ULTIMAKERCONTROLLER //as available from the Ultimaker online store.
//#define ULTIPANEL  //the UltiPanel as on Thingiverse
//#define LCD_FEEDBACK_FREQUENCY_HZ 1000    // this is the tone frequency the buzzer plays when on UI feedback. ie Screen Click
//#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 // the duration the buzzer plays the UI feedback sound. ie Screen Click


// The MaKr3d Makr-Panel with graphic controller and SD support
// http://reprap.org/wiki/MaKr3d_MaKrPanel
//#define MAKRPANEL


// The RepRapDiscount Smart Controller (white PCB)
// http://reprap.org/wiki/RepRapDiscount_Smart_Controller
#define REPRAP_DISCOUNT_SMART_CONTROLLER


// The GADGETS3D G3D LCD/SD Controller (blue PCB)
// http://reprap.org/wiki/RAMPS_1.3/1.4_GADGETS3D_Shield_with_Panel
//#define G3D_PANEL


// The RepRapDiscount FULL GRAPHIC Smart Controller (quadratic white PCB)
// http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller
//
// ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib
//#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER


// The RepRapWorld REPRAPWORLD_KEYPAD v1.1
// http://reprapworld.com/?products_details&products_id=202&cPath=1591_1626
//#define REPRAPWORLD_KEYPAD
//#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // how much should be moved when a key is pressed, eg 10.0 means 10mm per click


// The Elefu RA Board Control Panel
// http://www.elefu.com/index.php?route=product/product&product_id=53
// REMEMBER TO INSTALL LiquidCrystal_I2C.h in your ARUDINO library folder: https://github.com/kiyoshigawa/LiquidCrystal_I2C
//#define RA_CONTROL_PANEL


//automatic expansion
#if defined (MAKRPANEL)
 #define DOGLCD
 #define SDSUPPORT
 #define ULTIPANEL
 #define NEWPANEL
 #define DEFAULT_LCD_CONTRAST 17
#endif


#if defined (REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER)
 #define DOGLCD
 #define U8GLIB_ST7920
 #define REPRAP_DISCOUNT_SMART_CONTROLLER
#endif


#if defined(ULTIMAKERCONTROLLER) || defined(REPRAP_DISCOUNT_SMART_CONTROLLER) || defined(G3D_PANEL)
 #define ULTIPANEL
 #define NEWPANEL
#endif


#if defined(REPRAPWORLD_KEYPAD)
  #define NEWPANEL
  #define ULTIPANEL
#endif
#if defined(RA_CONTROL_PANEL)
 #define ULTIPANEL
 #define NEWPANEL
 #define LCD_I2C_TYPE_PCA8574
 #define LCD_I2C_ADDRESS 0x27   // I2C Address of the port expander
#endif


//I2C PANELS


//#define LCD_I2C_SAINSMART_YWROBOT
#ifdef LCD_I2C_SAINSMART_YWROBOT
  // This uses the LiquidCrystal_I2C library ( https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home )
  // Make sure it is placed in the Arduino libraries directory.
  #define LCD_I2C_TYPE_PCF8575
  #define LCD_I2C_ADDRESS 0x27   // I2C Address of the port expander
  #define NEWPANEL
  #define ULTIPANEL
#endif


// PANELOLU2 LCD with status LEDs, separate encoder and click inputs
//#define LCD_I2C_PANELOLU2
#ifdef LCD_I2C_PANELOLU2
  // This uses the LiquidTWI2 library v1.2.3 or later ( https://github.com/lincomatic/LiquidTWI2 )
  // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory.
  // (v1.2.3 no longer requires you to define PANELOLU in the LiquidTWI2.h library header file)
  // Note: The PANELOLU2 encoder click input can either be directly connected to a pin
  //       (if BTN_ENC defined to != -1) or read through I2C (when BTN_ENC == -1).
  #define LCD_I2C_TYPE_MCP23017
  #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander
  #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD
  #define NEWPANEL
  #define ULTIPANEL


  #ifndef ENCODER_PULSES_PER_STEP
    #define ENCODER_PULSES_PER_STEP 4
  #endif


  #ifndef ENCODER_STEPS_PER_MENU_ITEM
    #define ENCODER_STEPS_PER_MENU_ITEM 1
  #endif




  #ifdef LCD_USE_I2C_BUZZER
    #define LCD_FEEDBACK_FREQUENCY_HZ 1000
    #define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100
  #endif


#endif


// Panucatt VIKI LCD with status LEDs, integrated click & L/R/U/P buttons, separate encoder inputs
//#define LCD_I2C_VIKI
#ifdef LCD_I2C_VIKI
  // This uses the LiquidTWI2 library v1.2.3 or later ( https://github.com/lincomatic/LiquidTWI2 )
  // Make sure the LiquidTWI2 directory is placed in the Arduino or Sketchbook libraries subdirectory.
  // Note: The pause/stop/resume LCD button pin should be connected to the Arduino
  //       BTN_ENC pin (or set BTN_ENC to -1 if not used)
  #define LCD_I2C_TYPE_MCP23017
  #define LCD_I2C_ADDRESS 0x20 // I2C Address of the port expander
  #define LCD_USE_I2C_BUZZER //comment out to disable buzzer on LCD (requires LiquidTWI2 v1.2.3 or later)
  #define NEWPANEL
  #define ULTIPANEL
#endif


// Shift register panels
// ---------------------
// 2 wire Non-latching LCD SR from:
// https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!shiftregister-connection
//#define SR_LCD
#ifdef SR_LCD
   #define SR_LCD_2W_NL    // Non latching 2 wire shift register
   //#define NEWPANEL
#endif




#ifdef ULTIPANEL
//  #define NEWPANEL  //enable this if you have a click-encoder panel
  #define SDSUPPORT
  #define ULTRA_LCD
  #ifdef DOGLCD // Change number of lines to match the DOG graphic display
    #define LCD_WIDTH 20
    #define LCD_HEIGHT 5
  #else
    #define LCD_WIDTH 20
    #define LCD_HEIGHT 4
  #endif
#else //no panel but just LCD
  #ifdef ULTRA_LCD
  #ifdef DOGLCD // Change number of lines to match the 128x64 graphics display
    #define LCD_WIDTH 20
    #define LCD_HEIGHT 5
  #else
    #define LCD_WIDTH 16
    #define LCD_HEIGHT 2
  #endif
  #endif
#endif


// default LCD contrast for dogm-like LCD displays
#ifdef DOGLCD
# ifndef DEFAULT_LCD_CONTRAST
#  define DEFAULT_LCD_CONTRAST 32
# endif
#endif


// Increase the FAN pwm frequency. Removes the PWM noise but increases heating in the FET/Arduino
//#define FAST_PWM_FAN


// Temperature status LEDs that display the hotend and bet temperature.
// If all hotends and bed temperature and temperature setpoint are < 54C then the BLUE led is on.
// Otherwise the RED led is on. There is 1C hysteresis.
//#define TEMP_STAT_LEDS


// Use software PWM to drive the fan, as for the heaters. This uses a very low frequency
// which is not ass annoying as with the hardware PWM. On the other hand, if this frequency
// is too low, you should also increment SOFT_PWM_SCALE.
//#define FAN_SOFT_PWM


// Incrementing this by 1 will double the software PWM frequency,
// affecting heaters, and the fan if FAN_SOFT_PWM is enabled.
// However, control resolution will be halved for each increment;
// at zero value, there are 128 effective control positions.
#define SOFT_PWM_SCALE 0


// M240  Triggers a camera by emulating a Canon RC-1 Remote
// Data from: http://www.doc-diy.net/photo/rc-1_hacked/
// #define PHOTOGRAPH_PIN     23


// SF send wrong arc g-codes when using Arc Point as fillet procedure
//#define SF_ARC_FIX


// Support for the BariCUDA Paste Extruder.
//#define BARICUDA


//define BlinkM/CyzRgb Support
//#define BLINKM


/*********************************************************************\
* R/C SERVO support
* Sponsored by TrinityLabs, Reworked by codexmas
**********************************************************************/


// Number of servos
//
// If you select a configuration below, this will receive a default value and does not need to be set manually
// set it manually if you have more servos than extruders and wish to manually control some
// leaving it undefined or defining as 0 will disable the servo subsystem
// If unsure, leave commented / disabled
//
#define NUM_SERVOS 1 // Servo index starts with 0 for M280 command


// Servo Endstops
//
// This allows for servo actuated endstops, primary usage is for the Z Axis to eliminate calibration or bed height changes.
// Use M206 command to correct for switch height offset to actual nozzle height. Store that setting with M500.
//
#define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1
#define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 129,44} // X,Y,Z Axis Extend and Retract angles


#include "Configuration_adv.h"
#include "thermistortables.h"


#endif //__CONFIGURATION_H
```

----------


## AbuMaia

@jtice: In your configuration.h file, the line

// #define PROBE_SERVO_DEACTIVATION_DELAY 300

will *not* do anything until you remove the //. This may be why your servo is still jittery.

I have my

#define SERVO_ENDSTOPS {-1, -1, 0}

just like that, and it compiles no problem.

----------


## jtice

> @jtice: In your configuration.h file, the line
> 
> // #define PROBE_SERVO_DEACTIVATION_DELAY 300
> 
> will *not* do anything until you remove the //. This may be why your servo is still jittery.
> 
> I have my
> 
> #define SERVO_ENDSTOPS {-1, -1, 0}
> ...


I knew about removing the comments (//) to activate it, just hadnt yet, since I wanted to make sure about that {-1, -1, 0} part first.
That will be my next change to the firmware, once that is done, I must say, this really improves both the print quality, and lessens the frustration associated with bed leveling and first layer print height.

Thanks again for all the help everyone!

----------


## Roxy

> I am happy to report that I have Auto Leveling working very well now !!!!!
> Thanks to all the great info and helpful people here. !


You are going to enjoy this cool feature!!!




> What is it referring to when it says "You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile."
> The only place I could find SERVO_ENDSTOPS was the section of code I mentioned above, that I had set to 1 before.
> I had it set to one, thinking this was the place it meant not to set to 0


The #define for SERVO_ENSTOPS is always defined in the Configuration.h file.   I suspect that early in the development of the Auto Bed Leveling it was conditional.  But that is not the case now.  I think this comment is causing you concern when you can just ignore it.




> Alittle clarification on this would be appreciated.
> The servo twitches alittle while it is taking readings, but its not too bad, I mainly want to enable this feature so that the servo is disabled during printing.
> It makes noise as it maintains its retracted position, since the printer shakes it around a bit.


Just delete the // in front of:

// #define PROBE_SERVO_DEACTIVATION_DELAY 300

And the servo should automatically quit being powered.   But I kicked up the time a bit.   1/3 of a second seemed a little bit light.   I have mine at 1/2 second or a value of 500.

----------


## AbuMaia

Heh, I run mine at a straight 1000.  :Smile:

----------


## dacb

Sorry for being absent...  Traveling.

Sounds like Roxy really did a great job with all the questions!  Thanks, Roxy.

----------


## Roxy

So Dacb, can you give us an update?   Where are we?    I saw you merged the Sly20 script into the fork, but then it looks like that was all taken out again?   It might be good for us to circle back and talk about the Sly20 script.   I believe his script looks for long names on the G29 command line and replaces them with the post-processed values.      Are we still thinking it makes sense to use R-ight, L-eft, F-ront and B-ack for the parameter names?   (I suspect that makes sense, but it wouldn't hurt to get agreement with everybody involved.)

And if I understand things right,  The way the script parses the G29 line in the GCode, those parameter names can be anything???

I need to port this fork to my printer, but I've been so busy with school.   I just haven't had time to do it.

And Syl20:   Do you have good, step by step instructions on how to deploy your post processing script in different environments?   That would be very beneficial to the community if that could be packaged up with it.

----------


## dacb

I had intended to merge just Sly20's script, but unfortunately he included lots of extra stuff in the pull request that we/I don't want, like overriding the Makerfarm configuration for stuff specific to his reprap.  Sadly, it was late and I didn't review the full pull request before I merged (after which time I noticed the configuration stuff) it so I had to revert it out.  Now I'm faced with doing a cherry pick of the pull request commits or having him resubmit the pull request for just the commits that are relevant.  The latter is the best way from a software engineering standpoint (each feature should be a separate item to allow regression evaluation), but not the most friendly for him.

As for the firmware core, I've been using it exclusively on my printer.  Rarely, it will prompt me with a Waiting for user... after completing the G29, which is somewhat unexpected.  Other than that, it is working fine.

----------


## Drone

I mentioned this in another thread, but wanted to put it here in the fork thread to keep it in the proper thread. Is it possible to uncomment the #define SLED_DOCKING_OFFSET as default in this fork? I think everyone using this code will have to manually uncomment this define, even if they have a docking sled. And possibly change the default value to 0 instead of 5. I had a hang after the G28 in my gcode (would not continue to the G29) until this was uncommented. Other than this, the forked worked well with no modifications for me other than the usual steps, origin, probe offsets and extend/retract values for the servo.

----------


## AbuMaia

I've net yet had that problem with the sled docking offset define being commented. I'm currently using the latest EricZalm Marlin with the changes in beckdac's Marlin merged across.

----------


## Drone

Good to know Abu. Did your firmware download already come with the define uncommented and this is now part of the code or was it commented and this only affects just some MakerFarm printers?

----------


## AbuMaia

It is commented in both ericzalm and beckdac Marlin zips. Seems it's only affecting some printers, not all.

----------


## Drone

That's interesting that the hardware level affects this setting. I'm running the Arduino Mega 2560, what Arduino board do you have installed?

----------


## AbuMaia

Same, I think. It's the one I got from MakerFarm in their 8 inch i3 kit.

----------


## Drone

This issue is certainly beyond my paygrade to figure out then. I have no idea why there would be different behavior with the same hardware/firmware. I'm sure there is a logical explanation, I'm just not the guy that's going to figure it out. That being said though, I am very happy with the way ABL is working. I find the first layer to bed adhesion has dramatically improved for both ABS and PLA and now I don't use any tape, glue or hairspray for PLA at all and just glue stick for ABS. If I use glue stick with PLA, even after allowing to cool below 30c I have to use a blade to remove the part. Very happy with this.

----------


## AbuMaia

It tells me that the sled docking offset is likely a red herring, and the real bug is somewhere else, some setting that I have different or am not using at all.

----------


## dacb

This is interesting.  So if you don't define it you get a build error or a runtime error?

----------


## Drone

> This is interesting.  So if you don't define it you get a build error or a runtime error?


No, it compiles fine and runs fine except it performs a G28 properly, including raising the Z probe at the finish and then does nothing when it should be starting the G29 routine. I had this same issue when setting up ABL a little over a month ago and found the answer in a thread where someone else had the same issue. He uncommented that line and everything worked from then on. I had the same behavior and the same fix worked for me also. I haven't altered any file other than the few changes required in your fork in the configuration.h and the issue was there again. I had done hours of searching over a month ago to find a solution, so applied the same solution and had the same positive result with G29 running normally. I had assumed this must be a common issue, but from Abu's reply I'm guessing this is not common at all. The only changes I made that may not have been standard in the configuration is changing travel limits after homing #define Z_MAX_POS 250 (your build had a value of 235) and commented out Z_SAFE_HOMING.

I have included my configuration.h if you want to look at it.

Configuration.h

----------


## AbuMaia

That might be the issue there. I have Z_SAFE_HOMING enabled. If I disable it, I have the problem of my Y axis moving while the Z raise before homing runs, which offsets the Y axis by the Z raise amount. It seems as though Marlin is unaware of the Y movement, as it doesn't change the Y current position number to reflect the move. I couldn't figure it out, so I just leave Z Safe Homing enabled to avoid it altogether.

----------


## Roxy

I can confirm that the September 15th release of Marlin required extra Pre-Processor commands in Marlin_main.cpp in order to compile clean if the Sled stuff was not enabled.  The code needed to be modified as follows:


```
#ifdef ENABLE_AUTO_BED_LEVELING
#ifdef Z_PROBE_SLED
//
// Method to dock/undock a sled designed by Charles Bell.
//
// dock[in]     If true, move to MAX_X and engage the electromagnet
// offset[in]   The additional distance to move to adjust docking location
//
static void dock_sled(bool dock, int offset=0) {
 int z_loc;
 
 if (!((axis_known_position[X_AXIS]) && (axis_known_position[Y_AXIS]))) {
   LCD_MESSAGEPGM(MSG_POSITION_UNKNOWN);
   SERIAL_ECHO_START;
   SERIAL_ECHOLNPGM(MSG_POSITION_UNKNOWN);
   return;
 }

 if (dock) {
   do_blocking_move_to(X_MAX_POS + SLED_DOCKING_OFFSET + offset,
                       current_position[Y_AXIS],
                       current_position[Z_AXIS]);
   // turn off magnet
   digitalWrite(SERVO0_PIN, LOW);
 } else {
   if (current_position[Z_AXIS] < (Z_RAISE_BEFORE_PROBING + 5))
     z_loc = Z_RAISE_BEFORE_PROBING;
   else
     z_loc = current_position[Z_AXIS];
   do_blocking_move_to(X_MAX_POS + SLED_DOCKING_OFFSET + offset,
                       Y_PROBE_OFFSET_FROM_EXTRUDER, z_loc);
   // turn on magnet
   digitalWrite(SERVO0_PIN, HIGH);
 }
}
#endif
#endif

void process_commands()
```

----------


## AbuMaia

That is how my marlin_main looks. Looking at the marlin_main in the ericzalm zip file, it seems the changes are to add a 
#ifdef ENABLE_AUTO_BED_LEVELING to the start of the code section, and its corresponding #endif at the end.

----------


## Roxy

Dacb,   Right now the code says:

        if((f_probe_bed_position == b_probe_bed_position) || (r_probe_bed_position == l_probe_bed_position)) {
            SERIAL_ERROR_START;
            SERIAL_ERRORLNPGM(MSG_EMPTY_PLANE);
            Stop();
            return;
        }

Shouldn't this be changed to:

        if((f_probe_bed_position >= b_probe_bed_position) || (r_probe_bed_position <= l_probe_bed_position)) {
            SERIAL_ERROR_START;
            SERIAL_ERRORLNPGM(MSG_EMPTY_PLANE);
            Stop();
            return;
        }

If these values are wrong, other code breaks, such as:

        int xGridSpacing = (r_probe_bed_position - l_probe_bed_position) / (n_points-1);
        int yGridSpacing = (b_probe_bed_position - f_probe_bed_position) / (n_points-1);

----------


## dacb

Looks good to me.  Have you tested this?  If so, I'll make the change and publish it.

----------


## Roxy

> Looks good to me.  Have you tested this?  If so, I'll make the change and publish it.


No, it is not tested yet.   But I noticed this while trying to work through a problem for MiniMadRyan at http://3dprintboard.com/showthread.p...ll=1#post34112

----------


## RaySuave

I set-up ABL on a 10" i3v this morning with the firmware in the first post of this thread.  My issues I'm running into so far are:

- My bed origin has always been on the rear right bed corner (with printer facing forward).  Now when homing, after X and Y endstops are activated, the code probes toward the center of the bed for Z.  How can I get it to probe in the same rear right corner as X and Y?

- Immediately after probing the center of the bed when homing, the servo retracts and rubs the bed.  How can I get it to raise Z-axis a few mm before retracting the probe?

- When issuing a G29 for the ABL routine in Pronterface after homing, I get this error "echo:Home X/Y before Z".

I have googled a while for solutions, but the posted solutions I did find didnt work for any of the above issues.

----------


## Roxy

> I set-up ABL on a 10" i3v this morning with the firmware in the first post of this thread.  My issues I'm running into so far are:
> 
> - My bed origin has always been on the rear right bed corner (with printer facing forward).  Now when homing, after X and Y endstops are activated, the code probes toward the center of the bed for Z.  How can I get it to probe in the same rear right corner as X and Y?


Probably you have  #define Z_SAFE_HOMING   turned on.  Turn it off.




> - Immediately after probing the center of the bed when homing, the servo retracts and rubs the bed.  How can I get it to raise Z-axis a few mm before retracting the probe?


The Enhanced G29 code has this fixed.




> - When issuing a G29 for the ABL routine in Pronterface after homing, I get this error "echo:Home X/Y before Z".
> 
> I have googled a while for solutions, but the posted solutions I did find didnt work for any of the above issues.


Do a G28 immediately before the G29.

----------


## orionthunter

If you  want  to leave safe homing  on you could follow your G28 command with G28 X0 Y0 to return to the corner before running G29

----------


## RaySuave

> Probably you have  #define Z_SAFE_HOMING   turned on.  Turn it off.


My #define Z_SAFE_HOMING was turned on but earlier in the morning when I turned it off per a users post, the printer did probe the rear right bed corner, but after, since I was having the front of the micro switch rubbing the bed issue, the front of the micro switch hit the bed, but didnt retract all the way like it did before.  When the front of the micro switch hit the bed, everything stopped and the LCD screen went blank but was still illuminated like the code crashed or something.  I unplugged the printer then turned the #define Z_SAFE_HOMING back on to try to resolve the bed interference issue first.  Hopefully  when I get the interference issue fixed then turn this #define Z_SAFE_HOMING back on, the LCD wont go blank.





> The Enhanced G29 code has this fixed.


Can you tell me where in the code this was fixed so I can check the setting?






> Do a G28 immediately before the G29.


I apologize for not being clear in my original post, by "homing" I meant using the G28 Auto Home command via Pronterface, then immediately after use G29.


I appreciate the assistance...

----------


## Roxy

> Can you tell me where in the code this was fixed so I can check the setting?


It isn't a setting.   The code is different.  If you are running Dacb's MakerFarm fork of Marlin, you should have it.  And, unless you are giving the G29 the E option, it is only going to engage the Z-Probe once at the start.  It will wait until the Z-Probe is raised at the end to unengage the probe.

----------


## Drone

My LCD will go blank at random times, but always if the Z probe on the servo contacts the bed before retracting. The reason for me is the Arduino board doesn't have the voltage needed when the servo stalls momentarily if it contacts the bed during retract. Even after I installed the advanced G29 code from Roxy with the DACB fork and solved bed interference problems with servo retract since the new code does a Z raise before retract, I had a couple of isolated incidents of the Arduino rebooting due to lack of power. The solution for me was simple, just keep the USB cable connected to my laptop whenever the printer is turned on. Even with the laptop closed and sleeping it provides additional 5v through the USB to the Arduino board. It would probably be better to provide additional 5v power from another source to the Arduino, but since this works perfectly for me I just haven't bothered yet. If your LCD resets, it is likely a power to the board issue. Figure out a way to provide more power and it might solve the problem for you as well.

----------


## printbus

> My LCD will go blank at random times, but always if the Z probe on the servo contacts the bed before retracting. The reason for me is the Arduino board doesn't have the voltage needed when the servo stalls momentarily if it contacts the bed during retract. Even after I installed the advanced G29 code from Roxy with the DACB fork and solved bed interference problems with servo retract since the new code does a Z raise before retract, I had a couple of isolated incidents of the Arduino rebooting due to lack of power. The solution for me was simple, just keep the USB cable connected to my laptop whenever the printer is turned on. Even with the laptop closed and sleeping it provides additional 5v through the USB to the Arduino board. It would probably be better to provide additional 5v power from another source to the Arduino, but since this works perfectly for me I just haven't bothered yet. If your LCD resets, it is likely a power to the board issue. Figure out a way to provide more power and it might solve the problem for you as well.


Yep.  I go into the numbers starting with this post in my build thread - http://3dprintboard.com/showthread.p...ll=1#post28854. After looking at the design of the MEGA2560 board, my conclusion is that the on-board 5V regulator is pretty much maxed out with the basic LCD-equipped MakerFarm printer.  If you add an ABL servo or any other 5V loads onto the printer, you should provide your own 5V source or keep the printer USB port plugged into something that can provide 5V power via USB, thereby bypassing the on-board regulator.  I can't help but wonder how many ABL issues are caused by people trying to run the printer standalone off a 12V supply.

FOLLOWUP COMMENT: Stalling a servo will cause the current draw to the servo to surge, further increasing the likelihood of a problem.  And my guess is the LCD going blank is likely a sign that the Arduino board is undergoing a reboot.

----------


## RaySuave

After some more googling, starting from a fresh version of Dacb's MakerFarm fork of Marlin firmware a few times, and using different versions of Arduino for flashing (on 1.0.5-r2 currently) I still have the issue of the servo arm rubbing the bed on retraction after the G28 command (homing).  I also used Roxy's thread to invalidate the EEPROM in case this was a contributing factor. http://3dprintboard.com/showthread.p...lidate-Command Not sure what I'm doing wrong but it appears I am the only one still having this issue after using Dacb's firmware. Any other suggestions on what I could be doing wrong?

I did manage to successfully invoke the G28 command for the ABL procedure and with reading some other posts like the one above, I now understand why I was having the blank LCD issue after the servo arm rubs the bed.

After successfully running the ABL procedure, I have two more questions regarding fine tuning:

- When starting a print after ABL, my nozzle is too low, needs to raise about 0.2mm.  Is bumping the "Z_PROBE_OFFSET_FROM_EXTRUDER" value up the only change to make in the firmware?

- For adjusting the probing position, how do the LEFT, RIGHT, FRONT, and BACK probe positions correlate to looking at the printer/bed head-on from the front?

Thanks in advance...

----------


## Roxy

> After some more googling, starting from a fresh version of Dacb's MakerFarm fork of Marlin firmware a few times, and using different versions of Arduino for flashing (on 1.0.5-r2 currently) I still have the issue of the servo arm rubbing the bed on retraction after the G28 command (homing).  I also used Roxy's thread to invalidate the EEPROM in case this was a contributing factor. http://3dprintboard.com/showthread.p...lidate-Command Not sure what I'm doing wrong but it appears I am the only one still having this issue after using Dacb's firmware. Any other suggestions on what I could be doing wrong?




In the Enhanced G29 thread...  http://3dprintboard.com/showthread.p...ed-G29-command    In the first post...  It says:

    This step is also optional. Because of how some people's Z-Probe is constructed, it is best to raise the nozzle prior to retracting the probe. The Enhanced G29 code handles this circumstance. But as it turns out, the stock G28 command is also guilty of this bad behavior. If you need the G28 command to raise the nozzle prior to retracting the probe, make the following changes in Marlin_Main.cpp : 


```
Find the following code:
// Retract Servo endstop if enabled

#ifdef SERVO_ENDSTOPS
if (servo_endstops[axis] > -1) {
servos[servo_endstops[axis]].write(servo_endstop_angles[axis * 2 + 1]);
}
#endif
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS) retract_z_probe();
#endif
add these lines of code immediately after the "// Retract Servo endstop if enabled" comment.
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS)
do_blocking_move_relative(0, 0, Z_RAISE_BEFORE_PROBING);
#endif
```

It should look like this when you have made the change:


```
// Retract Servo endstop if enabled
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS)
do_blocking_move_relative(0, 0, Z_RAISE_BEFORE_PROBING);
#endif

#ifdef SERVO_ENDSTOPS
if (servo_endstops[axis] > -1) {
servos[servo_endstops[axis]].write(servo_endstop_angles[axis * 2 + 1]);
}
#endif
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
if (axis==Z_AXIS) retract_z_probe();
#endif
```



I don't know off hand if this change is folded into the DACB fork.   But if it isn't you might want to give it a try.





> I did manage to successfully invoke the G28 command for the ABL procedure and with reading some other posts like the one above, I now understand why I was having the blank LCD issue after the servo arm rubs the bed.
> 
> After successfully running the ABL procedure, I have two more questions regarding fine tuning:
> 
> - When starting a print after ABL, my nozzle is too low, needs to raise about 0.2mm.  Is bumping the "





> Z_PROBE_OFFSET_FROM_EXTRUDER" value up the only change to make in the firmware?


There are a number of configuration settings you can play with to get it tuned for your printer.  Have you tried adjusting things with:


```
 #define Z_RAISE_BEFORE_HOMING 9       // (in mm) Raise Z before homing (G28) for Probe Clearance.
                                        // Be sure you have this distance over your Z_MAX_POS in case
  #define Z_RAISE_BEFORE_PROBING 9     //How much the extruder will be raised before traveling to the first probing point.
  #define Z_RAISE_BETWEEN_PROBINGS 5  //How much the extruder will be raised when traveling from between next probing points
```




> - For adjusting the probing position, how do the LEFT, RIGHT, FRONT, and BACK probe positions correlate to looking at the printer/bed head-on from the front?


Left, Right, Front and Back were the result of a long discussion on what the names should be.  The problem is people have their origin in different places on the bed.   This was an attempt to not confuse things by saying things like X_MAX or Y_MIN.   It remains to be seen if this was a good choice of names.    But if you imagine your part on the bed, the Front would be the lowest Y coordinate, Back would be the largest Y coordinate.   Left and Right would be the lowest and largest X coordinate of the part.

----------


## RaySuave

> I don't know off hand if this change is folded into the DACB fork. But if it isn't you might want to give it a try.
> 
> Left, Right, Front and Back were the result of a long discussion on what the names should be. The problem is people have their origin in different places on the bed. This was an attempt to not confuse things by saying things like X_MAX or Y_MIN. It remains to be seen if this was a good choice of names. But if you imagine your part on the bed, the Front would be the lowest Y coordinate, Back would be the largest Y coordinate. Left and Right would be the lowest and largest X coordinate of the part.


Thanks for the tips.  It turns out that the code changes recommended were already in the fork so what I ended up doing was take a dremel and rounded off the micro switch case edge where it was contacting the bed since the interference was pretty small.  Problem Solved!!  Can post a pic if needed.

Regarding the probe position orientation, it would probably be helpful to put in some short descriptive comments after each probe position on the next fork update.  Your explanation was clear and made complete sense, now I have the probe area area perfectly adjusted.

----------


## BgHurt

I too have the issue of the Z axis not raising after the G28 before retractions. I put some debug code into the G28 to see if it was indeed running the do_blocking_move(blah, blah, +Z_RAISE_BETWEEN_PROBINGS)

It does run the command, but it never actually does the move on my arduino. Not sure if it is already in the middle of something so the function never runs. or if the move is no good. Not sure, but regardless it never lifts the Z before it retracts. 

Stock dacb, just compiled and pushed to my RAMPS. Didnt work, so I put some SERIALPGM's in to get where it was in the program loops.

----------


## dacb

Hi all,
I have just tested a bunch of the changes people have posted including Roxy's.  I'll get them into the fork in the next couple of days after a few more prints.  Stay tuned!

----------


## Roxy

> Hi all,
> I have just tested a bunch of the changes people have posted including Roxy's.  I'll get them into the fork in the next couple of days after a few more prints.  Stay tuned!


Darn!  I wish I knew you were going to do that...  I fixed a bug in the Bed Level Topology Report for the Front-Right case:

#ifdef ORIGIN_FRONT_RIGHT
    for(yy=0; yy<n_points; yy++ {
        for(xx=0; xx<n_points; xx++) { 
            SERIAL_PROTOCOLPGM(" ");
            if ( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean >= 0.0)
                SERIAL_PROTOCOLPGM("+");
            else
                SERIAL_PROTOCOLPGM("-");    // we need this extra - because Proterface uses a preportional
                                // font and it causes the columns to not line up nice without it.
            SERIAL_PROTOCOL_F( eqnBVector[ (n_points*n_points)-yy-(xx*n_points)-1 ]-mean, 5);
        }
        SERIAL_PROTOCOLPGM(" \n");
    }
    SERIAL_PROTOCOLPGM(" \n");
#endif  // ORIGIN_FRONT_RIGHT

----------


## dacb

I'll bring this change in too.

I have noticed that Waiting for user... appears more frequently now.  Almost every print.   :Confused:

----------


## Roxy

> I'll bring this change in too.
> 
> I have noticed that Waiting for user... appears more frequently now.  Almost every print.


I've never seen that message.  But I think I know why.   That message is only used in one place:


```
  else if(code_seen('M'))
  {
    switch( (int)code_value() )
    {
#ifdef ULTIPANEL
    case 0: // M0 - Unconditional stop - Wait for user button press on LCD
    case 1: // M1 - Conditional stop - Wait for user button press on LCD
    {
      LCD_MESSAGEPGM(MSG_USERWAIT);
      codenum = 0;
      if(code_seen('P')) codenum = code_value(); // milliseconds to wait
      if(code_seen('S')) codenum = code_value() * 1000; // seconds to wait

      st_synchronize()
```

I think this has something to do with your UltiPanel!    I have a dedicated (ancient) laptop acting as my LCD Display.  So I'm not going to see this message.    And if you look at the code...   You (or the panel) must be sending it an M1 command.

Right????

----------


## printbus

> I think this has something to do with your UltiPanel!    I have a dedicated (ancient) laptop acting as my LCD Display.  So I'm not going to see this message.    And if you look at the code...   You (or the panel) must be sending it an M1 command.


To clarify, the smartpanels on at least the MakerFarm printers have no intelligence of their own.  They're not capable of sending commands.  They're really quite simple - a one-way data interface is used to send character information to an LCD display, and discrete lines from a push-button rotary encoder are sensed by Marlin to determine when any operator knob rotation or knob press input is present. When knob rotation or knob press is detected, Marlin decides how to act on it.  It seems to me that the M0 or M1 would have to be in the gcode (as in a wait here for operator response), or there's some problem like an errant pointer clobbering variable or stack space within Marlin.

EDIT: And following all the auto bed leveling threads, I've been wondering about the data clobbering possibility for some time now.

----------


## dacb

There are no M0 or M1 in the Cura generated G-code.  It always happens after the auto bed level and before the print begins.  I'm leaning very strongly towards printbus's interpretation.

What was the bed topology report bug?  Did it write off the end of a buffer or something like that?

----------


## Roxy

> It seems to me that the M0 or M1 would have to be in the gcode (as in a wait here for operator response), or there's some problem like an errant pointer clobbering variable or stack space within Marlin.
> 
> EDIT: And following all the auto bed leveling threads, I've been wondering about the data clobbering possibility for some time now.





> There are no M0 or M1 in the Cura generated G-code.  It always happens after the auto bed level and before the print begins.  I'm leaning very strongly towards printbus's interpretation.
> 
> What was the bed topology report bug?  Did it write off the end of a buffer or something like that?


Well... You understand what I'm arguing, right?  That M1 is the only place that message can get issued from.  So some how the firmware thinks it got an M1 to process.    I have also seen some strange behavior depending upon how the code got built.   Some times just adding or taking out a little bit of code can make the firmware go from being stable to unstable.

If I was going to blame this on the Auto Bed Leveling code....  I would suspect it is tied to the Least Squares Fit code.   That is getting passed some big arrays and it is manipulating them (and using a fair chunk of memory to do its calculations).

But anyway...  The fact you have something (the M1 command) that you are not doing...   Gives us a good place to check out this theory.   I suggest we put some debug code in the M1 code that dumps the entire command buffer.   From that, we will be able to see if it is getting corrupted when the M1 starts executing.   It might also be good to dump the stack and see where (and what) it was executing just prior to getting into the M1 code.   (Did the top of the stack get corrupted, and the return address sent the processor to the M1 code???)

Update:  One more thought on this...  If we were to put debug code to dump various things in memory to try to resolve this...  We need to very early in the debug code say "We got into the debug code."   The reason I'm saying this is because I've seen one build of the firmware be OK.  And I've seen with a very small change that has nothing to do with the execution path the code become unstable.   Just adding the debug code, might shift it from going into the M1 code????

----------


## nefiwashere

got this loaded up today. been using the regular zenmaster setup for ABL and so far so good printing at .3 layer height with good results. when i print at .1 layer height i get some issue see video




nozzle is pushing/dragging through the print. feed rate 20mms temp 200.  using the Prometheus hot end .4 orifice. extrusion multiplier changed from 1 to .95 to .90 still had issues.  not sure if it something with the auto bed leveling 

thanks for any help

----------


## AbuMaia

Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?

----------


## Roxy

> Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?


Thanks!   I guess I better get these changes!   I wonder which path I should go?   I really should get DACB's fork ported to my machine.   But I want the M0/M1 changes.    

DACB, are you going to re-merge with the latest code soon?  If so, I'll wait so I don't have to do the port twice.  (I normally wouldn't be trying to get out of a merge / port, but I'm too busy with other things right now.)

----------


## clough42

Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?

My custom start gcode in Slic3r heats the bed, starts the hot ends heating and then runs G28 followed by G29 to home and auto-level.  After the G29, it moves the extruder tips just off the front edge of the bed (Y=215, Z=0), primes them and then wipes them onto the glass.

Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm.  Those first layers don't adhere to the bed real well when they're applied from 6mm up.   :Smile: 

I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer.  Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.

Ideas?

----------


## printbus

> Roxy, there's a new update to the EricZalm Marlin addressing something about the M0/M1. https://github.com/ErikZalm/Marlin/pull/1159 Think this might have something to do with the occasional "wait for user"?


Has anyone looked at the change to understand what it does? At just a glance, I couldn't tell if was changing how M0/M1 might be falsely detected, or changing how the M0/M1 command string is parsed when it is received. 




> Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?


Rather than let the question linger, I'll add my take even though I don't have ABL.  Multiple people seem to observed quirky issues with an ABL firmware build, including the M0/M1 issue here where for some reason Marlin thinks an command has been received that says to wait for a user prompt.  The possibility of stack or variable space corruption has came up. There's a concern that whatever the problem is, it may be related to having a build that includes both the ABL code and the LCD code.  One user has recently been fighting issues with a reprap based on an I2C LCD interface.  I2C adds considerably more software overhead than the more common REPRAP/ULTIPANEL LCD, so this raises the possibility that maybe Marlin is running into timing constraints that can't always be met with the processor cycles it has to work with.  On the hardware side, it has also been determined that the 5V regulator on the MEGA2560 board can't always handle the extra load of the ABL servo, and running the printer standalone presents a risk of the 5V power cutting out or perhaps dropping off.  ABL printers should either have a dedicated 5V source added in to provide 5V to RAMPS for the servo, or at least always have the printer connected to a USB source.

----------


## AbuMaia

> Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?
> 
> Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm.  Those first layers don't adhere to the bed real well when they're applied from 6mm up.  
> 
> I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer.  Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.
> 
> Ideas?


I used to have that problem. And yes, it was because I had finished a tall print, and it took the printer too long to home the Z axis that the X and Y steppers timed out and were deactivated, losing the X and Y home position. G29 will not run in this case, so I changed the stepper deactivating delay from (I think it was) 40 to 150. I haven't had the problem since. Sorry, I cannot remember where the setting is in the firmware.

edit: configuration_adv.h
//default stepper release if idle
#define DEFAULT_STEPPER_DEACTIVE_TIME 60

I changed the 60 to 150.

----------


## jtice

> Has anyone else had any trouble with the auto-bed-level sometimes not running or not completing?
> 
> My custom start gcode in Slic3r heats the bed, starts the hot ends heating and then runs G28 followed by G29 to home and auto-level.  After the G29, it moves the extruder tips just off the front edge of the bed (Y=215, Z=0), primes them and then wipes them onto the glass.
> 
> Sometimes, the G28 runs, and it homes in the center, but the G29 sequence doesn't run and the printer is left with the Z level off by about 6mm.  Those first layers don't adhere to the bed real well when they're applied from 6mm up.  
> 
> I haven't figured out how to reproduce it at will yet, but it seems to happen if I've already run one print job and haven't reset the printer.  Or maybe it's just happening when the Z axis is high (90mm or more) and it takes a long time for the G28 Z probe.
> 
> Ideas?


For the most part, mine works well, but I have alot of random times it fails.
Sometimes auto homing will not safe home in the middle, just homes in the corner, if it does this, then the 9 bed leveling test locations are all shifted more toward the homing corner.
There area also times it will skip the bed leveling completely, and often if that happens, bad things follow, the printer will do odd things like try to start the print 5" off the print bed, 
so the belts will slip while the printer tries to go out of range, I have to kill the power to stop it.
I have found no pattern to any of this, I can usually just start the print again, and its fine.
I have noticed that I think it helps if I push the bed and extruder to the extruder is near centered before I start the print.
If the extruder is near homed before I start the print, it tends to fail more often.

----------


## Roxy

This is scary...   There is some problem causing flakey behavior that we don't understand!

----------


## AbuMaia

A test to see if you're affected by the XY stepper motors timing out and preventing a G29, move your Z axis to its max position, then do a G28 followed by a G29. You may be able to hear during the Z leg of the G28 the X and Y motors deactivating, and the G29 may not work. It may tell you to "Home X and Y before homing Z" or something like that.

Or your printer may be fast enough to home the entire distance of Z in less than 1 minute and beat the stepper deactivation, and not be affected by this.

----------


## MiniMadRyan

> This is scary...   There is some problem causing flakey behavior that we don't understand!


Agreed. For myself, even after some fiddling around, there were still inconsistencies. I absolutely love what Roxy and Dacb have put together, and I still fully support their progress, but for the time being I've returned to the stock firmware and manual levelling just to get projects done before the holidays! Maybe this is a good reason to justify a 3rd printer to experiment with!  :Smile:

----------


## dacb

I have merged to the upstream Marlin_v1 with this commit: https://github.com/beckdac/Marlin/co...29b5184dab6fd0
and added the topology report fix, previously mentioned.

It is on a new branch: https://github.com/beckdac/Marlin/tr..._merge_11_2014

This is for the adventurous.  I've only done a handful of prints so far.

----------


## old man emu

Please, Oh Wise ones, enlighten a moron groping in the dark.

Today, do I download and flash this:

https://github.com/beckdac/Marlin/co...29b5184dab6fd0

or this:

https://github.com/beckdac/Marlin/tr..._merge_11_2014

*?*

Old Man Emu

----------


## dacb

The second.  It is the latest branch.  Please let me know how it works for you.  I'm pretty happy with my prints since the updates.

----------


## old man emu

Downloaded.

Do I still have to do the probe/extruder offset calibration?

OME

----------


## dacb

I would definitely.  My values (i.e. the ones in that config) are almost certainly not correct for your specific build.

----------


## Roxy

Dacb, Can you be talked into submitting a 'Pull Request' to Erik Zalm's Marlin?    I think the community could benefit from having it in the main branch of the source tree.    The big question is:  How much work would it be to prune the MakerFarm stuff out of it so it can be easily merged into his tree.

----------


## sniffle

I haven't looked at the arduino SDK or syntax, but it should be able to use a simple array to set most of the config.h, and call the cells of the array at the settign define.  

having not looked at the code i realized it's somewhat naieve to just pop in but doing so would be the basis for settign up profiles.  

as each array would have a name and you load profile X through a setting.  

so you could have a profile for makefarm, ultimaker, etc.

----------


## clough42

> This is scary...   There is some problem causing flakey behavior that we don't understand!


My problem was just the stepper deactivate timeout.  It was intermittent because I had a couple of tall jobs and lots of short ones I was printing.  Increasing the timeout solved my problem.  It always works for me now.

For the waiting for user issue, I had that at one point when I had pronterface connected, polling the temperatures.  I took a tip from another forum and turned the temp graph off and all is well now.  The temperature monitoring in Octoprint doesn't seem to cause this.

----------


## clough42

> Dacb, Can you be talked into submitting a 'Pull Request' to Erik Zalm's Marlin?    I think the community could benefit from having it in the main branch of the source tree.    The big question is:  How much work would it be to prune the MakerFarm stuff out of it so it can be easily merged into his tree.


If this happens, let me know.  I'm downstream from Dacb and might consider rebasing.

----------


## abuharsky

> I have merged to the upstream Marlin_v1 with this commit: https://github.com/beckdac/Marlin/co...29b5184dab6fd0
> and added the topology report fix, previously mentioned.
> 
> It is on a new branch: https://github.com/beckdac/Marlin/tr..._merge_11_2014
> 
> This is for the adventurous.  I've only done a handful of prints so far.



I have a problem with leveling on latest branch on my makerfarm i3 8".

SETTINGS:
--------------------

// set the rectangle in which to probe
    #define LEFT_PROBE_BED_POSITION 50
    #define RIGHT_PROBE_BED_POSITION 150
    #define BACK_PROBE_BED_POSITION 150
    #define FRONT_PROBE_BED_POSITION 50



GCODE:
--------------------

...
G28               ;move X/Y to min endstops
G29 V4 T n3    ;extended auto bed leveling
...


PROBLEM PHOTO:
--------------------

IMG_3693.jpg



PS:
with latest Marlin (upstream_merge_11_2014) I found new menu item: "Menu - Prepare - Set home offsets", what is it?

----------


## dacb

> Dacb, Can you be talked into submitting a 'Pull Request' to Erik Zalm's Marlin? I think the community could benefit from having it in the main branch of the source tree. The big question is: How much work would it be to prune the MakerFarm stuff out of it so it can be easily merged into his tree.





> If this happens, let me know. I'm downstream from Dacb and might consider rebasing.


Let me look into how this would work.  There is some divergence that we'd have to reconcile while separating out the MakerFarm specific bits.  I have a busy week coming up, so if someone is interested in looking at this sooner, PM me and we can arrange access to this repo such that you can initiate.




> My problem was just the stepper deactivate timeout. It was intermittent because I had a couple of tall jobs and lots of short ones I was printing. Increasing the timeout solved my problem. It always works for me now.
> 
> For the waiting for user issue, I had that at one point when I had pronterface connected, polling the temperatures. I took a tip from another forum and turned the temp graph off and all is well now. The temperature monitoring in Octoprint doesn't seem to cause this.


This is great advice.  I'm using Cura and Octoprint.  Since I moved our tree forward against the upstream/master, I've noticed the Waiting for user message has changed to M105.  M105 is the temperature poll for the extruder (IIRC).  I think I am having a timeout issue with my Octoprint settings.

I've printed a few dozen items since the last update and I'm pretty happy.

----------


## nefiwashere

This is great advice.  I'm using Cura and Octoprint.  Since I moved our tree forward against the upstream/master, I've noticed the Waiting for user message has changed to M105.  M105 is the temperature poll for the extruder (IIRC).  I think I am having a timeout issue with my Octoprint settings.

what does your cura start gcode look like? mine is like this

;Sliced at: {day} {date} {time}
;Basic settings: Layer height: {layer_height} Walls: {wall_thickness} Fill: {fill_density}
;Print time: {print_time}
;Filament used: {filament_amount}m {filament_weight}g
;Filament cost: {filament_cost}
M190 S50 ;Uncomment to add your own bed temperature line
G21        ;metric values
G28
G29
M109 S225 ;Uncomment to add your own temperature line
G90        ;absolute positioning
M82        ;set extruder to absolute mode
G1 Z15.0 F{travel_speed} ;move the platform down 15mm
G92 E0                  ;zero the extruded length
G1 F200 E3              ;extrude 3mm of feed stock
G92 E0                  ;zero the extruded length again
G1 F{travel_speed}
;Put printing message on LCD screen
M117 Printing...

----------


## bgct9a

hey i am having an issue trying to get abl to work properly using either beckdac or ErikZalm's firmware. no matter what i do to #define Z_PROBE_OFFSET_FROM_EXTRUDER, it keeps trying to start printing with the extruder height set to the z height of the probe when its in the down position. Am i doing something wrong or are other people experiencing the same problem with the firmware using ABL.

Thanks

----------


## Roxy

> hey i am having an issue trying to get abl to work properly using either beckdac or ErikZalm's firmware. no matter what i do to #define Z_PROBE_OFFSET_FROM_EXTRUDER, it keeps trying to start printing with the extruder height set to the z height of the probe when its in the down position. Am i doing something wrong or are other people experiencing the same problem with the firmware using ABL.
> 
> Thanks


For starters....  Turn off these configuration options if they are enabled in Configuration.h:


```
//#define EEPROM_SETTINGS
//#define EEPROM_CHITCHAT
```

Please report back what happens after you do that....

----------


## printbus

I've ran into an issue in how Marlin accepts a user entry for a MakerFarm parameter, but can't offer an easy solution. Someone else would have to figure that out. 

As part of lcd_control_motion_menu() within ultralcd.cpp, the statement... 

    MENU_ITEM_EDIT_CALLBACK(long5, MSG_AMAX MSG_Z, &max_acceleration_units_per_sq_second[Z_AXIS], 100, 99000, reset_acceleration_rates);

is what would be used to change the setting for Amax Z, or the Z axis maximum acceleration under the Control | Motion menu.  Apparently, a long5 can only be changed to something greater than 100 and in increments of 100. The MakerFarm default for Amax Z is just 5.  Once you go the Amax Z menu, the value is automatically changed to 100 and you can't set it back to 5.  The 100 in the above statement is the allowed minimum, but changing that alone doesn't fix much. I got lost in trying to trace through the MENU_ITEM macro hierarchy, and modifying how a type long5 is edited would affect editing the other type long5 acceleration parameters.  Amax Z may need to ideally be changed to a different type if this issue were to be resolved.  It'll likely be far easier to just never try to edit the Z acceleration parameter from the LCD.

EDIT: Code is as of the end of Sept dacb fork.

----------


## bgct9a

> For starters....  Turn off these configuration options if they are enabled in Configuration.h:
> 
> 
> ```
> //#define EEPROM_SETTINGS
> //#define EEPROM_CHITCHAT
> ```
> 
> Please report back what happens after you do that....


hey much better, it is now lowering the extruder ty!!!

----------


## Roxy

> hey much better, it is now lowering the extruder ty!!!


Do you understand what was happening?   If you really need the EEPROM settings enabled, you can turn them on.  But you have to save correct values to the EEPROM using M502 and M500.   The reason is the settings in your Configuration.h file will not be used.  Instead, the Marlin firmware will see values stored in the EEPROM, and use those instead.

----------


## bgct9a

> Do you understand what was happening?   If you really need the EEPROM settings enabled, you can turn them on.  But you have to save correct values to the EEPROM using M502 and M500.   The reason is the settings in your Configuration.h file will not be used.  Instead, the Marlin firmware will see values stored in the EEPROM, and use those instead.


this is where i am a little lost. I figured that what u upload to the mega is the new base settings and the whole eeprom usage is for when you use the lcd screen to make changes and then want to save them permanently.

----------


## printbus

> this is where i am a little lost. I figured that what u upload to the mega is the new base settings and the whole eeprom usage is for when you use the lcd screen to make changes and then want to save them permanently.


Nope. This confuses people all the time. If EEPROM is enabled, the settings last stored there are always loaded at Marlin startup.  Like Roxy said, you can over-ride those by sending the printer an M502 (load from factory default, where "factory" is the baseline in flash memory along with the executable code).  An M500 can be used any time you want to save all the current settings being used into EEPROM. Uploading new firmware from the Arduino IDE does not modify the contents of EEPROM.

----------


## sniffle

basically, if you want to use the eeprom to adjust settings on the fly.  as a rule of thumb you need to make notes of what you change, so that when you flash new firmware you update those changes in the actual firmware before flashing and after flashing the firmware automatically run an M502 to update the eeprom settings that were just flashed.

----------


## AbuMaia

I think the whole EEPROM thing is too much of a trouble-maker to be useful, IMO.  

I've encountered a pitfall regarding running ABL before every print, however. I just replaced both my Z nuts, because the one on the RAMPS side either wore out, or the threaded rod did. It's only in one small area, however, which I believe is due to the constant up-down of the probing wearing that one section more than any other. The Z nut on the RAMPS side kept slipping down the threaded rod during ABL, throwing the whole alignment out of whack by nearly 2mm. No matter how much I hand-turned the Z rods to level them, the topographic map was always the same, or very close. The new Z nut is just a stopgap measure for now, until I can get new threaded rods. 

 If your rods, like mine, get black from oil and whatever other junk, look for one area that's shinier than the rest, around the point where your ABL probing happens. This is a sign that that spot is getting worn out quicker.  

It seems that though I despise using the EEPROM, I may have to in order to avoid this excessive wear issue.

edit: Replacing the Z nuts did the trick:

Before (with hand-turning the Z rods in between each time):

Recv: Bed Height Topography:
Recv: Origin: Front Left
Recv:  --0.99552 --0.58427 --0.10027 +0.40423 +0.91598
Recv:  --0.96627 --0.53202 --0.05352 +0.45073 +0.95223
Recv:  --0.94152 --0.50377 --0.01652 +0.51248 +1.00023
Recv:  --0.92702 --0.47602 --0.01177 +0.54798 +1.04023
Recv:  --0.91602 --0.45577 +0.01198 +0.56598 +1.07823

Recv: Bed Height Topography:
Recv: Origin: Front Left
Recv:  --0.98843 --0.57268 --0.10043 +0.40732 +0.96382
Recv:  --0.96243 --0.53468 --0.05293 +0.43907 +0.95182
Recv:  --0.92243 --0.50643 --0.02218 +0.48957 +0.98982
Recv:  --0.91618 --0.47068 --0.00618 +0.55457 +1.03332
Recv:  --0.93643 --0.47818 +0.00357 +0.55457 +1.08282

Recv: Bed Height Topography:
Recv: Origin: Front Left
Recv:  --0.98989 --0.57314 --0.11264 +0.40236 +0.94361
Recv:  --0.96639 --0.53439 --0.06864 +0.43836 +1.01611
Recv:  --0.94014 --0.50789 --0.02189 +0.47636 +1.04811
Recv:  --0.92014 --0.48814 --0.00989 +0.50836 +1.09411
Recv:  --0.94389 --0.48214 +0.00211 +0.52486 +1.10486

Recv: Bed Height Topography:
Recv: Origin: Front Left
Recv:  --0.98813 --0.57938 --0.10138 +0.41412 +0.93487
Recv:  --0.95538 --0.53113 --0.05763 +0.46062 +0.99837
Recv:  --0.92613 --0.51163 --0.01738 +0.49237 +1.06087
Recv:  --0.91513 --0.48213 --0.01138 +0.52462 +1.06912
Recv:  --0.95738 --0.50538 --0.01913 +0.51512 +1.08862

After:

Recv: Bed Height Topography:
Recv: Origin: Front Left
Recv:  --0.22164 --0.12064 --0.03789 +0.01611 +0.06361
Recv:  --0.19539 --0.08789 +0.00186 +0.05711 +0.11011
Recv:  --0.17564 --0.06214 +0.04186 +0.09611 +0.12236
Recv:  --0.14789 --0.03514 +0.07536 +0.13861 +0.18036
Recv:  --0.17814 --0.03839 +0.07011 +0.14111 +0.18611

----------


## Roxy

> I think the whole EEPROM thing is too much of a trouble-maker to be useful, IMO.


Agreed.   I'm using it now just because I did that 'Save G29 Correction Matrix to EEPROM'.   And maybe I would see it differently if I had an LCD Panel.   But I'm having a hard time getting any value from the EEPROM.   Conversely, I see it mess up lots of people that are trying to get Auto Bed Leveling running.

----------


## sniffle

Maybe someone needs to write some eeprom read/write code for abl if eeprom is enabled.

Even if it is just a command that will spit out the eeprom values when abl is enabled would probably be a big help so that you can compare firmware and eeprom values so that it would make diagnosing the issue immediate.

Or if the abl code itself could override the eeprom saved values if there was a discrepancy between the two.

Dunno just talking ideas that could theoretically work.

----------


## Roxy

> Maybe someone needs to write some eeprom read/write code for abl if eeprom is enabled.
> 
> Even if it is just a command that will spit out the eeprom values when abl is enabled would probably be a big help so that you can compare firmware and eeprom values so that it would make diagnosing the issue immediate.
> 
> Or if the abl code itself could override the eeprom saved values if there was a discrepancy between the two.
> 
> Dunno just talking ideas that could theoretically work.


One simple idea would be to change the EEPROM Data Version number based on the Auto Bed Leveling state.  If Auto Bed Leveling gets turned on, the version number gets bumped and then the EEPROM values do not get used.

----------


## sniffle

That "should" be easy to setup.  But i havent looked at the code.

It would be an if statement in the initialization code

If(abl on variable == true)
 Version# = version#+1

Its just a matter of knowing actual variables where to insert code and proper syntax.  All of which i havent looked at.  But the fix itself is easy enough.

----------


## nefiwashere

having some issue were its not homing correctly.      after i complete a print i still leave the printer on and load up the new print. select the print from the sdcard and after my bed is done heating it should g28 to home and than g29 to abl.    what ends up happening is it seems like it is homing than it will start to probe in the back right corner for the abl which is wrong. ill turn of the printer and move the bed and the extruder off the endstops. start the print again and after the bed gets to temp it will start to home but what i noticed on the extruder wont even hit the X-Endstop. if i restart the printer a couple times it will work correctly. this is a new issue for me after i updated the firmware.

----------


## Roxy

No...  It's all pre-processor stuff.  It would be more of the form:



```
#define EEPROM_VERSION "V10"
#ifdef ENABLE_AUTO_BED_LEVELING  // Note:  This should be first in the Version over rides
    #undef EEPROM_VERSION        // because if DELTA or SCARA is defined, we want them
    #define EEPROM_VERSION "V30" // to have their way!
#endif
#ifdef DELTA
    #undef EEPROM_VERSION
    #define EEPROM_VERSION "V11"
#endif
#ifdef SCARA
    #undef EEPROM_VERSION
    #define EEPROM_VERSION "V12"
#endif
```

If we did something like this, the first time they turn on the Auto Bed Leveling, the version number would change, and the bad values stored in the EEPROM would be ignored.

What do you think Dacb?  Can we sneak this into your fork too (Because I'm hoping we merge it back into the main tree) ?     This code was in in Configuration_Store.cpp

----------


## sniffle

Yeah i knew it would be a simple if statement. just knowing where to place it is the hard part esp when you havent had a chance to look at the code.  My printer will be finished this week.  That will give me the the free time between/during prints to start looking at code more.

----------


## AbuMaia

You don't want to look at code during prints. When you find something to change, suddenly you're impatiently waiting for the print to finish before you can upload/test your changes.  :Smile:

----------


## Roxy

> Yeah i knew it would be a simple if statement. just knowing where to place it is the hard part esp when you havent had a chance to look at the code.  My printer will be finished this week.  That will give me the the free time between/during prints to start looking at code more.


Actually...  We could do it with real code as opposed to being entirely done in the pre-processor.   We would change this:



```
char ver2[4]=EEPROM_VERSION;
  i=EEPROM_OFFSET;
  EEPROM_WRITE_VAR(i,ver2); // validate data
```

to something like this each place it is used.   If we did this, it would work with SCARA and DELTA as the mode was switched back and forth.  This strategy would change the capital V in the version to a lower case v which would be sufficient to flag the data as out of date:


```
  char ver2[4]=EEPROM_VERSION;
#ifdef ENABLE_AUTO_BED_LEVELING 
  ver2[0]='v';
#endif
  i=EEPROM_OFFSET;
  EEPROM_WRITE_VAR(i,ver2); // validate data
```

----------


## sniffle

That seems like the more elegant solution aas it would work for all cases vs just adding more code per style of printer

----------


## Roxy

> That seems like the more elegant solution as it would work for all cases vs just adding more code per style of printer


Yes...  But the down side is there are 2 different routines that would have to have the same code added.  Not a big deal.  But both the Store and Retrieve would have to be a matched pair.   I'll try to post an updated file later today so Dacb can add it to his fork if he decides to.

----------


## sniffle

i think you could make it a single code check, using an array for the types of printers to check, and a small loop to check each of those versions, and make the change if it is said version.  since it is only 3-4 styles that check would be executed pretty much instantaneously.

----------


## bgct9a

> Nope. This confuses people all the time. If EEPROM is enabled, the settings last stored there are always loaded at Marlin startup.  Like Roxy said, you can over-ride those by sending the printer an M502 (load from factory default, where "factory" is the baseline in flash memory along with the executable code).  An M500 can be used any time you want to save all the current settings being used into EEPROM. Uploading new firmware from the Arduino IDE does not modify the contents of EEPROM.


Well that clears that up thanks!

----------


## printbus

With the new 12-inch printer from MakerFarm using RAMBO, there's more considerations in having one fork supporting all the MakerFarm printers.  IMO, one fork is still the way to go, but I might suggest it's time to rethink how some of the constants in configuration.h are defined. Why not have #DEFINES for i3v_8, i3v_10, and i3v_12.  The user uncomments the one that applies to them.  An ifdef/elseif chain is then used to set things like motherboard type, bed size, smart panel type, and enable code support for digital stepper driver adjustment.  First, it makes it easier for the user to specify the build for their printer - which printer do they have, and are they using ABL or not.  Second, and possibly most importantly, it provides the foundation for details in things like ABL to be tweaked for RAMBO by doing an ifdef i3v_12.

----------


## clough42

> With the new 12-inch printer from MakerFarm using RAMBO, there's more considerations in having one fork supporting all the MakerFarm printers.  IMO, one fork is still the way to go, but I might suggest it's time to rethink how some of the constants in configuration.h are defined. Why not have #DEFINES for i3v_8, i3v_10, and i3v_12.  The user uncomments the one that applies to them.  An ifdef/elseif chain is then used to set things like motherboard type, bed size, smart panel type, and enable code support for digital stepper driver adjustment.  First, it makes it easier for the user to specify the build for their printer - which printer do they have, and are they using ABL or not.  Second, and possibly most importantly, it provides the foundation for details in things like ABL to be tweaked for RAMBO by doing an ifdef i3v_12.


It all depends on where this goes from here.  Of you want to merge back to Marlin and stop maintaining the fork, you don't want more customization.  If you want to support MakerFarm and keep doing it forever, then customizations are the way to go.

It's tough being downstream from an active project.  Even though you've added your value and are done, you still have to work on it forever to keep it up to date.

----------


## Roxy

> It all depends on where this goes from here.  Of you want to merge back to Marlin and stop maintaining the fork, you don't want more customization.  If you want to support MakerFarm and keep doing it forever, then customizations are the way to go.


Agreed!   I would think the thing to do is merge it back into the main branch.   And then as a secondary effort, add the support to make it easily customizable for the various flavors of MakerFarm.    After all...  In order to merge it back to the main branch, the MakerFarm stuff needs to be abstracted or turned off so it doesn't affect most people.

----------


## sniffle

adding in general profile support, to condense settings into a parsable string would be a way to abstract things out, but it would also be a huge undertaking considering how many printers and options it would entail adding

----------


## printbus

Who is taking on the merge? I don't recall any talk of it since Dec 8.  Seems like ABL issues wants and needs are still forcing ongoing changes, so are we really ready for that?  We're about to need something NOW for the people who want ABL on their 12-inch printers and associated firmware (er, configuration) tweaks.  Roxy is about the only one who helps people out with ABL firmware - is she ready to deal with multiple people trying to hack their way through getting ABL running on the 12 inch printers?

Doesn't really matter to me - I was just offering a suggestion.  Since I have no experience with it, I have no problem ignoring the threads from people begging for ABL help.

----------


## dacb

Great discussion.  

I think the relevant points are all represented.  A more MakerFarm dedicated fork could be streamlined for the MarkerFarm users and lower the barrier to getting new stuff going like ABL. However, this will inevetiably distance the fork from the Marlin trunk and make unification with upstream more difficult and time consuming.

I will say that my time is limited.  Doing a large number of test prints before I commit changes is a fair amount of work but more importantly it takes a week or so.  

I'd like to think about how we could make this less of my fork and more of our fork.

----------


## Roxy

> Great discussion.  
> 
> I think the relevant points are all represented.  A more MakerFarm dedicated fork could be streamlined for the MarkerFarm users and lower the barrier to getting new stuff going like ABL. However, this will inevetiably distance the fork from the Marlin trunk and make unification with upstream more difficult and time consuming.
> 
> I will say that my time is limited.  Doing a large number of test prints before I commit changes is a fair amount of work but more importantly it takes a week or so.  
> 
> I'd like to think about how we could make this less of my fork and more of our fork.


I think the code is mature enough to be merged back into the main branch.  It has a lot of people using it.   I think the bigger problem is packaging it up and getting it into a form where it can be pushed back.   A big part of my thinking is it simplifies continued support of Auto Bed Leveling to do this.  The good stuff would be automatically included and at that point it is just a problem of getting it turned on and working on a person's machine.

----------


## sniffle

I really need to look at the changes that have been made.  So far i have abl setup on the 12" its working great!

----------


## Roxy

Sniffle, are you a C programmer?   The whole problem with getting this merged back into the main tree is the person has to have an assortment of skills.  While I know the programming (firmware and hardware side), I can't seem to get a grip on the GitHub system.  I managed to get the M48 Z-Probe-Repeatability code merged back in.  But every attempt after that went sideways.  That is why I was so anxious to get DACB's fork fully functional.  I wanted to get that merged back into the main tree.  But he is busy and as a result, everything is frozen in time.

If you had the code base packaged up nicely, would you be willing (and able) to fight your way through the GitHub system to get it ready for Erik Zalm to look at?

And, if not Sniffle...  Is there anybody out there willing and able to fight the GitHub system for a good cause????

----------


## sniffle

I suck at git, but as i have time i should be able to work on it

----------


## dacb

Great response!  I'm actually quite versed in git as I use it everyday at work.  Time is my limiting factor.  Marriage made via internet.  Please feel free to PM me.

----------


## printbus

Just for the record, I have the time and the desire, but really only grasp the basics as far as programming, am really not into the complexities of github, and continue to not need ABL on my printer. I disqualify myself, at least for this round.

----------


## sniffle

as far as my qualifications, before having 2 kids under 2 I was in the middle of changing careers by means of a computer science degree.  They taught in Java at UAB, as far as concepts, I am well versed in all points leading up to and including OO, but my actual coding skills are rusty and as far as C/C++ is concerned, it's just syntax at this point :-P

so yeah my time is constrained by a 20 month old, and a 3 month old... but i obviously find/make time for hobbies or i would go crazy :-P

I'll help out as i can, but first i need to get hip deep into it like you guys are because right now for me it's like looking down a rabbit hole and wondering how deep it goes... because i have no clue what all you guys have done to it.

----------


## clough42

I'm willing to help, if I can.

The usual approach is to create a clean topic branch from the master, get all your changes on that branch, pushed up to your fork, and then submit a pull request.

----------


## Roxy

I wonder if it would make sense to make the 'Clean Topic Branch'  something like 'Marlin Enhancements from 3dprintboard' ?   And if we did  it right...  The MakerFarm stuff would be a #define added to the  Configuration.h file?     And for that matter, perhaps everything else  is there with #define's like the G29 Bed Correction matrix saved to  EEPROM ?

UPDATE:   One thing that would be very helpful would be if everybody that can, load what ever it is we think we are going to submit.  That would let us get some test time of the final code before it got submitted to help insure everything is fully cooked.

----------


## sniffle

I will say roxy you definitely need to check the current codebase.  In the version of marlin i downloaded some of you features have already been implemented.  I went and looked at the marlin firmware updates and i was able to specify the number of points to probe, raise z Xmm before probing(which is only partially working the initial home probe isnt raising but does get underneath enough to trigger the endstop and then doublecheck its measurement.) etc.

Starting again from a fresh up to date marlin and inputting codd that hasnt been yet and quickly requesting a pull request after testing is probably a good idea.

----------


## AbuMaia

I guess this will have to wait a bit, EZ's Marlin just went into a bug-fix feature-freeze. I guess that gives us more time to figure out what to do with the MakerFarm-specific parts and test them to be stable before issuing a pull request.

----------


## printbus

IIRC, dacb took on the challenge of migrating ABL and the enhanced G29 code from uncontrolled baselines into a significantly more recent Marlin version than the MakerFarm distribution, adding in the right configuration parameters and the perplexing MakerFarm manipulation of the Type 6 thermistor data, and demonstrating the build would still work under a newer version of the Arduino IDE.  

I wouldn't mind a recap of the MakerFarm specific parts we're talking about having to merge back in. Aren't we really only talking about configuration.h details like the combination of display type, bed size, etc.? The need for the revised Type 6 thermistor data table has been resolved by just specifying Type 1 thermistors instead.  The code changes to ABL and enhanced G29 are generic, as I understand my monitoring from the ABL sidelines.   Maybe there's a need to deal with pin mapping for the ABL servo, but I view that as being driven by using RAMPS, not for being a MakerFarm printer.  Am I forgetting other changes?

Once we have the fork merged back into the main, we're still going to be left with people having to adapt configuration.h to work for them.  I doubt there's ever going to be a way around that. For any of us that have done it, yes it's a pretty straightforward thing to do.  But for most people new to Marlin and Arduino, the first time can be pretty overwhelming.  Maybe at some point we can get by with a sticky that lists the settings needed for each of the common MakerFarm printers.    The sticky could also be maintained to note what Marlin version has been demonstrated to work on different MakerFarm printer types (anticipating that RAMPS vs RAMBO and the graphics panel configurations may not always be tested by MakerFarm owners at the same time).  

I still like the idea of a block of ifdefs for configuration.h where once you say you have like an i3v-8, it sets the lower level stuff up for you.  That could be a block of text included in the sticky that gets pasted into configuration.h above the motherboard selection.  Of course, by the time you explain how to do that and explain editing the type of MakerFarm printer you have, it's not much harder to just say here are the 3 or 4, or 8 or whatever settings that need to be set for that printer type. I don't like the idea have having different configuration.h files for people to use - that'd just lead to more configuration control work.  What are the printers we'd address? i3, i3v-8, i3v-10, i3v-12? ABL and non-ABL and we're already at 8 files to maintain.

EDIT: Sorry about the long post - I just want to make sure we take care of the new people, who need the help the most.  People who have been around a while will already know what to do, and will already likely be off doing their own thing anyway.

----------


## Roxy

> IIRC, dacb took on the challenge of migrating ABL and the enhanced G29 people had in personal baselines into a significantly more recent Marlin baseline than the MakerFarm distribution, and demonstrating it would still work under a newer version of the Arduino IDE.  
> 
> I wouldn't mind a recap of the MakerFarm specific parts. Aren't we really only talking about configuration.h details like the combination of display type, bed size, etc.? The code changes to ABL and enhanced G29 are generic, as I understand my monitoring from the ABL sidelines.
> 
> ...
> 
> I still like the idea of a block of ifdefs for configuration.h where once you say you have like an i3v-8, it sets the lower level stuff up for you.  That could be a block of text included in the sticky that gets pasted into configuration.h above the motherboard selection.  Of course, by the time you explain how to do that and explain editing the type of MakerFarm printer you have....


I think the cleanest way to do this is define a new set of mother board types in Pins.h   And then just put everything you need in the new sections(s).   Pull up Pins.h and see how it is organized (and I'm using that word loosely!!!).    It is just a monster list of different things, all turned on by the mother board type.

If we went that way...   The only difference from what we want to merge back into the main branch of the tree would be the default mother board type.  We would just leave that at what ever the normal default is.  (It's 7 by default)

----------


## beerdart

Is there a way to use the stock frame mounted Z end-stop for auto home?

----------


## clough42

I just submitted a pull request for the default MakerFarm configuration.  The code in the repository currently has the max endstops enabled, but with the pullups disabled.  On the original MakerFarm electronics, there are of course no max endstops, so the inputs are just left floating.

This works most of the time, but occasionally, the G28 home doesn't complete properly.

I just built a second printer with cheap eBay electronics ($13 arduino, $10 RAMPS, $2 StepSticks), and it fails to home properly most of the time.

When the printer hits the endstop while homing, it's supposed to retract and hit it a second time to confirm the position.  Sometimes, my printer was skipping this step.  If the printer was already in contact with the end stop, sometimes it failed to home at all.  I could hear the click of one microstep fromt the motor, and the code just dropped through the routine.

I think the firmware was reading that the max endstop had been hit.  With the max endstops enabled, but the pullups disabled and the wires disconnected, I suspect it was reading ground noise from the motors and false-triggering.

Disabling the MAX endstops in Configuration.h fixed the problem.

----------


## Roxy

This just in from mwyrick:    I haven't had time to check it out, but I think what he says and did is correct:

*Y-Axis moving during Z Raise for Unsafe Home*  							Roxy,
  I noticed you helping several people with the problem of the Y-Axis  moving with the initial  Z Raise  during homing when Safe homing is not  enabled.  I have a fix for that that I have not seen in the code yet.  I  wanted to share it with you.  It also fixes G28 finishing too high when  doing a raising before retracting.

In Marlin_main.cpp in the homeaxis function,  after

    axis_is_at_home(axis);
    destination[axis] = current_position[axis];
    feedrate = 0.0;
    endstops_hit_on_purpose();
    axis_known_position[axis] = true;
I added:

plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);




The problem was after current_position was set to zero, the planner  position was not set and the delta for the move was too large by the  amount of the commanded move final to find the switch,   -2*home_retract_mm.  With this change I can now issue just a G28 and  have to current_position correct so I don't need to run G29 if I don't  want to. Or run with Z_SAFE_HOME disabled.

- Michael

----------


## AbuMaia

I've added the new line to my Marlin, but I haven't flashed it to test yet.

----------


## Roxy

> I've added the new line to my Marlin, but I haven't flashed it to test yet.


Please let us know what happens when you do.   One more thought...  Some of the 'Corrections' for where the nozzle is left might not make sense with this change.  I haven't had time to go through things yet.   I suggest you keep your finger on the Reset button when you tell it to print while it goes through the G28 and G29 process!    :Smile:

----------


## AbuMaia

> Some of the 'Corrections' for where the nozzle is left might not make sense with this change.


Yes, I plan to walk back my own corrections for G28 after adding this new line. Still trying to decide if I want to download an updated Marlin or not, it's hard to figure out what's usable.

----------


## Roxy

Well...  The Marlin code base is frozen right now...  So this fork is pretty current.   And those extra corrections mostly raised the nozzle a small amount. So I suspect this patch is going to help.    Also, it isn't going to be hard to identify and pull out any extra raise of the nozzle if it bothers you!   Other than I keep getting distracted (OpenJScad now!!!) it shouldn't be a big a deal to check out DACB's fork with this change.    I just haven't done it yet.

----------


## mwyrick

> Well...  The Marlin code base is frozen right now...  So this fork is pretty current.   And those extra corrections mostly raised the nozzle a small amount. So I suspect this patch is going to help.    Also, it isn't going to be hard to identify and pull out any extra raise of the nozzle if it bothers you!   Other than I keep getting distracted (OpenJScad now!!!) it shouldn't be a big a deal to check out DACB's fork with this change.    I just haven't done it yet.


I started with https://github.com/beckdac/Marlin.git from commit 6de51c0 and added the change.

What it did for me was after a G28 it was at the correct height and not 4mm too high like it was before the change.  It also let me turn off Z_SAFE_HOME and the Y Axis would no longer move during the initial Z raise.  Before the change it would move Y 10mm due to the home_retract_mm setting for Y set to 5mm.

I have printed by doing just a G28 after power up and it printed fine.  I also printed doing a G28 then G29 and it printed fine.

I put in a pull request to the above version so the change can be grabbed from the request if needed.  Hopefully it works for everyone and can get added in.

----------


## beerdart

Quick questions. 
1. When I run G29 does the topo get storied for the next prints? 
2. How do I change the number of probe points I know there are several probe maps in the config but how do I select? 

Thanks

----------


## Roxy

> Quick questions. 
> 1. When I run G29 does the topo get storied for the next prints? 
> 2. How do I change the number of probe points I know there are several probe maps in the config but how do I select? 
> 
> Thanks


If you get the Enhanced G29 stuff going...  You can go look in the 'Firmware Enhancements for Marlin' folder for the M499 feature.  That will store the bed level correction matrix and allow you to avoid doing G29's until things change enough that it makes sense to do it again.

----------


## pichuete

ok i found my issue i was missing the Board.h File .  any particular reason why this file is not included? i copied from the firmware im currently using.. 

hi, 

im trying to upload the firmware to my rambo board and im getting this error, i already changed the motheboard to 301 . changed my ABL, servo settings and E-steps .. but for some reason im getting this error . any ideas what im doing wrong? im currently running the latest marlin firmware but im having some trouble with extrution, temperature and inconsistency .

  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.
Arduino: 1.0.6 (Windows NT (unknown)), Board: "Arduino Mega 2560 or Mega ADK"
In file included from /Marlin.h:23,
                 from BlinkM.cpp:5:
/pins.h:4:20: error: boards.h: No such file or directory
/pins.h:6:8: error: missing binary operator before token "("
/pins.h:2523:7: error: missing binary operator before token "("
/pins.h:2625:7: error: missing binary operator before token "("
/pins.h:2736:7: error: missing binary operator before token "("
/pins.h:2831:7: error: missing binary operator before token "("
/pins.h:2931:2: error: #error Unknown MOTHERBOARD value in configuration.h

----------


## tsteever

So excited to find this thread. Thanks Roxy for pointing it out to me. So Far I have been trying to get the firmware I downloaded from this post  up and running and I had a few issues. Particularly the weird G28 behavior where is ends its movements above the bed.

My question is which should I be using? The link in the first post of this thread, or the other one. This seems to be more "maker farm" specific. How do I know which it the correct, most current "fixed" firmware to be using? Does the link on the first page always get updated with the preferred firmware?

How come this thread is not linked and stickied in the MakerFarm section?

----------


## Roxy

> ok i found my issue i was missing the Board.h File .  any particular reason why this file is not included? i copied from the firmware im currently using.. 
> 
> ...
> 
> Arduino: 1.0.6 (Windows NT (unknown)), Board: "Arduino Mega 2560 or Mega ADK"
> In file included from /Marlin.h:23,
>                  from BlinkM.cpp:5:
> /pins.h:4:20: error: boards.h: No such file or directory
> /pins.h:6:8: error: missing binary operator before token "("
> /pins.h:2523:7: error: missing binary operator before token "("


It is almost as if you did not specify the correct board in the 'Tools' section of Arduino.   But any Marlin archive you grab should have a complete set of files that will compile if you have your environment setup correctly.

----------


## Roxy

> So excited to find this thread. Thanks Roxy for pointing it out to me. So Far I have been trying to get the firmware I downloaded from this post  up and running and I had a few issues. Particularly the weird G28 behavior where is ends its movements above the bed.


That is a feature.  And in fact, that may be in the main Erik Zalm branch of the tree now.   The reason that is a 'feature' is because some people have Z Probes that rotate when they disengage and actually go lower than what the Z_PROBE_OFFSET is specified at.  You want to have some clearance so the probes don't strike the bed when engaging or disengaging.




> My question is which should I be using? The link in the first post of this thread, or the other one. This seems to be more "maker farm" specific. How do I know which it the correct, most current "fixed" firmware to be using? Does the link on the first page always get updated with the preferred firmware?


MakerFarm had a few things that needed to be smoothed over and that was the reason for the thread.   But the smoothed over version for MakerFarm also included the Enhanced G29.    MakerFarm is a very generic RepRap printer.   If you take the MakerFarm fork and put your configuration.h settings in it, you will be at a very similar place to if you took the most recent Erik Zalm Marlin fork, added your configuration.h settings and then did the work to add the Enhanced G29 code.   Going with the MakerFarm version is more straight forward.  




> How come this thread is not linked and stickied in the MakerFarm section?


Perhaps it should be...   I don't know how many MakerFarm people are using DACB's Marlin fork.   If it is enough, maybe we should stickie the thread???

----------


## hernejj

I am using it, just not with ABL. Works great.

----------


## voodoo28

The link on the first page is broken.. (Feature: Added a modified version of the dynamic ABL probe area code from here: https://github.com/ErikZalm/Marlin/pull/1022)

----------


## tsteever

I tried to follow the link you posted and it leads no where. As I stated, I downloaded the firmware from the link I posted my post above (#204) and have it limping along. It is the Erikzalm firmware. What I am wondering is what would have been the better firmware to spend my time on. 

It is my understanding that the ErikZalm firmware is a generic Marlin Firmware while the BeckDac is more in line with the Makerfarm printers.

Or, in rereading the first post, am I misunderunderstanding it? Does the https://github.com/beckdac/Marlin linked firmware include the dynamic ABL probe area?

----------


## tsteever

Whew! Just read all that. So, the question I have is then how to get the dynamic ABL scripts into Slic3r or Cura.

----------


## Roxy

I only use Slic3r.   You can add Post-Processing scripts to Slic3r.   Check out:   http://manual.slic3r.org/advanced/post-processing

----------


## tsteever

Read that page and for people like me (non-coders), I have no idea what to do next. It says add the file path to the script to run (I get that) but in the zip file there are multiple files in the slic3r post script folder. Which is the executable file you link to? Where does the parent folder get placed? 

I m happy not using this, just thought it intereesting enough to try and incorporate into my printing routine.

----------


## Roxy

What scripts do you see in the .ZIP file?   I suspect the name is going to indicate what it does.   What I would do is move the script to the Slicer directory in Program Files and then point to it within Slic3r.   I also suspect it will give you error messages if it can't find the script but I don't know that for sure.

----------


## tsteever

Just the same files that are in the gut hub folders.

----------


## Roxy

Ok, I know what is going on...   That stuff you found is my G29 Post Processing code written with MicroSoft's Visual Studio.   At the time that was done we were thinking Cura and Slic3r would need different post processing scripts.   I think we have agreed that is not true.  There is a Python script that should be in the Cura directory.   In fact, I'm not sure there should be separate directories because the post processors should be compatible regardless of which slicer you use.   You are looking for a file called:  G29_bounding_box.py    I can't attach a Python file, so I'll paste it into this message:



```
#Name: G29 Bounding Box 0.1
#Info: Find a print's bounding box and pass those coordinates to enhanced G29
#Help: G29BoundingBox
#Depend: GCode
#Type: postprocess
#Param: boundingBoxExtension(float:0) Buffer to add to print bounding box (mm)


## Prototype by Dave Beck, beck.dac@live.com
## Please contribute!
## Idea from various sources
## Please see the following forum topics:
## http://3dprintboard.com/showthread.php?6165-Marlin-firmware-fork-for-MakerFarm-i3v-w-auto-bed-level-amp-Roxy-s-enhancements
## http://3dprintboard.com/showthread.php?3105-Auto_Bed_Leveling-Enhanced-G29-command


## This script is licensed under the Creative Commons - Attribution - Share Alike (CC BY-SA) terms


# Uses -
# G29 V<verbosity flag, 0-4> T n<probe points in X & Y> L<in mm> F<in mm> R<in mm> B<in mm>
#    where LFRB define the bounding box coordinates in mm


#history / changelog:
# v 0.9: Initial prototype


version = '0.9'


import re
import sys # for maxint


def getValue(line, key, default = None):
	if not key in line or (';' in line and line.find(key) > line.find(';') and not ";LAYER:" in key):
		return default
	subPart = line[line.find(key) + len(key):] #allows for string lengths larger than 1
        if ";LAYER:" in key:
                m = re.search('^[+-]?[0-9]*', subPart)
        else:
                m = re.search('^[-]?[0-9]+\.?[0-9]*', subPart) #the minus at the beginning allows for negative values, e.g. for delta printers
	if m == None:
		return default
	try:
		return float(m.group(0))
	except:
		return default


bbL = -sys.maxint;
bbF = sys.maxint;
bbR = sys.maxint;
bbB = -sys.maxint;
with open(filename, "r") as f:
	lines = f.readlines()


x = 0;
y = 0;
layer = 0;
for line in lines:
	if getValue(line, 'G', None) == 1:
		x = getValue(line, 'X', None);
		y = getValue(line, 'Y', None);
		if x != None:
			if x > bbL:
				bbL = x;
			if x < bbR:
				bbR = x;
		if y != None:
			if y > bbB:
				bbB = y;
			if y < bbF:
				bbF = y;
		#print line
		#print repr(x) + " " + repr(y) + " - L" + repr(bbL) + " F" + repr(bbF) + " R" + repr(bbR) + " B" + repr(bbB)
	if getValue(line, 'G', None) == 29:
		G29line = line;
	if ';LAYER:' in line:
		layer = getValue(line, ';LAYER:', layer)
		if layer > 0:
			break;


# do error checking on bb values
# not implemented


# adjust bb values with boundingBoxExtension
# not implemented


print "Bounding Box: L" + repr(bbL) + " F" + repr(bbF) + " R" + repr(bbR) + " B" + repr(bbB)
print "G29 line before modification: " + G29line


# reprocess file and modify G29
# not implemented
```

----------


## clough42

> I only use Slic3r.   You can add Post-Processing scripts to Slic3r.   Check out:   http://manual.slic3r.org/advanced/post-processing


Can someone explain why we need post processing scripts again?  Inever followed that part of the conversation.  I've been using Slic3r exclusively with this firmware without any scripts for months.

----------


## AbuMaia

The post-processing scripts were for the G29 ABL routine to limit itself just to the area of the print bed where the object would be printed, instead of the whole bed.

----------


## clough42

> The post-processing scripts were for the G29 ABL routine to limit itself just to the area of the print bed where the object would be printed, instead of the whole bed.


Gotcha.  That makes sense.  Since I'm not using it, that also explains why I was blissfully unaware.   :Smile:

----------


## tsteever

I got this series of numbers returned to me after my ABL tonight.

1.000000 0.000000 -0.000845
0.000000 1.000000 0.000304
0.000845 -0.000304 1.000000


The diagonal reads 1.xxxxx  Does my glass really have a 1mm ridge down the diagonal?

----------


## Roxy

> I got this series of numbers returned to me after my ABL tonight.
> 
> 1.000000 0.000000 -0.000845
> 0.000000 1.000000 0.000304
> 0.000845 -0.000304 1.000000
> 
> The diagonal reads 1.xxxxx  Does my glass really have a 1mm ridge down the diagonal?


Almost for sure, that is the Bed Level Correction matrix.   This is the matrix any coordinate gets multiplied against to map it into the 'unlevel' coordinate system.    The strange thing is it looks like you are fighting resolution problems with the Arduino math package.  The diagonal can't really be unity if there are other components.   It would be more plausible if you had .9999 going down the diagonal.   But be that as it may be, it is saying your bed is very level!

----------


## AbuMaia

> But be that as it may be, it is saying your bed is very level!


I don't know about that... here's a recent matrix:  

Recv: Bed Level Correction Matrix: 
Recv: 1.000000 0.000000 0.000637 
Recv: -0.000000 1.000000 0.000254 
Recv: -0.000637 -0.000254 1.000000  

and the topographic report that went with it:  

Recv: Bed Height Topography: 
Recv: Origin: Front Left 
Recv:  --0.05153 +0.04247 +0.04872 --0.04903 
Recv:  --0.04903 +0.03047 +0.07922 +0.03297 
Recv:  --0.07103 +0.03072 +0.07647 +0.02297 
Recv:  --0.15053 --0.00853 +0.02397 --0.00828

----------


## tsteever

> Almost for sure, that is the Bed Level Correction matrix.   This is the matrix any coordinate gets multiplied against to map it into the 'unlevel' coordinate system.    *The strange thing is it looks like you are fighting resolution problems with the Arduino math package.*  The diagonal can't really be unity if there are other components.   It would be more plausible if you had .9999 going down the diagonal.   But be that as it may be, it is saying your bed is very level!



What exactly does that mean? Would it influence my prints? I ask cause I can print small things fine but larger parts have failed so far. I get some warping and then the layers delaminate. I got the 12" model to print large things. Very frustrating to not be able to use the full build volume.

How do I run a topo report?

----------


## AbuMaia

If you're using Roxy's code, run G28 then "G29 T n4" or whatever n# you prefer. The "T" is what tells it to make a topographic map.

----------


## TopJimmyCooks

I also don't understand the bed level correction matrix.  I always get the diagonal row of 1.0's as well.  doesn't make obvious sense to me.  It works ok so no complaints here, just cant' parse the matrix.

----------


## Roxy

> I also don't understand the bed level correction matrix.  I always get the diagonal row of 1.0's as well.  doesn't make obvious sense to me.  It works ok so no complaints here, just cant' parse the matrix.


Do you see the Z Axis move back and forth as it prints a layer?   If so, the Auto Bed Leveling is doing it's thing.   The way the 'new' coordinates are calculated is by doing matrix math and multiplying the coordinate in the GCode times the Bed Level Correction matrix to get the 'new' coordinate.    My Bed Level Correction matrix can have a 1.000 on the diagonal, but never 3 of them.   That is why I thought the previous matrix was done on a very level bed.

If you are willing to unlevel your bed to learn about this, you can tilt your bed and generate a new Bed Level Correction matrix.  As you make the bed more and more unlevel, you should see the numbers along the diagonal decrease in size and you should see the numbers off of the diagonal start getting bigger in absolute size.   (And there should be symmetry along the diagonal.  One side will have a + version of the same - number the other side has)

----------


## AbuMaia

The matrix is a grid of X Y and Z values. Across the top are 

X Y Z

and down the side are 

X
Y
Z

             ............X................              Y.............                Z
X 1.000000 0.000000 0.000637 
Y -0.000000 1.000000 0.000254 
Z -0.000637 -0.000254 1.000000

The coordinates in your gcode gets multiplied by this grid. A move in X gets multiplied by the 1 in X, so the X distance doesn't change. It gets multiplied by the 0 in Y, so it doesn't move in Y at all. It gets multiplied by the number in Z, so the Z axis moves a little bit to make the print level.

Same thing happens for Y and Z. Y moves won't move in X, won't change in Y, and change Z a little. Z moves change a little in X, change a little in Y, and don't change in Z.

Hope this helps.

----------


## sniffle

this made me want to look at my g29 matrix to see how bad my bed is unlevel... :-P

----------


## Roxy

> ............X................              Y.............                Z
> X 1.000000 0.000000 0.000637 
> Y -0.000000 1.000000 0.000254 
> Z -0.000637 -0.000254 1.000000
> 
> The coordinates in your gcode gets multiplied by this grid. A move in X gets multiplied by the 1 in X, so the X distance doesn't change. It gets multiplied by the 0 in Y, so it doesn't move in Y at all. It gets multiplied by the number in Z, so the Z axis moves a little bit to make the print level.


And back to my point...  The 1's along the diagonal don't look right with 'correction' numbers off to the sides.  I think we are seeing limitations with the Arduino's single precision floating point math.   X*1 + Y*0 + Z*.000637 means X movement in the 'corrected' number system is greater than its magnitude in the original system.   It would seem the X number should drop from 1.0 to .999  if there are Y & Z components.

----------


## MulBe039

Just to check if i got this right: if you were using the matrix only as a readout to check if your printer is perfectly levelled you would need to achieve a matrix that consists only of 1.000 values right?
also, i want to say thank you to dacb for creating this thread, it totally saved me

----------


## Roxy

> Just to check if i got this right: if you were using the matrix only as a readout to check if your printer is perfectly levelled you would need to achieve a matrix that consists only of 1.000 values right?
> also, i want to say thank you to dacb for creating this thread, it totally saved me


In a perfect world, Yes the matrix should just have 1.000 down the diagonal.   But there is no way you are going to have that precise and repeatable measurement of your bed and have your bed that level.

----------


## tsteever

I too will see a similar correction matrix. Are you suggesting there may be something wrong?

----------


## Roxy

> I too see a similar correction matrix. Are you suggesting there may be something wrong?


No...   Those numbers are expected.    But if your printer was perfect, you would have 1.000000 going down the diagonal and 0.00000 everywhere else.

----------


## inventabuild

My bed is held at three points.  I want Marlin to tap at those three points for autobed level.  Currently my Marlin firmware is set to tap at four points, creating a rectangle of taps, namely:

 // these are the positions on the bed to do the probing
  #define LEFT_PROBE_BED_POSITION 15
  #define RIGHT_PROBE_BED_POSITION 170
  #define BACK_PROBE_BED_POSITION 180
  #define FRONT_PROBE_BED_POSITION 20

How do I set Marlin to probe only three points that I define instead of four points?  Also, G28 causes the hot end to home in the middle of the bed.  How do I get it to home at the front left corner which is where it homed before I implemented auto bed leveling?

----------


## Roxy

Go into Configuration.h and turn off


//#define AUTO_BED_LEVELING_GRID

Then set the 3 probe points to where you want the bed measured:


      #define ABL_PROBE_PT_1_X 35
      #define ABL_PROBE_PT_1_Y 180
      #define ABL_PROBE_PT_2_X 35
      #define ABL_PROBE_PT_2_Y 40
      #define ABL_PROBE_PT_3_X 170
      #define ABL_PROBE_PT_3_Y 2

----------


## inventabuild

> Go into Configuration.h and turn off
> 
> 
> //#define AUTO_BED_LEVELING_GRID
> 
> Then set the 3 probe points to where you want the bed measured:
> 
> 
>       #define ABL_PROBE_PT_1_X 35
> ...


I don't have #define AUTO_BED_LEVELING_GRID in my version of Marlin and if I comment out the four lines I mentioned above that define the probe points then Marlin_main.cpp errors out with the message "Left_Probe_Bed_Position was not declared, etc for the other three points.

----------


## Roxy

Can you provide a link to where you got the Marlin you are using?   The name of AUTO_BED_LEVELING_GRID has changed a number of times.   But the 3-Point leveling was the first bed leveling and has always been in the Configuration.h file.    Those 4 #defines should not be commented out.  The reason is they get turned off by not enabling the GRID based leveling.   Those 4 #define's set the boundary box for the probe to run around.  You don't care about that, and those will get turned off when you switch of the GRID based leveling.   At that point, those 6 lines with the X & Y of the 3 probe points will be used.

Go look for  #define LEFT_PROBE_BED_POSITION   and immediately above it there will be an #ifdef something or another.  That is the name you need turned off to toggle the compiler to do 3-Point leveling.   I have included a Cut & Paste of some code that is pretty close in the point of time with what you are using.



```
#ifdef ENABLE_AUTO_BED_LEVELING


// There are 2 different ways to pick the X and Y locations to probe:


//  - "grid" mode
//    Probe every point in a rectangular grid
//    You must specify the rectangle, and the density of sample points
//    This mode is preferred because there are more measurements.
//    It used to be called ACCURATE_BED_LEVELING but "grid" is more descriptive


//  - "3-point" mode
//    Probe 3 arbitrary points on the bed (that aren't colinear)
//    You must specify the X & Y coordinates of all 3 points


#define AUTO_BED_LEVELING_GRID
  // with AUTO_BED_LEVELING_GRID, the bed is sampled in a
  // AUTO_BED_LEVELING_GRID_POINTSxAUTO_BED_LEVELING_GRID_POINTS grid
  // and least squares solution is calculated
  // Note: this feature occupies 10'206 byte
  #ifdef AUTO_BED_LEVELING_GRID


    // set the rectangle in which to probe
    #define LEFT_PROBE_BED_POSITION 35
    #define RIGHT_PROBE_BED_POSITION 175
    #define BACK_PROBE_BED_POSITION 175
    #define FRONT_PROBE_BED_POSITION 35
```

----------


## inventabuild

I got the Marlin firmware here under the heading "Downloads needed":

https://ohai.lulzbot.com/project/taz4_dual_extruder/

When I comment out #ifdef ENABLE_AUTO_BED_LEVELING and try to upload to my TAZ 4 I get a Configuration.h error message: #endif without #if

----------


## Roxy

Holy Cow!    They totally butchered the Configuration.h file.   I didn't check the other source files.    Do you have a MakerFarm printer?   If so, grab this fork, compile it, load it, and it is going to be super close to what you want.

https://github.com/beckdac/Marlin

Even if you don't have a MakerFarm printer, I would suggest you grab this fork, and then start at the beginning of my comments, and use those comments to turn on 3-Point bed leveling.

----------


## inventabuild

Yea, not sure why they had to  butchered it. I have a Lulzbot TAZ 4 so it was convenient to use their firmware. There's probably a lot of settings i will need to modify to use the Marlin at your link. Can you please tell me the main settings I will need to change and are they all in configuration.h?

----------


## Roxy

Take the settings #define'd in the Lulzbot TAZ 4 s  Configuration.h and change them in the BeckDac fork's Configuration.h    That will get things very close.

----------


## inventabuild

Alternatively, is it worth a shot to cherry pick lines from the version at your link and add them to my existing version of Marlin? If so, which lines?

----------


## inventabuild

Thank you Roxy. We cross posted, I just read your last response. I was hoping I could just change a few  lines, but it sounds like it's better to use the latest version and copy over the #define values. I'll give it shot.

----------


## inventabuild

Hello Roxy, it worked like a charm.  Thank you.

One last sticking point though.  I also tried working with the  AUTO_BED_LEVELING_GRID and whether I put in a value of 2 or 5 for #define AUTO_BED_LEVELING_GRID_POINTS Marlin always probes 9 points.  How do I get Marlin to vary the number of probe points, for example how do I get Marlin to probe only the four corners?

----------


## Roxy

> Hello Roxy, it worked like a charm.  Thank you.
> 
> One last sticking point though.  I also tried working with the  AUTO_BED_LEVELING_GRID and whether I put in a value of 2 or 5 for #define AUTO_BED_LEVELING_GRID_POINTS Marlin always probes 9 points.  How do I get Marlin to vary the number of probe points, for example how do I get Marlin to probe only the four corners?


Snicker...  Snicker...   You need to look at the code!   That #define sets how the firmware is built and allocates storage for what it is going to do.   Setting it to 5 allows up to a 5x5 grid to be probed.  But usually, people don't want to do that.  So the default (if you don't tell it how many points to do) is 3.   Even a 3x3 grid takes a bit of time and a lot of people don't want to wait that long.   Just because you allocate the storage to handle a 5x5 grid, it won't do that unless you tell it to do that.    Give it a G29 n 5 T    and you will get the full detail grid printed for what your bed looks like.

----------


## inventabuild

Oh, so if I give it a G29 n 3 T will it calculate the surface using 9 points and if I give it a G29 n 5 T will it calculate the surface using 25 points.

Also, how does Marlin determine what the surface looks like.  Does it use all the points I tell it to use with G29 n ? T to define a single least squares plane or does it break up the surface into many different planes?  I thought I read about some firmware out there doing this or trying to do this.

----------


## Roxy

> Oh, so if I give it a G29 n 3 T will it calculate the surface using 9 points and if I give it a G29 n 5 T will it calculate the surface using 25 points.


Yes.  That is correct.  But you can only go as high as you have allocated storage using that #define.




> Also, how does Marlin determine what the surface looks like.  Does it use all the points I tell it to use with G29 n ? T to define a single least squares plane or does it break up the surface into many different planes?  I thought I read about some firmware out there doing this or trying to do this.


In the Grid Based Bed Leveling, it will find the mean (average) of all the points and subtract that off of each point when doing the Topography report.  That lets you easily see what is too high or too low and by how much.    Independent of that, it will feed all the sampled points into a Least Square Fit algorithm to find the plane that most closely matches those points.    The Mesh based leveling will do a bi-linear fit as it moves the nozzle from cell to cell.    Soon, the Mesh based will have automatic sampling of the bed and it is possible the Delta's will be using the same bed leveling compensation that the Cartesian Mesh users are doing.

----------


## inventabuild

Hello Roxy,

When I comment out the AUTO_BED_LEVELING_GRID and try to upload the 3 point leveling to my TAZ I'm getting the following error message in Marlin_main.cpp $:

 'retract_flag'was not declared in this scope

Please let me know how to declare this.  Thank you.

----------


## Roxy

Can you post your Marlin_main.cpp file?   I'll take a look at it.

----------


## inventabuild

> Can you post your Marlin_main.cpp file?   I'll take a look at it.


Thanks. I did not modify Marlin_main.cpp, I only modified the configuration.h file. I'll post Marlin_main.cpp when I get home in a little bit.

----------


## inventabuild

> Thanks. I did not modify Marlin_main.cpp, I only modified the configuration.h file. I'll post Marlin_main.cpp when I get home in a little bit.


Hi Roxy, I attached my Marlin_Main as a zipped text file.  Please let me know if you need anything else.  Thank you.

----------


## Roxy

Yeah...  It looks like retract_flag should be within scope.  But if you change these line, I think it will compile.  You just won't be able to use the 'E' option to force the probe up and down for each sampled point:



```
#else // AUTO_BED_LEVELING_GRID not defined

            // Probe at 3 arbitrary points
            // probe 1
            float z_at_pt_1 = probe_pt(ABL_PROBE_PT_1_X, ABL_PROBE_PT_1_Y, Z_RAISE_BEFORE_PROBING, 0, verbose_level);

            // probe 2
            float z_at_pt_2 = probe_pt(ABL_PROBE_PT_2_X, ABL_PROBE_PT_2_Y, current_position[Z_AXIS] + Z_RAISE_BETWEEN_PROBINGS, 0, verbose_level);

            // probe 3
            float z_at_pt_3 = probe_pt(ABL_PROBE_PT_3_X, ABL_PROBE_PT_3_Y, current_position[Z_AXIS] + Z_RAISE_BETWEEN_PROBINGS, 0, verbose_level);

            clean_up_after_endstop_move();

            set_bed_level_equation_3pts(z_at_pt_1, z_at_pt_2, z_at_pt_3);

            free(plane_equation_coefficients);
            free(eqnAVector);
            free(eqnBVector);

#endif // AUTO_BED_LEVELING_GRID
```

----------


## inventabuild

Thank you for the code Roxy. If I don't retract between probe points, I'm concerned the hot end will drag across the glass build surface if everything is not perfectly leveled to begin with.

Do you have any suggestions to prevent this from happening?

----------


## Roxy

No...  It is kind of the opposite.  The Z-Probe is lower than the nozzle when it is deployed.   The nozzle will stay Z_PROBE_OFFSET_FROM_EXTRUDER above the bed during the whole probing sequence.

----------


## inventabuild

Oh sorry, let me explain my setup. I'm using the hot end nozzle tip to tap the bed which triggers fsr's attached to the underside of the bed to fire off just like a probe. So my x, y and z offsets are 0 because the tip of the nozzle is the probe. This is why I think I need retraction between probe points. Please let me know your thoughts.

----------


## Roxy

No.  You don't need 'retraction'.  That is just what it is called when you have a servo kick down the probe leg.  Or actually...  When it brings the probe leg back up.   What you want to do is make sure you have some amount of Z_RAISE_BETWEEN_PROBING, Z_RAISE_BEFORE_PROBING and Z_RAISE_AFTER_PROBING defined.    That will still happen.    

We don't have to make the change like I suggested.   The .ZIP file you sent only had a .txt file which was Marlin_main.cpp renamed in it.   If you .ZIP up the entire code base and attach it, I can take a quick look and figure out why you are getting that compile time error and actually make a more surgical fix to your file.

----------


## inventabuild

Hi Roxy, attached are my Marlin files for you to work your magic.

----------


## Roxy

You deleted some stuff that caused mis-matched braces.   Attached is a Marlin_main.cpp that I believe is correct for you.   But you still have other problems now in the U8 graphics library.

Probably the thing to do is save your current configuration.h, configuration_adv.h and this marlin_main.cpp file.    Download a fresh copy of BeckDac and drop those saved files on top of it.   And then see if it compiles clean and loads on your board.

----------


## inventabuild

Awesome, thank you. And just so I don't mess it up, when you say drop those saved files on top, do you mean copy the text in my files and paste it over the text in the respective tabs of the Beckham version of Marlin?

----------


## inventabuild

It worked, I'm probing three points.  Thank you.  I expect to have an interesting auto bed leveling modification working within a week.  I will post to your website when it's good to go.

----------


## pgx3s

Sorry for the slight of topic question: how is ur z-nut fixed?
I mean in the sence of wobbling and excat positionin of the z-axis during printing?  As it is constantly moving up and down ...

BR
Manuel

----------


## Roxy

> Awesome, thank you. And just so I don't mess it up, when you say drop those saved files on top, do you mean copy the text in my files and paste it over the text in the respective tabs of the Beckham version of Marlin?


Well...   A lot of people say "Drag and Drop" when using a Graphical User Interface.   (Obviously you figured it out!)    So, yes...  Drag those files to the directory where the rest of the Marlin source files are, and drop them there.  They will step on and replace what ever was there.

----------


## inventabuild

Hi Roxy, G29 n 2 T does not work for AUTO_BED_LEVELING_GRID.  Marline still probes 9 points.  Shouldn't I be able to just probe 4 points (for example the 4 corners) with G29 n 2 T.

----------


## Roxy

> Hi Roxy, G29 n 2 T does not work for AUTO_BED_LEVELING_GRID.  Marline still probes 9 points.  Shouldn't I be able to just probe 4 points (for example the 4 corners) with G29 n 2 T.


I thought you wanted to get the 3-point leveling going?   You don't get to pick the number of probe points in that version.  And the quickest way to get you going was to comment out this code:



```
/*
    if ( code_seen('n') || code_seen('U') || code_seen('u') ) {
        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;
        }
    }
*/
```

If you want to switch back to grid based leveling, then you will need to uncomment that code.

----------


## inventabuild

Very cool, thank you.  I'm currently printing with 3 point leveling and printing parts to set up my printer to go with 4 point leveling; hence the reason I need both...for the time being anyway.

----------


## inventabuild

Roxy, 3 point auto bed leveling is not working.  After having so many issues with trying to get a good first layer I finally ran a large rectangular calibration print and found that the z-axis rods are not raising and lowering to compensate for differences in height from one side of the bed to the other.

I run G28 followed by G29 and the probe homes then taps the bed at the 3 points I designated, but there is no auto bed leveling compensation occurring as the hot end travels around the bed.  Please help.

----------


## Roxy

I only used the 3-Point leveling when it first came out.  It was quickly replaced with the Grid based leveling.   3-Point did help, but depending upon where you put the sample points, you could still end up with huge sections of your bed where the height was wrong.   My suggestion would be to take the un-altered marlin_main.cpp from the BeckDac release and replace what you currently have.   And if you want, you can try it with a 2x2 grid.   Depending upon how good the mechanics of your machine are, that might be enough points.   I usually use 4x4 but 3x3 works OK on my printer.

----------


## inventabuild

OK, thanks Roxy, Grid based leveling is working.

----------


## inventabuild

With Grid Based Leveling does Marlin use the first homing point (found w/ G28) as one of its points in the plane that it generates with the least squares fit method?

----------


## Roxy

> With Grid Based Leveling does Marlin use the first homing point (found w/ G28) as one of its points in the plane that it generates with the least squares fit method?


No.   That is a separate command and the G29 does not have access to that information.   Perhaps in the future we can optimize that.  But right now, it is not included in the G29 calculations.

----------


## inventabuild

> No.   That is a separate command and the G29 does not have access to that information.   Perhaps in the future we can optimize that.  But right now, it is not included in the G29 calculations.


OK, thanks.  It turns out I'm glad it does not include that information for the way I am currently implementing auto bed leveling so if it is included in a future version perhaps there could be a way to turn it on (include) or off (not include).

----------


## clough42

Roxy, what's the status of this fork?

I'm still recommending (a fork with preconfigured settings) of this for users of my extruders, but recently I've been playing with the latest release Marlin.  The latest release code seems to have all of the ABL functionality I need, but it doesn't lift before retracting the probe, so snap switches without wheels collide with the bed during retraction.

For switches with wheels, the Marlin code works great.

Are there any plans to get the lift-before-retract functionality into Marlin?

----------


## Roxy

> Roxy, what's the status of this fork?
> 
> I'm still recommending (a fork with preconfigured settings) of this for users of my extruders,


As strange as it may seem...  I'm still pointing people to the BeckDac for in special cases too!




> but recently I've been playing with the latest release Marlin.  The latest release code seems to have all of the ABL functionality I need, but it doesn't lift before retracting the probe, so snap switches without wheels collide with the bed during retraction.
> 
> For switches with wheels, the Marlin code works great.
> 
> Are there any plans to get the lift-before-retract functionality into Marlin?


So this confuses me.  Are you saying with the various Z_RAISE_BEFORE, Z_RAISE_BETWEEN and Z_RAISE_AFTER you can't make it work for you?   If that is the case there is still work to do.  But I was under the impression that those three settings gave everybody enough control they can set things up for however their printer is built.

Please give me some more detail!!!

----------


## inventabuild

Roxy, I am able to upload BeckDac with my modified Configuration.h to the RAMBO board on my printer; however when I close out of Marlin on my laptop, reopen it and try to upload it again (with or without any tweaks to my Confguration.h) I always get the error message "n_points was not declared in this scope" and the line "int xGridSpacing = (r_probe_bed_position - l_probe_bed_position) / (n_points-1);" is highlighted in Marlin_main.cpp

Why would Marlin upload fine the first time, but not again after closing out of it and reopening it?

----------


## clough42

> So this confuses me.  Are you saying with the various Z_RAISE_BEFORE, Z_RAISE_BETWEEN and Z_RAISE_AFTER you can't make it work for you?   If that is the case there is still work to do.  But I was under the impression that those three settings gave everybody enough control they can set things up for however their printer is built.
> 
> Please give me some more detail!!!


Between probes, it is raising, but it retracts the probe before it raises.  The sequence is:

1.  Move to probe location
2.  Extend probe
3.  Probe, reverse and repeat probe slowly
4.  Retract probe
5.  Raise
6.  Move to next probing position

My Configuration.h file is attached.  Maybe I'm missing something obvious.

Configuration.h

My code was taken from Marlin fcc15f4897ddabef35d1d51cb08513a3b8fbcc83 on August 1.

----------


## Roxy

Clough...  I'll look more carefully at it tomorrow.  But Yes! That does sound wrong.   Can you use M111 to turn on the Auto Bed Leveling debug flags?   And then post the verbose output of what is going on?   I bet we can figure things out pretty quickly with that.   (ThinkyHead is the one that put that into the code base.   I don't like the fact we have a bunch of extra code for doing debug print outs, but it is worth the nuisance!!!!)

If you have any trouble figuring it out... You can just force the issue.  In Marlin_main.cpp change this line to be:

uint8_t marlin_debug_flags = DEBUG_INFO|DEBUG_ERRORS   |DEBUG_LEVELING ;

and then do a G28 and a G29.

----------


## clough42

> Clough...  I'll look more carefully at it tomorrow.  But Yes! That does sound wrong.   Can you use M111 to turn on the Auto Bed Leveling debug flags?   And then post the verbose output of what is going on?   I bet we can figure things out pretty quickly with that.   (ThinkyHead is the one that put that into the code base.   I don't like the fact we have a bunch of extra code for doing debug print outs, but it is worth the nuisance!!!!)
> 
> If you have any trouble figuring it out... You can just force the issue.  In Marlin_main.cpp change this line to be:
> 
> uint8_t marlin_debug_flags = DEBUG_INFO|DEBUG_ERRORS   |DEBUG_LEVELING ;
> 
> and then do a G28 and a G29.


I don't seem to have the line of code you mention with the debug flags, so let me ask real quick which code I should be using?

I'm currently branched from https://github.com/MarlinFirmware/Marlin.git from the "marlin/release" branch.  Is that the 1.0 code?  Should I be pulling something else?  marlin/RC?

----------


## Roxy

> I don't seem to have the line of code you mention with the debug flags, so let me ask real quick which code I should be using?
> 
> I'm currently branched from https://github.com/MarlinFirmware/Marlin.git from the "marlin/release" branch.  Is that the 1.0 code?  Should I be pulling something else?  marlin/RC?


Probably, the best version for you to use is:  https://github.com/MarlinFirmware/Marlin and select the RC  (Release Candidate) branch.   (I don't use Git yet, so I'm not sure how to answer the rest of your question.   But using the web interface, go to that link, and select RC.  That is the most stable and has everything you want in it.   The MarlinFirmware/MarlinDev side of things is really the same code, but we are changing the development environment to let us start breaking up the big files and organize things better.)

I just did a diff of your Configuration.h file you posted up above with the RC's Configuration.h file.   I think the root of your problem is Z_RAISE_AFTER_PROBING got added to the code base and you don't have that in your Configuration.h file.  So no raise happens at the end of probing. 




```
#define Z_RAISE_BEFORE_PROBING 15   // How much the Z axis will be raised before traveling to the first probing point.
  #define Z_RAISE_BETWEEN_PROBINGS 5  // How much the Z axis will be raised when traveling from between next probing points.
  #define Z_RAISE_AFTER_PROBING 15    // How much the Z axis will be raised after the last probing point.

//#define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10" // These commands will be executed in the end of G29 routine.
                                                                            // Useful to retract a deployable Z probe.
```

----------


## Roxy

Clough???   Did adding the Z_RAISE_AFTER_PROBING fix the problem?

----------


## clough42

> Clough???   Did adding the Z_RAISE_AFTER_PROBING fix the problem?


Thank you for your help.  Sorry I didn't respond.  I have a few irons in the fire, and this is just one of them.   :Smile: 

After trying a bunch of quick things (made a branch of my code and tried to merge down the RC) it looks like it'll be a little more work than that to get it working.  There have been a lot of changes.  Now that I understand what code I need, I'll get back to it when I get a spare moment.  I've got a bunch of tuning in the EEPROM to record and some production jobs to run.

I'll let you know when I get it working.

Thanks.

----------


## clough42

> Clough???   Did adding the Z_RAISE_AFTER_PROBING fix the problem?


Yes.  That worked.

I finally bit the bullet, pulled the RC and back-merged all of my config changes.  I haven't actually printed yet, but the bed leveling is working.

Looks like the motor directions got switched (again) and there are some changes to the thermal runaway detection (no configuration parameters) so we'll see how it goes.

----------


## inventabuild

Hi Roxy, 

In pins.h I have the Case Fan defined:
#define FAN2_PIN           2  //Fan2 --- Case Fan

I need to run this fan so my stepper drivers don't overheat.  Please let me know where the lines are that turn this fan on and set its speed?

Also, please let me know where is the "temperature.c - temperature control" tab?  It doesn't show across the top or in the drop down arrow selection.

----------


## clough42

> Clough???   Did adding the Z_RAISE_AFTER_PROBING fix the problem?


Thanks, Roxy.  It's working well for me.  I've got about 35 hours of continuous printing on it now, and its looking solid.

I do have a little oddity with the bed leveling I can't figure out.  The probe results show that the bed is not flat.  The readings at the right edge and the middle of the bed are just about the same, but the readings at the left edge are a tenth of a mm or so lower.  But with a straightedge and .05mm feeler gauge, it seems completely flat to me.

It's odd, and it after the leveling, the z seems to rise linearly when moving to the left, so stuff on the left side of the bed doesn't adhere well.

I would have expected the opposite, dropping as it moves left, compromising on the first layer being tight in the middle..

I can't get the diagnostics right now, because it's currently printing.

----------


## clough42

Okay, here's the output of G29:



```
Send: G29
Recv: G29 Auto Bed Leveling
Recv: Eqn coefficients: a: 0.00184583 b: 0.00039097 d: 4.03347873
Recv: planeNormal x: -0.001846 y: -0.000391 z: 1.000000
Recv: 
Recv: 
Recv: Bed Level Correction Matrix:
Recv: +0.999998 +0.000000 +0.001846
Recv: -0.000001 +1.000000 +0.000391
Recv: -0.001846 -0.000391 +0.999998
Recv: ok
```

If I'm reading this correctly, the Z height of the bed varies the most in the X direction, and the normal vector tilts toward negative X, meaning the bed is higher at the positive X edge of the bed.

And the printer does seem to be moving this way.  When it moves in the positive X direction, the head moves upward (the +0.001846) term in the [0,2] matrix cell.

But I think my bed is actually lower at the positive X edge, so I'm confused why it's doing this.

Is there an easy way to see the actual probe Z coordinates it's reading?  That would help me to determine if something is really wrong here or if it's just doing its best with a warped bed or X axis.

I tried M111 S32.  Heck, I even tried M111 S255, but didn't get anything more from G29 than what you see above.

----------


## Roxy

Doing a Topography report would be helpful.  Something like G29 V4 P5 T    That will give you a map of the height of the bed at different points.



> but the readings at the left edge are a tenth of a mm or so lower. But with a straightedge and .05mm feeler gauge, it seems completely flat to me.
> 
> It's odd, and it after the leveling, the z seems to rise linearly when moving to the left, so stuff on the left side of the bed doesn't adhere well.


I think that is tell you that the extruder is not moving perfectly flat or linearly.

----------


## clough42

> Doing a Topography report would be helpful.  Something like G29 V4 P5 T    That will give you a map of the height of the bed at different points.
> 
> 
> I think that is tell you that the extruder is not moving perfectly flat or linearly.


Yeah...I think you're right.  It's printing now, so I'll have to check tomorrow, but I'll bet that the X axis extrusions are either not parallel, causing the X carriage plate to flex, or the wheels on the X carriage are too tight, causing the extrusions to flex.

A few minutes with a digital caliper will tell the tale.

I have to take a step back for perspective sometimes.  I'm dealing with a machine here that I put together out of plywood and off-the-shelf hardware, not to mention a pile of parts made by the very machine itself, and I'm chasing a misalignment that's probably half a tenth of a millimeter.  Pretty crazy.

----------


## clough42

> Doing a Topography report would be helpful.  Something like G29 V4 P5 T    That will give you a map of the height of the bed at different points.
> 
> 
> I think that is tell you that the extruder is not moving perfectly flat or linearly.


Got a topography report.  If I'm reading this correctly, I have a bow in both directions, which is probably a glass or mounting issue, right?

Also, since 0,0 is in the back, right corner, are the matrices rotated 180 degrees?

Send: M80
Recv: ok
[...]
Send: G28
Recv: ok
[...]
Send: G29 V4 P5 T
Recv: G29 Auto Bed Leveling
Recv: Bed X: 30.000 Y: 30.000 Z: 3.448
Recv: Bed X: 90.000 Y: 30.000 Z: 3.686
Recv: Bed X: 150.000 Y: 30.000 Z: 3.851
Recv: Bed X: 210.000 Y: 30.000 Z: 3.952
Recv: Bed X: 270.000 Y: 30.000 Z: 3.997
Recv: Bed X: 270.000 Y: 90.000 Z: 3.996
Recv: Bed X: 210.000 Y: 90.000 Z: 3.974
Recv: Bed X: 150.000 Y: 90.000 Z: 3.879
Recv: Bed X: 90.000 Y: 90.000 Z: 3.742
Recv: Bed X: 30.000 Y: 90.000 Z: 3.492
Recv: Bed X: 30.000 Y: 150.000 Z: 3.569
Recv: Bed X: 90.000 Y: 150.000 Z: 3.816
Recv: Bed X: 150.000 Y: 150.000 Z: 3.927
Recv: Bed X: 210.000 Y: 150.000 Z: 4.007
Recv: Bed X: 270.000 Y: 150.000 Z: 4.044
Recv: Bed X: 270.000 Y: 210.000 Z: 4.000
Recv: Bed X: 210.000 Y: 210.000 Z: 4.013
Recv: Bed X: 150.000 Y: 210.000 Z: 3.947
Recv: Bed X: 90.000 Y: 210.000 Z: 3.834
Recv: Bed X: 30.000 Y: 210.000 Z: 3.634
Recv: Bed X: 30.000 Y: 270.000 Z: 3.601
Recv: Bed X: 90.000 Y: 270.000 Z: 3.780
Recv: Bed X: 150.000 Y: 270.000 Z: 3.900
Recv: Bed X: 210.000 Y: 270.000 Z: 3.970
Recv: Bed X: 270.000 Y: 270.000 Z: 3.981
Recv: Eqn coefficients: a: 0.00186917 b: 0.00031375 d: 3.51421260
Recv: Mean of sampled points: 3.84165048
Recv: planeNormal x: -0.001869 y: -0.000314 z: 1.000000
Recv: 
Recv: Bed Height Topography:
Recv: +-----------+
Recv: |...Back....|
Recv: |Left..Right|
Recv: |...Front...|
Recv: +-----------+
Recv:  -0.24115 -0.06140 +0.05835 +0.12860 +0.13910
Recv:  -0.20715 -0.00765 +0.10510 +0.17160 +0.15835
Recv:  -0.27265 -0.02565 +0.08585 +0.16560 +0.20235
Recv:  -0.34990 -0.09965 +0.03785 +0.13285 +0.15435
Recv:  -0.39390 -0.15590 +0.00960 +0.11010 +0.15535
Recv: 
Recv: 
Recv: Corrected Bed Height vs. Bed Topology:
Recv:  +0.07745 +0.14505 +0.15265 +0.11075 +0.00910
Recv:  +0.13028 +0.21763 +0.21823 +0.17258 +0.04718
Recv:  +0.08360 +0.21845 +0.21780 +0.18540 +0.11000
Recv:  +0.02517 +0.16328 +0.18862 +0.17147 +0.08083
Recv:  +0.00000 +0.12585 +0.17920 +0.16755 +0.10065
Recv: 
Recv: 
Recv: 
Recv: Bed Level Correction Matrix:
Recv: +0.999998 +0.000000 +0.001869
Recv: -0.000001 +1.000000 +0.000314
Recv: -0.001869 -0.000314 +0.999998
Recv: ok

----------


## clough42

I just reran the report with the bed freshly heated and again after soaking.  It warps another .05mm when heating and then settles somewhere in between.  Time to start swapping glass and adjusting insulation, I suppose.

----------


## Roxy

```
Recv: -0.24115 -0.06140 +0.05835 +0.12860 +0.13910
Recv: -0.20715 -0.00765 +0.10510 +0.17160 +0.15835
Recv: -0.27265 -0.02565 +0.08585 +0.16560 +0.20235
Recv: -0.34990 -0.09965 +0.03785 +0.13285 +0.15435
Recv: -0.39390 -0.15590 +0.00960 +0.11010 +0.15535

```

That's interesting...  I didn't know there was a *Corrected Bed Height vs. Bed Topology:  
*section to the report.  That is new.  I'll have to look at the code to see what that is doing.   But if the report is orientated correctly for your bed it is saying the front left is almost .4mm below the mean and the front right is .15mm above the mean.    Going diagonally, you have .5mm of difference from front left to back right.   And .4mm difference from back left to front right.  That is a lot.  The Auto Bed Leveling should be able to adjust for that, but you will get better prints if you physically adjust out some of that error.

At this point if you manually adjust your bed to bring all those numbers closer to zero, you will be able to see if there is a warp or a bulge in the bed.   What will happen in the case of a warp or bulge is you will see a row or column start off +, go to - and then flip back to +.   (or start -, goto +, and then back to -)  If you see that on any column or row, you have a non-flat bed and there is some kind of warp.    If you see that happen in both a row and a column, it will be likely the intersection of the two is the location of the bulge.   But that will only show up on the Topological Map if you have it adjusted closer to level.

----------


## dacb

> Thanks, Roxy.  It's working well for me.  I've got about 35 hours of continuous printing on it now, and its looking solid.
> 
> I do have a little oddity with the bed leveling I can't figure out.  The probe results show that the bed is not flat.  The readings at the right edge and the middle of the bed are just about the same, but the readings at the left edge are a tenth of a mm or so lower.  But with a straightedge and .05mm feeler gauge, it seems completely flat to me.
> 
> It's odd, and it after the leveling, the z seems to rise linearly when moving to the left, so stuff on the left side of the bed doesn't adhere well.
> 
> I would have expected the opposite, dropping as it moves left, compromising on the first layer being tight in the middle..
> 
> I can't get the diagnostics right now, because it's currently printing.


Hi Clough,
Do I take this post to mean that you've been running the most recent version of Marlin with changes to support your geometry and not my old fork? If so, that's great news.

----------


## clough42

> Hi Clough,
> Do I take this post to mean that you've been running the most recent version of Marlin with changes to support your geometry and not my old fork? If so, that's great news.


Yes.  At the moment, I still have a fork of your fork published and recommended for my customers, but I have been running the RC on one of my production printers for a while now, and it works great.

----------


## clough42

> ```
> Recv: -0.24115 -0.06140 +0.05835 +0.12860 +0.13910
> Recv: -0.20715 -0.00765 +0.10510 +0.17160 +0.15835
> Recv: -0.27265 -0.02565 +0.08585 +0.16560 +0.20235
> Recv: -0.34990 -0.09965 +0.03785 +0.13285 +0.15435
> Recv: -0.39390 -0.15590 +0.00960 +0.11010 +0.15535
> 
> ```
> 
> ...


Just realized I never came back with an update.  I eventually got the bed shimmed to within .06mm of flat and it's good enough if I split the difference on the Z height.

After talking with a mechanical engineer at work, it seems that this is typical.  Flat glass really isn't very rigid.  It tends to take a bow, usually across the diagonal.  Once it takes this bow, it becomes very rigid and stable, but it's very tricky to keep it entirely flat.

----------


## dacb

> Just realized I never came back with an update.  I eventually got the bed shimmed to within .06mm of flat and it's good enough if I split the difference on the Z height.
> 
> After talking with a mechanical engineer at work, it seems that this is typical.  Flat glass really isn't very rigid.  It tends to take a bow, usually across the diagonal.  Once it takes this bow, it becomes very rigid and stable, but it's very tricky to keep it entirely flat.


This is almost certainly why borosilicate glass is preferred for the application. I'd be curious to hear from someone who has used it.

----------


## clough42

> This is almost certainly why borosilicate glass is preferred for the application. I'd be curious to hear from someone who has used it.


You're hearing from one now.   :Smile: 

This is what I'm using:

http://rover.ebay.com/rover/1/711-53...mtid=824&kw=lg

I have a high-power silicone bed heater, and I was exploding ordinary window glass.  It turns out I was going a little too hot (140C) due to a thermistor configuration problem, but the heater was getting there so fast that the glass couldn't take the thermal stress and it was shattering.  The borosilicate glass takes it just fine.  I have since fixed my thermistor issue, but I still use the borosilicate glass.

----------


## dacb

> You're hearing from one now.  
> 
> This is what I'm using:
> 
> http://rover.ebay.com/rover/1/711-53...mtid=824&kw=lg
> 
> I have a high-power silicone bed heater, and I was exploding ordinary window glass.  It turns out I was going a little too hot (140C) due to a thermistor configuration problem, but the heater was getting there so fast that the glass couldn't take the thermal stress and it was shattering.  The borosilicate glass takes it just fine.  I have since fixed my thermistor issue, but I still use the borosilicate glass.


Terrific information.  So even with the borosilicate you see deformation of the glass plane?  Interesting.

----------


## systemslave

My weekend project was updating my Makerfarm i3v12 with Marlin and ABL.  G28 and G29 work great from the terminal, but when I tried to run my bed leveling gcode from the sd card the printer tries to probe the Z at X0, Y0.  I have Z_SAFE_HOMING set as follows, so I am confused.  Can you give me a quick pointer where I have gone astray?

  #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with probe outside the bed area.
                          // When defined, it will:
                          // - Allow Z homing only after X and Y homing AND stepper drivers still enabled
                          // - If stepper drivers timeout, it will need X and Y homing again before Z homing
                          // - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
                          // - Block Z homing only when the probe is outside bed area.

  #ifdef Z_SAFE_HOMING

    #define Z_SAFE_HOMING_X_POINT (X_MAX_LENGTH/2)    // X point for Z homing when homing all axis (G28)
    #define Z_SAFE_HOMING_Y_POINT (Y_MAX_LENGTH/2)    // Y point for Z homing when homing all axis (G28)

  #endif

----------


## Roxy

That doesn't sound right.   Whether the GCode comes from the host control program or from the SD Memory card, the commands get handled the same way.

I think there is something else going on here.

----------


## clough42

> My weekend project was updating my Makerfarm i3v12 with Marlin and ABL.  G28 and G29 work great from the terminal, but when I tried to run my bed leveling gcode from the sd card the printer tries to probe the Z at X0, Y0.  I have Z_SAFE_HOMING set as follows, so I am confused.  Can you give me a quick pointer where I have gone astray?
> 
>   #define Z_SAFE_HOMING   // This feature is meant to avoid Z homing with probe outside the bed area.
>                           // When defined, it will:
>                           // - Allow Z homing only after X and Y homing AND stepper drivers still enabled
>                           // - If stepper drivers timeout, it will need X and Y homing again before Z homing
>                           // - Position the probe in a defined XY point before Z Homing when homing all axis (G28)
>                           // - Block Z homing only when the probe is outside bed area.
> 
> ...


I have seen situations where the current draw of the probe servo causes the Ardunio to reset.  This could get you different results between the host program and the SD card because the SD interpretation would stop, but the host would keep going once the firmware rebooted.

You could try putting the servo on a separate 5V supply, or even just unplug the servo and extend the probe manually to see if it makes a difference.

----------


## Roxy

> I have seen situations where the current draw of the probe servo causes the Ardunio to reset.  This could get you different results between the host program and the SD card because the SD interpretation would stop, but the host would keep going once the firmware rebooted.
> 
> You could try putting the servo on a separate 5V supply, or even just unplug the servo and extend the probe manually to see if it makes a difference.


Good thinking!   That is a good thing to ask:   How are you powering your servo?

----------


## systemslave

Thank you Roxy and clough42 for the quick response.  I actually built an off board power supply to compensate for current draw.  I am using a RUMBA board and it did not source enough power to run the servo.  I really liked the servo headers and power jumper on a RAMPS board, so I built a daughter board for my RUMBA.  I am picking up the PWM signal from pin 5.  I pull 12v from main and regulate it to 5v on the sweet little daughter board where I have two servo headers plus three extra power pin sets.  Pins 5 and 6 (PWM) get pulled into the daughter board and routed to the servo pin headers.  I have been running a pi3 running octopi on one of the power sets so that I have WiFi control of the printer.  I pulled the pi off the first time this happened because I figured (like clough42) that I was short juice.  It didn't help.  The servo isn't drawing current from the Board.  The probe draws the same current whether it is on the swing arm or not.  By the way clough42, it is your swing arm design.  Thank you for that.

And as an aside, I print on borosilicate glass with PEI surface. I use the peel and stick PEI sheets.

----------


## Roxy

As a side note to all the MakerFarm people running the BeckDac fork at:   https://github.com/beckdac/Marlin

Here are my thoughts:    This branch was very helpful and was extremely stable for the last 18 months.   People with MakerFarm machines could just load it and use it.   And for sure...  It would just plain work.   It was very stable!    (Good job BeckDac!!!!)

Probably what makes sense now is if anybody with a MakerFarm machine has moved over to RC-7 of Marlin, we should set up a directory with your Configuration.h files and make it easy for people to get their machines running RC-7 too.    If you have Configuration.h, Configuration_adv.h and a Pins.h file that are working with MakerFarm hardware, please let me know.  I'll make a directory in the examples folder and people will be able to duplicate your setup very easily.

----------


## clough42

> Thank you Roxy and clough42 for the quick response.  I actually built an off board power supply to compensate for current draw.  I am using a RUMBA board and it did not source enough power to run the servo.  I really liked the servo headers and power jumper on a RAMPS board, so I built a daughter board for my RUMBA.  I am picking up the PWM signal from pin 5.  I pull 12v from main and regulate it to 5v on the sweet little daughter board where I have two servo headers plus three extra power pin sets.  Pins 5 and 6 (PWM) get pulled into the daughter board and routed to the servo pin headers.  I have been running a pi3 running octopi on one of the power sets so that I have WiFi control of the printer.  I pulled the pi off the first time this happened because I figured (like clough42) that I was short juice.  It didn't help.  The servo isn't drawing current from the Board.  The probe draws the same current whether it is on the swing arm or not.  By the way clough42, it is your swing arm design.  Thank you for that.
> 
> And as an aside, I print on borosilicate glass with PEI surface. I use the peel and stick PEI sheets.


You're welcome.

I run all of my printers with used HP DPS-600PB server power supplies.  I power a Raspberry Pi, the RAMPS board (VCC) and the RAMPS servo bus (+5V) direct from the 5VSB on the power supply, with three separate wires back to the source.  This way, the electronics are always on.  I switch the power supply on and off using the PS_ON line from the RAMPS power header, so the 12V bus for the motors and heaters is only on when needed.

I'm running an industrial silicone heater pad under borosilicate glass on my 12", and it delivers a lot of power.  I have to use borosilicate because ordinary glass explodes during the fast warmup cycle.   :Smile:

----------


## tsteever

Yes! I have been waiting for a Beckdac version of RC7 for quite some time. I can 
Get around the code but just haven't had time. Hopefully we can get a Makerfarm version of the latest firmware soon.  




> As a side note to all the MakerFarm people running the BeckDac fork at:   https://github.com/beckdac/Marlin
> 
> Here are my thoughts:    This branch was very helpful and was extremely stable for the last 18 months.   People with MakerFarm machines could just load it and use it.   And for sure...  It would just plain work.   It was very stable!    (Good job BeckDac!!!!)
> 
> Probably what makes sense now is if anybody with a MakerFarm machine has moved over to RC-7 of Marlin, we should set up a directory with your Configuration.h files and make it easy for people to get their machines running RC-7 too.    If you have Configuration.h, Configuration_adv.h and a Pins.h file that are working with MakerFarm hardware, please let me know.  I'll make a directory in the examples folder and people will be able to duplicate your setup very easily.

----------


## AbuMaia

I'm running RC7. So far I have only modified the Configuration.h and pins_RAMPS.h files. Where shall I put them?  I had to modify the pins_RAMPS.h file in order to use E3D's new cartridge upgrade and PT100 sensor.

----------


## clough42

> Probably what makes sense now is if anybody with a MakerFarm machine has moved over to RC-7 of Marlin, we should set up a directory with your Configuration.h files and make it easy for people to get their machines running RC-7 too.    If you have Configuration.h, Configuration_adv.h and a Pins.h file that are working with MakerFarm hardware, please let me know.  I'll make a directory in the examples folder and people will be able to duplicate your setup very easily.


I'm very interested in having something like this.  I have a fork of the beckdac fork with customized branches for my double extruder on various MakerFarm printers.  I'd really like to get out of that business, but I've been waiting for Marlin to be ready.  I'm personally running RC4 and very happy with it.

If there are going to be MakerFarm samples, do you think it would be appropriate to have Itty Bitty Double Extruder variants, or is that something I need to keep separate?

----------


## systemslave

I'm game.  Of course that is easy for me to say since the current version isn't currently doing what I want.  This is a hobby for me, so I will work on it this weekend. RC-7 here I come.

----------


## Roxy

> I'm running RC7. So far I have only modified the Configuration.h and pins_RAMPS.h files. Where shall I put them?  I had to modify the pins_RAMPS.h file in order to use E3D's new cartridge upgrade and PT100 sensor.





> I'm game.  Of course that is easy for me to say since the current version isn't currently doing what I want.  This is a hobby for me, so I will work on it this weekend. RC-7 here I come.


AbuMara:  Can you post them here?   How about we start a whole new thread for this purpose?   Maybe call it something like *Marlin RC-7 on MakerFarm*   ?

SystemSlave:  Can you please try to start with AbuMara's files.   That way we get some confirmation and Q/A time.   And we will have a starting point with the files that handle's at least two people's needs.

----------


## systemslave

> SystemSlave:  Can you please try to start with AbuMara's files.   That way we get some confirmation and Q/A time.   And we will have a starting point with the files that handle's at least two people's needs.


Absolutely!  I am just leaving for work.  I am excited to help build something that I think will be really useful.  AbuMaia sent me his working config.h file last night.  I want to thank him for that!

----------


## printbus

> ...Can you post them here?   How about we start a whole new thread for this purpose?   Maybe call it something like *Marlin RC-7 on MakerFarm*   ? ...


There was a short "how should we go about this" discussion some time ago that led to no clear scheme, and the problem is worse now than ever.  All need to remember that the MakerFarm product line is far more complex than it used to be.  Long gone are the days where a single set of files works for everyone with a MakerFarm printer, at least not without some adjustments.  

Don't get me wrong - I'm all about sharing lessons learned and helping out the next user.  As a minimum, things like thread posts, comments, descriptions, filenames, and foldernames should probably clarify what the content applies to. Even without factoring user modifications, the type of electronics (RAMPS, RUMBA, RAMBO), type of LCD (character vs graphic), type of extruder (Greg's Wade, bulldog, Pegasus, Titan single vs dual), and bed compensation scheme are examples of ways MakerFarm printers can differ as far as a firmware build and configuration parameters.  Many users can readily deal with tailoring standard files for their unique configuration, but history has shown that some, especially new users still somewhat unfamiliar with the firmware and lacking confidence in what they are doing, will struggle in doing this. If that is considered somehow from the beginning, maybe it'll be easier for all in the long-run.

----------


## tsteever

I picture myself the person you are talking about here! I know there is a new firmware out but have not adopted due to the reasons you mention. First, I am not 100% sure what needs to be done to make the RC-7 work on my machine.

Perhaps a checklist of things that need to be changed in the RC-7 to fit your machine could be made? That would perhaps give the user the confidence to at least try it out.

With that in mind, what changes need to be made?
*change esteps to fit your chassis, X,Y,Z,E
*Activate ABL if using
     -define pins in pins.h is using ABS
     -Set probe extend retract degrees
     -set probe points
     -define offsets
*define motherboard
*Define temp probe
*adjust PIDs


What else would a user need to change in RC-7 to fit their machine? Also, where can one find the current stable RC-7 file for use? Link?




> There was a short "how should we go about this" discussion some time ago that led to no clear scheme, and the problem is worse now than ever.  All need to remember that the MakerFarm product line is far more complex than it used to be.  Long gone are the days where a single set of files works for everyone with a MakerFarm printer, at least not without some adjustments.  
> 
> Don't get me wrong - I'm all about sharing lessons learned and helping out the next user.  As a minimum, things like thread posts, comments, descriptions, filenames, and foldernames should probably clarify what the content applies to. Even without factoring user modifications, the type of electronics (RAMPS, RUMBA, RAMBO), type of LCD (character vs graphic), type of extruder (Greg's Wade, bulldog, Pegasus, Titan single vs dual), and bed compensation scheme are examples of ways MakerFarm printers can differ as far as a firmware build and configuration parameters.  Many users can readily deal with tailoring standard files for their unique configuration, but history has shown that some, especially new users still somewhat unfamiliar with the firmware and lacking confidence in what they are doing, will struggle in doing this. If that is considered somehow from the beginning, maybe it'll be easier for all in the long-run.

----------


## Roxy

> There was a short "how should we go about this" discussion some time ago that led to no clear scheme, and the problem is worse now than ever.  All need to remember that the MakerFarm product line is far more complex than it used to be.  Long gone are the days where a single set of files works for everyone with a MakerFarm printer, at least not without some adjustments.


At worst case, we could have a MakerFarm folder with 3 or 4 different models in it.   And a Configuration.h file for each flavor.   That would be OK and still help people.

----------


## BLKKROW

I may be stupid but what's the difference between the R7 and the latest fork? Or are they the same?

----------


## Roxy

> I may be stupid but what's the difference between the R7 and the latest fork? Or are they the same?


There have been a family of 'Release Candidates'.  We are trying to do a 'Stable Release'.   RC-7 is the latest version.   It is much improved over the original RC-1.   I think we will have one more in the family, namely: RC-8.   I think that will be the last and final Release Candidate.   And that will become an official Stable Release.    

RC-7 is frozen in time.   RCBugFix is everything we have changed since RC-7 started.   You should be working with RCBugFix if you do any work or are bringing up a printer.    But the point is...  If you get Configuration.h files that work with RCBugFix (or RC-7) it won't be hard to package them up and make them available for the Stable Release when that happens.

----------


## AbuMaia

Ok, here is my Configuration.h file, and pins_RAMPS.h file.

MakerFarm i3v 8"
RAMPS 1.4
Marlin RCBugfix from August 26, 2016 (#4704?)
Toranado extruder http://www.thingiverse.com/thing:1246951
E3D 1.75 hotend with PT100 sensor http://www.makerfarm.com/index.php/h...grade-kit.html
Capacitive proximity sensor Z endstop/ABL probe https://www.amazon.com/dp/B00542U3M4/

pins_RAMPS.h
Configuration.h

----------


## tsteever

Where is the RC-7 download located? I thought I might take a look at it.

----------


## tsteever

Also, I know people use a text comparison program to look at the differences between two texts. What is a good free one to use to compare these two files?

----------


## Roxy

> Where is the RC-7 download located? I thought I might take a look at it.


It is here:  https://github.com/MarlinFirmware/Marlin/tree/RCBugFix    You should be using RCBugFix and not the frozen RC-7.   RCBugFix is RC-7 with all known bugs fixed.




> Also, I know people use a text comparison program to look at the differences between two texts. What is a good free one to use to compare these two files?


I like ExamDiff Pro.    But NotePad++ will do a good job of comparing your Configuration.h files.

----------


## tsteever

Wow, looking at the RC7 the comparison might not even work. There are a lot of differences on my initial investigation. 

I am running ABL, and that section looks a lot different.

----------


## uncle_bob

> Wow, looking at the RC7 the comparison might not even work. There are a lot of differences on my initial investigation. 
> 
> I am running ABL, and that section looks a lot different.


Hi

If you are coming from MakerFarm's ver 1.02 or 1.1.0 RC3 files, there *are* a lot of changes. Best to set aside some quality time to dig into the details ....

Bob

----------


## AbuMaia

> Also, I know people use a text comparison program to look at the differences between two texts. What is a good free one to use to compare these two files?


I use Meld on my Ubuntu Linux box.

----------


## printbus

> ...Using Dropbox because there was an error trying to upload the files here.


Eddie and the admin crew have been fixing things today.  Looks like the ability to post attachments is back.  

BTW - The Toranado looks like quite an extruder.

----------


## systemslave

Configuration.h

Here is my configuration.h file for a MakerFarm i3V12-RUMBA-ABL.  No change to RUMBA.pins was necessary.  I just finished this, but the test prints came out nicely.  I started with AbuMaia's RC7 configuration.h file and my old configuration.h file in Meld on an Ubuntu box.  I have a Windows 10 box right beside it, so my choice of tools was clearly a choice.

----------


## tsteever

I tried to load the RC7 but am getting an error in the compile. See below... 


Arduino: 1.6.5 (Mac OS X), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"


Build options changed, rebuilding all
In file included from MarlinConfig.h:37:0,
                 from Marlin.h:36,
                 from blinkm.cpp:28:
Configuration.h:504: error: floating constant in preprocessor expression
 #define X_PROBE_OFFSET_FROM_EXTRUDER 29.5  // X offset: -left  +right  [of the nozzle]
                                      ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:85:24: note: in definition of macro 'max'
 #define max(a,b) ((a)>(b)?(a) :Frown: b))
                        ^
Conditionals_post.h:721:53: note: in expansion of macro 'X_PROBE_OFFSET_FROM_EXTRUDER'
     #define MIN_PROBE_X (max(X_MIN_POS, X_MIN_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:510:37: note: in expansion of macro 'MIN_PROBE_X'
       #if LEFT_PROBE_BED_POSITION < MIN_PROBE_X
                                     ^
Configuration.h:504: error: floating constant in preprocessor expression
 #define X_PROBE_OFFSET_FROM_EXTRUDER 29.5  // X offset: -left  +right  [of the nozzle]
                                      ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:85:32: note: in definition of macro 'max'
 #define max(a,b) ((a)>(b)?(a) :Frown: b))
                                ^
Conditionals_post.h:721:53: note: in expansion of macro 'X_PROBE_OFFSET_FROM_EXTRUDER'
     #define MIN_PROBE_X (max(X_MIN_POS, X_MIN_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:510:37: note: in expansion of macro 'MIN_PROBE_X'
       #if LEFT_PROBE_BED_POSITION < MIN_PROBE_X
                                     ^
Configuration.h:637: error: floating constant in preprocessor expression
 #define X_MAX_POS 306.5
                   ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:20: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                    ^
Conditionals_post.h:722:30: note: in expansion of macro 'X_MAX_POS'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                              ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
Configuration.h:637: error: floating constant in preprocessor expression
 #define X_MAX_POS 306.5
                   ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:24: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                        ^
Conditionals_post.h:722:41: note: in expansion of macro 'X_MAX_POS'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                         ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
Configuration.h:504: error: floating constant in preprocessor expression
 #define X_PROBE_OFFSET_FROM_EXTRUDER 29.5  // X offset: -left  +right  [of the nozzle]
                                      ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:24: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                        ^
Conditionals_post.h:722:53: note: in expansion of macro 'X_PROBE_OFFSET_FROM_EXTRUDER'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
Configuration.h:637: error: floating constant in preprocessor expression
 #define X_MAX_POS 306.5
                   ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:28: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                            ^
Conditionals_post.h:722:30: note: in expansion of macro 'X_MAX_POS'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                              ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
Configuration.h:637: error: floating constant in preprocessor expression
 #define X_MAX_POS 306.5
                   ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:32: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                                ^
Conditionals_post.h:722:41: note: in expansion of macro 'X_MAX_POS'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                         ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
Configuration.h:504: error: floating constant in preprocessor expression
 #define X_PROBE_OFFSET_FROM_EXTRUDER 29.5  // X offset: -left  +right  [of the nozzle]
                                      ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:32: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                                ^
Conditionals_post.h:722:53: note: in expansion of macro 'X_PROBE_OFFSET_FROM_EXTRUDER'
     #define MAX_PROBE_X (min(X_MAX_POS, X_MAX_POS + X_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:512:40: note: in expansion of macro 'MAX_PROBE_X'
       #elif RIGHT_PROBE_BED_POSITION > MAX_PROBE_X
                                        ^
In file included from MarlinConfig.h:39:0,
                 from Marlin.h:36,
                 from blinkm.cpp:28:
SanityCheck.h:513: error: #error "The given RIGHT_PROBE_BED_POSITION can't be reached by the Z probe."
         #error "The given RIGHT_PROBE_BED_POSITION can't be reached by the Z probe."
          ^
In file included from MarlinConfig.h:37:0,
                 from Marlin.h:36,
                 from blinkm.cpp:28:
Configuration.h:505: error: floating constant in preprocessor expression
 #define Y_PROBE_OFFSET_FROM_EXTRUDER -1.3  // Y offset: -front +behind [the nozzle]
                                       ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:85:24: note: in definition of macro 'max'
 #define max(a,b) ((a)>(b)?(a) :Frown: b))
                        ^
Conditionals_post.h:723:53: note: in expansion of macro 'Y_PROBE_OFFSET_FROM_EXTRUDER'
     #define MIN_PROBE_Y (max(Y_MIN_POS, Y_MIN_POS + Y_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:514:40: note: in expansion of macro 'MIN_PROBE_Y'
       #elif FRONT_PROBE_BED_POSITION < MIN_PROBE_Y
                                        ^
Configuration.h:505: error: floating constant in preprocessor expression
 #define Y_PROBE_OFFSET_FROM_EXTRUDER -1.3  // Y offset: -front +behind [the nozzle]
                                       ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:85:32: note: in definition of macro 'max'
 #define max(a,b) ((a)>(b)?(a) :Frown: b))
                                ^
Conditionals_post.h:723:53: note: in expansion of macro 'Y_PROBE_OFFSET_FROM_EXTRUDER'
     #define MIN_PROBE_Y (max(Y_MIN_POS, Y_MIN_POS + Y_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:514:40: note: in expansion of macro 'MIN_PROBE_Y'
       #elif FRONT_PROBE_BED_POSITION < MIN_PROBE_Y
                                        ^
Configuration.h:505: error: floating constant in preprocessor expression
 #define Y_PROBE_OFFSET_FROM_EXTRUDER -1.3  // Y offset: -front +behind [the nozzle]
                                       ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:24: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                        ^
Conditionals_post.h:724:53: note: in expansion of macro 'Y_PROBE_OFFSET_FROM_EXTRUDER'
     #define MAX_PROBE_Y (min(Y_MAX_POS, Y_MAX_POS + Y_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:516:39: note: in expansion of macro 'MAX_PROBE_Y'
       #elif BACK_PROBE_BED_POSITION > MAX_PROBE_Y
                                       ^
Configuration.h:505: error: floating constant in preprocessor expression
 #define Y_PROBE_OFFSET_FROM_EXTRUDER -1.3  // Y offset: -front +behind [the nozzle]
                                       ^
/Applications/Arduino.app/Contents/Java/hardware/arduino/avr/cores/arduino/Arduino.h:84:32: note: in definition of macro 'min'
 #define min(a,b) ((a)<(b)?(a) :Frown: b))
                                ^
Conditionals_post.h:724:53: note: in expansion of macro 'Y_PROBE_OFFSET_FROM_EXTRUDER'
     #define MAX_PROBE_Y (min(Y_MAX_POS, Y_MAX_POS + Y_PROBE_OFFSET_FROM_EXTRUDER))
                                                     ^
SanityCheck.h:516:39: note: in expansion of macro 'MAX_PROBE_Y'
       #elif BACK_PROBE_BED_POSITION > MAX_PROBE_Y
                                       ^
floating constant in preprocessor expression


  This report would have more information with
  "Show verbose output during compilation"
  enabled in File > Preferences.

----------


## AbuMaia

SanityCheck.h:510:37: note: in expansion of macro 'MIN_PROBE_X'
       #if LEFT_PROBE_BED_POSITION < MIN_PROBE_X
                                     ^
Configuration.h:504: error: floating constant in preprocessor expression
 #define X_PROBE_OFFSET_FROM_EXTRUDER 29.5  // X offset: -left  +right  [of the nozzle]

That may tell us something. Will your X Probe Offset cause the nozzle to go out of the print bed area on the X axis?   

On my printer, My X Probe Offset is 40, so my Min Probe X is 50 to keep the nozzle over the print bed.

edit: I see I shouldn't have edited this post. My first suggestion was to drop the decimal points on X and Y offset to see what happened.

----------


## Roxy

> I tried to load the RC7 but am getting an error in the compile. See below...


There are only a few places where a floating point number is allowed on a #define.   For example, #define Z_PROBE_OFFSET_FROM_EXTRUDER 3.4  can have a decimal point and extra precision.  But even X_PROBE_OFFSET_FROM_EXTRUDER and Y_PROBE_OFFSET_FROM_EXTRUDER need to be integers without a decimal point.  The same is true of X_MAX_POS and Y_MIN_POS.     The reason is the C++ preprocessor can't handle floating point numbers and if you put them into the Configuration.h it will blow up the preprocessor.

----------


## dustmann

Check your ABL probe positions, and make sure that your values will work within the parameters of your X/Y probe offset values.  For example, your X probe offset from extruder looks to be 29.5, so your LEFT_PROBE_BED_POSITION should be > 29.5 or the probe will not be able to reach the indicated position (which would be on the other side of your Xmin endstop).  Also, your Y probe is -1.3 so your BACK_PROBE_BED_POSITION should be less than your YMAX - 1.3.

These are my settings as an example (and to show you the values of which I am referring):

#if ENABLED(AUTO_BED_LEVELING_GRID) 
   #define LEFT_PROBE_BED_POSITION 30
    #define RIGHT_PROBE_BED_POSITION 260
    #define FRONT_PROBE_BED_POSITION 0
    #define BACK_PROBE_BED_POSITION 260

#define X_PROBE_OFFSET_FROM_EXTRUDER 28  // X offset: -left  +right  [of the nozzle]
#define Y_PROBE_OFFSET_FROM_EXTRUDER -20  // Y offset: -front +behind [the nozzle]
#define Z_PROBE_OFFSET_FROM_EXTRUDER -4.14   // Z offset: -below +above  [the nozzle]

----------


## tsteever

I will check. I just copied the old values right into the new firmware since none of the physical printer changed. 

Did the firmware change how this is calculated? When I look at the printer my probe is on a foot that rotates down on the left side of the nozzle. I am using clough's design forn the probe.

----------


## tsteever

I did try to compile without the decimal points and it still did not work.

----------


## tsteever

I don't understand. How can you have offsets without a decimal point?


> There are only a few places where a floating point number is allowed on a #define.   For example, #define Z_PROBE_OFFSET_FROM_EXTRUDER 3.4  can have a decimal point and extra precision.  But even X_PROBE_OFFSET_FROM_EXTRUDER and Y_PROBE_OFFSET_FROM_EXTRUDER need to be integers without a decimal point.  The same is true of X_MAX_POS and Y_MIN_POS.     The reason is the C++ preprocessor can't handle floating point numbers and if you put them into the Configuration.h it will blow up the preprocessor.

----------


## tsteever

My left probe is 50. It is greater than 29.5.


> Check your ABL probe positions, and make sure that your values will work within the parameters of your X/Y probe offset values.  For example, your X probe offset from extruder looks to be 29.5, so your LEFT_PROBE_BED_POSITION should be > 29.5 or the probe will not be able to reach the indicated position (which would be on the other side of your Xmin endstop).  Also, your Y probe is -1.3 so your BACK_PROBE_BED_POSITION should be less than your YMAX - 1.3.These are my settings as an example (and to show you the values of which I am referring):#if ENABLED(AUTO_BED_LEVELING_GRID)    #define LEFT_PROBE_BED_POSITION 30    #define RIGHT_PROBE_BED_POSITION 260    #define FRONT_PROBE_BED_POSITION 0    #define BACK_PROBE_BED_POSITION 260#define X_PROBE_OFFSET_FROM_EXTRUDER 28  // X offset: -left  +right  [of the nozzle]#define Y_PROBE_OFFSET_FROM_EXTRUDER -20  // Y offset: -front +behind [the nozzle]#define Z_PROBE_OFFSET_FROM_EXTRUDER -4.14   // Z offset: -below +above  [the nozzle]

----------


## tsteever

Here is my config file if you want to take a look.

----------


## AbuMaia

> I don't understand. How can you have offsets without a decimal point?


  Your X and Y offsets should be rounded up to the nearest MM. The Z offset can have a decimal, as it needs more precision.

----------


## tsteever

Got rid of the decimal points in the X/Y probe offsets. It compiled. Have some servo jitters that weren't there before the new code.

----------


## dustmann

Looks like you forgot to uncomment line 1300

//#define DEACTIVATE_SERVOS_AFTER_MOVE

----------


## tsteever

> Looks like you forgot to uncomment line 1300//#define DEACTIVATE_SERVOS_AFTER_MOVE


Thanks! I went and made that change! I should have read the code a bit better. That is a neat addition.

----------


## tsteever

So, when I just do a g28, the nozzle height looks good. When I do a g29, the nozzle crashes into the bed. The two give me completely different heights.

Also, what do I need to change to get the encoder to not flip 2 values when turning the knob. For example, it jumps by 2 instead of one.

----------


## AbuMaia

> what do I need to change to get the encoder to not flip 2 values when turning the knob. For example, it jumps by 2 instead of one.


  Search your configuration.h file for "Encoder Settings". It should be around line 1012. You want the "pulses per step" option I think.

----------


## beerdart

Here is our RC6bugfix. MakerFarm i38" RAMPS 1.4 Itty Bitty dual flex E3D 3mm servo ABL.

----------


## dustmann

Are you setting your Z offset with the bed heated?  I always set Z offset with the bed heated, and after running a G29 command, so that the offset accounts for the bed mapping stored by G29.  Also, it is important to have the bed heated to printing temperature because of the expansion that occurs.  I have noticed my bed is significantly higher (and hotter) under the "Mak" in makerfarm.  I suspect this hot spot, along with imperfectly shaped glass and a bed that hasn't been leveled in 6 months (in my case), throws off the offset values before/after temperature, which isn't a problem after compensating with ABL.

----------


## tsteever

Yes, I am heating the bed. With the old firmware I would adjust the offset in the menu system and then put that number in the firmware. This saved a few extra steps. The issue I am having is the homing command and the bed leveling command are giving me two different nozzle heights.

----------


## AbuMaia

Be careful with the Z probe offset. I have my capacitive proximity probe above the nozzle, so I thought the offset would be a positive number, for above the nozzle. It's not. It triggers below the nozzle, so my offset has to be negative.

----------


## uncle_bob

> Yes, I am heating the bed. With the old firmware I would adjust the offset in the menu system and then put that number in the firmware. This saved a few extra steps. The issue I am having is the homing command and the bed leveling command are giving me two different nozzle heights.


Hi

The homing command is going to take you to the point that the end stops trigger. For X and Y that's probably ok. For Z ... not so much. The old approach was to use the Z probe as the Z end stop. Same probe, same height, problem solved.

Bob

----------


## systemslave

Is there a way to automatically issue the g28 and g29 from the firmware prior to printing?  I currently have to run it from the terminal or insert it into the gcode file.

----------


## AbuMaia

I have Slic3r put it into the G-code for me automatically whenever I slice anything.

Printer Settings tab
Custom G-code

M190 S[first_layer_bed_temperature] ; set bed temperature, wait for it to reach target before proceeding
M117 Homing...
G28
M104 S[first_layer_temperature] ; set hotend temperature. Use M109 to set and wait
M117 Auto Bed Leveling...
G29 P4 ; auto level
G1 X99 Y99 Z1 F1500; reposition extruder
M109 S[first_layer_temperature] ; in case the hotend didn't heat up fully during ABL
M117 Printing...

----------


## systemslave

Thanks AbuMaia, I get that.  I am doing the same with Cura.  I would like to trigger it in the firmware instead of depending on the slicer to embed it.  Even in the case where the leveling ran twice because it was embedded in the gcode the machine would not be hurt.

----------


## uncle_bob

Hi

Pretty much every slicer out there has a section for gcode to send when the printer is started and when it is stopped. It is well worth looking into *what* should best be in those sections. You can do all sorts of cute things (wipe the print head at start, move the part out of the way at end) with them. There is often a bit of fine tuning in terms of what goes first or last in the file. 

Bob

----------


## tsteever

I am getting some inconsistent results. I have had about 50% fail rate since updating to the new firmware. 

I think I have tracked my problem down to the ABL probe. It seems to over extend which results in a crash. I readjusted the extend and retract angles. I tested these by running a g28 and then a g29 and it worked. I shut down the printer. 

The next day I ran a print and it failed. Looks like the ABL probe is using the old values even though the firmware has been updated with new values. 

Ideas on where to start?

----------


## dustmann

Do you have eeprom settings enabled?  It sounds like perhaps you have a conflict between your firmware and the eeprom settings for your Z probe.  Try running an M502 command followed by M500 to rule it out.

----------


## kd7eir

> I am getting some inconsistent results. I have had about 50% fail rate since updating to the new firmware. 
> 
> I think I have tracked my problem down to the ABL probe. It seems to over extend which results in a crash. I readjusted the extend and retract angles. I tested these by running a g28 and then a g29 and it worked. I shut down the printer. 
> 
> The next day I ran a print and it failed. Looks like the ABL probe is using the old values even though the firmware has been updated with new values. 
> 
> Ideas on where to start?


Did you compile and uploaded the firmware after changing the servo endpoints?

Try testing with this, making sure the probe ends up where you expect

M401 - deploys the probe
M402 - retracts the probe

----------


## tsteever

What exactly do those commands do? 

I have the eeprom disabled
//#define EEPROM_SETTINGS

----------


## tsteever

Yes, I used the M280 commands to determine to correct angles. Uploaded the changes and then used the m401 and m402 commands to check. I even did a g28 and g29 to confirm. All work well. 

The next time I fired up the machine the servo angles are wonky. 






> Did you compile and uploaded the firmware after changing the servo endpoints?
> 
> Try testing with this, making sure the probe ends up where you expect
> 
> M401 - deploys the probe
> M402 - retracts the probe

----------


## uncle_bob

> ......
> 
> The next time I fired up the machine the servo angles are wonky.


Hi

Was the machine hot(er) one time than the other? My experience is that some servos are crazy temperature sensitive as well as being a bit drift prone.

Bob

----------


## tsteever

Man, not sure I should have opened this can of worms. It was working fine before. 

I went to check the servo angles and now it won't home. I am getting the following error...

Error:MINTEMP triggered, system stopped! Heater_ID: 0
Error:Printer halted. kill() called!

10 minutes later and i can get it to home but now Octoprint won't connect!  
*Error: volume.init failed*

----------


## AbuMaia

For the mintemp, I'd check your hotend thermistor wires, make sure they're not shorting together.

As for the octoprint, I don't think that's a Marlin problem. Reboot your octoprint (octopi?).

----------


## printbus

> For the mintemp, I'd check your hotend thermistor wires, make sure they're not shorting together.


Actually, mintemp would be an open connection.  The thermistor resistances go up with colder temperatures.  So, assuming no wiring changes were made, maybe there's a configuration problem with the input that is being sampled for that temperature.

EDIT: Here's a resistance vs. temperature plot for the typical EPCOS thermistor...

----------


## AbuMaia

Ah. When I disconnected the hotend module from the Toranado extruder while the printer was on, I thought it gave a maxtemp error due to the open circuit. I might have just misread the screen, though.

----------


## tsteever

Okay, I am at a loss here!  I cannot get anything to print. I first had issues with the ABL probe. Got that solved. Had issues with Octoprint, solved. Now I am am having temp issues.

The most recent print failed and I get the following message on my screen...

heating failed
Printer Halted
Please reset.

I am printing from the SD card. I could actually see the temp on the hot end going down even through the display says it is set at 200.  Heats up fine and will hold temps no problem letting it sit at temp for a while. It seems at layer two in the print if goes wonky.

----------


## tsteever

What i have managed to find out is when the fans kick on the temp drops....and continues to drop. If I redirect the fans, the temp comes back up. This happens at all fan speeds. 

I was using the new silicone sock but took it off cause it ripped on one of my failed prints. I am going to put on another one to see if that makes any difference. I did run a PID autotune with it on and the fans blowing. Should I run the PID with the fans off and sock off?

----------


## printbus

Were you heating the bed too, or just the hot end?

Do you have a print cooling fan that is set in the slicer to kick in at say, layer 2?

I'm just wondering about a possible thermal runaway situation.  The OEM builds from MakerFarm at least up to some point had thermal runaway detection disabled.  There was a thread here some months ago where an early adopter of the revamped Marlin started getting thermal runaway errors when he upgraded to it.  It turned out that at least as of that build, the default was for thermal runaway detection to be enabled.  If I recall, that problem was with the heated bed - it would heat up OK but then in the print the bed temp would drop off just enough and for a long enough period to trip the thermal runaway condition that shuts down the print.  I imagine the same thing could happen with the hot end if too much print cooling airflow is applied after the hot end is at temp and the heater can't keep up with it.

EDIT: Reading tsteever's latest post that came in while I was typing, this sounds like a real possibility

----------


## printbus

FWIW, here is that earlier thread.  The thermal runaway part of the thread starts at post #19.  

About to try Marlin1.1.0RC4...

----------


## uncle_bob

Hi

Based on a disaster that happened here over the last few days:

If the fan shroud on the e3d is damaged, it will dump a bunch of air onto the heated block. The PWM will go to 100% and it will struggle to hold temperature on the hot end. It *will* hang out long enough in this state to trigger "thermal runaway" with the stock settings. The problem will be made worse if you have a bum connection in the heater circuit or if the heater cartridge is loose in the block. A loose thermistor mounting screw would do similar things. 

Simple check:

Don't try to print anything. Having stuff moving around is confusing.

Fire up the heated bed and make sure the PWM goes into blink mode (LED blinks vs full on, I watch the one on my SSR) 
Check the power supply is at 12V or more

Fire up the hot end (heated bed still on) and make sure the LED goes into blink mode for it. 
Check the power supply is still at 12V or more

The fans cooling the e3d must be on any time it is on, so they are already running. 
Turn on any other fans you have
Watch the PWM and /or temperature
Check the power supply

Somewhere along in there you should find the problem, if not:

Start giggling wires. You likely have a loose / broken connection.

Bob

----------


## AbuMaia

> I'm just wondering about a possible thermal runaway situation. ... If I recall, that problem was with the heated bed - it would heat up OK but then in the print the bed temp would drop off just enough and for a long enough period to trip the thermal runaway condition that shuts down the print.


  I've been having that trouble myself occasionally since I started using RCBugfix. The bed heater seems to stall out, then the print cancels and the printer disconnects from OctoPi. I'm glad to hear it's a known issue, and that there's a workaround.

----------


## Roxy

> I've been having that trouble myself occasionally since I started using RCBugfix. The bed heater seems to stall out, then the print cancels and the printer disconnects from OctoPi. I'm glad to hear it's a known issue, and that there's a workaround.


We are near the end of RC-7.   I'm not sure that I remember any thermal issues in RC-7.   I do remember some issues in RC-6.   

The only thing concerning thermal issues lately is this thread speculating there may be a bug in the way the PID algorithm works:

https://github.com/MarlinFirmware/Marlin/issues/4881

If you are having problems with your heaters doing the right thing, please let us know!!!

----------


## tsteever

Where does one post these issues? I am relatively new to the debugging process. before I used the Bec release with great success. I think it may be a PID issue. As soon as the fan is on and anywhere close to the nozzle the temps drop like a rock without the sock on. I have had issues before with air cooling the nozzle down but the printer could usually keep up and the temp only would drop a few degrees.

I took off the silicone E3D sock heated the nozzle to 210 and then turned on the fan. The temps dropped to below 148 in less than 30 seconds. As soon as the air hit the nozzle it was as if the PID had no idea what to do.  With the sock on and the fan set to full the temp drops a little, about 10 degrees or so.

----------


## AbuMaia

> We are near the end of RC-7.   I'm not sure that I remember any thermal issues in RC-7.   I do remember some issues in RC-6.     The only thing concerning thermal issues lately is this thread speculating there may be a bug in the way the PID algorithm works:  https://github.com/MarlinFirmware/Marlin/issues/4881  If you are having problems with your heaters doing the right thing, please let us know!!!


  So far my only problems have been with the print bed heater, and I (think I) have it on a bang-bang setup, not PID. I have my bed heater connected through a relay, so I don't think PID or PWM would be a good option. The issue is somewhat rare, though. Maybe only once in 7-8 prints.

----------


## Roxy

> So far my only problems have been with the print bed heater, and I (think I) have it on a bang-bang setup, not PID. I have my bed heater connected through a relay, so I don't think PID or PWM would be a good option. The issue is somewhat rare, though. Maybe only once in 7-8 prints.


Right!  Bang Bang mode is separate from PID.   But still...  You shouldn't be seeing any problems.  If you are running RC-7 and see an issue, please click the 'Issues' button (at: https://github.com/MarlinFirmware/Ma...3Aupdated-desc )   and describe the problem.

----------


## uncle_bob

Hi

Yes, it's duplicate info, but it's probably worth posting here. 

If you are running the Arduino app that MakerFarm recommends (1.06) on a Mac, the latest OS update to Sierra brakes it. You re-install Java after the update. After that the app simply locks up. The solution is stupid. You delete the app and re-install it. Once you do, all is well again.

Bob

----------


## AbuMaia

Just had the bed throw an error again.



```
Recv: Error:Heating failed, system stopped! Heater_ID: bed
Changing monitoring state from 'Printing' to 'Error: Heating failed, system stopped! Heater_ID: bed
'
Recv: Error:Printer halted. kill() called!
```

That was all the error message OctoPrint gave me. Doesn't say if it was a thermal runaway or not.

----------


## uncle_bob

> Just had the bed throw an error again.
> 
> 
> 
> ```
> Recv: Error:Heating failed, system stopped! Heater_ID: bed
> Changing monitoring state from 'Printing' to 'Error: Heating failed, system stopped! Heater_ID: bed
> '
> Recv: Error:Printer halted. kill() called!
> ...


Hi

That looks like thermal runaway to me. Simply put, it's calling for heat for to long a period of time and deciding the thermistor is not responding. Simple answer is to stretch out the timeout, if you do it in firmware. Putting a solid state relay on my printer was a < $15 decision. With PWM the problem has never occurred. To fix it without new hardware, bumping up your power supply voltage might do the trick. Obviously, each of these approaches has its own drawbacks. 

Bob

----------


## Roxy

The Thermal Parameters are (in my opinion) overly tight.   The people that wrote the Thermal Protection wanted to make them even tighter!  I have mine currently at these numbers, but I think I'm going to have to bump the 20 up to 30.



```
#if ENABLED(THERMAL_PROTECTION_BED)
  #define THERMAL_PROTECTION_BED_PERIOD 20    // Seconds
  #define THERMAL_PROTECTION_BED_HYSTERESIS 2 // Degrees Celsius


  #define WATCH_BED_TEMP_PERIOD 60                // Seconds
  #define WATCH_BED_TEMP_INCREASE 2               // Degrees Celsius
#endif
```

----------


## uncle_bob

Hi

A heated bed is a much different animal than a hot end. The numbers you need for one are not what you need for the other. A bed isn't going to kill it's self in a minute or three. A hot end easily could get into big trouble in that amount of time. ....

Bob

----------


## Chips

I am trying to get my 8" i3v going again after several months of neglect.   I have the hardware for ABL.. what is the address of the latest/best marlin RAMPS build?

----------


## uncle_bob

> I am trying to get my 8" i3v going again after several months of neglect.   I have the hardware for ABL.. what is the address of the latest/best marlin RAMPS build?


Hi

https://github.com/MarlinFirmware/Marlin  is always the "right" way in. RC7 appears to be the latest.

Bob

----------


## Roxy

Actually...  RC-7 is a very stable point in time.   But RCBugFix is always more up to date than the frozen RC-#    Unless you have a real reason for not using RCBugFix, that is usually the best choice.

----------


## Chips

Is there a configuation.h that you have built?  After I uploaded rc7, my LCD is blank...  I looked over the  configuation.h, but nothing jumped out at me.

----------


## uncle_bob

> Is there a configuation.h that you have built?  After I uploaded rc7, my LCD is blank...  I looked over the  configuation.h, but nothing jumped out at me.


Hi

You probably have the wrong display enabled.

Bob

----------


## BLKKROW

> Actually...  RC-7 is a very stable point in time.   But RCBugFix is always more up to date than the frozen RC-#    Unless you have a real reason for not using RCBugFix, that is usually the best choice.


I am getting ready to update my firmware and noticed the RC-8 is available. Should I use this or RC-7?

----------


## Roxy

For sure...  RC-8 is much better than RC-7.    But you really should be using RCBugFix.  Right now, RCBugFix is very close to RC-8.   But over time...   RCBugFix will be much better than RC-8.

----------


## uncle_bob

Hi

What's the status of mesh bed leveling in RC-8 / RCBugFix?

Bob

----------


## Roxy

It works.   But the RC-8 / RCBugFix version does not allow you to save the mesh.   The UBL Branch lets you save the mesh and it also provides very nice Mesh Validation Pattern and Editing commands for the Mesh.

----------


## uncle_bob

Hi

It's the mesh pattern validation stuff that I'm waiting for .... trust but verify  :Smile:  ... I've dropped the median filter back to 3 samples on the BLTouch and need to check things from time to time. 

Bob

----------


## BLKKROW

> It works.   But the RC-8 / RCBugFix version does not allow you to save the mesh.   The UBL Branch lets you save the mesh and it also provides very nice Mesh Validation Pattern and Editing commands for the Mesh.


I apologize for all the questions, but I do appreciate your knowledge and time.

This morning I started modifying the RC Bug Fix and then I read this comment. In the future I am planning on using the BL touch to implement ABL/Mesh Leveling. if I understand your comment correctly, with RC Bug Fix it won't save the Mesh but will run at the start of every print to create that mesh. Is this correct?

I just want to ensure whatever firmware I use I will be setup for success with my planned upgrades.

----------


## uncle_bob

Hi

You have two simple choices: 

1) Auto bed leveling, (bilinear or whatever) that just does it's thing with a G29 gcode. It resets when any G28 (X,Y,Z) comes in.
2) Mesh bed leveling, this runs with a sequence of G28 commands (or at least it used to). There is a bit more to the startup script as a result.

The BLTouch has it's own issues, but seems to be "good enough".

Bob

----------


## BLKKROW

So I am working through the firmware and am getting compile errors.

https://www.dropbox.com/s/sjafx44u4d...arlin.rar?dl=0

That is a RAR of my firmware, can someone look at it and let me know what I did wrong? Thank you!

----------


## uncle_bob

Hi

Start from scratch and do a compile. It should compile without errors. If it does not, re-install your toolchain and re-download the code. Next, add your changes one at a time and do a compile. The one that makes it puke is suspect  :Smile:  Multiple definitions for a feature are the most common issue (You can only have one display etc). If you are a "bulk change" sort of person, make notes on each line you change. Do the process in reverse, comment out each change and compile after each reversal. 

That may sound like a lot of time and a lot of work. It is enormously faster than waiting for somebody else to download your config and then find the time to check it out. There is inevitably a bit of back and forth with that process:

The first layer issue with your config is that it is defining ULTIPANEL as the display and then looking for the data structures that are associated with it. Do you have a normal MakerFarm or have you modified the display?

Bob

----------


## BLKKROW

> Hi
> 
> Start from scratch and do a compile. It should compile without errors. If it does not, re-install your toolchain and re-download the code. Next, add your changes one at a time and do a compile. The one that makes it puke is suspect  Multiple definitions for a feature are the most common issue (You can only have one display etc). If you are a "bulk change" sort of person, make notes on each line you change. Do the process in reverse, comment out each change and compile after each reversal. 
> 
> That may sound like a lot of time and a lot of work. It is enormously faster than waiting for somebody else to download your config and then find the time to check it out. There is inevitably a bit of back and forth with that process:
> 
> The first layer issue with your config is that it is defining ULTIPANEL as the display and then looking for the data structures that are associated with it. Do you have a normal MakerFarm or have you modified the display?
> 
> Bob


Thank you for your input!

I have been copying a lot of settings from the original Marlin 1.02 that is provided by Colin. So I will keep digging through it and see what happens.

Yes I do have the original Graphical LCD.

----------


## uncle_bob

Hi

There are only a handful of settings that matter:

1) The display
2) The heater Kp, Ki, Kd numbers
3) The steps per mm on each axis
4) The thermistor types
5) End stops polarity 
6) Home directions
7) The bed size
8) The speed and acceleration stuff
9) the temperature limits


Past that it's things like enable (or not) on the eeprom and bed leveling / probes. There is also some fluff like giving it a name. Get the first set of items above working and then add the other stuff a bit at a time. If you want to cut the list above in half and just do 1 through 6, the printer should work in that state. It won't be perfect, but it will boot and home. 

Bob

----------


## BLKKROW

> Hi
> 
> There are only a handful of settings that matter:
> 
> 1) The display
> 2) The heater Kp, Ki, Kd numbers
> 3) The steps per mm on each axis
> 4) The thermistor types
> 5) End stops polarity 
> ...


So I have movement, PID, thermistor's, etc working. The only thing I cannot get to work is the LCD. I keep getting that compile error.

I have the following two things defined:

#define DOGLCD 
#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER

If I undefine those two lines then it will compile and upload. But then I cannot use the LCD. Any idea's?

----------


## uncle_bob

Hi

Dump DOGLCD.

Bob

----------


## BLKKROW

> Hi
> 
> Dump DOGLCD.
> 
> Bob


I have tried that and just left "#define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER". It still gives me a compiling error, I am attempting to use Marlin 1.1 RC8 Bug Fix.

I also have the UG8lib in my libraries folder.

----------


## printbus

What is your compile error?  

I did a debug build for someone a long time ago, and what it boiled down to was this (from configuration.h at the time)

// ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: https://github.com/olikraus/U8glib_Arduino

Without that library, the graphic stuff won't build.

EDIT: Ah. Just saw your comment that came in while I was typing.

----------


## uncle_bob

Hi

Start from a scratch compile, undefine their default display and define the graphics controller. Unless there is a very new bug, it should compile. 

Bob

----------


## BLKKROW

> What is your compile error?  
> 
> I did a debug build for someone a long time ago, and what it boiled down to was this (from configuration.h at the time)
> 
> // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: https://github.com/olikraus/U8glib_Arduino
> 
> Without that library, the graphic stuff won't build.
> 
> EDIT: Ah. Just saw your comment that came in while I was typing.





> Hi
> 
> Start from a scratch compile, undefine their default display and define the graphics controller. Unless there is a very new bug, it should compile. 
> 
> Bob


I got it working! I found a typo in the following section:

"#define PREHEAT_1_TEMP_HOTEND 180
#define PREHEAT_1_TEMP_BED     70
#define PREHEAT_1_FAN_SPEED     0"

So when it was trying to compile it couldn't match those values with another .h file. All is fixed for now. Thank you!

----------


## uncle_bob

Glad it's working !!!

----------


## Roxy

> I apologize for all the questions, but I do appreciate your knowledge and time.
> 
> This morning I started modifying the RC Bug Fix and then I read this comment. In the future I am planning on using the BL touch to implement ABL/Mesh Leveling. if I understand your comment correctly, with RC Bug Fix it won't save the Mesh but will run at the start of every print to create that mesh. Is this correct?
> 
> I just want to ensure whatever firmware I use I will be setup for success with my planned upgrades.


Yes...  Your understanding is correct.   And incidentally, the BL-Touch stuff was added after UBL forked from RC-7.   So you can use a BL-Touch with UBL, but you have to set it up as manually instead of just saying you have a BL-Touch probe.   I'm off skiing in Taos.   As soon as I get back I'm going to be doing a 3-way merge to get UBL running on top of RC-8.  At that point, the simple BL-Touch support will be in UBL also.  Realistically, it will be a week or two into January before that happens.

But if you are going to do Mesh Bed Leveling...   You really should consider bringing up the UBL system.  You will get 100% adhesion across the entire bed every time.

----------


## techinout

I use Sketchup pro to design my models and I just export the STL file into simplifying 3D and boom chicken soup I can create 2 color prints any shape I want really easy if you're interested I have included a link to YouTube showing the process     https://youtu.be/TXpJW1RhCA4

----------


## uncle_bob

> I use Sketchup pro to design my models and I just export the STL file into simplifying 3D and boom chicken soup I can create 2 color prints any shape I want really easy if you're interested I have included a link to YouTube showing the process     https://youtu.be/TXpJW1RhCA4


Hi

The problems come when you have multiple colors (say 4) and they are all present on a layer (think Rubix cube). Unlike simple color change past this layer stuff, that sort of thing is not easily handled at several levels in our existing tool chains. Brewing up 4 interlocking STL's and getting them all set up is the way it's done. Not a lot of fun ....

Bob

----------

