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

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