Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

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

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

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.

Quote:

---

Originally Posted by printbus

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

---

Definitely.

Quote:

---

Originally Posted by 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.

---

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

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.

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

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.

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

Quote:

---

Originally Posted by 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.

---

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.

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

Quote:

---

Originally Posted by 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.

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


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

---

Quote:

---

Originally Posted by AbuMaia

...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)'.

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.

Quote:

---

Originally Posted by 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.

---

Quote:

---

Originally Posted by printbus

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.

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by printbus

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!

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

Quote:

---

Originally Posted by dacb

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

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.

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?

Quote:

---

Originally Posted by dacb

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

Quote:

---

Originally Posted by Roxy

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.

Quote:

---

Originally Posted by printbus

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

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.

Quote:

---

Originally Posted by clough42

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

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.

Quote:

---

Originally Posted by 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.

---

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

Sly20 said:

Quote:

---

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!

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:

Code:

---

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.

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

Code:

---

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

Code:

---

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

---

Quote:

---

Originally Posted by dacb

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

Code:

---

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

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.

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

Quote:

---

Originally Posted by 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

---

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 ?
  
  

Quote:

---

Originally Posted by dacb

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

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?

Quote:

---

Originally Posted by 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?

---

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?

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.

Quote:

---

Originally Posted by dacb

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.

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:
Attachment 2826

And the debug output:

Code:

---

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:

Code:

---

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

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?

Quote:

---

Originally Posted by Roxy

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

Quote:

---

Originally Posted by clough42

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

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.