Marlin 3D Printer Firmware

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!

3D Print Mill Kinematics

Historically belt printers have interpreted the X Y Z parameters as referring to the positions of the XY gantry in its own plane, and the Z belt position in its own plane. As a result, extra processing has been required to produce G-code suitable for the scheme. In the past, this was also the case for SCARA and Delta printers. Slicers have started to fall in line with the de-facto standard, so the time is nigh to correct the kinematics.

There are two components to the problem:

• The slicer needs to produce G-code that aligns properly to the belt / gantry, but with supports as if the belt was the bottom of the model. However, the slicer has to rotate the solid model and generated support geometry together by the machine angle (e.g., 45°) before slicing 'as usual' in the Z plane.

• The firmware needs to know what Y coordinate corresponds to Z0 before it starts the print. The firmware unfortunately can't easily guess. The "height of the first layer" on this machine is semi-meaningless, because it's guaranteed to keep drawing lines on the belt at some regular height throughout the print, and babystepping might be a very regular need. We could guess by using the volume what the height is supposed to be off of the belt, and use that to tune the relationship between Y0 and Z0.

How is Y related to Z in the G-code and why is this important? All prints, even on a belt, will start with Z0 and then will continue with Z at the first layer height. Since a model may be sliced anywhere in the Y space, we need to know which Y position it "starts at" and seed the kinematics appropriately.

Anyway, the thing is.... Once the kinematics or workspace offset are seeded, the Y and Z axes need to be considered together before applying Core kinematics and conversion into steps. It gets a tiny bit tricky, but shouldn't be too impossible to follow. The formula is applied in the same location as the CoreXY stuff:

1. Convert Y and Z inputs into YB and C, where YB is the Y position of the XY gantry in its own plane.
2. Hand YB over to CoreXY kinematics where Y would normally go.
3. For babystepping of "the squish side" just allowing direct Y adjustment is enough. No other babystepping is needed.

The formula to convert for Y and Z into YB and C is... Notes! - Cartesion Y0 Z0 converts to YB0 C0. The "YB0 offset" is the adjustment made to the YB0 position, which will keep the squished side against the belt, even as the G-code Y position is going ever-downward, or ever-upward. Figure out which way is more correct. I assume Y goes downward. (Maybe both angular variants can be supported with extra G333 parameters. Why 333? Because the Belt of Orion...) - For simplicity the YB0 offset simply corresponds to the current Z position, so 'Z' can be taken as ruling over YB0. This could be expressed as a steps value which is adjusted whenever Z is changed, or it can simply be based on current C steps with a clever formula. - Note that when YB is at the machine native home point (0), it's as close to the belt as it can get (though, this could be usefully adjusted with a Y home offset) so it's at the minimum the Z layer height. - The YB position alone determines the height of the nozzle over the belt, hence the actual "squish level" on the belt side of the model. For these purposes it's better to think of this as "the belt side" rather than the bottom. - So, how much should the YB coordinate be messed with in relation to Z? - YB = Y - Z * sin(angle) ; C = Z * (1 / sin(angle)) - The ratio between Z motion and Belt motion is (1 / sin(angle)) => Hypot (YB) / Adjacent (Z) - For every +1mm that C moves, YB needs to be offset by -1.414mm. - For every +1.414mm that YB moves, C needs to be offset by -1mm. - Position Y0 Z10 is YB... C14.14

I suggest requiring a G-code that both enables correct Belt Cartesian Kinematics (BCK), but also sets the Y0/Z0 relationship at the same time. Assuming BCK is the default, the slicer could easily set this value with an existing command like G92 Y123.2. If BCK needs to be enabled, maybe a Y offset could be included.

Marlin 2.0 Bugfix Branch

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.

Building Marlin 2.0

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).

Hardware Abstraction Layer (HAL)

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.

Current HALs

AVR (8-bit)

board	processor	speed	flash	sram	logic	fpu
Arduino AVR	ATmega, ATTiny, etc.	16-20MHz	64-256k	2-16k	5V	no

DUE

boards	processor	speed	flash	sram	logic	fpu
Arduino Due, RAMPS-FD, etc.	SAM3X8E ARM-Cortex M3	84MHz	512k	64+32k	3.3V	no

ESP32

board	processor	speed	flash	sram	logic	fpu
ESP32	Tensilica Xtensa LX6	160-240MHz variants	---	---	3.3V	---

LPC1768 / LPC1769

boards	processor	speed	flash	sram	logic	fpu
Re-ARM	LPC1768 ARM-Cortex M3	100MHz	512k	32+16+16k	3.3-5V	no
MKS SBASE	LPC1768 ARM-Cortex M3	100MHz	512k	32+16+16k	3.3-5V	no
Selena Compact	LPC1768 ARM-Cortex M3	100MHz	512k	32+16+16k	3.3-5V	no
Azteeg X5 GT	LPC1769 ARM-Cortex M3	120MHz	512k	32+16+16k	3.3-5V	no
Smoothieboard	LPC1769 ARM-Cortex M3	120MHz	512k	64k	3.3-5V	no

SAMD51

boards	processor	speed	flash	sram	logic	fpu
Adafruit Grand Central M4	SAMD51P20A ARM-Cortex M4	120MHz	1M	256k	3.3V	yes

STM32F1

boards	processor	speed	flash	sram	logic	fpu
Arduino STM32	STM32F1 ARM-Cortex M3	72MHz	256-512k	48-64k	3.3V	no
Geeetech3D GTM32	STM32F1 ARM-Cortex M3	72MHz	256-512k	48-64k	3.3V	no

STM32F4

boards	processor	speed	flash	sram	logic	fpu
STEVAL-3DP001V1	STM32F401VE Arm-Cortex M4	84MHz	512k	64+32k	3.3-5V	yes

Teensy++ 2.0

boards	processor	speed	flash	sram	logic	fpu
Teensy++ 2.0	AT90USB1286	16MHz	128k	8k	5V	no

Teensy 3.1 / 3.2

boards	processor	speed	flash	sram	logic	fpu
Teensy 3.2	MK20DX256VLH7 ARM-Cortex M4	72MHz	256k	32k	3.3V-5V	yes

Teensy 3.5 / 3.6

boards	processor	speed	flash	sram	logic	fpu
Teensy 3.5	MK64FX512VMD12 ARM-Cortex M4	120MHz	512k	192k	3.3-5V	yes
Teensy 3.6	MK66FX1M0VMD18 ARM-Cortex M4	180MHz	1M	256k	3.3V	yes

Teensy 4.0 / 4.1

boards	processor	speed	flash	sram	logic	fpu
Teensy 4.0	IMXRT1062DVL6A ARM-Cortex M7	600MHz	1M	2M	3.3V	yes
Teensy 4.1	IMXRT1062DVJ6A ARM-Cortex M7	600MHz	1M	2M	3.3V	yes

Submitting Patches

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=....

RepRap.org Wiki Page

Credits

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  

License

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.