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

[printbus]

IIRC, dacb took on the challenge of migrating ABL and the enhanced G29 code from uncontrolled baselines into a significantly more recent Marlin version than the MakerFarm distribution, adding in the right configuration parameters and the perplexing MakerFarm manipulation of the Type 6 thermistor data, and demonstrating the build would still work under a newer version of the Arduino IDE.

I wouldn't mind a recap of the MakerFarm specific parts we're talking about having to merge back in. Aren't we really only talking about configuration.h details like the combination of display type, bed size, etc.? The need for the revised Type 6 thermistor data table has been resolved by just specifying Type 1 thermistors instead. The code changes to ABL and enhanced G29 are generic, as I understand my monitoring from the ABL sidelines. Maybe there's a need to deal with pin mapping for the ABL servo, but I view that as being driven by using RAMPS, not for being a MakerFarm printer. Am I forgetting other changes?

Once we have the fork merged back into the main, we're still going to be left with people having to adapt configuration.h to work for them. I doubt there's ever going to be a way around that. For any of us that have done it, yes it's a pretty straightforward thing to do. But for most people new to Marlin and Arduino, the first time can be pretty overwhelming. Maybe at some point we can get by with a sticky that lists the settings needed for each of the common MakerFarm printers. The sticky could also be maintained to note what Marlin version has been demonstrated to work on different MakerFarm printer types (anticipating that RAMPS vs RAMBO and the graphics panel configurations may not always be tested by MakerFarm owners at the same time).

I still like the idea of a block of ifdefs for configuration.h where once you say you have like an i3v-8, it sets the lower level stuff up for you. That could be a block of text included in the sticky that gets pasted into configuration.h above the motherboard selection. Of course, by the time you explain how to do that and explain editing the type of MakerFarm printer you have, it's not much harder to just say here are the 3 or 4, or 8 or whatever settings that need to be set for that printer type. I don't like the idea have having different configuration.h files for people to use - that'd just lead to more configuration control work. What are the printers we'd address? i3, i3v-8, i3v-10, i3v-12? ABL and non-ABL and we're already at 8 files to maintain.

EDIT: Sorry about the long post - I just want to make sure we take care of the new people, who need the help the most. People who have been around a while will already know what to do, and will already likely be off doing their own thing anyway.

[Roxy]

IIRC, dacb took on the challenge of migrating ABL and the enhanced G29 people had in personal baselines into a significantly more recent Marlin baseline than the MakerFarm distribution, and demonstrating it would still work under a newer version of the Arduino IDE.

I wouldn't mind a recap of the MakerFarm specific parts. Aren't we really only talking about configuration.h details like the combination of display type, bed size, etc.? The code changes to ABL and enhanced G29 are generic, as I understand my monitoring from the ABL sidelines.

...

I still like the idea of a block of ifdefs for configuration.h where once you say you have like an i3v-8, it sets the lower level stuff up for you. That could be a block of text included in the sticky that gets pasted into configuration.h above the motherboard selection. Of course, by the time you explain how to do that and explain editing the type of MakerFarm printer you have....

I think the cleanest way to do this is define a new set of mother board types in Pins.h And then just put everything you need in the new sections(s). Pull up Pins.h and see how it is organized (and I'm using that word loosely!!!). It is just a monster list of different things, all turned on by the mother board type.

If we went that way... The only difference from what we want to merge back into the main branch of the tree would be the default mother board type. We would just leave that at what ever the normal default is. (It's 7 by default)

[beerdart]

Is there a way to use the stock frame mounted Z end-stop for auto home?

[clough42]

I just submitted a pull request for the default MakerFarm configuration. The code in the repository currently has the max endstops enabled, but with the pullups disabled. On the original MakerFarm electronics, there are of course no max endstops, so the inputs are just left floating.

This works most of the time, but occasionally, the G28 home doesn't complete properly.

I just built a second printer with cheap eBay electronics ($13 arduino, $10 RAMPS, $2 StepSticks), and it fails to home properly most of the time.

When the printer hits the endstop while homing, it's supposed to retract and hit it a second time to confirm the position. Sometimes, my printer was skipping this step. If the printer was already in contact with the end stop, sometimes it failed to home at all. I could hear the click of one microstep fromt the motor, and the code just dropped through the routine.

I think the firmware was reading that the max endstop had been hit. With the max endstops enabled, but the pullups disabled and the wires disconnected, I suspect it was reading ground noise from the motors and false-triggering.

Disabling the MAX endstops in Configuration.h fixed the problem.

[Roxy]

This just in from mwyrick: I haven't had time to check it out, but I think what he says and did is correct:

Y-Axis moving during Z Raise for Unsafe Home

Roxy,
I noticed you helping several people with the problem of the Y-Axis moving with the initial Z Raise during homing when Safe homing is not enabled. I have a fix for that that I have not seen in the code yet. I wanted to share it with you. It also fixes G28 finishing too high when doing a raising before retracting.

In Marlin_main.cpp in the homeaxis function, after

axis_is_at_home(axis);
destination[axis] = current_position[axis];
feedrate = 0.0;
endstops_hit_on_purpose();
axis_known_position[axis] = true;

I added: plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);

The problem was after current_position was set to zero, the planner position was not set and the delta for the move was too large by the amount of the commanded move final to find the switch, -2*home_retract_mm. With this change I can now issue just a G28 and have to current_position correct so I don't need to run G29 if I don't want to. Or run with Z_SAFE_HOME disabled.

- Michael

[AbuMaia]

I've added the new line to my Marlin, but I haven't flashed it to test yet.

[Roxy]

I've added the new line to my Marlin, but I haven't flashed it to test yet.

Please let us know what happens when you do. One more thought... Some of the 'Corrections' for where the nozzle is left might not make sense with this change. I haven't had time to go through things yet. I suggest you keep your finger on the Reset button when you tell it to print while it goes through the G28 and G29 process!

[AbuMaia]

Some of the 'Corrections' for where the nozzle is left might not make sense with this change.

Yes, I plan to walk back my own corrections for G28 after adding this new line. Still trying to decide if I want to download an updated Marlin or not, it's hard to figure out what's usable.

[Roxy]

Well... The Marlin code base is frozen right now... So this fork is pretty current. And those extra corrections mostly raised the nozzle a small amount. So I suspect this patch is going to help. Also, it isn't going to be hard to identify and pull out any extra raise of the nozzle if it bothers you! Other than I keep getting distracted (OpenJScad now!!!) it shouldn't be a big a deal to check out DACB's fork with this change. I just haven't done it yet.

[mwyrick]

Well... The Marlin code base is frozen right now... So this fork is pretty current. And those extra corrections mostly raised the nozzle a small amount. So I suspect this patch is going to help. Also, it isn't going to be hard to identify and pull out any extra raise of the nozzle if it bothers you! Other than I keep getting distracted (OpenJScad now!!!) it shouldn't be a big a deal to check out DACB's fork with this change. I just haven't done it yet.

I started with https://github.com/beckdac/Marlin.git from commit 6de51c0 and added the change.

What it did for me was after a G28 it was at the correct height and not 4mm too high like it was before the change. It also let me turn off Z_SAFE_HOME and the Y Axis would no longer move during the initial Z raise. Before the change it would move Y 10mm due to the home_retract_mm setting for Y set to 5mm.

I have printed by doing just a G28 after power up and it printed fine. I also printed doing a G28 then G29 and it printed fine.

I put in a pull request to the above version so the change can be grabbed from the request if needed. Hopefully it works for everyone and can get added in.