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

[Roxy]

That seems like the more elegant solution as it would work for all cases vs just adding more code per style of printer

Yes... But the down side is there are 2 different routines that would have to have the same code added. Not a big deal. But both the Store and Retrieve would have to be a matched pair. I'll try to post an updated file later today so Dacb can add it to his fork if he decides to.

[sniffle]

i think you could make it a single code check, using an array for the types of printers to check, and a small loop to check each of those versions, and make the change if it is said version. since it is only 3-4 styles that check would be executed pretty much instantaneously.

[bgct9a]

Nope. This confuses people all the time. If EEPROM is enabled, the settings last stored there are always loaded at Marlin startup. Like Roxy said, you can over-ride those by sending the printer an M502 (load from factory default, where "factory" is the baseline in flash memory along with the executable code). An M500 can be used any time you want to save all the current settings being used into EEPROM. Uploading new firmware from the Arduino IDE does not modify the contents of EEPROM.

Well that clears that up thanks!

[printbus]

With the new 12-inch printer from MakerFarm using RAMBO, there's more considerations in having one fork supporting all the MakerFarm printers. IMO, one fork is still the way to go, but I might suggest it's time to rethink how some of the constants in configuration.h are defined. Why not have #DEFINES for i3v_8, i3v_10, and i3v_12. The user uncomments the one that applies to them. An ifdef/elseif chain is then used to set things like motherboard type, bed size, smart panel type, and enable code support for digital stepper driver adjustment. First, it makes it easier for the user to specify the build for their printer - which printer do they have, and are they using ABL or not. Second, and possibly most importantly, it provides the foundation for details in things like ABL to be tweaked for RAMBO by doing an ifdef i3v_12.

[clough42]

With the new 12-inch printer from MakerFarm using RAMBO, there's more considerations in having one fork supporting all the MakerFarm printers. IMO, one fork is still the way to go, but I might suggest it's time to rethink how some of the constants in configuration.h are defined. Why not have #DEFINES for i3v_8, i3v_10, and i3v_12. The user uncomments the one that applies to them. An ifdef/elseif chain is then used to set things like motherboard type, bed size, smart panel type, and enable code support for digital stepper driver adjustment. First, it makes it easier for the user to specify the build for their printer - which printer do they have, and are they using ABL or not. Second, and possibly most importantly, it provides the foundation for details in things like ABL to be tweaked for RAMBO by doing an ifdef i3v_12.

It all depends on where this goes from here. Of you want to merge back to Marlin and stop maintaining the fork, you don't want more customization. If you want to support MakerFarm and keep doing it forever, then customizations are the way to go.

It's tough being downstream from an active project. Even though you've added your value and are done, you still have to work on it forever to keep it up to date.

[Roxy]

It all depends on where this goes from here. Of you want to merge back to Marlin and stop maintaining the fork, you don't want more customization. If you want to support MakerFarm and keep doing it forever, then customizations are the way to go.

Agreed! I would think the thing to do is merge it back into the main branch. And then as a secondary effort, add the support to make it easily customizable for the various flavors of MakerFarm. After all... In order to merge it back to the main branch, the MakerFarm stuff needs to be abstracted or turned off so it doesn't affect most people.

[sniffle]

adding in general profile support, to condense settings into a parsable string would be a way to abstract things out, but it would also be a huge undertaking considering how many printers and options it would entail adding

[printbus]

Who is taking on the merge? I don't recall any talk of it since Dec 8. Seems like ABL issues wants and needs are still forcing ongoing changes, so are we really ready for that? We're about to need something NOW for the people who want ABL on their 12-inch printers and associated firmware (er, configuration) tweaks. Roxy is about the only one who helps people out with ABL firmware - is she ready to deal with multiple people trying to hack their way through getting ABL running on the 12 inch printers?

Doesn't really matter to me - I was just offering a suggestion. Since I have no experience with it, I have no problem ignoring the threads from people begging for ABL help.

[dacb]

Great discussion.

I think the relevant points are all represented. A more MakerFarm dedicated fork could be streamlined for the MarkerFarm users and lower the barrier to getting new stuff going like ABL. However, this will inevetiably distance the fork from the Marlin trunk and make unification with upstream more difficult and time consuming.

I will say that my time is limited. Doing a large number of test prints before I commit changes is a fair amount of work but more importantly it takes a week or so.

I'd like to think about how we could make this less of my fork and more of our fork.

[Roxy]

Great discussion.

I think the relevant points are all represented. A more MakerFarm dedicated fork could be streamlined for the MarkerFarm users and lower the barrier to getting new stuff going like ABL. However, this will inevetiably distance the fork from the Marlin trunk and make unification with upstream more difficult and time consuming.

I will say that my time is limited. Doing a large number of test prints before I commit changes is a fair amount of work but more importantly it takes a week or so.

I'd like to think about how we could make this less of my fork and more of our fork.

I think the code is mature enough to be merged back into the main branch. It has a lot of people using it. I think the bigger problem is packaging it up and getting it into a form where it can be pushed back. A big part of my thinking is it simplifies continued support of Auto Bed Leveling to do this. The good stuff would be automatically included and at that point it is just a problem of getting it turned on and working on a person's machine.