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

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