7188ce0ad6
Why double touch probing is not a good thing. It's widely believed we can get better __probing__ results when using a double touch when probing. Let's compare to double touch __homing__. Or better let's begin with single touch __homing__. We home to find out out position, so our position is unknown. To find the endstop we have to move into the direction of the endstop. The maximum way we have to move is a bit longer than the axis length. When we arrive at the endstop - when it triggers, the stepper pulses are stopped immediately. It's a sudden stop. No smooth deacceleration is possible. Depending on the speed and the moving mass we lose steps here. Only if we approached slow enough (below jerk speed?) we will not lose steps. Moving a complete axis length, that slow, takes for ever. To speed up homing, we now make the first approach faster, get a guess about our position, back up a bit and make a second slower approach to get a exact result without losing steps. What we do in double touch probing is the same. But the difference here is: a. we already know where we are b. if the first approach is to fast we will lose steps here to. But this time there is no second approach to set the position to 0. We are measuring only. The lost steps are permanent until we home the next time. So if you experienced permanently rising values in M48 you now know why. (Too fast, suddenly stopped, first approach) What can we do to improve probing? We can use the information about our current position. We can make a really fast, but deaccelerated, move to a place we know it is a bit before the trigger point. And then move the rest of the way really slow. |
||
|---|---|---|
| buildroot | ||
| Marlin | ||
| .gitignore | ||
| .travis.yml | ||
| LICENSE | ||
| README.md | ||
Marlin 3D Printer Firmware
Additional documentation can be found in The Marlin Wiki. Please test this firmware and inform us if it misbehaves in any way, volunteers are standing by!
Release Candidate -- Marlin 1.1.0-RCBugFix - 27 April 2016
Not for production use – use with caution!
You can download earlier versions of Marlin on the Releases page. (The latest "stable" release of Marlin is 1.0.2-1.)
You'll always find the latest Release Candidate in the "RC" branch. Bugs that we find in the current Release Candidate are patched in the "RCBugFix" branch, so during beta testing this is where you can always find the latest code on its way towards release.
Future development (Marlin 1.2 and beyond) takes place in the MarlinDev repository.
Recent Changes
-
RCBugFix
-
RC6 - 24 Apr 2016
- Completed support for CoreXY / CoreXZ in planner
- Changes to positioning behavior
- Various issues fixed. More details pending.
- Throw error if compiling with older versions (<1.60) of Arduino due to serious problems with outdated Arduino versions
- Please upgrade your IDE at least to Arduino 1.6.0. Thanks.
-
RC5 - 01 Apr 2016
- Warn if compiling with older versions (<1.50) of Arduino
- Fix various LCD menu issues
- Add formal support for MKSv1.3 and Sainsmart (RAMPS variants)
- Fix bugs in M104, M109, and M190
- Fix broken M404 command
- Fix issues with M23 and "Start SD Print"
- More output for M111
- Rename FILAMENT_SENSOR to FILAMENT_WIDTH_SENSOR
- Fix SD card bugs
- and a lot more
- see https://github.com/MarlinFirmware/Marlin/releases/tag/1.1.0-RC5 for details
-
RC4 - 24 Mar 2016
- Many lingering bugs and nagging issues addressed
- Improvements to LCD menus, CoreXY/CoreXZ, Delta, Bed Leveling, and more…
-
RC3 - 01 Dec 2015
- A number of language sensitive strings have been revised
- Formatting of the LCD display has been improved to handle negative coordinates better
- Various compiler-related issues have been corrected
-
RC2 - 29 Sep 2015
- File styling reverted
- LCD update frequency reduced
-
RC1 - 19 Sep 2015
- Published for testing
Submitting Patches
Proposed patches should be submitted as a Pull Request against the RCBugFix branch.
- Don't submit new feature proposals. The RCBugFix branch is for fixing bugs in existing features.
- Do submit questions and concerns. The "naive" question is often the one we forget to ask.
- Follow the proper coding style. Pull requests with styling errors will be delayed. See our Coding Standards page for more information.
RepRap.org Wiki Page
Credits
The current Marlin dev team consists of:
- Scott Lahteine [@thinkyhead] - English
- [@Wurstnase] - Deutsch, English
- F. Malpartida [@fmalpartida] - English, Spanish
- Jochen Groppe [@CONSULitAS] - Deutsch, English
- [@maverikou]
- Chris Palmer [@nophead]
- [@paclema]
- Edward Patel [@epatel] - Swedish, English
- Erik van der Zalm [@ErikZalm]
- David Braam [@daid]
- Bernhard Kubicek [@bkubicek]
- Roxanne Neufeld [@Roxy-3DPrintBoard] - English
More features have been added by:
- Alberto Cotronei [@MagoKimbra]
- Lampmaker,
- Bradley Feldman,
- and others...
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.