mirror of https://github.com/MarlinFirmware/Marlin.git synced 2024-11-28 06:21:31 +00:00

History

AnHardt 7188ce0ad6 double bump probing as a feature 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.		2016-07-30 03:00:49 +02:00
..
DUAL	double bump probing as a feature	2016-07-30 03:00:49 +02:00
Configuration_adv.h	Unify config in a single include without nested includes	2016-07-25 23:04:19 -07:00
Configuration.h	double bump probing as a feature	2016-07-30 03:00:49 +02:00
README.md	Moves Felix's dual configuration to a folder	2016-05-20 00:49:16 +01:00

README.md

Felix 2.0/3.0 Configuration for Marlin Firmware

Bringing silky smooth prints to Felix.

Build HOWTO

Install the latest non-beta Arduino software IDE/toolset: http://www.arduino.cc/en/Main/Software
Download the Marlin firmware
- Latest developement version
- Stable version
In both cases use the "Download Zip" button on the right.

cd Marlin/Marlin
cp example_configurations/Felix/Configuration_adv.h .

The next step depends on your setup:

Single Extruder Configuration

cp example_configurations/Felix/Configuration.h .

Dual Extruder Configuration

cp example_configurations/Felix/DUAL/Configuration.h Configuration.h

Compile Firmware

Start the Arduino IDE.
Select Tools -> Board -> Arduino Mega 2560
Select the correct serial port in Tools -> Serial Port (usually /dev/ttyUSB0)
Open Marlin.pde or .ino
Click the Verify/Compile button

Flash Firmware

Connected directly via USB

Click the Upload button. If all goes well the firmware is uploading

Remote update

Find the latest Arduino build:

ls -altr /tmp/
drwxr-xr-x 5 chrono users 12288 Mar 3 21:41 build6072035599686630843.tmp

Copy the firmware to your printer host:

scp /tmp/build6072035599686630843.tmp/Marlin.cpp.hex a.b.c.d:/tmp/

Connect to your printer host via ssh, stop Octoprint or any other service that may block your USB device and make sure you have avrdude installed, then run:

avrdude -C/etc/avrdude.conf -v -v -v -patmega2560 -cwiring -P/dev/ttyUSB0 \
-b115200 -D -Uflash:w:/tmp/Marlin.cpp.hex:i

Acknowledgements

Mashed together and tested on https://apollo.open-resource.org/mission:resources:picoprint based on collaborative teamwork of @andrewsil1 and @thinkyhead.