This fork was created with the intention of giving the best possible experience to E3V2 users. However, GitHub, flashing new firmware, etc. can all be quite daunting for new users. Pretty much everything you need to know is here on github, so here's a quick rundown of where to find what you need!

Just got here? Check out the wiki tab on GitHub for all the information you need to get started. It has current features, OctoPrint settings, how to flash new firmware, etc. All the major information about the firmware can be found on the wiki.

While you are welcome to compile the source yourself to get the most up to date features and fixes, there are structured releases for those who would rather stick to precompiled files. These can be found in the releases section of GitHub. Releases come out as needed, so make sure to check back every so often for new versions. The version number can be found in the info menu of the printer if you forget what release you last flashed.

The discussions tab is home to any and all questions regarding the firmware. If you have a question, use the search feature to check if it has been asked before. If not, feel free to open up a discussion of your own. Just try to be clear on what exactly you want to know and provide a "steps to reproduce" if you are asking about a specific problem.

If you are unsure of an issue and would like some community input, you can post about it in the GitHub discussions. Otherwise, if you believe you have found a bug in the firmware, create a new issue from the issues tab on GitHub. This creates an easy way to discuss and get to the root of any possible problems in an organized and formatted way. Make sure to provide a clear description of the problem and a "steps to reproduce" if applicable.

New feature ideas are always welcome and a great way to improve the firmware. There are three ways you can suggest a feature. If you have a general idea, but would like some community input on the feature, open up a discussion where everyone can chime in. If you have a concrete idea you think would benefit the firmware, you can create a feature request in the issus tab on GitHub. If you have a solid idea and have the ability to implement it yourself, implement it in your own fork and create a pull request to the main branch.

Additional documentation can be found at the Marlin Home Page. Please test this firmware and let us know if it misbehaves in any way. Volunteers are standing by!

Not for production use. Use with caution!

Marlin 2.0 takes this popular RepRap firmware to the next level by adding support for much faster 32-bit and ARM-based boards while improving support for 8-bit AVR boards. Read about Marlin's decision to use a "Hardware Abstraction Layer" below.

This branch is for patches to the latest 2.0.x release version. Periodically this branch will form the basis for the next minor 2.0.x release.

Download earlier versions of Marlin on the Releases page.

To build Marlin 2.0 you'll need Arduino IDE 1.8.8 or newer or PlatformIO. We've posted detailed instructions on Building Marlin with Arduino and Building Marlin with PlatformIO for ReArm (which applies well to other 32-bit boards).

Marlin 2.0 introduces a layer of abstraction so that all the existing high-level code can be built for 32-bit platforms while still retaining full 8-bit AVR compatibility. Retaining AVR compatibility and a single code-base is important to us, because we want to make sure that features and patches get as much testing and attention as possible, and that all platforms always benefit from the latest improvements.

Proposed patches should be submitted as a Pull Request against the (bugfix-2.0.x) branch.

• This branch is for fixing bugs and integrating any new features for the duration of the Marlin 2.0.x life-cycle.
• Follow the Coding Standards to gain points with the maintainers.
• Please submit Feature Requests and Bug Reports to the Issue Queue. Support resources are also listed there.
• Whenever you add new features, be sure to add tests to buildroot/tests and then run your tests locally, if possible.
  • It's optional: Running all the tests on Windows might take a long time, and they will run anyway on GitHub.
  • If you're running the tests on Linux (or on WSL with the code on a Linux volume) the speed is much faster.
  • You can use make tests-all-local or make tests-single-local TEST_TARGET=....
  • If you prefer Docker you can use make tests-all-local-docker or make tests-all-local-docker TEST_TARGET=....

The current Marlin dev team consists of:

• Scott Lahteine [@thinkyhead] - USA   Donate / Flattr:
• Roxanne Neufeld [@Roxy-3D] - USA
• Chris Pepper [@p3p] - UK
• Bob Kuhn [@Bob-the-Kuhn] - USA
• João Brazio [@jbrazio] - Portugal
• Erik van der Zalm [@ErikZalm] - Netherlands  

Marlin is published under the GPL license because we believe in open development. The GPL comes with both rights and obligations. Whether you use Marlin firmware as the driver for your open or closed-source product, you must keep Marlin open, and you must provide your compatible Marlin source code to end users upon request. The most straightforward way to comply with the Marlin license is to make a fork of Marlin on Github, perform your modifications, and direct users to your modified fork.

While we can't prevent the use of this code in products (3D printers, CNC, etc.) that are closed source or crippled by a patent, we would prefer that you choose another firmware or, better yet, make your own.