Messy code, branches with a lack of guidelines and comments are killing Marlin!

Marlin no more exists as a single, readable, common branch!

Where shall I go now?

In a previous post, I described a tiny contribution I made to the 3D printer firmware Marlin. The deal was to help with the calibration of a Delta printer thanks to a manual Z-probe (calibration really is the drawback of Delta printers, due to their weird geometry as compared to easier cartesian X-Y bots like the usual printers). It was already painful for such a small, one-time improvement to the code source, and given the invested time, I tried to make it broader by implementing multi-line comments (and to learn about git by the way).
http://www.dailymotion.com/video/x2gp98t_hal-fixing-a-light-bulb_fun

This is how I feel when I want to code something in Marlin!

(Malcom in the Middle, fixing a light bulb)

So I worked in mainstream Marlin. My idea was that it could benefit to existing variants of Marlin as well, when they decide to get changes from the "official" parent. But it does not work so well in reality.

This experience unveiled another, deeper, issue related to the many Marlin variants, and I think it is due to the fundamental way github works, in addition to git own complexity. In my opinion, Marlin is just dying because of this, together with the limits of the Arduino platform.




In fact, shortly after my pull request was included, the basic support for Z-probes was removed from Marlin (the M700 - M702 gcode height probing commands were gone! -- I was there at the wrong time I guess).

May be it was changed in a way I could not find it anymore (I do not think so)... Or it was too experimental (since M7xx commands seem not to be well defined). Or someone removed it by mistake. Or it was considered too obsolete a procedure.

IMHO it is still straightforward to assess the height of three point by use of a removable push-button on a socket that is hand-placed below the nozzle at three points on the bed. Actually, I do not want to add complexity or to hack to my printer with retracting probes, nor to add weight to my head (even though there are interesting hacks of course).

Clever but complex retractable automatic Z-probe,

with multiple test points on a Delta (Johann Rocholl)

Anyhow here is the problem: unless I try and modify Marlin again so it stays compatible with my use of "discarded" G-code manual probing commands, I would have to change my hardware.

In my post you may have seen that any contribution to a project hosted on git hub requires a new branch to be created and a parent branch to be chosen.

This is where a bigger problem occurs in my opinion.

Down with Marlin (variants)?

First, do not get me wrong: Marlin is vital. Marlin was a huge step forward and it is still the most widely free and open source software for driving low cost 3D printers. I do use it on all of my three 3D printers.

But in my opinion, Marlin no more exists as a single, readable, common branch. And it may be doomed.

First, it is already bloated by so many different electronics and hardware setup that it is barely readable. It looks like Marlin death is slowly approaching because of the new hardware it tries to support further.

Then and thus, there are myriads of branches, including some that are alive and made by well-know pillars of 3D printing, such as Richard Horne (see this branch tweaked for his 3DR v2 Delta printer), or the older deltabot branch by Johann Rocholl (arguably a father of most Delta printers). Sure, Ultimaker sponsored Erik Zalm when he took over Sprinter. This gave evidence about the main branch, which is a beacon in the whole mess but which is not enough sadly.

Indeed, the main branch no more looks like a definitive reference for wilder children or hardware configurations. There are tons of variants, and I am not even speaking of older variations on older branches like Sprinter, nor the parallel rise of other firmware (which may be the only possible outcome in the long term). This really is not the fault of the tool, but it helps spreading the disease by not requiring developers to stick to correct guidelines (like, please: comments and minimal documentation on what to find where and why).

Even very knowledgeable people like Anthony Morris (aka ThantiK) ask for help about which Marlin variant to use for a specific hardware, and there is no clear answer. Or it sounds like "better make the hardware according to the firmware you chose".

I cannot make my mind either about the branch to use, which is live, which is stable, which I can trust, which I shall contribute to, which suits my need... And this is even more of a serious problem when features are dropped without notice from the main branch!

My options right now...

1) I would love to keep on using the mainline, and even to adapt my own needs or even my hardware so it reflects what Marlin supports nowadays (unhappy though). Since M700 are gone and I did not want to make my hardware more complex, I had to revert to manual M206 to set the offsets on the origins. But this is unbearable (I have to "send" the g-code with guessed values with an external software like pronterface: back to prehistory! I hate tethered printers).
I definitely could write some more software to fix my burden in main Marlin, but I am not sure I can be confident that Marlin will still be compatible with my hardware in a few releases, which kills my motivation to contribute to it (especially due to git + github tiring procedures imho). And would I like to spend half and hours and days of reviews to have my specific need included in next Marlin?

2) So I could just stop trying, and live on my own branch, as many do. Then I could try to contribute to mainline on regular occasions. It is probably the common strategy among many developers. But it is a pity as I would just create one more pseudo-active branch, and it would eventually divert so much from mainline with time that it will no more be possible to merge the two (as I do not intend to work a lot on it, not even to keep it up to date with the upstream). There are just so many dead branches of Marlin already on github that adding one is not wise.

3) Or I can use my own Marlin branch and stop worrying at all about other hardware and other branches. Trying to support all hardware in a single branch is cool, but time proved nonetheless that it resulted in many wild forks that defeated the intention!

4) Further, I could even get rid of all existing support for the hardware I do not own! I considered this nasty until I thought about how more productive I would be with a clean source to work with! There are just too many #defines in the existing configuration.h, for hundreds of variants of hardware, that it is unreadable and very tricky to submit anything safely back to the main branch anyway.

5) I could give other firmware a try, like Repetier. But it means dropping all help I could provide to the main community. And it does not solve another raising issue: the RAMPS electronic environment is so much limited by the tiny Arduino Mega that I consider it to be at the end of its life...

6) So... I may better forget about Marlin and Arduino alike! May be it is time to have a clean start with Smoothieware on my old but powerful R2C2 ARM board instead (32 bits, 100MHz). This would be a big change, but a larger environment and a faster CPU would give real room for real improvements. It could also be a chance to get rid of most of the mess at the source code.

The Arduino is dying as a 3D printer firmware controller. ARM is the future!

Switching to ARM is a good thing, and more people are considering the move to be the next major step in 3D printing (see Thomas Sanladerer's review of the Smoothieboard for example). It gives some air for improvements, and I hope it is well written as a new start. In my opinion, a recent firmware would benefit a lot by relying on an object-oriented paradigm and on hardware abstraction layers via compulsory interfaces, pure virtual methods, etc.

Most 3D printer firmware for ARM processors are still based on the original GRBL G-code interpreter, just like Marlin is. I will have to look at the source code of GRBL also, it seems ubiquitous! I did not look at the source code of any new firmware yet, but I sincerely hope they ensure that any subsequent software development does comply with real and safe standards, contrary to Marlin which is full of ugly tricks and unsafe shortcuts (OK, they might have been considered compulsory because of the limited power of the Arduino, the Arduino IDE, and the anarchy induced by github imho!).

And still, I find it hard to conclude I should better move to an ARM board! It requires some physical and hardware changes to my existing printer. My goal was only to try and improve the calibration procedure for my current Marlin / RAMPS setup. What a pity!

I just cannot make my mind... Someone should write a post with the different branches, their activity, state and compatibility.

(Uplate to make it clear that my rant is not against github really, but just a point of view on the state of Marlin - and I praise applaud the evelopers that have the energy to contribute to it regularly! )