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!
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.
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.
| board | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Arduino AVR | ATmega, ATTiny, etc. | 16-20MHz | 64-256k | 2-16k | 5V | no |
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Arduino Due, RAMPS-FD, etc. | SAM3X8E ARM-Cortex M3 | 84MHz | 512k | 64+32k | 3.3V | no |
| board | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| ESP32 | Tensilica Xtensa LX6 | 160-240MHz variants | --- | --- | 3.3V | --- |
| 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 |
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Adafruit Grand Central M4 | SAMD51P20A ARM-Cortex M4 | 120MHz | 1M | 256k | 3.3V | yes |
| 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 |
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| STEVAL-3DP001V1 | STM32F401VE Arm-Cortex M4 | 84MHz | 512k | 64+32k | 3.3-5V | yes |
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy++ 2.0 | AT90USB1286 | 16MHz | 128k | 8k | 5V | no |
| boards | processor | speed | flash | sram | logic | fpu |
|---|---|---|---|---|---|---|
| Teensy 3.2 | MK20DX256VLH7 ARM-Cortex M4 | 72MHz | 256k | 32k | 3.3V-5V | yes |
| 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 |
| 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 |
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/testsand 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-localormake tests-single-local TEST_TARGET=.... - If you prefer Docker you can use
make tests-all-local-dockerormake 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.