Homing & Leveling Bugs

[thinkyhead]

We've gotten rid of a lot of little bugs in homing and leveling lately, but the current Development code still has an obscure Z positioning problem with G29. So, I've narrowed down the current leveling issues to a small handful of recent changes, and rolled back the leveling code to around March 26 at the branch https://github.com/thinkyhead/Marlin/tree/before_delta_merge

The differences between that code and the current leveling / homing code are embodied in commit https://github.com/thinkyhead/Marlin/commit/3f0a990360d04a45c11ba6ebdfeff2b16d26bf34 One of the changes in this commit is almost certainly responsible for the current weird behavior.

So, I suggest starting with before_delta_merge to see if it behaves properly. Then we can try to determine which of those recent changes is responsible for any remaining problems.

Once these leveling bugs are squashed, we can close all these issues:

1507 #1833 #1844 #1894 #1701 #1730 #1731 #1737

[thinkyhead]

That code you pointed at is the 3 point bed leveling. Is that the only flavor that has a problem?

@Roxy-3DPrintBoard Both of the final set-leveling functions have the same closing code designed to get the "true position" based on the current position. The other one is here.

[thinkyhead]

only probing half the bed

@Sniffle It shouldn't do that on a delta if 0,0 is in the middle. Seeing that on a cartesian?

[Sniffle]

@thinkyhead I covered everything in the next post i made with the video of the ABL routine, along with my Marlin_main.cpp and Configuration.h.

It is an i3 variant, with a RAMBo board :-) it was the main dev branch with the ABL modified to match your "debug_z" height adjustment change (thus the reason why i linked my Marlin_main.cpp)… I'll test again next weekend. I have started a printing company, so I can't have the printer down during the week... but I will do test cases as best as I can over the weekend to get this resolved... the printer runs much better on the dev branch... but with ABL broken i can't use it…

I am with @Roxy-3DPrintBoard at this point ABL should be broken out into its own files, and broken down into less complex parts to help with maintaining it... a big part of the problem with the ABL code is trying to keep it all straight... being broken down will probably show bugs and logic errors more easily

[Roxy-3D]

I am with @Roxy-3DPrintBoard at this point abl should be broken out into its own files, and broken down into less complex parts to help with maintaining it... a big part of the problem with the ABL code is trying to keep it all straight... being broken down will probably show bugs and logic errors more easily

Plus... It will be clear who is having a problem. If only one particular configuration is having issues, it will be obvious where the bug is.

[thinkyhead]

only probing half the bed

covered everything in the next post i made with the video of the abl routine

Ah, cool. I thought you meant you had seen that before, in-general. Looking closer at the configs now…

[thinkyhead]

a big part of the problem with the ABL code is trying to keep it all straight... being broken down will probably show bugs and logic errors more easily

Breaking up Marlin_main.cpp is a good idea, but there needs to be some fundamental work done on encapsulation first. Just the simple act of moving gcode_G29 into a separate file opens up a whole can of worms.

[Sniffle]

I completely understand that its just something that big expansive routines that get very complex between varying styles of printers really needs to have done...

For both maintaining and understanding where bugs are coming from... I know you know this... If i had the time and c++ knowledge i would help more than being a weekend tester On May 24, 2015 9:43 PM, "Scott Lahteine" notifications@github.com wrote:

a big part of the problem with the ABL code is trying to keep it all straight... being broken down will probably show bugs and logic errors more easily

Breaking up Marlin_main.cpp is a good idea, but there needs to be some fundamental work done on encapsulation first. Just the simple act of moving gcode_G29 into a separate file opens up a whole can of worms.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2040#issuecomment-105098922 .

[Roxy-3D]

Breaking up Marlin_main.cpp is a good idea, but there needs to be some fundamental work done on encapsulation first. Just the simple act of moving gcode_G29 into a separate file opens up a whole can of worms.

I disagree. What I'm envisioning is the current G29 mess being replaced with a few #ifdef's that pull in the code from the appropriate module (file). Right now, we have 4 different flavors. We have 3-Point, n x n grid, mesh and delta. It would be much cleaner to have each do their own thing and be defined in their own file. That all can be done with no C++ or encapsulation.

Just stepping back and looking at this from a higher level, it seems clear the G29 problem is only going to get worse. Its been 18 months since the first version showed up and now we have 4 distinctly different flavors and all for valid reasons. I bet over the next 12 months we get another 2 or 3 flavors.

Putting each flavor into its own file insulates the rest of the Marlin code from the chaos. And it drastically simplifies the maintenance of each of the independent versions. And remember... There is an iterative Least Squares Fit algorithm that can save 10+ Kb of code space when the time comes. Once again, the way to implement that is as its own file with a set of #ifdef's to control which code base gets pulled in. That is independent of which G29 flavor is being used (with the exception of 3-Point which doesn't need it.)

[emartinez167]

I agree with doing away with the current mix and separate coding per machine type/method in individual files. Makes debugging/maintaining much easier. On Mon, 25 May 2015 at 11:02 Roxy-3DPrintBoard notifications@github.com wrote:

Breaking up Marlin_main.cpp is a good idea, but there needs to be some fundamental work done on encapsulation first. Just the simple act of moving gcode_G29 into a separate file opens up a whole can of worms.

I disagree. What I'm envisioning is the current G29 mess being replaced with a few #ifdef's that pull in the code from the appropriate module (file). Right now, we have 4 different flavors. We have 3-Point, n x n grid, mesh and delta. It would be much cleaner to have each do their own thing and be defined in their own file. That all can be done with no C++ or encapsulation.

Just stepping back and looking at this from a higher level, it seems clear the G29 problem is only going to get worse. Its been 18 months since the first version showed up and now we have 4 distinctly different flavors and all for valid reasons. I bet over the next 12 months we get another 2 or 3 flavors.

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2040#issuecomment-105106380 .

[thinkyhead]

the current G29 mess being replaced with a few #ifdef's that pull in the code from the appropriate module.

Please post a demo PR, or make a branch that accomplishes this. If it can be done in some more encapsulated way, that would be great. I found it to be a lot more work than initially expected and gave up.

[jsnbrgg]

Hello, I've been messing with this all weekend and this is my first try with Marlin because I wanted to use the auto bed leveling feature. I'm running a modified Da Vinci Printer 1.0 with a RAMBO 1.2d motherboard. Server and z-probe endstop are working ok but the bed leveling and homing are all messed up. I'm not sure if it is the way I configured it or if it's the software after reading these issue comments. Sooo.. Here's what's happening. With the Da Vinci the X and Y homing endstops are off the left of the bed when standing behind the printer. So any time I try to home it goes back there and drops the probe, which will miss the bed and cause a disaster if I'm not keeping finger on power switch. I have my x and y manual home endstop settings correct I think because if I home x and y and then tell it to go to x0 y0 then it will go to the edge of the bed, but it always screws up on the homing.. If I manually run x and y to the center of the bed it will home z. But then if I run the auto bed level it will drop the probe and run across the bed with the probe down (in the x direction) one trip and that's it. Never lifts the probe or does anything else.

I'll try and post supporting documentation in a few minutes.

Any help would be appreciated!

[jsnbrgg]

Here is my Configuration H settings:

Configuration.h

``` #ifndef CONFIGURATION_H #define CONFIGURATION_H #include "boards.h" //=========================================================================== //============================= Getting Started ============================= //=========================================================================== /* Here are some standard links for getting your machine calibrated: * http://reprap.org/wiki/Calibration * http://youtu.be/wAL9d7FgInk * http://calculator.josefprusa.cz * http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide * http://www.thingiverse.com/thing:5573 * https://sites.google.com/site/repraplogphase/calibration-of-your-reprap * http://www.thingiverse.com/thing:298812 */ // This configuration file contains the basic settings. // Advanced settings can be found in Configuration_adv.h // BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration //=========================================================================== //============================= DELTA Printer =============================== //=========================================================================== // For a Delta printer replace the configuration files with the files in the // example_configurations/delta directory. // //=========================================================================== //============================= SCARA Printer =============================== //=========================================================================== // For a Scara printer replace the configuration files with the files in the // example_configurations/SCARA directory. // // @section info // User-specified version info of this build to display in [Pronterface, etc] terminal window during // startup. Implementation of an idea by Prof Braino to inform user that any changes made to this // build by the user have been successfully uploaded into firmware. #define STRING_VERSION "1.0.3 dev" #define STRING_VERSION_CONFIG_H __DATE__ " " __TIME__ // build date and time #define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes. #define STRING_SPLASH_LINE1 "v" STRING_VERSION // will be shown during bootup in line 1 //#define STRING_SPLASH_LINE2 STRING_VERSION_CONFIG_H // will be shown during bootup in line2 // @section machine // SERIAL_PORT selects which serial port should be used for communication with the host. // This allows the connection of wireless adapters (for instance) to non-default port pins. // Serial port 0 is still used by the Arduino bootloader regardless of this setting. // :[0,1,2,3,4,5,6,7] #define SERIAL_PORT 0 // This determines the communication speed of the printer // :[2400,9600,19200,38400,57600,115200,250000] #define BAUDRATE 250000 // This enables the serial port associated to the Bluetooth interface //#define BTENABLED // Enable BT interface on AT90USB devices // The following define selects which electronics board you have. // Please choose the name from boards.h that matches your setup #ifndef MOTHERBOARD #define MOTHERBOARD BOARD_RAMBO #endif // Optional custom name for your RepStrap or other custom machine // Displayed in the LCD "Ready" message #define CUSTOM_MACHINE_NAME "3D Printer" // Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines) // You can use an online service to generate a random UUID. (eg http://www.uuidgenerator.net/version4) // #define MACHINE_UUID "00000000-0000-0000-0000-000000000000" // This defines the number of extruders // :[1,2,3,4] #define EXTRUDERS 1 // Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing). // The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder). // For the other hotends it is their distance from the extruder 0 hotend. //#define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis //#define EXTRUDER_OFFSET_Y {0.0, 5.00} // (in mm) for each extruder, offset of the hotend on the Y axis //// The following define selects which power supply you have. Please choose the one that matches your setup // 1 = ATX // 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC) // :{1:'ATX',2:'X-Box 360'} #define POWER_SUPPLY 1 // Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it. // #define PS_DEFAULT_OFF // @section temperature //=========================================================================== //============================= Thermal Settings ============================ //=========================================================================== // //--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table // //// Temperature sensor settings: // -2 is thermocouple with MAX6675 (only for sensor 0) // -1 is thermocouple with AD595 // 0 is not used // 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup) // 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup) // 3 is Mendel-parts thermistor (4.7k pullup) // 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !! // 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup) // 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup) // 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup) // 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup) // 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) // 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup) // 10 is 100k RS thermistor 198-961 (4.7k pullup) // 11 is 100k beta 3950 1% thermistor (4.7k pullup) // 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed) // 13 is 100k Hisens 3950 1% up to 300°C for hotend "Simple ONE " & "Hotend "All In ONE" // 20 is the PT100 circuit found in the Ultimainboard V2.x // 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950 // // 1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k // (but gives greater accuracy and more stable PID) // 51 is 100k thermistor - EPCOS (1k pullup) // 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup) // 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup) // // 1047 is Pt1000 with 4k7 pullup // 1010 is Pt1000 with 1k pullup (non standard) // 147 is Pt100 with 4k7 pullup // 110 is Pt100 with 1k pullup (non standard) // 998 and 999 are Dummy Tables. They will ALWAYS read 25°C or the temperature defined below. // Use it for Testing or Development purposes. NEVER for production machine. // #define DUMMY_THERMISTOR_998_VALUE 25 // #define DUMMY_THERMISTOR_999_VALUE 100 // :{ '0': "Not used", '4': "10k !! do not use for a hotend. Bad resolution at high temp. !!", '1': "100k / 4.7k - EPCOS", '51': "100k / 1k - EPCOS", '6': "100k / 4.7k EPCOS - Not as accurate as Table 1", '5': "100K / 4.7k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '7': "100k / 4.7k Honeywell 135-104LAG-J01", '71': "100k / 4.7k Honeywell 135-104LAF-J01", '8': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT", '9': "100k / 4.7k GE Sensing AL03006-58.2K-97-G1", '10': "100k / 4.7k RS 198-961", '11': "100k / 4.7k beta 3950 1%", '12': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT (calibrated for Makibox hot bed)", '13': "100k Hisens 3950 1% up to 300°C for hotend 'Simple ONE ' & hotend 'All In ONE'", '60': "100k Maker's Tool Works Kapton Bed Thermistor beta=3950", '55': "100k / 1k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '2': "200k / 4.7k - ATC Semitec 204GT-2", '52': "200k / 1k - ATC Semitec 204GT-2", '-2': "Thermocouple + MAX6675 (only for sensor 0)", '-1': "Thermocouple + AD595", '3': "Mendel-parts / 4.7k", '1047': "Pt1000 / 4.7k", '1010': "Pt1000 / 1k (non standard)", '20': "PT100 (Ultimainboard V2.x)", '147': "Pt100 / 4.7k", '110': "Pt100 / 1k (non-standard)", '998': "Dummy 1", '999': "Dummy 2" } #define TEMP_SENSOR_0 1 #define TEMP_SENSOR_1 0 #define TEMP_SENSOR_2 0 #define TEMP_SENSOR_3 0 #define TEMP_SENSOR_BED 1 // This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted. //#define TEMP_SENSOR_1_AS_REDUNDANT #define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10 // Actual temperature must be close to target for this long before M109 returns success #define TEMP_RESIDENCY_TIME 10 // (seconds) #define TEMP_HYSTERESIS 3 // (degC) range of +/- temperatures considered "close" to the target one #define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early. // The minimal temperature defines the temperature below which the heater will not be enabled It is used // to check that the wiring to the thermistor is not broken. // Otherwise this would lead to the heater being powered on all the time. #define HEATER_0_MINTEMP 5 #define HEATER_1_MINTEMP 5 #define HEATER_2_MINTEMP 5 #define HEATER_3_MINTEMP 5 #define BED_MINTEMP 5 // When temperature exceeds max temp, your heater will be switched off. // This feature exists to protect your hotend from overheating accidentally, but *NOT* from thermistor short/failure! // You should use MINTEMP for thermistor short/failure protection. #define HEATER_0_MAXTEMP 245 #define HEATER_1_MAXTEMP 245 #define HEATER_2_MAXTEMP 245 #define HEATER_3_MAXTEMP 245 #define BED_MAXTEMP 112 // If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the // average current. The value should be an integer and the heat bed will be turned on for 1 interval of // HEATER_BED_DUTY_CYCLE_DIVIDER intervals. //#define HEATER_BED_DUTY_CYCLE_DIVIDER 4 // If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS //#define EXTRUDER_WATTS (12.0*12.0/6.7) // P=I^2/R //#define BED_WATTS (12.0*12.0/1.1) // P=I^2/R //=========================================================================== //============================= PID Settings ================================ //=========================================================================== // PID Tuning Guide here: http://reprap.org/wiki/PID_Tuning // Comment the following line to disable PID and enable bang-bang. #define PIDTEMP #define BANG_MAX 255 // limits current to nozzle while in bang-bang mode; 255=full current #define PID_MAX BANG_MAX // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current #ifdef PIDTEMP //#define PID_DEBUG // Sends debug data to the serial port. //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX //#define SLOW_PWM_HEATERS // PWM with very low frequency (roughly 0.125Hz=8s) and minimum state time of approximately 1s useful for heaters driven by a relay //#define PID_PARAMS_PER_EXTRUDER // Uses separate PID parameters for each extruder (useful for mismatched extruders) // Set/get with gcode: M301 E[extruder number, 0-2] #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max. #define PID_INTEGRAL_DRIVE_MAX PID_MAX //limit for the integral term #define K1 0.95 //smoothing factor within the PID // If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it // Ultimaker #define DEFAULT_Kp 22.2 #define DEFAULT_Ki 1.08 #define DEFAULT_Kd 114 // MakerGear // #define DEFAULT_Kp 7.0 // #define DEFAULT_Ki 0.1 // #define DEFAULT_Kd 12 // Mendel Parts V9 on 12V // #define DEFAULT_Kp 63.0 // #define DEFAULT_Ki 2.25 // #define DEFAULT_Kd 440 #endif // PIDTEMP //=========================================================================== //============================= PID > Bed Temperature Control =============== //=========================================================================== // Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis // // Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder. // If your PID_dT is the default, and correct for your hardware/configuration, that means 7.689Hz, // which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating. // This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater. // If your configuration is significantly different than this and you don't understand the issues involved, you probably // shouldn't use bed PID until someone else verifies your hardware works. // If this is enabled, find your own PID constants below. //#define PIDTEMPBED // //#define BED_LIMIT_SWITCHING // This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option. // all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis) // setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did, // so you shouldn't use it unless you are OK with PWM on your bed. (see the comment on enabling PIDTEMPBED) #define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current //#define PID_BED_DEBUG // Sends debug data to the serial port. #ifdef PIDTEMPBED //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10) #define DEFAULT_bedKp 10.00 #define DEFAULT_bedKi .023 #define DEFAULT_bedKd 305.4 //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from pidautotune // #define DEFAULT_bedKp 97.1 // #define DEFAULT_bedKi 1.41 // #define DEFAULT_bedKd 1675.16 // FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles. #endif // PIDTEMPBED // @section extruder //this prevents dangerous Extruder moves, i.e. if the temperature is under the limit //can be software-disabled for whatever purposes by #define PREVENT_DANGEROUS_EXTRUDE //if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately. #define PREVENT_LENGTHY_EXTRUDE #define EXTRUDE_MINTEMP 170 #define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances. //=========================================================================== //======================== Thermal Runaway Protection ======================= //=========================================================================== /** * Thermal Runaway Protection protects your printer from damage and fire if a * thermistor falls out or temperature sensors fail in any way. * * The issue: If a thermistor falls out or a temperature sensor fails, * Marlin can no longer sense the actual temperature. Since a disconnected * thermistor reads as a low temperature, the firmware will keep the heater on. * * The solution: Once the temperature reaches the target, start observing. * If the temperature stays too far below the target (hysteresis) for too long, * the firmware will halt as a safety precaution. */ #define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders #define THERMAL_PROTECTION_BED // Enable thermal protection for the heated bed //=========================================================================== //============================= Mechanical Settings ========================= //=========================================================================== // @section machine // Uncomment this option to enable CoreXY kinematics // #define COREXY // Enable this option for Toshiba steppers // #define CONFIG_STEPPERS_TOSHIBA // @section homing // coarse Endstop Settings #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors #ifndef ENDSTOPPULLUPS // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined // #define ENDSTOPPULLUP_XMAX // #define ENDSTOPPULLUP_YMAX // #define ENDSTOPPULLUP_ZMAX #define ENDSTOPPULLUP_XMIN #define ENDSTOPPULLUP_YMIN #define ENDSTOPPULLUP_ZMIN #define ENDSTOPPULLUP_ZPROBE #endif // Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup). const bool X_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Y_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_PROBE_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. //#define DISABLE_MAX_ENDSTOPS //#define DISABLE_MIN_ENDSTOPS // @section machine // If you want to enable the Z Probe pin, but disable its use, uncomment the line below. // This only affects a Z Probe Endstop if you have separate Z min endstop as well and have // activated Z_PROBE_ENDSTOP below. If you are using the Z Min endstop on your Z Probe, // this has no effect. //#define DISABLE_Z_PROBE_ENDSTOP // For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1 // :{0:'Low',1:'High'} #define X_ENABLE_ON 0 #define Y_ENABLE_ON 0 #define Z_ENABLE_ON 0 #define E_ENABLE_ON 0 // For all extruders // Disables axis when it's not being used. // WARNING: When motors turn off there is a chance of losing position accuracy! #define DISABLE_X false #define DISABLE_Y false #define DISABLE_Z false // @section extruder #define DISABLE_E false // For all extruders #define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled // @section machine // Invert the stepper direction. Change (or reverse the motor connector) if an axis goes the wrong way. #define INVERT_X_DIR false #define INVERT_Y_DIR true #define INVERT_Z_DIR false // @section extruder // For direct drive extruder v9 set to true, for geared extruder set to false. #define INVERT_E0_DIR false #define INVERT_E1_DIR false #define INVERT_E2_DIR false #define INVERT_E3_DIR false // @section homing // ENDSTOP SETTINGS: // Sets direction of endstops when homing; 1=MAX, -1=MIN // :[-1,1] #define X_HOME_DIR -1 #define Y_HOME_DIR -1 #define Z_HOME_DIR -1 #define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS. #define max_software_endstops false // If true, axis won't move to coordinates greater than the defined lengths below. // @section machine // Travel limits after homing (units are in mm) #define X_MIN_POS 0 #define Y_MIN_POS 0 #define Z_MIN_POS 0 #define X_MAX_POS 200 #define Y_MAX_POS 200 #define Z_MAX_POS 200 //=========================================================================== //========================= Filament Runout Sensor ========================== //=========================================================================== //#define FILAMENT_RUNOUT_SENSOR // Uncomment for defining a filament runout sensor such as a mechanical or opto endstop to check the existence of filament // In RAMPS uses servo pin 2. Can be changed in pins file. For other boards pin definition should be made. // It is assumed that when logic high = filament available // when logic low = filament ran out #ifdef FILAMENT_RUNOUT_SENSOR const bool FIL_RUNOUT_INVERTING = true; // Should be uncommented and true or false should assigned #define ENDSTOPPULLUP_FIL_RUNOUT // Uncomment to use internal pullup for filament runout pins if the sensor is defined. #define FILAMENT_RUNOUT_SCRIPT "M600" #endif //=========================================================================== //=========================== Manual Bed Leveling =========================== //=========================================================================== // #define MANUAL_BED_LEVELING // Add display menu option for bed leveling // #define MESH_BED_LEVELING // Enable mesh bed leveling #ifdef MANUAL_BED_LEVELING #define MBL_Z_STEP 0.025 // Step size while manually probing Z axis #endif // MANUAL_BED_LEVELING #ifdef MESH_BED_LEVELING #define MESH_MIN_X 10 #define MESH_MAX_X (X_MAX_POS - MESH_MIN_X) #define MESH_MIN_Y 10 #define MESH_MAX_Y (Y_MAX_POS - MESH_MIN_Y) #define MESH_NUM_X_POINTS 3 // Don't use more than 7 points per axis, implementation limited #define MESH_NUM_Y_POINTS 3 #define MESH_HOME_SEARCH_Z 4 // Z after Home, bed somewhere below but above 0.0 #endif // MESH_BED_LEVELING //=========================================================================== //============================ Bed Auto Leveling ============================ //=========================================================================== // @section bedlevel #define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line) #define Z_PROBE_REPEATABILITY_TEST // If not commented out, Z-Probe Repeatability test will be included if Auto Bed Leveling is Enabled. #ifdef ENABLE_AUTO_BED_LEVELING // There are 2 different ways to specify probing locations // // - "grid" mode // Probe several points in a rectangular grid. // You specify the rectangle and the density of sample points. // This mode is preferred because there are more measurements. // // - "3-point" mode // Probe 3 arbitrary points on the bed (that aren't colinear) // You specify the XY coordinates of all 3 points. // Enable this to sample the bed in a grid (least squares solution) // Note: this feature generates 10KB extra code size #define AUTO_BED_LEVELING_GRID #ifdef AUTO_BED_LEVELING_GRID #define LEFT_PROBE_BED_POSITION 30 #define RIGHT_PROBE_BED_POSITION 195 #define FRONT_PROBE_BED_POSITION 5 #define BACK_PROBE_BED_POSITION 145 #define MIN_PROBE_EDGE 10 // The probe square sides can be no smaller than this // Set the number of grid points per dimension // You probably don't need more than 3 (squared=9) #define AUTO_BED_LEVELING_GRID_POINTS 2 #else // !AUTO_BED_LEVELING_GRID // Arbitrary points to probe. A simple cross-product // is used to estimate the plane of the bed. #define ABL_PROBE_PT_1_X 15 #define ABL_PROBE_PT_1_Y 180 #define ABL_PROBE_PT_2_X 15 #define ABL_PROBE_PT_2_Y 20 #define ABL_PROBE_PT_3_X 170 #define ABL_PROBE_PT_3_Y 20 #endif // AUTO_BED_LEVELING_GRID // Offsets to the probe relative to the extruder tip (Hotend - Probe) // X and Y offsets must be integers #define X_PROBE_OFFSET_FROM_EXTRUDER 26 // Probe on: -left +right #define Y_PROBE_OFFSET_FROM_EXTRUDER -51 // Probe on: -front +behind #define Z_PROBE_OFFSET_FROM_EXTRUDER -2.3 // -below (always!) #define Z_RAISE_BEFORE_HOMING 4 // (in mm) Raise Z before homing (G28) for Probe Clearance. // Be sure you have this distance over your Z_MAX_POS in case #define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min #define Z_RAISE_BEFORE_PROBING 15 //How much the extruder will be raised before traveling to the first probing point. #define Z_RAISE_BETWEEN_PROBINGS 5 //How much the extruder will be raised when traveling from between next probing points #define Z_RAISE_AFTER_PROBING 0 //How much the extruder will be raised after the last probing point. // #define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10" //These commands will be executed in the end of G29 routine. //Useful to retract a deployable probe. //#define Z_PROBE_SLED // turn on if you have a z-probe mounted on a sled like those designed by Charles Bell //#define SLED_DOCKING_OFFSET 5 // the extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like. //If defined, the Probe servo will be turned on only during movement and then turned off to avoid jerk //The value is the delay to turn the servo off after powered on - depends on the servo speed; 300ms is good value, but you can try lower it. // You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile. #define PROBE_SERVO_DEACTIVATION_DELAY 300 //If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing, //it is highly recommended you let this Z_SAFE_HOMING enabled!!! #define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area. // When defined, it will: // - Allow Z homing only after X and Y homing AND stepper drivers still enabled // - If stepper drivers timeout, it will need X and Y homing again before Z homing // - Position the probe in a defined XY point before Z Homing when homing all axis (G28) // - Block Z homing only when the probe is outside bed area. #ifdef Z_SAFE_HOMING #define Z_SAFE_HOMING_X_POINT 100 // X point for Z homing when homing all axis (G28) #define Z_SAFE_HOMING_Y_POINT 100 // Y point for Z homing when homing all axis (G28) #endif // Support for a dedicated Z PROBE endstop separate from the Z MIN endstop. // If you would like to use both a Z PROBE and a Z MIN endstop together or just a Z PROBE with a custom pin, uncomment #define Z_PROBE_ENDSTOP and read the instructions below. // If you want to still use the Z min endstop for homing, disable Z_SAFE_HOMING above. Eg; to park the head outside the bed area when homing with G28. // WARNING: The Z MIN endstop will need to set properly as it would without a Z PROBE to prevent head crashes and premature stopping during a print. // To use a separate Z PROBE endstop, you must have a Z_PROBE_PIN defined in the pins.h file for your control board. // If you are using a servo based Z PROBE, you will need to enable NUM_SERVOS, SERVO_ENDSTOPS and SERVO_ENDSTOPS_ANGLES in the R/C Servo below. // RAMPS 1.3/1.4 boards may be able to use the 5V, Ground and the D32 pin in the Aux 4 section of the RAMPS board. Use 5V for powered sensors, otherwise connect to ground and D32 // for normally closed configuration and 5V and D32 for normally open configurations. Normally closed configuration is advised and assumed. // The D32 pin in Aux 4 on RAMPS maps to the Arduino D32 pin. Z_PROBE_PIN is setting the pin to use on the Arduino. Since the D32 pin on the RAMPS maps to D32 on Arduino, this works. // D32 is currently selected in the RAMPS 1.3/1.4 pin file. All other boards will need changes to the respective pins_XXXXX.h file. // WARNING: Setting the wrong pin may have unexpected and potentially disastrous outcomes. Use with caution and do your homework. //#define Z_PROBE_ENDSTOP #endif // ENABLE_AUTO_BED_LEVELING // @section homing // The position of the homing switches #define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used //#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0) // Manual homing switch locations: // For deltabots this means top and center of the Cartesian print volume. #ifdef MANUAL_HOME_POSITIONS #define MANUAL_X_HOME_POS -40 #define MANUAL_Y_HOME_POS 0 #define MANUAL_Z_HOME_POS 0 //#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing. #endif // @section movement /** * MOVEMENT SETTINGS */ #define HOMING_FEEDRATE {50*60, 50*60, 4*60, 0} // set the homing speeds (mm/min) // default settings #define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,2560,100} // default steps per unit for Ultimaker #define DEFAULT_MAX_FEEDRATE {300, 300, 5, 25} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {3000,3000,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. #define DEFAULT_ACCELERATION 3000 // X, Y, Z and E acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 3000 // E acceleration in mm/s^2 for retracts #define DEFAULT_TRAVEL_ACCELERATION 3000 // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves // The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously) #define DEFAULT_XYJERK 15.0 // (mm/sec) #define DEFAULT_ZJERK 0.4 // (mm/sec) #define DEFAULT_EJERK 5.0 // (mm/sec) //============================================================================= //============================= Additional Features =========================== //============================================================================= // @section more // Custom M code points #define CUSTOM_M_CODES #ifdef CUSTOM_M_CODES #ifdef ENABLE_AUTO_BED_LEVELING #define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851 #define Z_PROBE_OFFSET_RANGE_MIN -20 #define Z_PROBE_OFFSET_RANGE_MAX 20 #endif #endif // @section extras // EEPROM // The microcontroller can store settings in the EEPROM, e.g. max velocity... // M500 - stores parameters in EEPROM // M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily). // M502 - reverts to the default "factory settings". You still need to store them in EEPROM afterwards if you want to. //define this to enable EEPROM support //#define EEPROM_SETTINGS #ifdef EEPROM_SETTINGS // To disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out: #define EEPROM_CHITCHAT // Please keep turned on if you can. #endif // @section temperature // Preheat Constants #define PLA_PREHEAT_HOTEND_TEMP 180 #define PLA_PREHEAT_HPB_TEMP 70 #define PLA_PREHEAT_FAN_SPEED 0 // Insert Value between 0 and 255 #define ABS_PREHEAT_HOTEND_TEMP 240 #define ABS_PREHEAT_HPB_TEMP 110 #define ABS_PREHEAT_FAN_SPEED 0 // Insert Value between 0 and 255 //==============================LCD and SD support============================= // @section lcd // Define your display language below. Replace (en) with your language code and uncomment. // en, pl, fr, de, es, ru, bg, it, pt, pt-br, fi, an, nl, ca, eu, kana, kana_utf8, cn, test // See also language.h #define LANGUAGE_INCLUDE GENERATE_LANGUAGE_INCLUDE(en) // Choose ONE of these 3 charsets. This has to match your hardware. Ignored for full graphic display. // To find out what type you have - compile with (test) - upload - click to get the menu. You'll see two typical lines from the upper half of the charset. // See also documentation/LCDLanguageFont.md #define DISPLAY_CHARSET_HD44780_JAPAN // this is the most common hardware //#define DISPLAY_CHARSET_HD44780_WESTERN //#define DISPLAY_CHARSET_HD44780_CYRILLIC //#define ULTRA_LCD //general LCD support, also 16x2 //#define DOGLCD // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family) //#define SDSUPPORT // Enable SD Card Support in Hardware Console //#define SDSLOW // Use slower SD transfer mode (not normally needed - uncomment if you're getting volume init error) //#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication //#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder //#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking //#define ULTIMAKERCONTROLLER //as available from the Ultimaker online store. //#define ULTIPANEL //the UltiPanel as on Thingiverse //#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 // the duration the buzzer plays the UI feedback sound. ie Screen Click //#define LCD_FEEDBACK_FREQUENCY_HZ 1000 // this is the tone frequency the buzzer plays when on UI feedback. ie Screen Click // 0 to disable buzzer feedback. Test with M300 S P // PanelOne from T3P3 (via RAMPS 1.4 AUX2/AUX3) // http://reprap.org/wiki/PanelOne //#define PANEL_ONE // The MaKr3d Makr-Panel with graphic controller and SD support // http://reprap.org/wiki/MaKr3d_MaKrPanel //#define MAKRPANEL // The Panucatt Devices Viki 2.0 and mini Viki with Graphic LCD // http://panucatt.com // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib //#define VIKI2 //#define miniVIKI // This is a new controller currently under development. https://github.com/eboston/Adafruit-ST7565-Full-Graphic-Controller/ // // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib //#define ELB_FULL_GRAPHIC_CONTROLLER // The RepRapDiscount Smart Controller (white PCB) // http://reprap.org/wiki/RepRapDiscount_Smart_Controller //#define REPRAP_DISCOUNT_SMART_CONTROLLER // The GADGETS3D G3D LCD/SD Controller (blue PCB) // http://reprap.org/wiki/RAMPS_1.3/1.4_GADGETS3D_Shield_with_Panel //#define G3D_PANEL // The RepRapDiscount FULL GRAPHIC Smart Controller (quadratic white PCB) // http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller // // ==> REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER // The RepRapWorld REPRAPWORLD_KEYPAD v1.1 // http://reprapworld.com/?products_details&products_id=202&cPath=1591_1626 //#define REPRAPWORLD_KEYPAD //#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // how much should be moved when a key is pressed, eg 10.0 means 10mm per click // The Elefu RA Board Control Panel // http://www.elefu.com/index.php?route=product/product&product_id=53 // REMEMBER TO INSTALL LiquidCrystal_I2C.h in your ARDUINO library folder: https://github.com/kiyoshigawa/LiquidCrystal_I2C //#define RA_CONTROL_PANEL /** * I2C Panels */ //#define LCD_I2C_SAINSMART_YWROBOT // PANELOLU2 LCD with status LEDs, separate encoder and click inputs //#define LCD_I2C_PANELOLU2 // Panucatt VIKI LCD with status LEDs, integrated click & L/R/U/P buttons, separate encoder inputs //#define LCD_I2C_VIKI // Shift register panels // --------------------- // 2 wire Non-latching LCD SR from: // https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!shiftregister-connection //#define SAV_3DLCD // @section extras // Increase the FAN pwm frequency. Removes the PWM noise but increases heating in the FET/Arduino //#define FAST_PWM_FAN // Use software PWM to drive the fan, as for the heaters. This uses a very low frequency // which is not as annoying as with the hardware PWM. On the other hand, if this frequency // is too low, you should also increment SOFT_PWM_SCALE. //#define FAN_SOFT_PWM // Incrementing this by 1 will double the software PWM frequency, // affecting heaters, and the fan if FAN_SOFT_PWM is enabled. // However, control resolution will be halved for each increment; // at zero value, there are 128 effective control positions. #define SOFT_PWM_SCALE 0 // Temperature status LEDs that display the hotend and bet temperature. // If all hotends and bed temperature and temperature setpoint are < 54C then the BLUE led is on. // Otherwise the RED led is on. There is 1C hysteresis. //#define TEMP_STAT_LEDS // M240 Triggers a camera by emulating a Canon RC-1 Remote // Data from: http://www.doc-diy.net/photo/rc-1_hacked/ // #define PHOTOGRAPH_PIN 23 // SkeinForge sends the wrong arc g-codes when using Arc Point as fillet procedure //#define SF_ARC_FIX // Support for the BariCUDA Paste Extruder. //#define BARICUDA //define BlinkM/CyzRgb Support //#define BLINKM /*********************************************************************\ * R/C SERVO support * Sponsored by TrinityLabs, Reworked by codexmas **********************************************************************/ // Number of servos // // If you select a configuration below, this will receive a default value and does not need to be set manually // set it manually if you have more servos than extruders and wish to manually control some // leaving it undefined or defining as 0 will disable the servo subsystem // If unsure, leave commented / disabled // #define NUM_SERVOS 3 // Servo index starts with 0 for M280 command // Servo Endstops // // This allows for servo actuated endstops, primary usage is for the Z Axis to eliminate calibration or bed height changes. // Use M851 to set the z-probe vertical offset from the nozzle. Store that setting with M500. // #define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1 #define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 82,130} // X,Y,Z Axis Extend and Retract angles /**********************************************************************\ * Support for a filament diameter sensor * Also allows adjustment of diameter at print time (vs at slicing) * Single extruder only at this point (extruder 0) * * Motherboards * 34 - RAMPS1.4 - uses Analog input 5 on the AUX2 connector * 81 - Printrboard - Uses Analog input 2 on the Exp1 connector (version B,C,D,E) * 301 - Rambo - uses Analog input 3 * Note may require analog pins to be defined for different motherboards **********************************************************************/ // Uncomment below to enable //#define FILAMENT_SENSOR #define FILAMENT_SENSOR_EXTRUDER_NUM 0 //The number of the extruder that has the filament sensor (0,1,2) #define MEASUREMENT_DELAY_CM 14 //measurement delay in cm. This is the distance from filament sensor to middle of barrel #define DEFAULT_NOMINAL_FILAMENT_DIA 3.0 //Enter the diameter (in mm) of the filament generally used (3.0 mm or 1.75 mm) - this is then used in the slicer software. Used for sensor reading validation #define MEASURED_UPPER_LIMIT 3.3 //upper limit factor used for sensor reading validation in mm #define MEASURED_LOWER_LIMIT 1.9 //lower limit factor for sensor reading validation in mm #define MAX_MEASUREMENT_DELAY 20 //delay buffer size in bytes (1 byte = 1cm)- limits maximum measurement delay allowable (must be larger than MEASUREMENT_DELAY_CM and lower number saves RAM) //defines used in the code #define DEFAULT_MEASURED_FILAMENT_DIA DEFAULT_NOMINAL_FILAMENT_DIA //set measured to nominal initially //When using an LCD, uncomment the line below to display the Filament sensor data on the last line instead of status. Status will appear for 5 sec. //#define FILAMENT_LCD_DISPLAY #include "Configuration_adv.h" #include "thermistortables.h" #endif //CONFIGURATION_H ```

[Sniffle]

@jsnbrgg if you want auto leveling on marlin right now you should download the 1.0.2 tag... it doesn't have as many bug fixes but a lot of the problems that have crept into auto leveling aren't there as well... marlin and auto leveling work on 1.0.2 with a rambo board... I know it's my standard flash when i'm printing during the week.

The current development branch of marlin's bed leveling is generally not working... it is being worked on heavily, but not there yet...

On Mon, May 25, 2015 at 9:34 AM, jsnbrgg notifications@github.com wrote:

Here is my Configuration H settings:

Configuration.h

``` #ifndef CONFIGURATION_H #define CONFIGURATION_H #include "boards.h" //=========================================================================== //============================= Getting Started //=========================================================================== /* Here are some standard links for getting your machine calibrated: - http://reprap.org/wiki/Calibration - http://youtu.be/wAL9d7FgInk - http://calculator.josefprusa.cz - http://reprap.org/wiki/Triffid_Hunter%27s_Calibration_Guide - http://www.thingiverse.com/thing:5573 - https://sites.google.com/site/repraplogphase/calibration-of-your-reprap - http://www.thingiverse.com/thing:298812 */ // This configuration file contains the basic settings. // Advanced settings can be found in Configuration_adv.h // BASIC SETTINGS: select your board type, temperature sensor type, axis scaling, and endstop configuration //=========================================================================== //============================= DELTA Printer //=========================================================================== // For a Delta printer replace the configuration files with the files in the // example_configurations/delta directory. // //=========================================================================== //============================= SCARA Printer //=========================================================================== // For a Scara printer replace the configuration files with the files in the // example_configurations/SCARA directory. // // @section https://github.com/section info // User-specified version info of this build to display in [Pronterface, etc] terminal window during // startup. Implementation of an idea by Prof Braino to inform user that any changes made to this // build by the user have been successfully uploaded into firmware. #define STRING_VERSION "1.0.3 dev" #define STRING_VERSION_CONFIG_H _DATE_ " " _TIME_ // build date and time #define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes. #define STRING_SPLASH_LINE1 "v" STRING_VERSION // will be shown during bootup in line 1 //#define STRING_SPLASH_LINE2 STRING_VERSION_CONFIG_H // will be shown during bootup in line2 // @section https://github.com/section machine // SERIAL_PORT selects which serial port should be used for communication with the host. // This allows the connection of wireless adapters (for instance) to non-default port pins. // Serial port 0 is still used by the Arduino bootloader regardless of this setting. // :[0,1,2,3,4,5,6,7] #define SERIAL_PORT 0 // This determines the communication speed of the printer // :[2400,9600,19200,38400,57600,115200,250000] #define BAUDRATE 250000 // This enables the serial port associated to the Bluetooth interface //#define BTENABLED // Enable BT interface on AT90USB devices // The following define selects which electronics board you have. // Please choose the name from boards.h that matches your setup #ifndef MOTHERBOARD #define MOTHERBOARD BOARD_RAMBO #endif // Optional custom name for your RepStrap or other custom machine // Displayed in the LCD "Ready" message #define CUSTOM_MACHINE_NAME "3D Printer" // Define this to set a unique identifier for this printer, (Used by some programs to differentiate between machines) // You can use an online service to generate a random UUID. (eg http://www.uuidgenerator.net/version4) // #define MACHINE_UUID "00000000-0000-0000-0000-000000000000" // This defines the number of extruders // :[1,2,3,4] #define EXTRUDERS 1 // Offset of the extruders (uncomment if using more than one and relying on firmware to position when changing). // The offset has to be X=0, Y=0 for the extruder 0 hotend (default extruder). // For the other hotends it is their distance from the extruder 0 hotend. //#define EXTRUDER_OFFSET_X {0.0, 20.00} // (in mm) for each extruder, offset of the hotend on the X axis //#define EXTRUDER_OFFSET_Y {0.0, 5.00} // (in mm) for each extruder, offset of the hotend on the Y axis //// The following define selects which power supply you have. Please choose the one that matches your setup // 1 = ATX // 2 = X-Box 360 203Watts (the blue wire connected to PS_ON and the red wire to VCC) // :{1:'ATX',2:'X-Box 360'} #define POWER_SUPPLY 1 // Define this to have the electronics keep the power supply off on startup. If you don't know what this is leave it. // #define PS_DEFAULT_OFF // @section https://github.com/section temperature //=========================================================================== //============================= Thermal Settings //=========================================================================== // //--NORMAL IS 4.7kohm PULLUP!-- 1kohm pullup can be used on hotend sensor, using correct resistor and table // //// Temperature sensor settings: // -2 is thermocouple with MAX6675 (only for sensor 0) // -1 is thermocouple with AD595 // 0 is not used // 1 is 100k thermistor - best choice for EPCOS 100k (4.7k pullup) // 2 is 200k thermistor - ATC Semitec 204GT-2 (4.7k pullup) // 3 is Mendel-parts thermistor (4.7k pullup) // 4 is 10k thermistor !! do not use it for a hotend. It gives bad resolution at high temp. !! // 5 is 100K thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (4.7k pullup) // 6 is 100k EPCOS - Not as accurate as table 1 (created using a fluke thermocouple) (4.7k pullup) // 7 is 100k Honeywell thermistor 135-104LAG-J01 (4.7k pullup) // 71 is 100k Honeywell thermistor 135-104LAF-J01 (4.7k pullup) // 8 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) // 9 is 100k GE Sensing AL03006-58.2K-97-G1 (4.7k pullup) // 10 is 100k RS thermistor 198-961 (4.7k pullup) // 11 is 100k beta 3950 1% thermistor (4.7k pullup) // 12 is 100k 0603 SMD Vishay NTCS0603E3104FXT (4.7k pullup) (calibrated for Makibox hot bed) // 13 is 100k Hisens 3950 1% up to 300°C for hotend "Simple ONE " & "Hotend "All In ONE" // 20 is the PT100 circuit found in the Ultimainboard V2.x // 60 is 100k Maker's Tool Works Kapton Bed Thermistor beta=3950 // // 1k ohm pullup tables - This is not normal, you would have to have changed out your 4.7k for 1k // (but gives greater accuracy and more stable PID) // 51 is 100k thermistor - EPCOS (1k pullup) // 52 is 200k thermistor - ATC Semitec 204GT-2 (1k pullup) // 55 is 100k thermistor - ATC Semitec 104GT-2 (Used in ParCan & J-Head) (1k pullup) // // 1047 is Pt1000 with 4k7 pullup // 1010 is Pt1000 with 1k pullup (non standard) // 147 is Pt100 with 4k7 pullup // 110 is Pt100 with 1k pullup (non standard) // 998 and 999 are Dummy Tables. They will ALWAYS read 25°C or the temperature defined below. // Use it for Testing or Development purposes. NEVER for production machine. // #define DUMMY_THERMISTOR_998_VALUE 25 // #define DUMMY_THERMISTOR_999_VALUE 100 // :{ '0': "Not used", '4': "10k !! do not use for a hotend. Bad resolution at high temp. !!", '1': "100k / 4.7k - EPCOS", '51': "100k / 1k - EPCOS", '6': "100k / 4.7k EPCOS - Not as accurate as Table 1", '5': "100K / 4.7k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '7': "100k / 4.7k Honeywell 135-104LAG-J01", '71': "100k / 4.7k Honeywell 135-104LAF-J01", '8': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT", '9': "100k / 4.7k GE Sensing AL03006-58.2K-97-G1", '10': "100k / 4.7k RS 198-961", '11': "100k / 4.7k beta 3950 1%", '12': "100k / 4.7k 0603 SMD Vishay NTCS0603E3104FXT (calibrated for Makibox hot bed)", '13': "100k Hisens 3950 1% up to 300°C for hotend 'Simple ONE ' & hotend 'All In ONE'", '60': "100k Maker's Tool Works Kapton Bed Thermistor beta=3950", '55': "100k / 1k - ATC Semitec 104GT-2 (Used in ParCan & J-Head)", '2': "200k / 4.7k - ATC Semitec 204GT-2", '52': "200k / 1k - ATC Semitec 204GT-2", '-2': "Thermocouple + MAX6675 (only for sensor 0)", '-1': "Thermocouple + AD595", '3': "Mendel-parts / 4.7k", '1047': "Pt1000 / 4.7k", '1010': "Pt1000 / 1k (non standard)", '20': "PT100 (Ultimainboard V2.x)", '147': "Pt100 / 4.7k", '110': "Pt100 / 1k (non-standard)", '998': "Dummy 1", '999': "Dummy 2" } #define TEMP_SENSOR_0 1 #define TEMP_SENSOR_1 0 #define TEMP_SENSOR_2 0 #define TEMP_SENSOR_3 0 #define TEMP_SENSOR_BED 1 // This makes temp sensor 1 a redundant sensor for sensor 0. If the temperatures difference between these sensors is to high the print will be aborted. //#define TEMP_SENSOR_1_AS_REDUNDANT #define MAX_REDUNDANT_TEMP_SENSOR_DIFF 10 // Actual temperature must be close to target for this long before M109 returns success #define TEMP_RESIDENCY_TIME 10 // (seconds) #define TEMP_HYSTERESIS 3 // (degC) range of +/- temperatures considered "close" to the target one #define TEMP_WINDOW 1 // (degC) Window around target to start the residency timer x degC early. // The minimal temperature defines the temperature below which the heater will not be enabled It is used // to check that the wiring to the thermistor is not broken. // Otherwise this would lead to the heater being powered on all the time. #define HEATER_0_MINTEMP 5 #define HEATER_1_MINTEMP 5 #define HEATER_2_MINTEMP 5 #define HEATER_3_MINTEMP 5 #define BED_MINTEMP 5 // When temperature exceeds max temp, your heater will be switched off. // This feature exists to protect your hotend from overheating accidentally, but _NOT_ from thermistor short/failure! // You should use MINTEMP for thermistor short/failure protection. #define HEATER_0_MAXTEMP 245 #define HEATER_1_MAXTEMP 245 #define HEATER_2_MAXTEMP 245 #define HEATER_3_MAXTEMP 245 #define BED_MAXTEMP 112 // If your bed has low resistance e.g. .6 ohm and throws the fuse you can duty cycle it to reduce the // average current. The value should be an integer and the heat bed will be turned on for 1 interval of // HEATER_BED_DUTY_CYCLE_DIVIDER intervals. //#define HEATER_BED_DUTY_CYCLE_DIVIDER 4 // If you want the M105 heater power reported in watts, define the BED_WATTS, and (shared for all extruders) EXTRUDER_WATTS //#define EXTRUDER_WATTS (12.0 _12.0/6.7) // P=I^2/R //#define BED_WATTS (12.0_12.0/1.1) // P=I^2/R //=========================================================================== //============================= PID Settings //=========================================================================== // PID Tuning Guide here: http://reprap.org/wiki/PID_Tuning // Comment the following line to disable PID and enable bang-bang. #define PIDTEMP #define BANG_MAX 255 // limits current to nozzle while in bang-bang mode; 255=full current #define PID_MAX BANG_MAX // limits current to nozzle while PID is active (see PID_FUNCTIONAL_RANGE below); 255=full current #ifdef PIDTEMP //#define PID_DEBUG // Sends debug data to the serial port. //#define PID_OPENLOOP 1 // Puts PID in open loop. M104/M140 sets the output power from 0 to PID_MAX //#define SLOW_PWM_HEATERS // PWM with very low frequency (roughly 0.125Hz=8s) and minimum state time of approximately 1s useful for heaters driven by a relay //#define PID_PARAMS_PER_EXTRUDER // Uses separate PID parameters for each extruder (useful for mismatched extruders) // Set/get with gcode: M301 E[extruder number, 0-2] #define PID_FUNCTIONAL_RANGE 10 // If the temperature difference between the target temperature and the actual temperature // is more then PID_FUNCTIONAL_RANGE then the PID will be shut off and the heater will be set to min/max. #define PID_INTEGRAL_DRIVE_MAX PID_MAX //limit for the integral term #define K1 0.95 //smoothing factor within the PID // If you are using a pre-configured hotend then you can use one of the value sets by uncommenting it // Ultimaker #define DEFAULT_Kp 22.2 #define DEFAULT_Ki 1.08 #define DEFAULT_Kd 114 // MakerGear // #define DEFAULT_Kp 7.0 // #define DEFAULT_Ki 0.1 // #define DEFAULT_Kd 12 // Mendel Parts V9 on 12V // #define DEFAULT_Kp 63.0 // #define DEFAULT_Ki 2.25 // #define DEFAULT_Kd 440 #endif // PIDTEMP //=========================================================================== //============================= PID Bed Temperature Control //=========================================================================== // Select PID or bang-bang with PIDTEMPBED. If bang-bang, BED_LIMIT_SWITCHING will enable hysteresis // // Uncomment this to enable PID on the bed. It uses the same frequency PWM as the extruder. // If your PID_dT is the default, and correct for your hardware/configuration, that means 7.689Hz, // which is fine for driving a square wave into a resistive load and does not significantly impact you FET heating. // This also works fine on a Fotek SSR-10DA Solid State Relay into a 250W heater. // If your configuration is significantly different than this and you don't understand the issues involved, you probably // shouldn't use bed PID until someone else verifies your hardware works. // If this is enabled, find your own PID constants below. //#define PIDTEMPBED // //#define BED_LIMIT_SWITCHING // This sets the max power delivered to the bed, and replaces the HEATER_BED_DUTY_CYCLE_DIVIDER option. // all forms of bed control obey this (PID, bang-bang, bang-bang with hysteresis) // setting this to anything other than 255 enables a form of PWM to the bed just like HEATER_BED_DUTY_CYCLE_DIVIDER did, // so you shouldn't use it unless you are OK with PWM on your bed. (see the comment on enabling PIDTEMPBED) #define MAX_BED_POWER 255 // limits duty cycle to bed; 255=full current //#define PID_BED_DEBUG // Sends debug data to the serial port. #ifdef PIDTEMPBED //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from FOPDT model - kp=.39 Tp=405 Tdead=66, Tc set to 79.2, aggressive factor of .15 (vs .1, 1, 10) #define DEFAULT_bedKp 10.00 #define DEFAULT_bedKi .023 #define DEFAULT_bedKd 305.4 //120v 250W silicone heater into 4mm borosilicate (MendelMax 1.5+) //from pidautotune // #define DEFAULT_bedKp 97.1 // #define DEFAULT_bedKi 1.41 // #define DEFAULT_bedKd 1675.16 // FIND YOUR OWN: "M303 E-1 C8 S90" to run autotune on the bed at 90 degreesC for 8 cycles. #endif // PIDTEMPBED // @section https://github.com/section extruder //this prevents dangerous Extruder moves, i.e. if the temperature is under the limit //can be software-disabled for whatever purposes by #define PREVENT_DANGEROUS_EXTRUDE //if PREVENT_DANGEROUS_EXTRUDE is on, you can still disable (uncomment) very long bits of extrusion separately. #define PREVENT_LENGTHY_EXTRUDE #define EXTRUDE_MINTEMP 170 #define EXTRUDE_MAXLENGTH (X_MAX_LENGTH+Y_MAX_LENGTH) //prevent extrusion of very large distances. //=========================================================================== //======================== Thermal Runaway Protection //=========================================================================== /** - Thermal Runaway Protection protects your printer from damage and fire if a - thermistor falls out or temperature sensors fail in any way. * - The issue: If a thermistor falls out or a temperature sensor fails, - Marlin can no longer sense the actual temperature. Since a disconnected - thermistor reads as a low temperature, the firmware will keep the heater on. * - The solution: Once the temperature reaches the target, start observing. - If the temperature stays too far below the target (hysteresis) for too long, - the firmware will halt as a safety precaution. */ #define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders #define THERMAL_PROTECTION_BED // Enable thermal protection for the heated bed //=========================================================================== //============================= Mechanical Settings //=========================================================================== // @section https://github.com/section machine // Uncomment this option to enable CoreXY kinematics // #define COREXY // Enable this option for Toshiba steppers // #define CONFIG_STEPPERS_TOSHIBA // @section https://github.com/section homing // coarse Endstop Settings #define ENDSTOPPULLUPS // Comment this out (using // at the start of the line) to disable the endstop pullup resistors #ifndef ENDSTOPPULLUPS // fine endstop settings: Individual pullups. will be ignored if ENDSTOPPULLUPS is defined // #define ENDSTOPPULLUP_XMAX // #define ENDSTOPPULLUP_YMAX // #define ENDSTOPPULLUP_ZMAX #define ENDSTOPPULLUP_XMIN #define ENDSTOPPULLUP_YMIN #define ENDSTOPPULLUP_ZMIN #define ENDSTOPPULLUP_ZPROBE #endif // Mechanical endstop with COM to ground and NC to Signal uses "false" here (most common setup). const bool X_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Y_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_MIN_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool X_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Y_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_MAX_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. const bool Z_PROBE_ENDSTOP_INVERTING = false; // set to true to invert the logic of the endstop. //#define DISABLE_MAX_ENDSTOPS //#define DISABLE_MIN_ENDSTOPS // @section https://github.com/section machine // If you want to enable the Z Probe pin, but disable its use, uncomment the line below. // This only affects a Z Probe Endstop if you have separate Z min endstop as well and have // activated Z_PROBE_ENDSTOP below. If you are using the Z Min endstop on your Z Probe, // this has no effect. //#define DISABLE_Z_PROBE_ENDSTOP // For Inverting Stepper Enable Pins (Active Low) use 0, Non Inverting (Active High) use 1 // :{0:'Low',1:'High'} #define X_ENABLE_ON 0 #define Y_ENABLE_ON 0 #define Z_ENABLE_ON 0 #define E_ENABLE_ON 0 // For all extruders // Disables axis when it's not being used. // WARNING: When motors turn off there is a chance of losing position accuracy! #define DISABLE_X false #define DISABLE_Y false #define DISABLE_Z false // @section https://github.com/section extruder #define DISABLE_E false // For all extruders #define DISABLE_INACTIVE_EXTRUDER true //disable only inactive extruders and keep active extruder enabled // @section https://github.com/section machine // Invert the stepper direction. Change (or reverse the motor connector) if an axis goes the wrong way. #define INVERT_X_DIR false #define INVERT_Y_DIR true #define INVERT_Z_DIR false // @section https://github.com/section extruder // For direct drive extruder v9 set to true, for geared extruder set to false. #define INVERT_E0_DIR false #define INVERT_E1_DIR false #define INVERT_E2_DIR false #define INVERT_E3_DIR false // @section https://github.com/section homing // ENDSTOP SETTINGS: // Sets direction of endstops when homing; 1=MAX, -1=MIN // :[-1,1] #define X_HOME_DIR -1 #define Y_HOME_DIR -1 #define Z_HOME_DIR -1 #define min_software_endstops false // If true, axis won't move to coordinates less than HOME_POS. #define max_software_endstops false // If true, axis won't move to coordinates greater than the defined lengths below. // @section https://github.com/section machine // Travel limits after homing (units are in mm) #define X_MIN_POS 0 #define Y_MIN_POS 0 #define Z_MIN_POS 0 #define X_MAX_POS 200 #define Y_MAX_POS 200 #define Z_MAX_POS 200 //=========================================================================== //========================= Filament Runout Sensor //=========================================================================== //#define FILAMENT_RUNOUT_SENSOR // Uncomment for defining a filament runout sensor such as a mechanical or opto endstop to check the existence of filament // In RAMPS uses servo pin 2. Can be changed in pins file. For other boards pin definition should be made. // It is assumed that when logic high = filament available // when logic low = filament ran out #ifdef FILAMENT_RUNOUT_SENSOR const bool FIL_RUNOUT_INVERTING = true; // Should be uncommented and true or false should assigned #define ENDSTOPPULLUP_FIL_RUNOUT // Uncomment to use internal pullup for filament runout pins if the sensor is defined. #define FILAMENT_RUNOUT_SCRIPT "M600" #endif //=========================================================================== //=========================== Manual Bed Leveling //=========================================================================== // #define MANUAL_BED_LEVELING // Add display menu option for bed leveling // #define MESH_BED_LEVELING // Enable mesh bed leveling #ifdef MANUAL_BED_LEVELING #define MBL_Z_STEP 0.025 // Step size while manually probing Z axis #endif // MANUAL_BED_LEVELING #ifdef MESH_BED_LEVELING #define MESH_MIN_X 10 #define MESH_MAX_X (X_MAX_POS - MESH_MIN_X) #define MESH_MIN_Y 10 #define MESH_MAX_Y (Y_MAX_POS - MESH_MIN_Y) #define MESH_NUM_X_POINTS 3 // Don't use more than 7 points per axis, implementation limited #define MESH_NUM_Y_POINTS 3 #define MESH_HOME_SEARCH_Z 4 // Z after Home, bed somewhere below but above 0.0 #endif // MESH_BED_LEVELING //=========================================================================== //============================ Bed Auto Leveling //=========================================================================== // @section https://github.com/section bedlevel #define ENABLE_AUTO_BED_LEVELING // Delete the comment to enable (remove // at the start of the line) #define Z_PROBE_REPEATABILITY_TEST // If not commented out, Z-Probe Repeatability test will be included if Auto Bed Leveling is Enabled. #ifdef ENABLE_AUTO_BED_LEVELING // There are 2 different ways to specify probing locations // // - "grid" mode // Probe several points in a rectangular grid. // You specify the rectangle and the density of sample points. // This mode is preferred because there are more measurements. // // - "3-point" mode // Probe 3 arbitrary points on the bed (that aren't colinear) // You specify the XY coordinates of all 3 points. // Enable this to sample the bed in a grid (least squares solution) // Note: this feature generates 10KB extra code size #define AUTO_BED_LEVELING_GRID #ifdef AUTO_BED_LEVELING_GRID #define LEFT_PROBE_BED_POSITION 30 #define RIGHT_PROBE_BED_POSITION 195 #define FRONT_PROBE_BED_POSITION 5 #define BACK_PROBE_BED_POSITION 145 #define MIN_PROBE_EDGE 10 // The probe square sides can be no smaller than this // Set the number of grid points per dimension // You probably don't need more than 3 (squared=9) #define AUTO_BED_LEVELING_GRID_POINTS 2 #else // !AUTO_BED_LEVELING_GRID // Arbitrary points to probe. A simple cross-product // is used to estimate the plane of the bed. #define ABL_PROBE_PT_1_X 15 #define ABL_PROBE_PT_1_Y 180 #define ABL_PROBE_PT_2_X 15 #define ABL_PROBE_PT_2_Y 20 #define ABL_PROBE_PT_3_X 170 #define ABL_PROBE_PT_3_Y 20 #endif // AUTO_BED_LEVELING_GRID // Offsets to the probe relative to the extruder tip (Hotend - Probe) // X and Y offsets must be integers #define X_PROBE_OFFSET_FROM_EXTRUDER 26 // Probe on: -left +right #define Y_PROBE_OFFSET_FROM_EXTRUDER -51 // Probe on: -front +behind #define Z_PROBE_OFFSET_FROM_EXTRUDER -2.3 // -below (always!) #define Z_RAISE_BEFORE_HOMING 4 // (in mm) Raise Z before homing (G28) for Probe Clearance. // Be sure you have this distance over your Z_MAX_POS in case #define XY_TRAVEL_SPEED 8000 // X and Y axis travel speed between probes, in mm/min #define Z_RAISE_BEFORE_PROBING 15 //How much the extruder will be raised before traveling to the first probing point. #define Z_RAISE_BETWEEN_PROBINGS 5 //How much the extruder will be raised when traveling from between next probing points #define Z_RAISE_AFTER_PROBING 0 //How much the extruder will be raised after the last probing point. // #define Z_PROBE_END_SCRIPT "G1 Z10 F12000\nG1 X15 Y330\nG1 Z0.5\nG1 Z10" //These commands will be executed in the end of G29 routine. //Useful to retract a deployable probe. //#define Z_PROBE_SLED // turn on if you have a z-probe mounted on a sled like those designed by Charles Bell //#define SLED_DOCKING_OFFSET 5 // the extra distance the X axis must travel to pickup the sled. 0 should be fine but you can push it further if you'd like. //If defined, the Probe servo will be turned on only during movement and then turned off to avoid jerk //The value is the delay to turn the servo off after powered on - depends on the servo speed; 300ms is good value, but you can try lower it. // You MUST HAVE the SERVO_ENDSTOPS defined to use here a value higher than zero otherwise your code will not compile. #define PROBE_SERVO_DEACTIVATION_DELAY 300 //If you have enabled the Bed Auto Leveling and are using the same Z Probe for Z Homing, //it is highly recommended you let this Z_SAFE_HOMING enabled!!! #define Z_SAFE_HOMING // This feature is meant to avoid Z homing with probe outside the bed area. // When defined, it will: // - Allow Z homing only after X and Y homing AND stepper drivers still enabled // - If stepper drivers timeout, it will need X and Y homing again before Z homing // - Position the probe in a defined XY point before Z Homing when homing all axis (G28) // - Block Z homing only when the probe is outside bed area. #ifdef Z_SAFE_HOMING #define Z_SAFE_HOMING_X_POINT 100 // X point for Z homing when homing all axis (G28) #define Z_SAFE_HOMING_Y_POINT 100 // Y point for Z homing when homing all axis (G28) #endif // Support for a dedicated Z PROBE endstop separate from the Z MIN endstop. // If you would like to use both a Z PROBE and a Z MIN endstop together or just a Z PROBE with a custom pin, uncomment #define Z_PROBE_ENDSTOP and read the instructions below. // If you want to still use the Z min endstop for homing, disable Z_SAFE_HOMING above. Eg; to park the head outside the bed area when homing with G28. // WARNING: The Z MIN endstop will need to set properly as it would without a Z PROBE to prevent head crashes and premature stopping during a print. // To use a separate Z PROBE endstop, you must have a Z_PROBE_PIN defined in the pins.h file for your control board. // If you are using a servo based Z PROBE, you will need to enable NUM_SERVOS, SERVO_ENDSTOPS and SERVO_ENDSTOPS_ANGLES in the R/C Servo below. // RAMPS 1.3/1.4 boards may be able to use the 5V, Ground and the D32 pin in the Aux 4 section of the RAMPS board. Use 5V for powered sensors, otherwise connect to ground and D32 // for normally closed configuration and 5V and D32 for normally open configurations. Normally closed configuration is advised and assumed. // The D32 pin in Aux 4 on RAMPS maps to the Arduino D32 pin. Z_PROBE_PIN is setting the pin to use on the Arduino. Since the D32 pin on the RAMPS maps to D32 on Arduino, this works. // D32 is currently selected in the RAMPS 1.3/1.4 pin file. All other boards will need changes to the respective pins_XXXXX.h file. // WARNING: Setting the wrong pin may have unexpected and potentially disastrous outcomes. Use with caution and do your homework. //#define Z_PROBE_ENDSTOP #endif // ENABLE_AUTO_BED_LEVELING // @section https://github.com/section homing // The position of the homing switches #define MANUAL_HOME_POSITIONS // If defined, MANUAL_*_HOME_POS below will be used //#define BED_CENTER_AT_0_0 // If defined, the center of the bed is at (X=0, Y=0) // Manual homing switch locations: // For deltabots this means top and center of the Cartesian print volume. #ifdef MANUAL_HOME_POSITIONS #define MANUAL_X_HOME_POS -40 #define MANUAL_Y_HOME_POS 0 #define MANUAL_Z_HOME_POS 0 //#define MANUAL_Z_HOME_POS 402 // For delta: Distance between nozzle and print surface after homing. #endif // @section https://github.com/section movement /** - MOVEMENT SETTINGS */ #define HOMING_FEEDRATE {50_60, 50_60, 4*60, 0} // set the homing speeds (mm/min) // default settings #define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,2560,100} // default steps per unit for Ultimaker #define DEFAULT_MAX_FEEDRATE {300, 300, 5, 25} // (mm/sec) #define DEFAULT_MAX_ACCELERATION {3000,3000,100,10000} // X, Y, Z, E maximum start speed for accelerated moves. E default values are good for Skeinforge 40+, for older versions raise them a lot. #define DEFAULT_ACCELERATION 3000 // X, Y, Z and E acceleration in mm/s^2 for printing moves #define DEFAULT_RETRACT_ACCELERATION 3000 // E acceleration in mm/s^2 for retracts #define DEFAULT_TRAVEL_ACCELERATION 3000 // X, Y, Z acceleration in mm/s^2 for travel (non printing) moves // The speed change that does not require acceleration (i.e. the software might assume it can be done instantaneously) #define DEFAULT_XYJERK 15.0 // (mm/sec) #define DEFAULT_ZJERK 0.4 // (mm/sec) #define DEFAULT_EJERK 5.0 // (mm/sec) //============================================================================= //============================= Additional Features //============================================================================= // @section https://github.com/section more // Custom M code points #define CUSTOM_M_CODES #ifdef CUSTOM_M_CODES #ifdef ENABLE_AUTO_BED_LEVELING #define CUSTOM_M_CODE_SET_Z_PROBE_OFFSET 851 #define Z_PROBE_OFFSET_RANGE_MIN -20 #define Z_PROBE_OFFSET_RANGE_MAX 20 #endif #endif // @section https://github.com/section extras // EEPROM // The microcontroller can store settings in the EEPROM, e.g. max velocity... // M500 - stores parameters in EEPROM // M501 - reads parameters from EEPROM (if you need reset them after you changed them temporarily). // M502 - reverts to the default "factory settings". You still need to store them in EEPROM afterwards if you want to. //define this to enable EEPROM support //#define EEPROM_SETTINGS #ifdef EEPROM_SETTINGS // To disable EEPROM Serial responses and decrease program space by ~1700 byte: comment this out: #define EEPROM_CHITCHAT // Please keep turned on if you can. #endif // @section https://github.com/section temperature // Preheat Constants #define PLA_PREHEAT_HOTEND_TEMP 180 #define PLA_PREHEAT_HPB_TEMP 70 #define PLA_PREHEAT_FAN_SPEED 0 // Insert Value between 0 and 255 #define ABS_PREHEAT_HOTEND_TEMP 240 #define ABS_PREHEAT_HPB_TEMP 110 #define ABS_PREHEAT_FAN_SPEED 0 // Insert Value between 0 and 255 //==============================LCD and SD support============================= // @section https://github.com/section lcd // Define your display language below. Replace (en) with your language code and uncomment. // en, pl, fr, de, es, ru, bg, it, pt, pt-br, fi, an, nl, ca, eu, kana, kana_utf8, cn, test // See also language.h #define LANGUAGE_INCLUDE GENERATE_LANGUAGE_INCLUDE(en) // Choose ONE of these 3 charsets. This has to match your hardware. Ignored for full graphic display. // To find out what type you have - compile with (test) - upload - click to get the menu. You'll see two typical lines from the upper half of the charset. // See also documentation/LCDLanguageFont.md #define DISPLAY_CHARSET_HD44780_JAPAN // this is the most common hardware //#define DISPLAY_CHARSET_HD44780_WESTERN //#define DISPLAY_CHARSET_HD44780_CYRILLIC //#define ULTRA_LCD //general LCD support, also 16x2 //#define DOGLCD // Support for SPI LCD 128x64 (Controller ST7565R graphic Display Family) //#define SDSUPPORT // Enable SD Card Support in Hardware Console //#define SDSLOW // Use slower SD transfer mode (not normally needed - uncomment if you're getting volume init error) //#define SD_CHECK_AND_RETRY // Use CRC checks and retries on the SD communication //#define ENCODER_PULSES_PER_STEP 1 // Increase if you have a high resolution encoder //#define ENCODER_STEPS_PER_MENU_ITEM 5 // Set according to ENCODER_PULSES_PER_STEP or your liking //#define ULTIMAKERCONTROLLER //as available from the Ultimaker online store. //#define ULTIPANEL //the UltiPanel as on Thingiverse //#define LCD_FEEDBACK_FREQUENCY_DURATION_MS 100 // the duration the buzzer plays the UI feedback sound. ie Screen Click //#define LCD_FEEDBACK_FREQUENCY_HZ 1000 // this is the tone frequency the buzzer plays when on UI feedback. ie Screen Click // 0 to disable buzzer feedback. Test with M300 S P // PanelOne from T3P3 (via RAMPS 1.4 AUX2/AUX3) // http://reprap.org/wiki/PanelOne //#define PANEL_ONE // The MaKr3d Makr-Panel with graphic controller and SD support // http://reprap.org/wiki/MaKr3d_MaKrPanel //#define MAKRPANEL // The Panucatt Devices Viki 2.0 and mini Viki with Graphic LCD // http://panucatt.com // ==REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib //#define VIKI2 //#define miniVIKI // This is a new controller currently under development. https://github.com/eboston/Adafruit-ST7565-Full-Graphic-Controller/ // // ==REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib //#define ELB_FULL_GRAPHIC_CONTROLLER // The RepRapDiscount Smart Controller (white PCB) // http://reprap.org/wiki/RepRapDiscount_Smart_Controller //#define REPRAP_DISCOUNT_SMART_CONTROLLER // The GADGETS3D G3D LCD/SD Controller (blue PCB) // http://reprap.org/wiki/RAMPS_1.3/1.4_GADGETS3D_Shield_with_Panel //#define G3D_PANEL // The RepRapDiscount FULL GRAPHIC Smart Controller (quadratic white PCB) // http://reprap.org/wiki/RepRapDiscount_Full_Graphic_Smart_Controller // // ==REMEMBER TO INSTALL U8glib to your ARDUINO library folder: http://code.google.com/p/u8glib/wiki/u8glib #define REPRAP_DISCOUNT_FULL_GRAPHIC_SMART_CONTROLLER // The RepRapWorld REPRAPWORLD_KEYPAD v1.1 // http://reprapworld.com/?products_details&products_id=202&cPath=1591_1626 //#define REPRAPWORLD_KEYPAD //#define REPRAPWORLD_KEYPAD_MOVE_STEP 10.0 // how much should be moved when a key is pressed, eg 10.0 means 10mm per click // The Elefu RA Board Control Panel // http://www.elefu.com/index.php?route=product/product&product_id=53 // REMEMBER TO INSTALL LiquidCrystal_I2C.h in your ARDUINO library folder: https://github.com/kiyoshigawa/LiquidCrystal_I2C //#define RA_CONTROL_PANEL /** - I2C Panels */ //#define LCD_I2C_SAINSMART_YWROBOT // PANELOLU2 LCD with status LEDs, separate encoder and click inputs //#define LCD_I2C_PANELOLU2 // Panucatt VIKI LCD with status LEDs, integrated click & L/R/U/P buttons, separate encoder inputs //#define LCD_I2C_VIKI // Shift register panels // --------------------- // 2 wire Non-latching LCD SR from: // https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/schematics#!shiftregister-connection //#define SAV_3DLCD // @section https://github.com/section extras // Increase the FAN pwm frequency. Removes the PWM noise but increases heating in the FET/Arduino //#define FAST_PWM_FAN // Use software PWM to drive the fan, as for the heaters. This uses a very low frequency // which is not as annoying as with the hardware PWM. On the other hand, if this frequency // is too low, you should also increment SOFT_PWM_SCALE. //#define FAN_SOFT_PWM // Incrementing this by 1 will double the software PWM frequency, // affecting heaters, and the fan if FAN_SOFT_PWM is enabled. // However, control resolution will be halved for each increment; // at zero value, there are 128 effective control positions. #define SOFT_PWM_SCALE 0 // Temperature status LEDs that display the hotend and bet temperature. // If all hotends and bed temperature and temperature setpoint are < 54C then the BLUE led is on. // Otherwise the RED led is on. There is 1C hysteresis. //#define TEMP_STAT_LEDS // M240 Triggers a camera by emulating a Canon RC-1 Remote // Data from: http://www.doc-diy.net/photo/rc-1_hacked/ // #define PHOTOGRAPH_PIN 23 // SkeinForge sends the wrong arc g-codes when using Arc Point as fillet procedure //#define SF_ARC_FIX // Support for the BariCUDA Paste Extruder. //#define BARICUDA //define BlinkM/CyzRgb Support //#define BLINKM /*********************************************************************\ - R/C SERVO support - Sponsored by TrinityLabs, Reworked by codexmas **********************************************************************/ // Number of servos // // If you select a configuration below, this will receive a default value and does not need to be set manually // set it manually if you have more servos than extruders and wish to manually control some // leaving it undefined or defining as 0 will disable the servo subsystem // If unsure, leave commented / disabled // #define NUM_SERVOS 3 // Servo index starts with 0 for M280 command // Servo Endstops // // This allows for servo actuated endstops, primary usage is for the Z Axis to eliminate calibration or bed height changes. // Use M851 to set the z-probe vertical offset from the nozzle. Store that setting with M500. // #define SERVO_ENDSTOPS {-1, -1, 0} // Servo index for X, Y, Z. Disable with -1 #define SERVO_ENDSTOP_ANGLES {0,0, 0,0, 82,130} // X,Y,Z Axis Extend and Retract angles /**********************************************************************\ - Support for a filament diameter sensor - Also allows adjustment of diameter at print time (vs at slicing) - Single extruder only at this point (extruder 0) * - Motherboards - 34 - RAMPS1.4 - uses Analog input 5 on the AUX2 connector - 81 - Printrboard - Uses Analog input 2 on the Exp1 connector (version B,C,D,E) - 301 - Rambo - uses Analog input 3 - Note may require analog pins to be defined for different motherboards **********************************************************************/ // Uncomment below to enable //#define FILAMENT_SENSOR #define FILAMENT_SENSOR_EXTRUDER_NUM 0 //The number of the extruder that has the filament sensor (0,1,2) #define MEASUREMENT_DELAY_CM 14 //measurement delay in cm. This is the distance from filament sensor to middle of barrel #define DEFAULT_NOMINAL_FILAMENT_DIA 3.0 //Enter the diameter (in mm) of the filament generally used (3.0 mm or 1.75 mm) - this is then used in the slicer software. Used for sensor reading validation #define MEASURED_UPPER_LIMIT 3.3 //upper limit factor used for sensor reading validation in mm #define MEASURED_LOWER_LIMIT 1.9 //lower limit factor for sensor reading validation in mm #define MAX_MEASUREMENT_DELAY 20 //delay buffer size in bytes (1 byte = 1cm)- limits maximum measurement delay allowable (must be larger than MEASUREMENT_DELAY_CM and lower number saves RAM) //defines used in the code #define DEFAULT_MEASURED_FILAMENT_DIA DEFAULT_NOMINAL_FILAMENT_DIA //set measured to nominal initially //When using an LCD, uncomment the line below to display the Filament sensor data on the last line instead of status. Status will appear for 5 sec. //#define FILAMENT_LCD_DISPLAY #include "Configuration_adv.h" #include "thermistortables.h" #endif //CONFIGURATION_H ```

— Reply to this email directly or view it on GitHub https://github.com/MarlinFirmware/Marlin/issues/2040#issuecomment-105244550

[jsnbrgg]

Cool! Thanks Sniffle! I'm downloading it now..

I would still like to help with the development as maybe a beta tester?

[jsnbrgg]

Here's a video of what the Dev Version was doing:

https://youtu.be/pBanQ4dIXAc

[ipa64]

Hi everyone, I'm using auto leveling bed with 1.0.2 for a while now (works great). If you need someone more to make tests with 1.0.3 please I have time to contribute. Thanks for your job!

[RicardoGA]

@thinkyhead @jsnbrgg I experiment a similar problem with the current dev 1.0.3, with the features: auto leveling bed and also the z safe homing that aren´t working. After trying to make it work i found that if you disable the max endstop by changing // #define DISABLE_MAX_ENDSTOPS to #define DISABLE_MAX_ENDSTOPS the auto bed leveling and the z safe homing works.

Hope this help to solve the problem

[thinkyhead]

Thanks @RicardoGA ! That's definitely one of the things we're telling people right away if their axes don't move in one direction. The more insidious problem right now is that the Z position ends up being off for some setups, and it's been a bugger to track it down.

[lrpirlet]

@thinkyhead @Roxy-3DPrintBoard I have been very interrested by the behavior reported in #2240... Clearly, using G28 Z over 2 different XY coordinates produces a different offset at the end of G29… This gave me an idea to test… I used the Development published 2-jun, Version 1.1.0... The G29 in that version is NOT using my proposed solution… I pushed a pencil under the borosilicate glass, parallel to the X axis, at about 200 mm from the origin. So, the Z value increases when the Y value increases, no matter what X is… I home X and Y, move the X to mid bed … I position Y then issue G28 Z followed by G29 … I get an offset. For Y=10 the offset is 0.81 mm For Y=90 the offset is 3.46 mm For Y=170 the offset is 5.98 mm I conclude that G29 does NOT produce a correct Z offset, and that this offset is HIGHLY dependent on the Z height a the beginning of G29.... Logically, I conclude that the distance to the bed MUST BE MEASURED in G29 instead of being calculated (There are too many resets of the ZERO on the Z axis during G29)... Please find here the evidence…

G29 Auto Bed Leveling
Bed X: 15.000 Y: 20.000 Z: 2.772
Bed X: 170.000 Y: 20.000 Z: 2.923
Bed X: 15.000 Y: 170.000 Z: 7.767
Bed X: 170.000 Y: 170.000 Z: 7.976
Eqn coefficients: a: 0.00116129 b: 0.03349500 d: 2.07005572
Mean of sampled points: 5.35949993

Bed Height Topography:
+-----------+
|...Back....|
|Left..Right|
|...Front...|
+-----------+
+2.40750 +2.61675
-2.58750 -2.43675
planeNormal x: -0.001161 y: -0.033495 z: 1.000000

Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001161
-0.000039 +0.999440 +0.033476
-0.001161 -0.033476 +0.999439
N20 G1 Z0 *112
N21 M0 *48

For Y=10 the offset is 0.81 mm

N22 G1 Z8 *122
N23 G28 X0 Y0 *3
N24 G1 X90 Y90 F1500 *93
N25 G28 Z0 *78
N26 G29 V4 T P2 *114
G29 Auto Bed Leveling
Bed X: 15.000 Y: 20.000 Z: 0.169
Bed X: 170.000 Y: 20.000 Z: 0.310
Bed X: 15.000 Y: 170.000 Z: 5.103
Bed X: 170.000 Y: 170.000 Z: 5.322
Eqn coefficients: a: 0.00116290 b: 0.03315166 d: -0.53072662
Mean of sampled points: 2.72625017

Bed Height Topography:
+-----------+
|...Back....|
|Left..Right|
|...Front...|
+-----------+
+2.37675 +2.59600
-2.55700 -2.41575
planeNormal x: -0.001163 y: -0.033152 z: 1.000000

Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001163
-0.000039 +0.999451 +0.033133
-0.001162 -0.033133 +0.999450
N27 G1 Z0 *119
N28 M0 *57

For Y=90 the offset is 3.46 mm

N29 G1 Z8 *113
N30 G28 X0 Y0 *1
N31 G1 X90 Y170 F1500 *102
N32 G28 Z0 *72
N33 G29 V4 T P2 *118
G29 Auto Bed Leveling
Bed X: 15.000 Y: 20.000 Z: -2.611
Bed X: 170.000 Y: 20.000 Z: -2.463
Bed X: 15.000 Y: 170.000 Z: 2.395
Bed X: 170.000 Y: 170.000 Z: 2.600
Eqn coefficients: a: 0.00113951 b: 0.03356250 d: -3.31352949
Mean of sampled points: -0.01968747

Bed Height Topography:
+-----------+
|...Back....|
|Left..Right|
|...Front...|
+-----------+
+2.41494 +2.61944
-2.59156 -2.44281
planeNormal x: -0.001140 y: -0.033562 z: 1.000000

Bed Level Correction Matrix:
+0.999999 +0.000000 +0.001140
-0.000038 +0.999437 +0.033544
-0.001139 -0.033544 +0.999437
N34 G1 Z0 *117
N35 M0 *53

For Y=170 the offset is 5.98 mm

[thinkyhead]

@lrpirlet I'm just getting back to Marlin after a couple weeks of being very busy with moving to a new city. I will read through your notes and see where it points. I also went back to older code to see if I could update it with all the latest changes but leave leveling mostly alone, and then see what changes were left over. Then I figured, one of the leftover changes must be responsible. I've narrowed the issue down to a handful of changes, so hopefully your notes will help point to which of them is the most likely culprit.

[lrpirlet]

@thinkyhead @Roxy-3DPrintBoard I have been trying to understand the code, but could not (sorry, I do not know C++). So, I could not find what I was looking for... I then decided not the examine the code anymore and try to understand the math behind... Sorry if some looks basic, but I have not the tools to write correctly using mathematical notation... so I define what I mean along the way.

In a 3 dimensions space, a point may be represented by A(Ax, Ay, Az) with each of the coordinate (Ax, Ay, Az) being a distance from a well-known point, invariable, stable…

We can discover on the bed 3 points A, B and C… A segment of line on the bed may be represented as a vector AB = (Bx-Ax, By-Ay,Bz-Az) We can form 2 lines AB and AC

A perpendicular line traversing the bed in Point A can be determined by multiplying the vector AB by AC, giving a vector (a, b, c)

AB*AC = (a,b,c) and the values of a, b and c are

a=(By-Ay)(Cz-Az)-(Cy-Ay)(Bz-Az) b=(Bz-Az)(Cx-Ax)-(Cz-Az)(Bx-Ax) c=(Bx-Ax)(Cy-Ay)-(Cx-Ax)(By-Ay) d=-(aAx+bAy+cAz)

Those form the values of the generic plane equation ax+by+cz+d=0

Then, in the 3d printer world, the origin is on the bed, at location x=0, Y=0, Z=0. The bed plane equation takes the form a’x + b’y + c’z = -d = 0

In G29, because I just cannot read the C++ code, I am absolutely NOT sure that we ever extract the a, b and c values… I have NOT been able to find the value d that depend from the point A common to the 2 segments in the plane… remember: d=-(aAx+bAy+cAz)

Worse, if we do NOT define the origin at the correct place (X=Y=Z=0) we end up computing a plane parallel to the bed, not the plan on the bed…

When I probe the bed using G28 at a random X and Y coordinate, I define a random Z origin, and I end up defining a plane parallel to the bed at a random distance from the bed…

When I probe the bed using G28 at the Z_SAFE_HOMING coordinate, I define a NON zero Z leading to a NON FIXED Z origin, and I end up defining a plane parallel to the bed at an unknown distance from the bed…

Now, the only solutions I see is

1. to measure the distance using the last probing in G29 ABL, using the last distance found in the last G29 probe where we know all factors that compose that distance (offset, probe to hot-end tip,…)
2. to force probing the bed at coordinate 0,0,0… meaning redefining G28 to force it probing all 3 axis at 0,0,0 and write the g29 code to Check for the origin in X=Y=Z=0. I fail to see how we could easily do the later unless we integrate G28 in G29…

Now, if my theory is correct, it should explain the various reports around ABL. The above explains why it seems to work or nearly work (an offset is needed)… It does explain why I see different resulting distances when I enter the G29 after executing G28 Z at different X-Y coordinates.

It does not explain why some people report that it works for them… I could claim approximation… I think that it works because the math applied matches a “closed system”… for example, a well leveled bed going through the ABL will probably not be corrected or rather be corrected by a so small amount that it would not be measurable… another example is: if the sequence of gcodes prior G29 fills in the assumptions from the ABL code… Obviously in an open system where each and every printer and the associated Gcode prior to G29 may vary at random, we are bound to see different behavior…

[Roxy-3D]

In G29, because I just cannot read the C++ code, I am absolutely NOT sure that we ever extract the a, b and c values… I have NOT been able to find the value d that depend from the point A common to the 2 segments in the plane… remember: d=-(aAx+bAy+cAz)

It is more typical to say the equation for the plane is a_X + b_Y + cZ + d = 0 But, yes what you have is correct.

Worse, if we do NOT define the origin at the correct place (X=Y=Z=0) we end up computing a plane parallel to the bed, not the plane on the bed…

There is a matrix of 'd' values that get generated with all the probing. These points get stored in the eqnBVector[] array. These points are passed into qr_solve() along with the coordinates of the probed points in the eqnAMatrix[] matrix.

qr_solve() returns a least squares fit of the coefficients of this equation: a_X + b_Y + c*Z + d = 0

And if you take a look at the numbers being returned, they are pretty good! (I know! I spent some time writing an iterative version of qr_solve() and was comparing its results to the matrix solution of qr_solve() )

The biggest questions are things like "Do we need to compensate for the offset in 'd' because it is not plane normal when measured." I think the math is all good. The problem right now is there are bugs somewhere causing the Z_OFFSET to be wrong which causes air printing and such. And I think there is a similar question that relates to what you are saying: The coordinates of where you are setting the 'd' offset matter. If they are not at (0,0) the code needs to correct the Z value for where ever the nozzle is when 'd' gets set.

Update: In the older code base, this correction for not being at the origin happens. Here is the older code:

        // The following code correct the Z height difference from z-probe position and hotend tip position.
        // The Z height on homing is measured by Z-Probe, but the probe is quite far from the hotend.
        // When the bed is uneven, this height must be corrected.
        real_z = float(st_get_position(Z_AXIS))/axis_steps_per_unit[Z_AXIS];  //get the real Z (since the auto bed leveling is already correcting the plane)
        x_tmp = current_position[X_AXIS] + X_PROBE_OFFSET_FROM_EXTRUDER;
        y_tmp = current_position[Y_AXIS] + Y_PROBE_OFFSET_FROM_EXTRUDER;
        z_tmp = current_position[Z_AXIS];

        apply_rotation_xyz(plan_bed_level_matrix, x_tmp, y_tmp, z_tmp);         //Apply the correction sending the probe offset
        current_position[Z_AXIS] = z_tmp - real_z + current_position[Z_AXIS];   //The difference is added to current position and sent to planner.
        plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);

        do_blocking_move_to(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS] + Z_RAISE_BETWEEN_PROBINGS)

[Wackerbarth]

@Roxy-3DPrintBoard -- The biggest questions are things like "Do we need to compensate for the offset in 'd' because it is not plane normal when measured."

I think that is highly dependent on the nature of the bed positioning and the probe mechanism.

If we assume that the bed is "stable" (at a reproducible height and orientation) to the frame and that the probe is stable to the nozzle, then it is mostly a question of manufacturing/assembly tolerances.

If it is necessary to "calibrate" the relationship by a physical "testing" of the nozzle in close proximity to the bed (such a the "paper drag" feeler gauge approach or by measuring the actual thickness of a test layer, then there is no point in attempting to refine the calculation. Assuming that the bed is planar and at a constant orientation, and that the probe is repeatably located in relation to the nozzle, any error becomes a constant which gets incorporated into effective height of the probe.

OTOH, if the bed orientation varies significantly from print to print, compensation might improve the accuracy. However, if the printer cannot accurately reproduce the positioning, I would worry about its ability to maintain any particular pre-described position. Therefore, I question the value in attempting to compensate for the slope of the bed as it relates to the difference in the probed elevation and the "true" height of the nozzle.

[Roxy-3D]

Therefore, I question the value in attempting to compensate for the slope of the bed as it relates to the difference in the probed elevation and the "true" height of the nozzle.

Agreed. The reason this is true is because the bed is very close to level and the limit of sin(theta) approaches 0 as theta approaches 0. With the bed very close to level, the error from the non-normal measurements approaches 0. However... With that said, if you have a machine with large offsets from the probe to the nozzle, you are going to see error creep in when you try to set the height of the nozzle. It will change more if the distance to the probe is more.

[nophead]

I don't think there is any error at all because the probe is parallel to the Z axis and is placed where the nozzle would be, so it measures the height of the bed in the Z axis, which is correct. It shouldn't be a measurement normal to the plane of the bed. It is taking Z measurements of the bed at different XYs in order to work out the plane normal.

Mathematically it is wrong because it ignores the c and d values of the plane equation and takes Z from the last point probed, but I don't think that is the cause of the gross errors people report.

[Roxy-3D]

Mathematically it is wrong because it ignores the c and d values of the plane equation and takes Z from the last point probed, but I don't think that is the cause of the gross errors people report.

I agree with this also.

[Wackerbarth]

Correct, but that wasn't my point. There are two issues: (1) Is the bed nearly level? As you point out, the lateral displacement of the probe is not important as the bed approaches truly level. In any case, for a planar bed and a fixed displacement, the error is constant.

(2) Do we REALLY know the difference in the height of the nozzle and the height of the probe (when measured in a truly level space)?

If, as I typically observe, there are variations, printer to printer, in the assembly of the probe, then any small constant error in (1) may be added to the assembly error in (2) to produce a constant difference between the nozzle height and the probe contact point.

@nophead -- Chris, You are making assumptions about the probes. There are a number of probe designs. I'm not aware of any which have the probe in the true location of the nozzle. To avoid contact with the nozzle, the probe is somewhat lower than the nozzle. But in some designs, the position is also offset from the axis of the nozzle. In particular, the typical design for a delta printer has the probe permanently mounted to the carrier that positions the nozzle. When it is deployed, the probe is lowered, but there is no attempt to align it with the axis of the nozzle.

[nophead]

I have to say the way I implemented it in my own host software was a lot simpler. The probe operation doesn't alter the Z home point at all, so the machine simply moves around probing and never loses track of where it is and always works in machine coordinates. The values returned from my probe routine take the probe offset into account by moving to the target XY adjusted by the probe XY offset and returning the Z value adjusted by the Z offset. So again in machine coordinates.

Then when it is building the model, the model coordinates are mapped to machine coordinates by doing both a rotation and a translation.

[nophead]

It doesn't matter if the bed has a gross slope, my method still works because it places the probe where the nozzle would be.

I get the probe XY offset from my openscad model and a rough Z offset. I tweak it to be the exact Z offset by measuring the resultant skirt thickness.

[nophead]

Also I think Marlin correctly moves the probe to the XY position of the nozzle. That is what confuses people who don't understand it can't probe the whole of the bed if it has a large XY offset.

[Wackerbarth]

When things are planar, in determining the relative slopes between the planes, it doesn’t matter where you probe. The difference in the measured heights between two points depends only on the horizontal vector between them and the slope that you are attempting to determine. The absolute height depends on the origin, but relative heights are only the product of the normal to the plane and the relative distance vector joining the points. Yes, I realize that you ATTEMPT to move the probe to the position of the nozzle.

However, there is some error in that. In particular, for a delta printer, if we have some error in the mechanical dimensions, you will observe a “dishing” effect in what should otherwise be a planar surface. Similarly, if the axes are not truly perpendicular, you will not be placing the probe where you think that you are placing it.

Actually, I’ve wanted to try to do the probing for the calibration of my delta printer based on probing with the nozzle (not the probe itself) directly in the desired location.

Without knowing the lengths of the arms or the radius of the tower locations, assuming that the towers are parallel and that the bed is a plane, the one thing that I do know is that the difference in the height measured from the height of probe contact to the point of nozzle impact is a constant all over the bed.

On Jun 12, 2015, at 11:29 AM, Chris notifications@github.com wrote: Also I think Marlin correctly moves the probe to the XY position of the nozzle. That is what confuses people who don't understand it can't probe the whole of the bed if it has a large XY offset

[nophead]

A small X Y error is of no consequence when the bed is almost level. It would only make a minute ("my newt") difference in the Z reading.

The auto bed levelling is only to compensate for a sloping bed. Of course all bets are off if your machine does not move accurately in XYZ to start with.

[Wackerbarth]

On Jun 12, 2015, at 12:23 PM, Chris notifications@github.com wrote: A small X Y error is of no consequence when the bed is almost level. It would only make a minute difference in the Z reading.

Certainly.

The auto bed levelling is only to compensate for a sloping bed. Of course all bets are off if your machine does not move accurately in XYZ to start with.

No, it is not “accurate” movement that is required. What you need is a “repeatable” and “predictable” motion.

By probing, we can then, experimentally, fit values for the various parameters that are used to transform one coordinate system (The target object) into another (The actuator positions).

In general, the entire machine can be modeled in the form of a state vector and a transformation matrix.

By the physical geometry, we know, or presume, that many of the entries in the matrix are zero. If we can devise a set of probings that are sensitive to some particular entry, we can, experimentally, determine its value.

[nophead]

But the ABL software in Marlin that we are discussing is only for coping with a un-level bed assuming that the XYZ motion is accurate. You might want it to do more for a wonky delta machine, but that is a completely different piece of software.

Also a single transformation matrix is not sufficient to correct Cartesian motion errors in general, and certainly not non-linear kinematics. For example simply correcting for the Y bars not being parallel on an i3 requires a rotation about Y that varies with Y. You can't do that with a single matrix multiply.

[Wackerbarth]

Except for the fact that you imply that handling additional positional issues is "a completely different piece of software", I agree completely. I do observe that "different software" that is capable of handling such issues must also be capable of handling these issues as a part of a larger issue.

As for the "single matrix multiply", you are certainly correct in that a non-linear transformation cannot be done with one simple linear transformation. What can be done is to reduce the non-linear transformation to an approximation which is incrementally linear.

Even decades ago, we were implementing control systems that computed the correction vector by using the partial derivatives and computed errors to drive the system a small step in the correct direction. Then the derivatives would be re-evaluated and the next correction would be applied.

For linear systems, it isn't an issue. Once determined, the derivatives are constant.

But I will go back to my original assertion based on the assumptions being made (namely that the actuators accurately position the effector in machine coordinates, that the physical probe point is located (again in machine coordinates) at a fixed (3 dimensional) offset from the nozzle, and that the bed is stable and planar.

The only aspects that we are considering are the orientation and height of the bed with respect to the Z-axis of the machine. We assume that it is tilted and at an unknown elevation WRT the endstop/homing sensor.

[Wackerbarth]

I think that your approach is better.

I suspect that one of the difficulties in getting correct code is that various people are confusing coordinate systems.

On Jun 12, 2015, at 11:19 AM, Chris notifications@github.com wrote:

I have to say the way I implemented it in my own host software was a lot simpler. The probe operation doesn't alter the Z home point at all, so the machine simply moves around probing and never loses track of where it is and always works in machine coordinates. The values returned from my probe routine take the probe offset into account by moving to the target XY adjusted by the probe XY offset and returning the Z value adjusted by the Z offset. So again in machine coordinates.

Then when it is building the model, the model coordinates are mapped to machine coordinates by doing both a rotation and a translation.

[Wurstnase]

One issue is here float zPosition = -10; This should be something like MAX_Z_HIGH?!?

[lrpirlet]

That was a nice discussion that did NOT make me feel better in any way, because it went away from the point I am trying to make... Let me try to explain what I was looking for while trying to "decrypt the C++". The minimum number of probing is 3 provided that the origin is known...

I was looking for, but could not find, any clever way to see if the origin is known with X=Y=Z=0... So, G29 ABL, when using only 3 points probing, ASSUMES that the origin is known and equals to zero... I was looking for, but could not find if G29 ABL, when using more than 3 probe does reject the first probing... So, when I use G29 T V4 P2, the assumption is that all 4 probed values for Z are part of the same plan... Had I written it, I'd have written something to reject a first probe value obviously OFF the plane... But I could NOT find that...

Well, I have stopped using G29 ABL to use G29 Mesh. The later answer a lot better to the need I have with my Prusa i3 that does NOT keep a constant distance tip-bed.. The X axis is made of 2 smooth rods on top of each other, this architecture creates a torque that brings the tip about 0.15 mm (and more) closer to the bed in the middle of the X course... G29 V4 P5 T was very nice to outline this ... Note, I had either a leveled bed OR a probe in X=Y=0...

[nophead]

@Wackerbarth you might be interested in this: https://github.com/repetier/Repetier-Firmware/issues/367#issue-58547241

[Wackerbarth]

@nophead -- I'm definitely interested. It is just the sort of thing that I was planning to implement. (I hadn't figured out if I should do it in the printer, or off line.)

Basically, you can take a large array of readings (A, B, C) where the probe comes into contact with the bed. Then you can run those readings through an analyzer that spits out its best estimate of the variable elements.

The only thing that I would do differently is to ignore "tower rotation". I can do this because the locations of the towers can be expressed with only three degrees of freedom (OK, 5 if you insist in representing the true center of the physical bed -- unimportant when we don't care the true location of our target object.)

You can use either (R@0, R@A1, R@A2) or (R@0, R1@120, R2@240) to represent any three tower locations. In addition, my state vector would include the three arm lengths and the three tower registration (endstop) heights.

[lrpirlet]

@thinkyhead @Roxy-3DPrintBoard and to any participant to this discussion

Ok , I was wrong again. I CAN find the a, b, c and d factors of the plane equation… But not where I expected to find it…

I do propose 2 solutions to solve this issue with G29 ending up "in the air". I wish I could code but I need to rely on people that know how to... I cannot. Please read to the bottom where I expose my solution along with some ideas to minimize the errors. It was said in the code comments that c=1. The value of a, b and d are available in the printout of the G29 V4 equation.

In fact, the problem of the offset to apply is a simple translation of the plane since both the tip of the Hot-end and the tip of the probe evolve in 2 parallel planes…

So, If we take a (coherent, more of that later) plane equation, at a particular point we can very easily determine the offset…

In the probe plane, at X=Y=0 we have Z+d=0. Since we know d, we know the correction due to the slope of this plane.

Before continuing, for the ease of the writing, I define

x’ = X_PROBE_OFFSET_FROM_EXTRUDER
y’ = Y_PROBE_OFFSET_FROM_EXTRUDER 
z’ = Z_PROBE_OFFSET_FROM_EXTRUDER

In the hot-end plane at the same position as above, the plane equation becomes after translation

a(x+x’) + b(y+y’) + (z + z’) + d  = 0 = ax’+by’+z+z’+d=0

We know everything in this equation except z (the needed offset) that can be computed using

-z=(d+z’+ax’+by’)

This was the formula I was looking for in the code, that would have computed the distance to compensate for the probe to the tip displacement.

Now, I also said that we need to have a “coherent” plane. I mean by that that each point in the plane is referring to a coherent origin. If we home z anywhere else than at x=y=o, then we need to apply some translation.

Please consider to the results of my experiences above posted 14 days ago. I placed the important result in this table (for Test 1, 2 and 3)

a   0.00116129  0.00116290  0.00113951
b   0.03349500  0.03315166  0.03356250
c   1           1           1
d   2.07005572  -0.53072662 -3.31352949
x   90          90          90
y   10          90          170

With a, b and d the value displayed in the G29 V4 T P4, and x,y the position to home Z ( where I invoked G28 Z)…

I am probing the same bed so the plane equation should be the same if the G28 x,y coordinates have NO incidence... We see that d is different, so I conclude that G28 x,y coordinates do have an incidence… I also see that a, b and d are about the same value, with some error due to the measure... (Note that the absolute value of ax becomes more significant as x increase, see my suggestion later)

Since I have measured the same plane, I should find a plane equation that resolve to the same value…

Using the plane formulated as -z=(ax + by + d), with x and y the values used to execute G28 Z, I will compare 3 “coherent” plane équations. This in fact is to translate the X and Y coordinate to the SAME place… One can read it as shifting the z home to the X=Y=0 position.

The results are for test 1, test 2 and test 3

-z = (ax + by + d) =    2.50952182  2.55758378  2.49465141

This, in my eyes is quite near enough to prove that the equations represent the same plan. The differences being due to the errors of measures.

Another thing to consider is WHERE the G28 X,Y coordinates should be determined to minimize the effects of the measure errors. In the plane equation, ax + by + z + d=0, we want to have the smallest x and y. At x=y=0 the only term affected by the errors is d, the absolute distance in error will be proportional to the value of x and y where we home Z, so we better keep the x,y coordinates (to home z) as small as possible.

Now, the quick and durty (but easy to implement) solution is to measure the distance.

The "elegant" solution is to change the code so that

• make sure to know WHERE (x,y) z is homed… Say the G29 code forces to use G28 Z at Safe_homing coordinates

• I would strongly advise to change the definition of Z_SAFE_HOMING_X_POINT and Z_SAFE_HOMING_Y_POINT to the smallest possible value… My printer would be happy with both set to 0 (zero)…

• Apply Both offset correction I described earlier, the first using -z=(d+z’+ax’+by’) for the bed slope and tips distance, followed by -z = (ax + by + d) for home coordinates coherence

I hope this helps getting a stable version 1.0.3 out of the door… Sorry, I would have coded if I could…

[Roxy-3D]

This is a seperate issue from what lrpirlet is bringing up in this last post. But I think it is an issue:

Please read to the bottom where I expose my solution along with some ideas to minimize the errors. It was said in the code comments that c=1. The value of a, b and d are available in the printout of the G29 V4 equation.

c=1 is being passed into the QR_Solve() function. Depending upon what value is passed in for this coefficient, you get different numbers out for the other coefficients. I think what it is doing is OK, but it can be improved. The problem is this: We are asking it to solve the ax + by + z + d=0 equation using 1 as the coefficient for the Z coordinate. That would be fine if a & b were 0 but they are not. As a result, our movements will not be unity.

I think we should do what we are doing and calculate a solution for the plane with c=1. But then we should normalize the (a,b,c) coefficients (which will make c slightly less than 1) and use those numbers instead.

[fl380]

Is there anything that I can do to help fix ABL? The issue which I raised a few weeks ago (#2240) was closed and this issue was referenced. I'm still unable to get a consistent first layer height even though the probed Z only has very slight variations, the first layer is either printed in the air or the hotend is crashed into the bed.

Adding support to a part only makes it worse. I've just stopped a print which has multiple parts some of which have supports. The first layer of parts without support is printed in the air and with support is dug into thd bed.

[Roxy-3D]

Is there anything that I can do to help fix ABL?

This may not help... But if you have your EEPROM enabled... try doing a M502 followed by a M500 and see if that more closely resembles what you have for a Z_PROBE_OFFSET_FROM_EXTRUDER in your Configuration.h file.

[fl380]

But if you have your EEPROM enabled...

Thanks for the suggestion but EEPROM was disabled some time ago to try to solve this problem

[Nandox7]

Btw I was adjusting my sensor and I noticed that when changing the Z Offset value using the LCD it is not immediately applied. I need to restart the printer for the new values to be picked up.

Shouldn't it be applied right away? Looking at the code it seems to update the zprobe_zoffset var but I guess it is not picked somehow.

[Roxy-3D]

Shouldn't it be applied right away? Looking at the code it seems to update the zprobe_zoffset var but I guess it is not picked somehow.

I would agree. But the problem is the zprobe_zoffset variable is getting picked up from the EEPROM and then just gets referenced in the G29. You can also set it for later use if you have the CUSTOM_M_CODE_SET_Z_PROBE_OFFSET #define turned on in Configuration.h. But until a G28 or G29 happens... It doesn't get used.

[Nandox7]

Well but the way I was testing was changing the value and storing the EEPROM and then sending a print job where I have the G28 & G29.

[lrpirlet]

@Roxy-3DPrintBoard
What you said 2 days ago just worries me... I thought that the general plane equation of the form a'x + b'y + c'z + d'=o was expressed as (a'/c')x + (b'/c')y + (c'/c')z + d'/c' = ax + by +1z +d =0 Provided that C is NOT zero, we express here the exact same plane equation (we can see it expressed in a different scale). To me this means that we do NOT need to normalize anything...

Should we expect that this fonction change the plane equation (3 dots in a plane and a perpendicular vector) to something else?

Again, I am not a programmer to fully translate into math expression, but I would be very suspicious to use a function that corrupt the plane equation.

[Roxy-3D]

What you said 2 days ago just worries me... I thought that the general plane equation of the form...

Well... I'm not an authority on this stuff... But... QR_Solve() takes a couple of matrix's and does a least squares solution based on the numbers you pass in. The call to QR_Solve() is instructing the algorithm to solve for a, b, and d assuming the value for c=1. In the general case this works because a & b are very close to 0. But the problem is this: The a,b & c coefficients are being used to generate the correction matrix and they are not being normalized prior to being used to build the matrix.

I think the plane equations are fine. The problem is I don't think you can generate a correction matrix from them without first normalizing the coefficients.