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

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.