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

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

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

[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

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