-
So, why would you make it like that? Why not just connecting everything to the Fan1's mosfet key for example as everyone does?
-
Well because I think it's dumb to solder a PWM of the laser to the PWM of already occupied pin, while there's a whole one separate and free on the board - the PA8 pin of the Neopixel! And there's no need in soldering anything, just connect the dupont cable and go!
How to make everything work?
- Connect PA8 pin (you can find it on the pinout's picture of the board below) to the PWM of the laser VIA 150ohm CURRENT-LIMITING RESISTOR. There's a good chance burning the laser's driver in case you not doing it.
- Connect laser's ground to the motherboard's ground And then you have to change the configuration depending on what is connected to your board:
Configuration.h
-
Without BLTouch comment the #define BLTOUCH (and also, if you have the BLTouch - change the settings of the NOZZLE_TO_PROBE_OFFSET)
-
And change the Y_MIN_POS to 0/your value (mine is -30 with custom extruder), and Y_BED_SIZE to 235/your value
-
Calibrate the steps/mm of the extruder driver!!! By default it is usually well far from the needed values
How to use laser?
By default in this firmware, the #define DIRECT_PIN_CONTROL (and #define PINS_DEBUGGING) are uncommented, which means you can use M42 and M43 commands now.
- M42 P8 S[0-255] - sets directly laser's pin to the PWM value of S. DOES NOT TURN OFF by itself!!!
- M3 S[0-255] - sets the laser on and strikes the laser for LASER_SAFETY_TIMEOUT_MS miliseconds (default is 1000) and THEN TURNS OFF. If M3 works this way - then you've configured everything correctly.
Basic use
- G1 S[0-255] (generally S value is putten after all other values) - Sets laser on with S value for this G1 move, AND ALL OTHER G1 MOVES LATER. No need to specify S value every G1 move, the first one is sufficient.
- G0 S0 - I strongly recommend you to add S0 to the G0 commands in your postprocessor, because sometimes it does not put off the laser even with the G0 command. At least in my configuration
- G2/G3 seem to not work properly with Marlin, it just makes a straight line instead of a curve. Should not be a big deal - it seems that even Ultimaker Cura generally uses G1 commands creating a curve approximation.
So that's it! If you have troubles with this configuration - feel free to open an issue, where I can help you with your case. I think this configuration is usable for other lasers too, that's the matter of testing.
If you want to know how to generate gcode to this setup (and to, really, any other custom laser setup with Marlin) - feel free to check Wiki page of this repo!
Pinout SKR e3 mini V2
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.1 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.1.x release version. Periodically this branch will form the basis for the next minor 2.1.x release.
Download earlier versions of Marlin on the Releases page.
Before you can build Marlin for your machine you'll need a configuration for your specific hardware. Upon request, your vendor will be happy to provide you with the complete source code and configurations for your machine, but you'll need to get updated configuration files if you want to install a newer version of Marlin. Fortunately, Marlin users have contributed dozens of tested configurations to get you started. Visit the MarlinFirmware/Configurations repository to find the right configuration for your hardware.
To build and upload Marlin you will use one of these tools:
- The free Visual Studio Code using the Auto Build Marlin extension.
- The free Arduino IDE : See Building Marlin with Arduino
- You can also use VSCode with devcontainer : See Installing Marlin (VSCode devcontainer).
Marlin is optimized to build with the PlatformIO IDE extension for Visual Studio Code. You can still build Marlin with Arduino IDE, and we hope to improve the Arduino build experience, but at this time PlatformIO is the better choice.
We intend to continue supporting 8-bit AVR boards in perpetuity, maintaining a single codebase that can apply to all machines. We want casual hobbyists and tinkerers and owners of older machines to benefit from the community's innovations just as much as those with fancier machines. Plus, those old AVR-based machines are often the best for your testing and feedback!
Marlin includes an abstraction layer to provide a common API for all the platforms it targets. This allows Marlin code to address the details of motion and user interface tasks at the lowest and highest levels with no system overhead, tying all events directly to the hardware clock.
Every new HAL opens up a world of hardware. At this time we need HALs for RP2040 and the Duet3D family of boards. A HAL that wraps an RTOS is an interesting concept that could be explored. Did you know that Marlin includes a Simulator that can run on Windows, macOS, and Linux? Join the Discord to help move these sub-projects forward!
| Platform | MCU | Example Boards |
|---|---|---|
| Arduino AVR | ATmega | RAMPS, Melzi, RAMBo |
| Teensy++ 2.0 | AT90USB1286 | Printrboard |
| Arduino Due | SAM3X8E | RAMPS-FD, RADDS, RAMPS4DUE |
| ESP32 | ESP32 | FYSETC E4, E4d@BOX, MRR |
| LPC1768 | ARM® Cortex-M3 | MKS SBASE, Re-ARM, Selena Compact |
| LPC1769 | ARM® Cortex-M3 | Smoothieboard, Azteeg X5 mini, TH3D EZBoard |
| STM32F103 | ARM® Cortex-M3 | Malyan M200, GTM32 Pro, MKS Robin, BTT SKR Mini |
| STM32F401 | ARM® Cortex-M4 | ARMED, Rumba32, SKR Pro, Lerdge, FYSETC S6, Artillery Ruby |
| STM32F7x6 | ARM® Cortex-M7 | The Borg, RemRam V1 |
| STM32G0B1RET6 | ARM® Cortex-M0+ | BigTreeTech SKR mini E3 V3.0 |
| STM32H743xIT6 | ARM® Cortex-M7 | BigTreeTech SKR V3.0, SKR EZ V3.0, SKR SE BX V2.0/V3.0 |
| SAMD51P20A | ARM® Cortex-M4 | Adafruit Grand Central M4 |
| Teensy 3.5 | ARM® Cortex-M4 | |
| Teensy 3.6 | ARM® Cortex-M4 | |
| Teensy 4.0 | ARM® Cortex-M7 | |
| Teensy 4.1 | ARM® Cortex-M7 | |
| Linux Native | x86/ARM/etc. | Raspberry Pi |
The Issue Queue is reserved for Bug Reports and Feature Requests. Please use the following resources for help with configuration and troubleshooting:
- Marlin Documentation - Official Marlin documentation
- Marlin Discord - Discuss issues with Marlin users and developers
- Facebook Group "Marlin Firmware"
- RepRap.org Marlin Forum
- Facebook Group "Marlin Firmware for 3D Printers"
- Marlin Configuration on YouTube
You can contribute patches by submitting a Pull Request to the (bugfix-2.1.x) branch.
- We use branches named with a "bugfix" or "dev" prefix to fix bugs and integrate new features.
- Follow the Coding Standards to gain points with the maintainers.
- Please submit Feature Requests and Bug Reports to the Issue Queue. See above for user support.
- Whenever you add new features, be sure to add one or more build tests to
buildroot/tests. Any tests added to a PR will be run within that PR on GitHub servers as soon as they are pushed. To minimize iteration be sure to run your new tests locally, if possible.- Local build tests:
- All:
make tests-config-all-local - Single:
make tests-config-single-local TEST_TARGET=...
- All:
- Local build tests in Docker:
- All:
make tests-config-all-local-docker - Single:
make tests-config-all-local-docker TEST_TARGET=...
- All:
- To run all unit test suites:
- Using PIO:
platformio run -t test-marlin - Using Make:
make unit-test-all-local - Using Docker + make:
maker unit-test-all-local-docker
- Using PIO:
- To run a single unit test suite:
- Using PIO:
platformio run -t marlin_<test-suite-name> - Using make:
make unit-test-single-local TEST_TARGET=<test-suite-name> - Using Docker + make:
maker unit-test-single-local-docker TEST_TARGET=<test-suite-name>
- Using PIO:
- Local build tests:
- If your feature can be unit tested, add one or more unit tests. For more information see our documentation on Unit Tests.
Marlin is constantly improving thanks to a huge number of contributors from all over the world bringing their specialties and talents. Huge thanks are due to all the contributors who regularly patch up bugs, help direct traffic, and basically keep Marlin from falling apart. Marlin's continued existence would not be possible without them.
| Name | Role | Link | Donate |
|---|---|---|---|
| 🇺🇸 Scott Lahteine | Project Lead | [@thinkyhead] | 💸 Donate |
| 🇺🇸 Roxanne Neufeld | Admin | [@Roxy-3D] | |
| 🇺🇸 Keith Bennett | Admin | [@thisiskeithb] | 💸 Donate |
| 🇺🇸 Jason Smith | Admin | [@sjasonsmith] | |
| 🇧🇷 Victor Oliveira | Admin | [@rhapsodyv] | |
| 🇬🇧 Chris Pepper | Admin | [@p3p] | |
| 🇳🇿 Peter Ellens | Admin | [@ellensp] | 💸 Donate |
| 🇺🇸 Bob Kuhn | Admin | [@Bob-the-Kuhn] | |
| 🇳🇱 Erik van der Zalm | Founder | [@ErikZalm] |
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.