# Specific 3D Printers, Scanners, & Hardware > RepRap Format Printer Forum > Firmware Enhancements to Marlin >  Auto_Bed_Leveling with positive Z_PROBE_OFFSET_FROM_EXTRUDER

## regpye

Trying to work out how to use auto bed leveling without the use of a servo.
A micro switch has been added to a bracket and the nozzle acts as a lever to activate the micro switch when it touches the bed.

Hardware has been made and tested to a point where a small part has been printed.
A number of issues still need to be resolved. One issue is the deflection caused by the probing. This is being looked at now to reduce the amount of deflection as much as possible.

Configuration.zipMarlin_main.zip

----------


## ciutateivissa

regpye,

that sounds interessting, could you please post a photo for us to understand the hardware setup better? I use auto bed leveling with a servo right now, but I´m always open to try other solutions.

----------


## Roxy

> regpye,
> 
> that sounds interesting, could you please post a photo for us to understand the hardware setup better? I use auto bed leveling with a servo right now, but I´m always open to try other solutions.


Actually,  It would be very interesting to see the .STL files so we can understand how this thing is built.   But with that said, I'm looking at what has been done to support it in the Marlin_Main.cpp file.   I have some comments:

Question #1:   Why is there a servo defined in Configuration.h if there aren't any servo's used?

Question #2: Why are you using the very very first version of the Marlin code base that had Auto_Bed_Leveling?  Probably, the right way to view that code base is as 'experimental'.  It worked, but it had problems.  Many of the issues have been worked out concerning the X_PROBE_OFFSET and Y_PROBE_OFFSET now.    (Right now I have my origin in the back right because the code base you are using had issues with probing the X & Y in negative space)  And given you are doing a positive Z_PROBE_OFFSET which nobody else has done yet, you want the benefit of the best thinking on this OFFSET topic.   Can I encourage you to go get the latest code base, cross your configuration.h over to it and enable both:

#define ENABLE_AUTO_BED_LEVELING
#define AUTO_BED_LEVELING_GRID

And we start from there???

----------


## regpye

> Actually,  It would be very interesting to see the .STL files so we can understand how this thing is built.   But with that said, I'm looking at what has been done to support it in the Marlin_Main.cpp file.   I have some comments:
> 
> Question #1:   Why is there a servo defined in Configuration.h if there aren't any servo's used?
> 
> Question #2: Why are you using the very very first version of the Marlin code base that had Auto_Bed_Leveling?  Probably, the right way to view that code base is as 'experimental'.  It worked, but it had problems.  Many of the issues have been worked out concerning the X_PROBE_OFFSET and Y_PROBE_OFFSET now.    (Right now I have my origin in the back right because the code base you are using had issues with probing the X & Y in negative space)  And given you are doing a positive Z_PROBE_OFFSET which nobody else has done yet, you want the benefit of the best thinking on this OFFSET topic.   Can I encourage you to go get the latest code base, cross your configuration.h over to it and enable both:
> 
> #define ENABLE_AUTO_BED_LEVELING
> #define AUTO_BED_LEVELING_GRID
> 
> And we start from there???


Answer to question 1. Servo was used on previous model, and was not changed. (oversight) Works OK with it still activated, just no servo on the machine.
Answer to question 2. Have been using the old version for quiet a while with no real issues.  Should move over to a later version I suppose.

The setup I have now is working and has done a test print OK. There are some things that need tidying up though. I guess it would be best to use the later version and overcome any other problems along the way.

----------


## Roxy

> Answer to question 1. Servo was used on previous model, and was not changed. (oversight) Works OK with it still activated, just no servo on the machine.
> Answer to question 2. Have been using the old version for quiet a while with no real issues.  Should move over to a later version I suppose.
> 
> The setup I have now is working and has done a test print OK. There are some things that need tidying up though. I guess it would be best to use the later version and overcome any other problems along the way.


OK...  Can you switch to the new code base and verify things still work for you?   The Auto_Bed_Leveling in the current code base is better.  And it will be much easier to support you and get everything right because that is what most people are using.   If there is a real reason to get this going on the old code base, that can be done but at least for me, I would prefer to deal with the current code.    

If you can get it limping along and sort of working with the new code base we can get this polished pretty quickly.  What I'm thinking is if it works at all, you post the configuration.h and marlin_main.cpp along with a description of what is wrong and we can make some changes to the code and re-post it.  You compile and load the new firmware and report back if things are better or worse...   I'm thinking with 4 or 5 iterations, it will be going.

What about the .STL file?  Can you post that?  It would be interesting to see what we are trying to get going!

----------


## regpye

> regpye,
> 
> that sounds interessting, could you please post a photo for us to understand the hardware setup better? I use auto bed leveling with a servo right now, but I´m always open to try other solutions.


Hotend1.jpgHotend2.jpgHotend3.jpgHotend4.jpg
The hotend is like a hinge. When the nozzle touches the bed the hinge moves to activate a small micro switch. A light spring returns the hotend to it's printing position (only 2mm movement)
The hotend shown in these photos is working well, but I have noticed that it could be better,so I have designed another one that has a longer arm to increase the leverage and reduce the movement needed to activate the switch.  The short version as shown works, but there is some deflection when the probing takes place as the X carriage is extended.
Yesterday I re-designed and printed the new part and I will try and test it out with the settings I have presently (although the settings are not perfect yet)

----------


## regpye

Some other photos to show a bit more
Micro switch triggered by lever
.Hotend6.jpg


Another machine with a few small changes
Picture 005.jpgPicture-006.jpg


Very first test print
Picture-045.jpg

One of my test machines, just finished first test print.
Picture-046.jpg

----------


## old man emu

refpye,

You might find it easier and quicker to download thing 167440 and thing 167430 from Thingiverse and then watch the three videos starting with http://www.youtube.com/watch?v=awsI9bMndJA

Old Man Emu

----------


## Roxy

The problem is his Z_PROBE_OFFSET is positive.  The firmware doesn't expect the case where you drive the nozzle into the bed to take a measurement.  So we need to make a few tweaks to the firmware!    I can hardly wait!!!   :Smile:

----------


## regpye

> OK...  Can you switch to the new code base and verify things still work for you?   The Auto_Bed_Leveling in the current code base is better.  And it will be much easier to support you and get everything right because that is what most people are using.   If there is a real reason to get this going on the old code base, that can be done but at least for me, I would prefer to deal with the current code.    
> 
> If you can get it limping along and sort of working with the new code base we can get this polished pretty quickly.  What I'm thinking is if it works at all, you post the configuration.h and marlin_main.cpp along with a description of what is wrong and we can make some changes to the code and re-post it.  You compile and load the new firmware and report back if things are better or worse...   I'm thinking with 4 or 5 iterations, it will be going.
> 
> What about the .STL file?  Can you post that?  It would be interesting to see what we are trying to get going!


OK, I will take your advise and use the latest code. Where is the best place to obtain it?

I will share the STL files, however I am still working on the design to see what works the best. I have just printed a new design that I haven't tried out yet and will probably have that all tested within the next few days.  With the current hardware design it does work, however I have noticed that there is some deflection caused by the extended arm of the X axis (becomes a long lever) and that causes a small amount of flex while probing. To overcome this I have re-designed to give much less pressure while probing.  
When I have tested and found the improvement I will post the STL files.  Photos are a way of seeing how it works and I have posted several in another few replies already in this thread.

The test machine is a highly modified SmartRap. The SmartRap uses fishing line for the drives of both X and Y. I changed that to use GT2 belts.  Also the SmartRap uses a servo and RAMPS for the auto bed leveling. I have changed that to use Printrboard (because I have a lot of them left over) and no servo.

first1.jpg
This machine is using RAMPS, servo and the old Marlin code.

Picture-046.jpg
This machine is using Printrboard, no servo, old version of Marlin.
This is the very first test print with settings as in the uploaded firmware files. (old Marlin)
Both machines are using my design of extruder that is geared while the original machine design uses direct drive extruder.
All these machines use a Bowden delivery system for the filament feed.

Picture-019.jpg
Photo of the hinge parts that carry the hotend.
There are two micro switches. One is for the X limit and the other is for the Z limit and probing
The yellow zip tie is for tying the loom to keep the wiring tidy.

Picture-014.jpg
X limit switch.

----------


## regpye

> refpye,
> 
> You might find it easier and quicker to download thing 167440 and thing 167430 from Thingiverse and then watch the three videos starting with http://www.youtube.com/watch?v=awsI9bMndJA
> 
> Old Man Emu


The whole purpose of this exercise is to NOT use a servo. I have eight machines all currently working fine with a servo, but wanted to design a better way of doing it without the use of a servo.  Tests have been pretty good so far and it is only the start.
Thanks for you advise though, interesting the way they have done that, similar to what I have on my other machines. (most are i3s and Genie MagikMakers)

----------


## Roxy

> OK, I will take your advise and use the latest code. Where is the best place to obtain it?


If you goto https://github.com/ErikZalm/Marlin you can download a .ZIP file of everything.  The button to do that will be a little ways down on the far right side of the page.     It is what I'm running right now.  That will make it easy to support you.




> I will share the STL files, however I am still working on the design to see what works the best. I have just printed a new design that I haven't tried out yet and will probably have that all tested within the next few days.  With the current hardware design it does work, however I have noticed that there is some deflection caused by the extended arm of the X axis (becomes a long lever) and that causes a small amount of flex while probing. To overcome this I have re-designed to give much less pressure while probing.


I would love to print one of these up and try it!  But I guess we should get your firmware going first!

----------


## regpye

The new part that has to be tested.
This photo does not show the hotend in place, however the fan has been attached and from previous photos it shouldn't be too hard to work out where the nozzle will be.
The probing micro switch is easier to see in this photo, and the leverage has been increased a lot to minimize the pressure required to activate the switch.
I will try and get it setup today and ready to make some tests using it.

probing-switch.jpg

----------


## Roxy

Was this designed with Open_SCAD by any chance???

----------


## regpye

> The problem is his Z_PROBE_OFFSET is positive.  The firmware doesn't expect the case where you drive the nozzle into the bed to take a measurement.  So we need to make a few tweaks to the firmware!    I can hardly wait!!!


OK, I have downloaded the latest version of Marlin and prepared it as I think is correct for my machine.
When I go to compile it I get an error.
Maybe I did something wrong in the pins.h


In file included from /Marlin.h:23,
                 from BlinkM.cpp:5:
/pins.h:1:1: error: unterminated #ifndef


This is what I changed in pins.h

#if MOTHERBOARD == 8 || MOTHERBOARD == 81
#define KNOWN_BOARD 1
#define AT90USB 1286 // Disable MarlinSerial etc.


#ifndef __AVR_AT90USB1286__
#error Oops! Make sure you have 'Teensy++ 2.0' selected from the 'Tools -> Boards' menu.
#endif


#define LARGE_FLASH true


#define X_STEP_PIN 0
#define X_DIR_PIN 1
#define X_ENABLE_PIN 39


#define Y_STEP_PIN 2
#define Y_DIR_PIN 3
#define Y_ENABLE_PIN 38


#define Z_STEP_PIN 4
#define Z_DIR_PIN 5
#define Z_ENABLE_PIN 23


#define E0_STEP_PIN 6
#define E0_DIR_PIN 7
#define E0_ENABLE_PIN 19


#define HEATER_0_PIN 21 // Extruder
#define HEATER_1_PIN -1
#define HEATER_2_PIN -1
#define HEATER_BED_PIN 20 // Bed
#define FAN_PIN 22 // Fan
// You may need to change FAN_PIN to 16 because Marlin isn't using fastio.h
// for the fan and Teensyduino uses a different pin mapping.


#if MOTHERBOARD == 8 // Teensylu
#define X_STOP_PIN 13
#define Y_STOP_PIN 14
#define Z_STOP_PIN 15
#define TEMP_0_PIN 7 // Extruder / Analog pin numbering
#define TEMP_BED_PIN 6 // Bed / Analog pin numbering
#else // Printrboard
#define X_STOP_PIN 35
#define Y_STOP_PIN 37
#define Z_STOP_PIN 36
#define TEMP_0_PIN 1 // Extruder / Analog pin numbering
#define TEMP_BED_PIN 0 // Bed / Analog pin numbering
#endif


#define TEMP_1_PIN -1
#define TEMP_2_PIN -1


#define SDPOWER -1
#define SDSS 8
#define LED_PIN -1
#define PS_ON_PIN -1
#define KILL_PIN -1
#define ALARM_PIN -1


#ifdef NUM_SERVOS
#define SERVO0_PIN 11
#define Z_MIN_PIN 30	 //needs to be updated to what ever wire is used.


#if NUM_SERVOS > 1
#define SERVO1_PIN 6
#endif


#if NUM_SERVOS > 2
#define SERVO2_PIN 5
#endif


#if NUM_SERVOS > 3
#define SERVO3_PIN 4
#endif
#endif


#ifndef SDSUPPORT
// these pins are defined in the SD library if building with SD support
#define SCK_PIN 21 // 9
#define MISO_PIN 22 //11
#define MOSI_PIN 23 //10
#endif


/**************************************************  **************************************
 * Brainwave 1.0 pin assignments (AT90USB646)
 * Requires hardware bundle for Arduino:
https://github.com/unrepentantgeek/brainwave-arduino

----------


## Roxy

Tell you what...   I've attached my Pins.h    I have my Y-Axis limit switch on the E-Limit switch.   So, you can either move your connector to the same spot on your PrintrBoard, or you can change the pin numbers back for the Y-Limit switch.   (The reason is there is a conflict with the SD-Memory card pins.  Moving to the E-Limit switch resolves the issue)

Specifically...  I have my Y_STOP_PIN set as 37.  You would change this line to be like this if you don't want to move the connector to the E-Limit location:

  #define Y_STOP_PIN          8


That should get us past the compile issue....  However...  The strange thing is I don't think you need to mess with the Pins.h file typically.  I had to edit some stuff in there to get my servo pins defined.  But you aren't going to have a servo, so it seems strange that Pins.h had to be modified from its original state.

----------


## regpye

> Was this designed with Open_SCAD by any chance???


No, it was designed with Alibre Design, now called GeoMagic

----------


## regpye

> Tell you what...   I've attached my Pins.h    I have my Y-Axis limit switch on the E-Limit switch.   So, you can either move your connector to the same spot on your PrintrBoard, or you can change the pin numbers back for the Y-Limit switch.   (The reason is there is a conflict with the SD-Memory card pins.  Moving to the E-Limit switch resolves the issue)
> 
> Specifically...  I have my Y_STOP_PIN set as 37.  You would change this line to be like this if you don't want to move the connector to the E-Limit location:
> 
>   #define Y_STOP_PIN          8
> 
> 
> That should get us past the compile issue....  However...  The strange thing is I don't think you need to mess with the Pins.h file typically.  I had to edit some stuff in there to get my servo pins defined.  But you aren't going to have a servo, so it seems strange that Pins.h had to be modified from its original state.


I also have my Y on the E stop and my Y_STOP_PIN set as 37
I changed the pins.h just in case I stuffed up somewhere else, however I am still getting the same error message.



In file included from /Marlin.h:23,
                 from BlinkM.cpp:5:
/pins.h:1:1: error: unterminated #ifndef

----------


## regpye

Update:
I used the latest Marlin and made changes to suite my machine. After a few more changes to direction, stop positions and filament travel,  I managed to get it all working nicely and then made a small print.
The first print came out very skewed to one direction, so I made some more changes, reduced the acceleration down a lot, and then made another print. This time it came out fine.

How I got the system working was to first nudge the nozzle down until it opened the micro switch. That would be the zero point as far as the machine is concerned. This is actually below the bed level, so in the firmware I would have to put a positive offset.  I raised the nozzle in very small increments until the probing micro switch closed again, checking at each increment to make sure it was either open or closed.  When it closed I read the value from the screen and then added 0.3mm for the amount for lift above the bed (this I could experiment with) Altogether I had to lift 0.7mm to get the printing position I needed.
Tried it out and it works.  Now I will change the sensing head to a lower pressure design that I have made and test again. No other changes have been made to Marlin to this point, it is all standard code. :Wink:

----------


## Roxy

> Update:
> I used the latest Marlin and made changes to suite my machine. After a few more changes to direction, stop positions and filament travel,  I managed to get it all working nicely and then made a small print.
> The first print came out very skewed to one direction, so I made some more changes, reduced the acceleration down a lot, and then made another print. This time it came out fine.
> 
> How I got the system working was to first nudge the nozzle down until it opened the micro switch. That would be the zero point as far as the machine is concerned. This is actually below the bed level, so in the firmware I would have to put a positive offset.  I raised the nozzle in very small increments until the probing micro switch closed again, checking at each increment to make sure it was either open or closed.  When it closed I read the value from the screen and then added 0.3mm for the amount for lift above the bed (this I could experiment with) Altogether I had to lift 0.7mm to get the printing position I needed.
> Tried it out and it works.  Now I will change the sensing head to a lower pressure design that I have made and test again. No other changes have been made to Marlin to this point, it is all standard code.


All right!!!  Good!   OK, here is what I think:  I think we have two  main issues to deal with.  First, we need to make sure that any  Z_Probing leaves the nozzle in a good (safe) position.   And the second  thing I think is going to happen is the Z-Probe is going to get fired  during the middle of a print because of the edges curling upwards.      

Now that everybody is on the same version of the firmware, we can probably make progress pretty quickly.

OK...  First, lets try to get any Z-Probing to leave the nozzle at a safe height.  There are a couple problems with this.  G28 and G29 use different support functions to do their work right now.  (I think they will get cleaned up eventually to use the same stuff.  But right now, they do the work differently.)   

We need to have

*#define Z_RAISE_BETWEEN_PROBINGS 10.0*

defined in configuration.h    Probably 10 is excessive right now, but it will let you see if it is doing the right thing.

Now let's change run_z_probe() to leave the nozzle up.  Right now it looks like this:

*static void run_z_probe() {
    plan_bed_level_matrix.set_to_identity();
    feedrate = homing_feedrate[Z_AXIS];
...
    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();

    current_position[Z_AXIS] = st_get_position_mm(Z_AXIS);
    // make sure the planner knows where we are as it may be a bit different than we last said to move to
    plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
}
*
Lets change the very end of it to:

*plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS],  zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();

    current_position[Z_AXIS] = st_get_position_mm(Z_AXIS);
    // make sure the planner knows where we are as it may be a bit different than we last said to move to
    plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);

SERIAL_PROTOCOLLNPGM( "At end of run_z_probe()  raising nozzle." );
    do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
    SERIAL_PROTOCOLLNPGM( "At end of run_z_probe()  done raising nozzle." );
}
*
That should handle the bulk of the G29 code.   Now for the G28 code, lets make sure 

*#define Z_SAFE_HOMING* 

is enabled in configuration.h .   There are a million different code paths depending upon what options are turned on.  In this case, the Z-Axis is treated with extra care.  So...  probably it makes sense to start with that.   I'm not 100% certain this next change is going to do what we want, but it is the cleanest way to do this if it works.   Be sure to have your finger ready to press the reset button when you test it.    I think what we want to do is go find:

*static void homeaxis(int axis) {
#define HOMEAXIS_DO(LETTER) \
  ((LETTER##_MIN_PIN > -1 && LETTER##_HOME_DIR==-1) || (LETTER##_MAX_PIN > -1 && LETTER##_HOME_DIR==1))

  if (axis==X_AXIS ? HOMEAXIS_DO(X) :
      axis==Y_AXIS ? HOMEAXIS_DO(Y) :
      axis==Z_AXIS ? HOMEAXIS_DO(Z) :
      0) {
    int axis_home_dir = home_dir(axis);*

At the very end of this function (Macro Defination) is this code:

*#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
    if (axis==Z_AXIS) retract_z_probe();
#endif
  }
}
*
Let's change it to:

*
#if defined (ENABLE_AUTO_BED_LEVELING) && (PROBE_SERVO_DEACTIVATION_DELAY > 0)
    if (axis==Z_AXIS) retract_z_probe();
#endif
  }

if (axis==Z_AXIS) {
        SERIAL_PROTOCOLLNPGM( "At end of homeaxis(Z)  raising nozzle." );
        do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
        SERIAL_PROTOCOLLNPGM( "At end of homeaxis(Z)  done raising nozzle." );
   }
}*

If the G28 modification does not work right, we can do the changes right in the G28 code itself.   Please compile and load these changes.  And of course report back what is and isn't working right.    Once we get the Positive Z_PROBE_OFFSET handled, we need to make sure the print doesn't stop because the Z-Probe gets fired in the middle of a print.

----------


## regpye

> All right!!!  Good!   OK, here is what I think:  I think we have two  main issues to deal with.  First, we need to make sure that any  Z_Probing leaves the nozzle in a good (safe) position.   And the second  thing I think is going to happen is the Z-Probe is going to get fired  during the middle of a print because of the edges curling upwards.      
> 
> Now that everybody is on the same version of the firmware, we can probably make progress pretty quickly.
> 
> OK...  First, lets try to get any Z-Probing to leave the nozzle at a safe height.  There are a couple problems with this.  G28 and G29 use different support functions to do their work right now.  (I think they will get cleaned up eventually to use the same stuff.  But right now, they do the work differently.)   
> 
> We need to have
> 
> *#define Z_RAISE_BETWEEN_PROBINGS 10.0*
> ...


I have an error on compiling.



Marlin_main.cpp: In function 'void run_z_probe()':
Marlin_main.cpp:921: error: 'do_blocking_move_relative' was not declared in this scope




Section of code.

static void run_z_probe() {
    plan_bed_level_matrix.set_to_identity();
    feedrate = homing_feedrate[Z_AXIS];


    // move down until you find the bed
    float zPosition = -10;
plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
st_synchronize();


current_position[Z_AXIS] = st_get_position_mm(Z_AXIS);
// make sure the planner knows where we are as it may be a bit different than we last said to move to
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);


SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() raising nozzle." );
do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() done raising nozzle." );
}


static void do_blocking_move_to(float x, float y, float z) {
    float oldFeedRate = feedrate;


    feedrate = XY_TRAVEL_SPEED;


    current_position[X_AXIS] = x;
    current_position[Y_AXIS] = y;
    current_position[Z_AXIS] = z;
    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();


    feedrate = oldFeedRate;
}


static void do_blocking_move_relative(float offset_x, float offset_y, float offset_z) {
    do_blocking_move_to(current_position[X_AXIS] + offset_x, current_position[Y_AXIS] + offset_y, current_position[Z_AXIS] + offset_z);
}


static void setup_for_endstop_move() {
    saved_feedrate = feedrate;
    saved_feedmultiply = feedmultiply;
    feedmultiply = 100;
    previous_millis_cmd = millis();


    enable_endstops(true);
}


static void clean_up_after_endstop_move() {
#ifdef ENDSTOPS_ONLY_FOR_HOMING
    enable_endstops(false);
#endif


    feedrate = saved_feedrate;
    feedmultiply = saved_feedmultiply;
    previous_millis_cmd = millis();
}

----------


## Roxy

> I have an error on compiling.
> 
> 
> 
> Marlin_main.cpp: In function 'void run_z_probe()':
> Marlin_main.cpp:921: error: 'do_blocking_move_relative' was not declared in this scope
> ...
> }


My bad...

But it isn't my fault.  This is one of those times life isn't fair.   Scroll down 5 or 6 lines...  That is where the definition for do_blocking_move_relative() is.   A simple quick fix would be to cut and past the do_blocking_move_relative() function up above  run_z_probe().   Then it will be declared when run_z_probe() needs to reference it.     Its a shame to mess up the order of things, but if you want to keep making forward progress...  That will do it.   (But I have to get some sleep!!!!  I'll check back in the morning.)

----------


## regpye

> My bad...
> 
> But it isn't my fault.  This is one of those times life isn't fair.   Scroll down 5 or 6 lines...  That is where the definition for do_blocking_move_relative() is.   A simple quick fix would be to cut and past the do_blocking_move_relative() function up above  run_z_probe().   Then it will be declared when run_z_probe() needs to reference it.     Its a shame to mess up the order of things, but if you want to keep making forward progress...  That will do it.   (But I have to get some sleep!!!!  I'll check back in the morning.)


Not sure what to do about this, so I will leave it until I get further instructions.
I will work on another machine build ready to test this out on. I want to keep a machine for each version so I can compare  the differences between them.

----------


## Roxy

Here is the 'right' way to fix that forward reference issue that is keeping it from compiling.  It is literally a one line fix.
Make the declaration for *run_z_probe()* have the forward declaration for *do_blocking_move_relative()* just in front of it.
Usually there is a header file where this would go, but the best place to put this is just in front of the *run_z_probe()* function so it stays close to where it is needed.  That way all the changes are together if you need to move your changes to a more current code base in the future.  This time I actually changed my code to verify it would compile!   :Smile:   (and then changed it back)

With these changes the *run_z_probe()* function knows everything about *do_blocking_move()* that it needs to know.  It knows what type (and how many) parameters it takes and it knows what type (none) of value it returns.   The compiler can generate a 'call' to the function even though it doesn't know what the function looks like yet.

*
#endif // AUTO_BED_LEVELING_GRID

static void do_blocking_move_relative(float , float , float ) ;    // New line to fix forward reference issue

static void run_z_probe() {
    plan_bed_level_matrix.set_to_identity();
    feedrate = homing_feedrate[Z_AXIS];

*

----------


## regpye

> Here is the 'right' way to fix that forward reference issue that is keeping it from compiling.  It is literally a one line fix.
> Make the declaration for *run_z_probe()* have the forward declaration for *do_blocking_move_relative()* just in front of it.
> Usually there is a header file where this would go, but the best place to put this is just in front of the *run_z_probe()* function so it stays close to where it is needed.  That way all the changes are together if you need to move your changes to a more current code base in the future.  This time I actually changed my code to verify it would compile!    (and then changed it back)
> 
> With these changes the *run_z_probe()* function knows everything about *do_blocking_move()* that it needs to know.  It knows what type (and how many) parameters it takes and it knows what type (none) of value it returns.   The compiler can generate a 'call' to the function even though it doesn't know what the function looks like yet.
> 
> *
> #endif // AUTO_BED_LEVELING_GRID
> 
> ...


OK, done that and tried it oiut.
Nozzle really lifts high now  ha..ha..

Here is a printout of what appeared on the screen as it was working.

Printer is now online.
echo:Home X/Y before Z
At end of homeaxis(Z) raising nozzle.
At end of homeaxis(Z) done raising nozzle.
SENDING:G29
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 1.00 y: 1.00 z: 6.92
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 158.00 y: 1.00 z: 4.12
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 158.00 y: 160.00 z: 4.15
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 1.00 y: 160.00 z: 6.53
Eqn coefficients: a: -0.02 b: -0.00 d: 6.84
planeNormal x: 0.02 y: 0.00 z: 1.00
echo:endstops hit:  Z:-3.47

I haven't tried a print yet, it is nearly 1.00 am here in Australia, so I am off to the shower and then to bed.  Will have another look at it ion the morning (later in the morning)
Thanks for all your effort, much appreciated.

----------


## Roxy

> OK, done that and tried it oiut.
> Nozzle really lifts high now  ha..ha..



OK...  Well, that was intentional...  I would wait until everything else checks out, but you can change that equate from 10mm to 1mm or 2mm when you are ready.

And I would leave them in for now, but eventually you will want to delete that extra chit-chat about where the code is executing and what it is doing.  That just clutters up the display.     That was in there just to help with debugging if the firmware went crazy.




> Here is a printout of what appeared on the screen as it was working.
> 
> Printer is now online.
> echo:Home X/Y before Z
> At end of homeaxis(Z) raising nozzle.
> At end of homeaxis(Z) done raising nozzle.
> SENDING:G29
> At end of run_z_probe() raising nozzle.
> At end of run_z_probe() done raising nozzle.
> ...


If you got all the way through the G29 probes without an issue, we might be close.   I just noticed, you have a 2.5 mm slope to your bed????  I'm guessing that is on purpose?




> I haven't tried a print yet, it is nearly 1.00 am here in Australia, so I am off to the shower and then to bed.  Will have another look at it ion the morning (later in the morning)
> Thanks for all your effort, much appreciated.


I'm sorry I was so tired last night.  I couldn't stand to sit at my computer and try to get everything accurately typed in.   This working back and forth across the globe really slows things down!

It may be we can handle the Z-Probe triggering during a print with just a few changes to the configuration.h file.  I don't know about that yet.  I guess the right thing to do is just wait until you print a part and see what happens ????

And once all that is taken care of...  It would be good for you to visit this thread:

http://3dprintboard.com/showthread.p...2518#post12518

And add the M48 command to your Marlin_Main.CPP file.   With that you will be able to measure the repeatability of your Z-Probe to know if the mechanics are working well.   Probably you are going to get the best numbers we have seen so far.

----------


## regpye

> And add the M48 command to your Marlin_Main.CPP file.   With that you will be able to measure the repeatability of your Z-Probe to know if the mechanics are working well.   Probably you are going to get the best numbers we have seen so far.


Tried it out and left all the messages in so could see what is happening.

SENDING:G1 Y0 F4000   X0 F4000
At end of homeaxis(Z) raising nozzle.
At end of homeaxis(Z) done raising nozzle.
SENDING:G1 Y0 F4000   X0 F4000
SENDING:M48
M48 Z-Probe Repeatability test.   Version 1.85
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Mean: 11.120100
Standard Deviation: 0.005024
echo:endstops hit:  Z:6.12


Should be better with the new setup that I haven't fitted yet. I thought of some other hardware design changes, so I am printing those while re-building.
Should have the new hardware all setup within a few days.

----------


## Roxy

> Tried it out and left all the messages in so could see what is happening.
> 
> Mean: 11.120100
> Standard Deviation: 0.005024
> 
> Should be better with the new setup that I haven't fitted yet. I thought of some other hardware design changes, so I am printing those while re-building.
> Should have the new hardware all setup within a few days.


We don't have a lot of numbers yet, but .005 is pretty good!  You will get very good bed leveling with that number.   Do you have a high quality micro switch installed?   I don't know this for sure yet, but if you actually installed a Micro-Switch branded micro-switch, you probably get the best numbers you can get.

----------


## regpye

> We don't have a lot of numbers yet, but .005 is pretty good!  You will get very good bed leveling with that number.   Do you have a high quality micro switch installed?   I don't know this for sure yet, but if you actually installed a Micro-Switch branded micro-switch, you probably get the best numbers you can get.


I just got a micro switch from ebay like you did.  I have been looking at Farnell's they have a range of Honeywell switches and you can select the pressure that you need.  I will see if I can find one that is  very sensitive and affordable, because the price range goes from less than a dollar to several hundred dollars (go figure??)
Bed time again. can't stay up as late as I did last night, I really felt it today.

----------


## Roxy

Did you get through a print with the new setup?   Any problems?

----------


## regpye

> Did you get through a print with the new setup?   Any problems?


Yes I managed a print no worries. I still have to tune the printer for better settings for the filament feed as I have just guessed at the feed rate for that. 
The printer is working fine.  
I tried lowering the raise before probing and had to put it back up to 10 because it dragged along the bed if I went down to 5.  Works well on 10.

Next will be to finish off the new hardware and test the same on that to see if there is any further improvement.
All the new designs and printing has been done now for two more machines to play with and get the setting right, I am assembling them now.

Picture-058.jpg

Picture-049.jpg

----------


## Roxy

Wow!  That looks like it is going to be a nice printer!!!   I wish my printer looked that clean! 

But what is your Z_PROBE_OFFSET set at?  I thought is was under 1mm ?  If it is the same as what was in the Configuration.h file when you started this thread it is at .7 mm.    It would seem to me you could lower the 10 down to 1 or 2 mm?    I wonder if there is some other place in the firmware that is lowering the nozzle after we used the do_blocking_move_relative() to raise it?   It might be worth while to watch it carefully after the last probe to see what the nozzle does and maybe we can tweak that too so you can speed up the probing (because you are not raising the nozzle so much) ?

But all that aside....  I'm glad you got it working!

And now...  Because we are on opposite sides of the planet...  I'm off to sleep.   So I won't see any reply for 9 hours (I want to sleep in tomorrow!)

----------


## regpye

> Wow!  That looks like it is going to be a nice printer!!!   I wish my printer looked that clean! 
> 
> But what is your Z_PROBE_OFFSET set at?  I thought is was under 1mm ?  If it is the same as what was in the Configuration.h file when you started this thread it is at .7 mm.    It would seem to me you could lower the 10 down to 1 or 2 mm?    I wonder if there is some other place in the firmware that is lowering the nozzle after we used the do_blocking_move_relative() to raise it?   It might be worth while to watch it carefully after the last probe to see what the nozzle does and maybe we can tweak that too so you can speed up the probing (because you are not raising the nozzle so much) ?
> 
> But all that aside....  I'm glad you got it working!
> 
> And now...  Because we are on opposite sides of the planet...  I'm off to sleep.   So I won't see any reply for 9 hours (I want to sleep in tomorrow!)


I had to change a few things, but this is how it is setup now.

 #endif // AUTO_BED_LEVELING_GRID




  // these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
  #define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -9 //-12.35


  #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 10    //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

After you made some changes, the positive offset didn't work any more and I had to go back to a negative offset (I don't understand all this)
Anyway it is working fine like this.  I wonder what would happen if I tried to use these settings on one of my i3 machines that has a servo?

----------


## Roxy

> I had to change a few things, but this is how it is setup now.
> 
> 
>   #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
> 
> ...


This doesn't seem right.   It may be an issue with the do_blocking_move_relative() not having the correct information available to it about where to move.  I don't know.

I suggest you do a G28 followed by a G29 and then a M114 to ask where it thinks the nozzle is.   I think we are going to see an incorrect response on the M114.





> After you made some changes, the positive offset didn't work any more  and I had to go back to a negative offset (I don't understand all this)


And this doesn't make sense to me...   After you got the new firmware ported over with your changes, I only gave you that one set of things to change and it started working?  Did you try to fold the previous changes in also?

We may want to add a little more diagnostic code the Z-Probes so we can see where things are going wrong.

----------


## regpye

> This doesn't seem right.   It may be an issue with the do_blocking_move_relative() not having the correct information available to it about where to move.  I don't know.
> 
> I suggest you do a G28 followed by a G29 and then a M114 to ask where it thinks the nozzle is.   I think we are going to see an incorrect response on the M114.
> 
> 
> 
> 
> And this doesn't make sense to me...   After you got the new firmware ported over with your changes, I only gave you that one set of things to change and it started working?  Did you try to fold the previous changes in also?
> 
> We may want to add a little more diagnostic code the Z-Probes so we can see where things are going wrong.


SENDING:G28
At end of homeaxis(Z) raising nozzle.
At end of homeaxis(Z) done raising nozzle.
SENDING:G29
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 1.00 y: 1.00 z: 11.78
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 158.00 y: 1.00 z: 8.40
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 158.00 y: 158.00 z: 8.08
At end of run_z_probe() raising nozzle.
At end of run_z_probe() done raising nozzle.
Bed x: 1.00 y: 158.00 z: 11.19
Eqn coefficients: a: -0.02 b: -0.00 d: 11.74
planeNormal x: 0.02 y: 0.00 z: 1.00
echo:endstops hit:  Z:6.19
SENDING:M114
X:0.77 Y:157.97 Z:9.00 E:0.00 Count X: 0.95 Y:157.99 Z:8.52

----------


## regpye

> Did you get through a print with the new setup?   Any problems?


Printed OK, just need to fine tune because I just guessed the filament flow (close enough for a test)

----------


## Roxy

> SENDING:G28
> ...
> SENDING:G29
> ...
> Bed x: 1.00 y: 1.00 z: 11.78
> ...
> Bed x: 158.00 y: 1.00 z: 8.40
> ...
> Bed x: 158.00 y: 158.00 z: 8.08
> ...


OK...  That looks rational...   Those Z numbers look about where we would expect them to be given we told the probe routines to lift up 10 mm after the measurement is taken.

----------


## regpye

> OK...  That looks rational...   Those Z numbers look about where we would expect them to be given we told the probe routines to lift up 10 mm after the measurement is taken.


I will continue with the two hardware builds for a few days and then load up the current firmware and settings to each machine and continue with the testing. I have a couple of different ideas with the hardware that I feel will improve the stability of the physical parts of the machine. Problem is that this is always a continuing development, no sooner one idea comes to mind and is worked on, a better idea comes into mind and needs to be tried too. (love it)

----------


## Roxy

> I will continue with the two hardware builds for a few days and then load up the current firmware and settings to each machine and continue with the testing. I have a couple of different ideas with the hardware that I feel will improve the stability of the physical parts of the machine. Problem is that this is always a continuing development, no sooner one idea comes to mind and is worked on, a better idea comes into mind and needs to be tried too. (love it)


When things stabilize a little bit it would be good to see the .STL files for the extruder.   I like the way the Wade's extruder lets you pick which hot-end you have and it generates an appropriate base so you can just plug in what you will be using.    If yours is setup for a J-Head I could just print one up and play with it.

----------


## regpye

> When things stabilize a little bit it would be good to see the .STL files for the extruder.   I like the way the Wade's extruder lets you pick which hot-end you have and it generates an appropriate base so you can just plug in what you will be using.    If yours is setup for a J-Head I could just print one up and play with it.


The extruder I designed for Bowden delivery. The hotend is my own design also and is similar in the way it mounts to a J-head.
The extruders I have designed in right hand and left hand versions so that the hose can come out on which ever side is most appropriate for your design.
A pneumatic fitting is used to connect the Bowden hose to both the extruder and another one to the hotend.
If you want the STL files send me a PM with an email address or can they be put up here somehow?

----------


## Roxy

You can post them here!   If you have more than 5 files, just do a 2nd post with the second half of the files!

Do a 'Reply' and then you will see a 'Go Advanced' button where you get more options.  At that point you will be able to manage attachments.

I'm very eager to see the 3D rendering of it!

----------


## regpye

The extruder can also be used for any Bowden type of printer. Simply print a foot to place the motor end in and then the extruder will become a stand-alone Bowden ewxtruder.

Picture-050.jpgPicture-034.jpgPicture-004.jpg

http://regpye.com.au/Smartrap/SmartRap geared extruder L.stl
Left handed exit

http://regpye.com.au/Smartrap/SmartRap geared extruder R.stl
Right handed exit

----------


## Roxy

> The extruder can also be used for any Bowden type of printer. Simply print a foot to place the motor end in and then the extruder will become a stand-alone Bowden ewxtruder.
> 
> Picture-050.jpgPicture-034.jpgPicture-004.jpg
> 
> http://regpye.com.au/Smartrap/SmartRap geared extruder L.stl
> Left handed exit
> 
> http://regpye.com.au/Smartrap/SmartRap geared extruder R.stl
> Right handed exit


I really try hard to not nit-pick!  But those links don't work!   :Smile:  I got the left handed side .STL files by using:

regpye.com.au/Smartrap/SmartRap%20geared%20extruder%20L.stl

And I think the right handed one points to the same thing as the left handed one!    Even if I manually change the link to:  regpye.com.au/Smartrap/SmartRap%20geared%20extruder%20R.stl I get the same thing.

OK!  Enough complaining!   Do you have the .stl file for where the switch mounts and the lever that presses on it?

I was looking at your web site.  Your work bench is much cleaner and more tidy than mine!!!  With that said...  My code is very clean!  At least the code I know I'm going to release for others to see!    :Smile: 

I laughed when I saw you stuck regpye on your .stl file!   I have that same trait.   I stick Roxy on most .stl files I design:  http://3dprintboard.com/showthread.p...-Roxy-Iris-Box    You can see how messy my work area is.   The printer barely has room to move the bed back and forth.   It squished the bag of potato chips you can see behind the printer.

----------


## regpye

> I really try hard to not nit-pick!  But those links don't work!   I got the left handed side .STL files by using:
> 
> regpye.com.au/Smartrap/SmartRap%20geared%20extruder%20L.stl
> 
> And I think the right handed one points to the same thing as the left handed one!    Even if I manually change the link to:  regpye.com.au/Smartrap/SmartRap%20geared%20extruder%20R.stl I get the same thing.
> 
> OK!  Enough complaining!   Do you have the .stl file for where the switch mounts and the lever that presses on it?
> 
> I was looking at your web site.  Your work bench is much cleaner and more tidy than mine!!!  With that said...  My code is very clean!  At least the code I know I'm going to release for others to see!   
> ...


Sorry for the wrong file being up, it has been corrected now.
http://regpye.com.au/Smartrap/SmartRap%20geared%20extruder%20R.stl

----------


## regpye

> Do you have the .stl file for where the switch mounts and the lever that presses on it?


Yes, I am still working on that with an update.  I found that when I made the arm longer it also brought some additional movement with it that was not wanted.
I have re-designed it again with a teflon guide (3mm tube) to stop any sideways movement. Not tested it out yet, but I am sure it will do the trick.
Let me test first and then I will make the files available.

----------


## Roxy

> Yes, I am still working on that with an update.  I found that when I made the arm longer it also brought some additional movement with it that was not wanted.
> I have re-designed it again with a teflon guide (3mm tube) to stop any sideways movement. Not tested it out yet, but I am sure it will do the trick.
> Let me test first and then I will make the files available.


I was wondering about that very thing.   I was wondering if making a big fork on the lever where one prong pressed very gently on each side of a block would keep it aligned.   I don't know exactly what you have done looks like.   So what I'm thinking about might not even make sense.   But with a long arm, and slop in the pivot hinge is going to let stuff wiggle at the end.  The idea was to not have any wiggle because the prongs would be pressing (very gently) on each side of a block.

----------


## regpye

> I was wondering about that very thing.   I was wondering if making a big fork on the lever where one prong pressed very gently on each side of a block would keep it aligned.   I don't know exactly what you have done looks like.   So what I'm thinking about might not even make sense.   But with a long arm, and slop in the pivot hinge is going to let stuff wiggle at the end.  The idea was to not have any wiggle because the prongs would be pressing (very gently) on each side of a block.


I have managed to design a part that has no wiggle whatever. Need to test it out next. Time is my biggest problem, I just got back from the city, 3.5 hours drive each way, so the day has gone (just to get a few things like wire and screws)  I will have a rest for the rest of the day, can't work when I am too tired.
Pretty excited about the new build though, so maybe I will get back into it later this evening.

----------


## regpye

Update on progress so far with the SmartRaps. Should be ready soon to test again.

Picture-051.jpg

----------


## Roxy

> Update on progress so far with the SmartRaps. Should be ready soon to test again.
> 
> Picture-051.jpg


Look at all those orphan PrintrBoards needing a good home!!!

----------


## regpye

> Look at all those orphan PrintrBoards needing a good home!!!


Yes I am working on that.
Update to present design.
I have completed another machine with the extended lever for auto bed leveling and tested it.
 I am still not satisfied that it is good enough, so I have redesigned again and have printed out the parts already.
I will make the changes to one of the machines and test again and report back.

----------


## Roxy

I screwed up again.  I hit Edit Post instead of reply...  And then vBulletin didn't think I should change it back...  ARGGHHHH.....


If your configuration.h setting for  Z_PROBE_OFFSET_FROM_EXTRUDER is not  in the range of 0 to -1 mm you are going to have issues!    :Smile:    That's just my gut hunch telling me that!

----------


## regpye

> I screwed up again.  I hit Edit Post instead of reply...  And then vBulletin didn't think I should change it back...  ARGGHHHH.....
> 
> 
> If your configuration.h setting for  Z_PROBE_OFFSET_FROM_EXTRUDER is not  in the range of 0 to -1 mm you are going to have issues!      That's just my gut hunch telling me that!


I am using the second to last hardware change with the same software settings. I have a negative offset and it is working fine.

 // these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
  #define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4// 

I have the hardware built for the next version with a modified head bracket that uses even less pressure to trigger the probe.  I will wire the machine up over the weekend and test again.  All the printers to date I am keeping with their own setup so that I can compare the differences.  When I find the best of them all I will modify them all to be the same (just a matter of building a new head for them)

What I have noticed is that the nozzle will not lift before homing  when I hit a G28. I have overcome that by adding a lift in the slicing code. Lifts OK between probings.

----------


## Roxy

> I am using the second to last hardware change with the same software settings. I have a negative offset and it is working fine.
> 
>  // these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
>   #define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
>   #define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
>   #define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4// 
> 
> I have the hardware built for the next version with a modified head bracket that uses even less pressure to trigger the probe.  I will wire the machine up over the weekend and test again.  All the printers to date I am keeping with their own setup so that I can compare the differences.  When I find the best of them all I will modify them all to be the same (just a matter of building a new head for them)
> 
> What I have noticed is that the nozzle will not lift before homing  when I hit a G28. I have overcome that by adding a lift in the slicing code. Lifts OK between probings.


I believe if you have Z_RAISE_BEFORE_HOMING set to some positive number (in configuration.h) , it will raise that much prior to doing anything.   But if we can't get that going the way you want it with Configuration.h settings, we can do a one line patch to make it how you want it.

----------


## regpye

> I believe if you have Z_RAISE_BEFORE_HOMING set to some positive number (in configuration.h) , it will raise that much prior to doing anything.   But if we can't get that going the way you want it with Configuration.h settings, we can do a one line patch to make it how you want it.


This is how it bis set now, but I have to lift for homing in the sliced code, it wont lift if I just use a G28.

 // these are the offsets to the probe relative to the extruder tip (Hotend - Probe)
  #define X_PROBE_OFFSET_FROM_EXTRUDER 0 //-25
  #define Y_PROBE_OFFSET_FROM_EXTRUDER 0 //-29
  #define Z_PROBE_OFFSET_FROM_EXTRUDER -4.4// -1.8  -9  -12.35


  #define Z_RAISE_BEFORE_HOMING 10       // (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 10    //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

----------


## Roxy

OK...   I'll take a look at the various G28 code paths in the morning.     Do you have SAFE Z HOMING turned on?  If you can send your current Configuration.h file that would speed things up for me.   The G28 code has a million code paths depending on what is enabled.

----------


## regpye

> OK...   I'll take a look at the various G28 code paths in the morning.     Do you have SAFE Z HOMING turned on?  If you can send your current Configuration.h file that would speed things up for me.   The G28 code has a million code paths depending on what is enabled.


I have attached the configuration.h file that I am using/

Configuration.h

----------


## Roxy

Well...   I'm surprised!   This isn't the way it is supposed to be.    With your options, it is true.   It homes the X & Y before it messes with the Z.   We need to add a do_blocking_move_relative() to lift the Z at the right time.  Please search for the following code block (ignoring the first line which needs to be added).    Insert the 1st line you see in front of the code block.    That should fix the issue for you.

------------------------   

*do_blocking_move_relative( 0.0, 0.0, 5.0);   <----<<<  Add this line just in front of this code block!*

  if((home_all_axis) || (code_seen(axis_codes[X_AXIS])))
      {
      #ifdef DUAL_X_CARRIAGE
        int tmp_extruder = active_extruder;
        extruder_duplication_enabled = false;
        active_extruder = !active_extruder;
        HOMEAXIS(X);
        inactive_extruder_x_pos = current_position[X_AXIS];
        active_extruder = tmp_extruder;
        HOMEAXIS(X);
        // reset state used by the different modes
        memcpy(raised_parked_position, current_position, sizeof(raised_parked_position));
        delayed_move_time = 0;
        active_extruder_parked = true; 
      #else      
        HOMEAXIS(X);
      #endif         
      }

      if((home_all_axis) || (code_seen(axis_codes[Y_AXIS]))) {
        HOMEAXIS(Y);
      }

----------


## regpye

> Well...   I'm surprised!   This isn't the way it is supposed to be.    With your options, it is true.   It homes the X & Y before it messes with the Z.   We need to add a do_blocking_move_relative() to lift the Z at the right time.  Please search for the following code block (ignoring the first line which needs to be added).    Insert the 1st line you see in front of the code block.    That should fix the issue for you.
> 
> ------------------------   
> 
> *do_blocking_move_relative( 0.0, 0.0, 5.0);   <----<<<  Add this line just in front of this code block!*
> 
>   if((home_all_axis) || (code_seen(axis_codes[X_AXIS])))
>       {
>       #ifdef DUAL_X_CARRIAGE
> ...



OK, I have done done that and this is what happens now:

G28
Nozzle raises about 10mm
X homes and then moves + about 10mm while Z is moving down at the same time a few mm.
Then X returns back to home position.
Y then homes, Z moving down a few mm at the same time. Z touches the bed briefly and then rises up a few mm, Y homes again (just a few mm to travel)
Z rises a few mm (maybe 5mm) and goes to centre position of bed and then homes, bounces and homes again, lifting to about 10mm.


G29 works perfectly.

----------


## Roxy

> OK, I have done done that and this is what happens now:
> 
> G28
> Nozzle raises about 10mm
> X homes and then moves + about 10mm while Z is moving down at the same time a few mm.
> Then X returns back to home position.
> Y then homes, Z moving down a few mm at the same time. Z touches the bed briefly and then rises up a few mm, Y homes again (just a few mm to travel)
> Z rises a few mm (maybe 5mm) and goes to centre position of bed and then homes, bounces and homes again, lifting to about 10mm.
> 
> ...


I think we better take that new line out of the firmware and just use the manual G-Code command to raise the Z-Axis prior to doing the G28 in the start up code.  The current_position[] array is supposed to have everything the do_blocking_move() routines need but it is possible stuff isn't initialized that early in the process.

I've run into this type of behavior before and had to use plan_set_position(), plan_buffer_line() and st_synchronize() together to work around the problem.   I'll keep looking at it, but it is safest not have that extra line of code in the firmware until we know why it isn't working.

How disruptive for your users would it be to have a G-Code command to lift the nozzle prior to a G28 command ?   I know we can fix the firmware to handle this if we have to, but the problem is it is very difficult to debug these kind of issues when you don't have the actual machine in front of you.

----------


## regpye

> I think we better take that new line out of the firmware and just use the manual G-Code command to raise the Z-Axis prior to doing the G28 in the start up code.  The current_position[] array is supposed to have everything the do_blocking_move() routines need but it is possible stuff isn't initialized that early in the process.
> 
> I've run into this type of behavior before and had to use plan_set_position(), plan_buffer_line() and st_synchronize() together to work around the problem.   I'll keep looking at it, but it is safest not have that extra line of code in the firmware until we know why it isn't working.
> 
> How disruptive for your users would it be to have a G-Code command to lift the nozzle prior to a G28 command ?   I know we can fix the firmware to handle this if we have to, but the problem is it is very difficult to debug these kind of issues when you don't have the actual machine in front of you.


I am able to add some code when slicing to do the lift, that works fine. Just that everyone would have to use this front end code when slicing each part. If using just the G28 it will drag on the bed before homing and that throws all the calculations out a mile.
I will remove that line and wait for some feedback from you.

----------


## Roxy

> I am able to add some code when slicing to do the lift, that works fine. Just that everyone would have to use this front end code when slicing each part. If using just the G28 it will drag on the bed before homing and that throws all the calculations out a mile.
> I will remove that line and wait for some feedback from you.


Can you also send your current Marlin_Main.cpp file?   

The easy and nice way to do the lift is using the do_blocking_move() functions.   But what I can do is the equivalent with the lower level functions and get that working as it should.  And it would be easier to just insert them into your Marlin_Main.cpp file and send that back instead of writing up directions for you to make the change.  But until that is done, I guess you can continue testing with the 'Start Up GCode' alterations.     I do agree it would be better for your users to not have to use special 'Start Up GCode' !   That is kind of asking for support problems.

----------


## regpye

> Can you also send your current Marlin_Main.cpp file?   
> 
> The easy and nice way to do the lift is using the do_blocking_move() functions.   But what I can do is the equivalent with the lower level functions and get that working as it should.  And it would be easier to just insert them into your Marlin_Main.cpp file and send that back instead of writing up directions for you to make the change.  But until that is done, I guess you can continue testing with the 'Start Up GCode' alterations.     I do agree it would be better for your users to not have to use special 'Start Up GCode' !   That is kind of asking for support problems.


Attaching mainMarlin_main.zip

----------


## Roxy

It will be a couple days...  I'm swamped!

----------


## regpye

> It will be a couple days...  I'm swamped!


Me too, being retired doesn't mean I am not still very busy.

Would it be possible to have the head return to X0, Y0 at the end of probing?

That would save me having to do it is the start code as well.

I took that line of code out and tried it out again.
The Z does lift, but it lifts after the X and Y have homed instead of before they home.

Thanks, take your time.

----------


## Roxy

I found a number of things that I think were a problem in your Marlin_Main.cpp.    First,  in the run_z_probe() function you were missing these lines:
        // we have to let the planner know where we are right now as it is not where we said to go.
    zPosition = st_get_position_mm(Z_AXIS);
    plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS]);

    // move up the retract distance
    zPosition += home_retract_mm(Z_AXIS);
    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();

    // move back down slowly to find bed
    feedrate = homing_feedrate[Z_AXIS]/4;
    zPosition -= home_retract_mm(Z_AXIS) * 2;
    plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
    st_synchronize();
I don't think you meant to delete them.  But if you did, I put them back in the file so you are going to have to remove them again.   These lines are important because when it is trying to touch the bed with the Z-Probe it goes at a higher speed at first, and then once it touches, it backs off and does it again at a slower (and more accurate) speed.

I actually compiled your modified Marlin_Main.cpp file that I'm sending back to you and loaded it into my printer.   

When you do a G28, you are going to see the nozzle move up, and then move down and up 3 times.   This is just to confirm the G28 code is going to raise the nozzle when it starts.  After you see it do that...  Go to line 1284 and delete the 6 lines of C code that do that.  (and of course...  Recompile and load it into your board)

For the G29 stuff...   You need to go into your Configuration.h file and set:

    #define AUTO_BED_LEVELING_GRID_POINTS 5

Is your origin in the front left of the bed?  I assume that was where it was and set the G29 to use that as the origin.   If this is not true, go to line 1511 of Marlin_Main.cpp and enable the #define for where your origin is.  That will setup the Bed Level Topology map so you can see how high or low a given spot is on your bed.    (Do a G29 n 4 T)  

When you do the G29     Watch the Z-Probe.  After it takes the measurement, it raises.  And then it raises again.  We might have over done it.   And it is possible the problem we were fighting is related to that missing code in the run_z_probe() function.      Let me know if you think it is raising twice on your machine.  If so, we can pull out the extra lift.

At the end of the G29 I have it raise the nozzle (and then once again, I think we see the Z go up twice because the retract_z_probe() function is doing it too) and then move it to (x,y) = (100,100).   I know you said (x,y) = (0,0) but isn't (100,100) more useful because that is in the center of the bed???  If you really want the nozzle to goto (x,y) = (0,0) you will see the line that makes that happen at line # 1790.   However, even if you want it at (0,0) I would encourage you to make it (5,5) because at (0,0) you are going to trigger the X & Y end-stops.

Also, It was easier to put the M48 Z-Probe_Repeatability code into your Marlin_Main.cpp than to work around it when I was making sure your code compiled.   So...   If you want to see how accurate your Z-Probe is, just give it a command like:   M48 x 100 y 100 n 10 v 4    Or...  If you want to stress the X & Y axis while taking measurements give it a M48 x 100 y 100 n 10 v 4 L 6

----------


## regpye

> I found a number of things that I think were a problem in your Marlin_Main.cpp.    First,  in the run_z_probe() function you were missing these lines:
>         // we have to let the planner know where we are right now as it is not where we said to go.
>     zPosition = st_get_position_mm(Z_AXIS);
>     plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS]);
> 
>     // move up the retract distance
>     zPosition += home_retract_mm(Z_AXIS);
>     plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], zPosition, current_position[E_AXIS], feedrate/60, active_extruder);
>     st_synchronize();
> ...


Wow! Thanks for all of that, you have been busy. I will give it all a try this morning.
I have been busy too and have made a build page of one of these little machines that this code will be working on.
http://regpye.com.au/SmartRap%20builds.html

----------


## Roxy

> Wow! Thanks for all of that, you have been busy. I will give it all a try this morning.
> I have been busy too and have made a build page of one of these little machines that this code will be working on.
> http://regpye.com.au/SmartRap%20builds.html


Wow!  That is a clean design!

Back to the double raising of the Z-Axis.   If you agree it is doing that...   Probably we should make the 

#define  Z_RAISE_BETWEEN_PROBINGS 2

The reason is...  You only deflect less than 1mm to activate the Z-Probe.   Going up a whole bunch is making the double raising too much now that the code (very likely) is getting the nozzle off of the bed after a measurment.   But I don't have a machine to test on.

----------


## regpye

> Wow!  That is a clean design!


OK, I have done all of that and checked it.
The G28 second lift (EDIT)  is really not needed now as the (EDIT) first lift takes care of the problem we had before.
I changed the G29  final home to 5x 5 y 2z because I run a routine that sends a length of  filament down before starting the print. I like to see a line of filament come out clean before hand.
Ran all the tests and didn't see any problem except for the second lift when using a G28.
The machine design really needs a bit more support for the bed axis, too much physical flex at the X positive side. I think I will redesign another machine with wider Y rods so that the support is more even across the bed.


SENDING:M48 x 100 y 100 n 10 v 4
M48 Z-Probe Repeatability test.   Version 1.85
Positioning probe for the test.
1 of 10   z: 1.433000 mean: 1.433000   sigma: 0.000000
2 of 10   z: 1.493750 mean: 1.463375   sigma: 0.030375
3 of 10   z: 1.451500 mean: 1.459417   sigma: 0.025425
4 of 10   z: 1.464750 mean: 1.460750   sigma: 0.022139
5 of 10   z: 1.440750 mean: 1.456750   sigma: 0.021357
6 of 10   z: 1.434750 mean: 1.453083   sigma: 0.021150
7 of 10   z: 1.437750 mean: 1.450893   sigma: 0.020303
8 of 10   z: 1.439000 mean: 1.449406   sigma: 0.019395
9 of 10   z: 1.415750 mean: 1.445667   sigma: 0.021124
10 of 10   z: 1.471500 mean: 1.448250   sigma: 0.021487
Mean: 1.448250
Standard Deviation: 0.021487
echo:endstops hit:  Z:-3.53






SENDING:M48 x 100 y 100 n 10 v 4 L 6
M48 Z-Probe Repeatability test.   Version 1.85
Positioning probe for the test.
x: 101.74y: 90.15
x: 98.54y: 88.09
x: 96.06y: 89.73
x: 97.38y: 93.51
x: 92.78y: 91.70
1 of 10   z: 1.439000 mean: 1.439000   sigma: 0.000000
x: 106.50y: 111.26
x: 110.07y: 109.73
x: 110.29y: 106.18
x: 113.81y: 105.86
x: 112.22y: 104.45
2 of 10   z: 1.488250 mean: 1.463625   sigma: 0.024625
x: 89.80y: 104.12
x: 85.02y: 100.79
x: 84.41y: 96.40
x: 83.04y: 89.40
x: 81.89y: 84.25
3 of 10   z: 1.490250 mean: 1.472500   sigma: 0.023702
x: 119.15y: 83.93
x: 114.34y: 79.52
x: 111.47y: 83.62
x: 110.44y: 79.51
x: 105.26y: 82.79
4 of 10   z: 1.483000 mean: 1.475125   sigma: 0.021024
x: 96.87y: 82.27
x: 94.38y: 86.09
x: 88.67y: 86.01
x: 86.42y: 89.77
x: 83.20y: 93.55
5 of 10   z: 1.499750 mean: 1.480050   sigma: 0.021228
x: 102.26y: 112.80
x: 104.39y: 114.34
x: 108.33y: 117.08
x: 112.47y: 114.34
x: 112.73y: 112.73
6 of 10   z: 1.611000 mean: 1.501875   sigma: 0.052509
x: 119.40y: 126.70
x: 116.78y: 124.87
x: 110.11y: 125.03
x: 102.93y: 127.85
x: 97.82y: 124.90
7 of 10   z: 1.738250 mean: 1.535643   sigma: 0.095942
x: 92.02y: 115.01
x: 87.50y: 112.95
x: 86.42y: 111.81
x: 88.86y: 106.70
x: 88.32y: 105.70
8 of 10   z: 1.447500 mean: 1.524625   sigma: 0.094361
x: 89.22y: 92.73
x: 92.50y: 91.96
x: 93.71y: 92.23
x: 94.26y: 91.81
x: 97.00y: 92.58
9 of 10   z: 1.450500 mean: 1.516389   sigma: 0.091964
x: 88.72y: 104.10
x: 90.17y: 106.88
x: 91.45y: 106.92
x: 92.09y: 107.64
x: 93.19y: 113.37
10 of 10   z: 1.464500 mean: 1.511200   sigma: 0.088623
Mean: 1.511200
Standard Deviation: 0.088623
echo:endstops hit:  Z:-3.54




SENDING:G29 n 4 T
Eqn coefficients: a: -0.01 b: -0.00 d: 5.30
Correct +.14 with one clockwise turn.


Bed Height Topography:
 +0.75933 +0.21208 --0.36417 --0.93592
 +0.77933 +0.35908 --0.32967 --1.09992
 +0.66358 +0.22008 --0.28592 --0.69142
 +0.85158 +0.50908 --0.14017 --0.50692


planeNormal x: 0.01 y: 0.00 z: 1.00


Bed Level Correction Matrix:
1.00 0.00 -0.01
0.00 1.00 -0.00
0.01 0.00 1.00
echo:endstops hit:  Z:-1.57

----------


## regpye

> Wow!  That is a clean design!
> 
> Back to the double raising of the Z-Axis.   If you agree it is doing that...   Probably we should make the 
> 
> #define  Z_RAISE_BETWEEN_PROBINGS 2
> 
> The reason is...  You only deflect less than 1mm to activate the Z-Probe.   Going up a whole bunch is making the double raising too much now that the code (very likely) is getting the nozzle off of the bed after a measurment.   But I don't have a machine to test on.


OK, I will try that first. I am running a test print that will take about 40 minutes and then I will make the change and try again.

----------


## Roxy

> OK, I will try that first. I am running a test print that will take about 40 minutes and then I will make the change and try again.


And...   Depending upon what happens when you bump that down to a 'reasonable' number...   You may want to go to the very end of the run_z_probe() function and delete the code we added earlier.

//SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() raising nozzle." );
do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
//SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() done raising nozzle." );
}     <---<<<  Leave that brace in!

I think this is why we are getting the double lift.    But be ready with your finger on the reset button if you take that line out!!!!

Looking at your Standard Deviation...  Those numbers (.02) are a little bit on the big side.   You should still get good prints, but you are getting close to an order of magnitude of your layer height.     Oh!   I just noticed you did the Z-Probe Standard Deviation both ways.   The one that stresses the X & Y axis is concerning.  .08 is getting too big in my opinion.  The fact you get .02 without X & Y movement implies you have .05mm of slop in the X & Y axis.   It is hard to say without the machine in front of me, but somehow moving the X & Y is adding .05mm of slop to the measurement ?????

On the bed topography.   You have 1.5 mm or more slope from left to right.   Can that be adjusted out on your design?

It's bed time for me.    With a little luck, I'll get 9 hours of sleep tonight!

----------


## regpye

> And...   Depending upon what happens when you bump that down to a 'reasonable' number...   You may want to go to the very end of the run_z_probe() function and delete the code we added earlier.
> 
> //SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() raising nozzle." );
> do_blocking_move_relative( 0.0, 0.0, (float) Z_RAISE_BETWEEN_PROBINGS );
> //SERIAL_PROTOCOLLNPGM( "At end of run_z_probe() done raising nozzle." );
> }     <---<<<  Leave that brace in!
> 
> I think this is why we are getting the double lift.    But be ready with your finger on the reset button if you take that line out!!!!
> 
> ...


Yes I can easy make adjustments to manually level the bed better.  Can there be some code that will assist in checking that easy, like measure each corner to see what difference there is?

I have taken out that line that you mentioned. Didn't see any difference when testing another print.  The initial Z lift is close to 40mm I would guess.

----------


## regpye

> Yes I can easy make adjustments to manually level the bed better.  Can there be some code that will assist in checking that easy, like measure each corner to see what difference there is?
> 
> I have taken out that line that you mentioned. Didn't see any difference when testing another print.  The initial Z lift is close to 40mm I would guess.


I have put that line back again. After removing it the bed leveling went haywire?? It didn't work properly for some reason. Tried it a couple of times and it was reading the levels wrong and the nozzle didn't come near the plate on one side and was touching on the other side.  Put the line back and it is working again.
The initial lift is still about 40mm (guessing height)

----------


## Roxy

> Yes I can easy make adjustments to manually level  the bed better.  Can there be some code that will assist in checking  that easy, like measure each corner to see what difference there is?


That is one of the big benefits of the Bed Level Topology map.   If you have the bed orientated the same way you have the #define's setup...   You should be able to look at the topology map and picture that over your bed.   If one corner is higher than the others, lower it and re-run the test.  You will get a feel for how it zero's out.   The biggest problem is if you correct one corner the right amount, the other corners sort of 'float' and it will be closer, but it won't be right.   You keep getting closer and closer, but you never quite get there.   And with a Standard Deviation of .02 for the Z-Probe measurements, you won't ever get it flatter than that.  For the first couple of iterations, you can just use G29 n 2 T   to get the readings quicker.





> I have put that line back again. After removing it the bed leveling went haywire?? It didn't work properly for some reason. Tried it a couple of times and it was reading the levels wrong and the nozzle didn't come near the plate on one side and was touching on the other side.  Put the line back and it is working again.
> The initial lift is still about 40mm (guessing height)


OK.   There is another place we can try.  Or...   If it is behaving rationally, we can just leave it.   I was thinking a little bit more on the problem.   The nozzle has to raise enough to have clearance, but it has to raise even more because your bed it tilted.  If you measure a low spot, and raise it enough to have clearance, what happens if you move the nozzle to a high spot?  You will scrape the nozzle.  Raising it 4 or 5 mm above the bed might not be a bad thing to do in general.

And switching topics...   I don't know which axis (X or Y) is the one that the nozzle is moving on.   But if you do a set of  M48 commands at both sides I bet you see a noticeably difference.   My guess is doing an M48 x 25 y 25 n 10 v 4   is probably going to give a noticeably smaller Standard Deviation than doing a M48 x 175 y 175 n 10 v 4   If that is really true, the extra amount of error is coming in because the Z-Axis height is only set on the one side.   My guess is adding the L 6 parameter to add legs of travel in X & Y might also show up on the far side.   But if you do that, you have to be far enough away from the very edge that it can sweep out arcs.   It won't go past the edge of your bed, but you will lose some of the legs of travel between moves if it tries to head off the bed.

Because of the design of the machine, there isn't really an easy way to improve that (if this assertion is true).  But it is still worth while to know because what it will mean is you can print with higher accuracy closer to the Z-Axis support than on the far end of the X (or maybe it is Y) Axis.

----------


## regpye

> That is one of the big benefits of the Bed Level Topology map.   If you have the bed orientated the same way you have the #define's setup...   You should be able to look at the topology map and picture that over your bed.   If one corner is higher than the others, lower it and re-run the test.  You will get a feel for how it zero's out.   The biggest problem is if you correct one corner the right amount, the other corners sort of 'float' and it will be closer, but it won't be right.   You keep getting closer and closer, but you never quite get there.   And with a Standard Deviation of .02 for the Z-Probe measurements, you won't ever get it flatter than that.  For the first couple of iterations, you can just use G29 n 2 T   to get the readings quicker.
> 
> 
> 
> 
> OK.   There is another place we can try.  Or...   If it is behaving rationally, we can just leave it.   I was thinking a little bit more on the problem.   The nozzle has to raise enough to have clearance, but it has to raise even more because your bed it tilted.  If you measure a low spot, and raise it enough to have clearance, what happens if you move the nozzle to a high spot?  You will scrape the nozzle.  Raising it 4 or 5 mm above the bed might not be a bad thing to do in general.
> 
> And switching topics...   I don't know which axis (X or Y) is the one that the nozzle is moving on.   But if you do a set of  M48 commands at both sides I bet you see a noticeably difference.   My guess is doing an M48 x 25 y 25 n 10 v 4   is probably going to give a noticeably smaller Standard Deviation than doing a M48 x 175 y 175 n 10 v 4   If that is really true, the extra amount of error is coming in because the Z-Axis height is only set on the one side.   My guess is adding the L 6 parameter to add legs of travel in X & Y might also show up on the far side.   But if you do that, you have to be far enough away from the very edge that it can sweep out arcs.   It won't go past the edge of your bed, but you will lose some of the legs of travel between moves if it tries to head off the bed.
> 
> Because of the design of the machine, there isn't really an easy way to improve that (if this assertion is true).  But it is still worth while to know because what it will mean is you can print with higher accuracy closer to the Z-Axis support than on the far end of the X (or maybe it is Y) Axis.


I have made a change to a line and now it is working pretty good.
// Keep this one.  But delete the rest after it
do_blocking_move_relative( 0, 0, 5.0);        // <---<<< for RegPye do_blocking_move_relative( 0, 0, 20.0);

The main problem now is not the coding, but the machine.  There is too much flex on the right hand side of the bed plate. The nozzle is traveling on the X axis. The left hand side is fully supported by the bearings that are too close together and they need to be spaced further apart so that the floating end of the bed is supported.  This is causing flex when doing the probing and although it doesn't seem to flex much, it will show up in the calculations.  I guess I will need to design and build another one. Should be able to use the code as it is now, working well.  Thanks for all your hard work.

----------


## Roxy

> I have made a change to a line and now it is working pretty good.
> // Keep this one.  But delete the rest after it
> do_blocking_move_relative( 0, 0, 5.0);        // <---<<< for RegPye do_blocking_move_relative( 0, 0, 20.0);


Yeah...  20mm is excessive.  But I didn't want to scrape the nozzle against the bed!




> The main problem now is not the coding, but the machine.  There is too much flex on the right hand side of the bed plate.


Did you actually get M48 numbers for both sides of the bed?   You should see any flex show up as a bigger Standard Deviation of error in the measurements.  On this kind of stuff, I like to have measurements before and after so I know if what I changed actually improved things.  And if so...  By how much.




> The nozzle is traveling on the X axis. The left hand side is fully supported by the bearings that are too close together and they need to be spaced further apart so that the floating end of the bed is supported.  This is causing flex when doing the probing and although it doesn't seem to flex much, it will show up in the calculations.  I guess I will need to design and build another one. Should be able to use the code as it is now, working well.  Thanks for all your hard work.


OK.  Understood!   Also, consider what happens if you print something heavy on that side of the bed.  It will start warping just because the bed is being pushed down by the weight of the object being printed.

----------


## regpye

> Did you actually get M48 numbers for both sides of the bed?
> Yes it was giving numbers for both sides, no problem there.
> 
> OK.  Understood!   Also, consider what happens if you print something heavy on that side of the bed.  It will start warping just because the bed is being pushed down by the weight of the object being printed.


Yes, I was  bit concerned when I saw the original design and thought that it could be a problem. It turns out I was correct. Being as I have re-designed the whole machine so far. I will take it a bit further and re-design the layout better too, making the bed carriage wider and also more symmetrical.  I can definitely see some flexing when the X is extended and the nozzle presses against the bed, there is too little support under the bed at that location. I have managed to get some good prints though. so a change or two can only make the machine better.

----------


## Roxy

> Yes, I was  bit concerned when I saw the original design and thought that it could be a problem. It turns out I was correct. 
> ...
> I can definitely see some flexing when the X is extended and the nozzle presses against the bed, there is too little support under the bed at that location. I have managed to get some good prints though. so a change or two can only make the machine better.


I've been thinking about this since I read it earlier today.  The Bed Level Probing is different than normal printing.   When you are printing you are going to have the issue of the weight of the nozzle and such flexing the support structure.   But when you are probing, you get that error plus the error of pressing down on the bed.   

This would be a horrible hack.  But I wonder if putting in some kind of fudge factor depending upon how far out you are on the X-Axis would clean up the probing problem.   And it wouldn't be that difficult to calibrate either.     When you move the nozzle all the way out, you could visually see exactly when the nozzle just barely touched the bed.  And then you could see how much the bed deflected before the probe detected it.   That number is going to be different from what happens when you do the same thing without the X-Axis extended.

With those two numbers, it might be possible to 'scale' the numbers that are being generated during the G29.    Because during a normal print, you don't want to be pressing down on things.   You only have to deal with the 'normal' deflection.   And if the above thoughts have merit and the G29 was 'corrected' to handle that...  The routine bed leveling will handle the 'normal' case.   Do you care to give that idea some thought and improve on it?

----------


## regpye

> I've been thinking about this since I read it earlier today.  The Bed Level Probing is different than normal printing.   When you are printing you are going to have the issue of the weight of the nozzle and such flexing the support structure.   But when you are probing, you get that error plus the error of pressing down on the bed.   
> 
> This would be a horrible hack.  But I wonder if putting in some kind of fudge factor depending upon how far out you are on the X-Axis would clean up the probing problem.   And it wouldn't be that difficult to calibrate either.     When you move the nozzle all the way out, you could visually see exactly when the nozzle just barely touched the bed.  And then you could see how much the bed deflected before the probe detected it.   That number is going to be different from what happens when you do the same thing without the X-Axis extended.
> 
> With those two numbers, it might be possible to 'scale' the numbers that are being generated during the G29.    Because during a normal print, you don't want to be pressing down on things.   You only have to deal with the 'normal' deflection.   And if the above thoughts have merit and the G29 was 'corrected' to handle that...  The routine bed leveling will handle the 'normal' case.   Do you care to give that idea some thought and improve on it?


I had been thinking about the very same thing a while back, but I have no idea of how to implement it. There are a number of machines already made that this would be very useful for.
My idea is to get the machine right so that there is no need for it, however many people will still have the issues that we have discovered.
Is there some way that this fudge factor can be turned on or off so that the code can be used for a machine that needs fudge and one that does not?

I have re-designed a new Y plate and it has almost finished printing. It means a total re-build of the machine so I guess it is easier to build yet another machine and leave all the others intact.

----------


## Roxy

> I had been thinking about the very same thing a while back, but I have no idea of how to implement it. There are a number of machines already made that this would be very useful for.
> My idea is to get the machine right so that there is no need for it, however many people will still have the issues that we have discovered.
> Is there some way that this fudge factor can be turned on or off so that the code can be used for a machine that needs fudge and one that does not?


I do not think this is very difficult to do.  There would be a couple of approaches.   Probably the simplest and most straight forward method would be to modify the run_z_probe() function to return values that were compensated.   These values would bubble up to the G29 code that is collecting them and the Bed_Level_Correction_Matrix that is needed for the rest of the moves would have this factor built into it.

It would not be difficult to make it selectable on either of two basis.  It could be made so it was optional for a machine and gets built into the firmware with a #define in the configuration.h file.   It would also be very straight forward to add a parameter to the G29 command to build the Bed_Level_Correction_Matrix with this factored in.

Assuming the firmware existed, the process of setting up a printer to use this would not be hard.   It would involve taking a measurement on one side and comparing it to when you manually adjusted the nozzle to just barely touch the bed.   And then repeating it on the other side of the bed.




> I have re-designed a new Y plate and it has almost finished printing. It means a total re-build of the machine so I guess it is easier to build yet another machine and leave all the others intact.


Hey!  I have an idea...  Would it make sense to get one machine all the way working before you ramp production?       :Smile:

----------


## regpye

> I do not think this is very difficult to do.  There would be a couple of approaches.   Probably the simplest and most straight forward method would be to modify the run_z_probe() function to return values that were compensated.   These values would bubble up to the G29 code that is collecting them and the Bed_Level_Correction_Matrix that is needed for the rest of the moves would have this factor built into it.
> 
> It would not be difficult to make it selectable on either of two basis.  It could be made so it was optional for a machine and gets built into the firmware with a #define in the configuration.h file.   It would also be very straight forward to add a parameter to the G29 command to build the Bed_Level_Correction_Matrix with this factored in.
> 
> Assuming the firmware existed, the process of setting up a printer to use this would not be hard.   It would involve taking a measurement on one side and comparing it to when you manually adjusted the nozzle to just barely touch the bed.   And then repeating it on the other side of the bed.
> 
> 
> 
> Hey!  I have an idea...  Would it make sense to get one machine all the way working before you ramp production?


Sounds like you can do it.
I have the new design already printed and I have started to assemble, however I have to go to the city again today, so the whole day will be lost, it will be late when I get back and after driving for about 8 hours I will be too tired to do anything. (but sleep)
Having a few different machines will be a good thing because we can test all sorts of configurations and code changes.  I wish I had followed my gut feeling in the beginning and made this latest change to the hardware from the beginning. At least it will be a better machine as the end result, worth it I feel to spend the time and money now in development. (Anyway, it is fun)

I have about 6 already built that could use the new code and about 18 sets of parts that have been printed that if built could use the new code. There are plenty of people out there that have their own version of this machine and will be facing the same problems as they were all based on the original design that fist came out using a servo (that model also suffered from the same problem, but not as much)

----------


## regpye

> I do not think this is very difficult to do.  There would be a couple of approaches.   Probably the simplest and most straight forward method would be to modify the run_z_probe() function to return values that were compensated.   These values would bubble up to the G29 code that is collecting them and the Bed_Level_Correction_Matrix that is needed for the rest of the moves would have this factor built into it.
> 
> It would not be difficult to make it selectable on either of two basis.  It could be made so it was optional for a machine and gets built into the firmware with a #define in the configuration.h file.   It would also be very straight forward to add a parameter to the G29 command to build the Bed_Level_Correction_Matrix with this factored in.
> 
> Assuming the firmware existed, the process of setting up a printer to use this would not be hard.   It would involve taking a measurement on one side and comparing it to when you manually adjusted the nozzle to just barely touch the bed.   And then repeating it on the other side of the bed.
> 
> 
> 
> Hey!  I have an idea...  Would it make sense to get one machine all the way working before you ramp production?


I have shared the Marlin that we are working on with a few guys that also have a very similar machine on the SmartRap forum.
They are testing it too. Their machines are also the same configuration of the hardware. 
One of the guys is having a few issues, but I think the problem could be that he has an open z probe caused by the Bowden weight holding the probing mechanism to one side.  I had that happen to me once and recognized the same problems that he is having.

http://forums.reprap.org/read.php?34...614#msg-356614

----------


## KDog

Hi All, Nice to see you working on this.  I just got a printrbot metal simple.  It's using an induction sensor for autoleveling.  It's never extended or retracted as i just sits about 1 mm above the nozzle all the time.  The sensor detects the metal bed about 2-3 mm above it and acts as the sole z-endstop.  It was really simple to measure the offset and enter it into the firmware using M212.  I'm really impressed with this little printer.  I've since purchased another probe to install it on my bigger printer.  I'll let you know how it goes when I get it installed.

----------


## regpye

> Hi All, Nice to see you working on this.  I just got a printrbot metal simple.  It's using an induction sensor for autoleveling.  It's never extended or retracted as i just sits about 1 mm above the nozzle all the time.  The sensor detects the metal bed about 2-3 mm above it and acts as the sole z-endstop.  It was really simple to measure the offset and enter it into the firmware using M212.  I'm really impressed with this little printer.  I've since purchased another probe to install it on my bigger printer.  I'll let you know how it goes when I get it installed.


Great stuff, can you tell me more about the probe you are using, I would like to try it out too.

----------


## KDog

Here is the sensor: http://www.amazon.com/Cylindrical-In...J12A3-4-Z%2FBY

And here is a link where Brook Drumm explains how to set the offset: http://www.youtube.com/watch?v=lgVmN...hl2F_bmR01sjaA

Autoleveling is fun stuff.

----------


## regpye

Thanks for that, very interesting.

----------


## Roxy

> Hi All, Nice to see you working on this.  I just got a printrbot metal simple.  It's using an induction sensor for autoleveling.  It's never extended or retracted as i just sits about 1 mm above the nozzle all the time.  The sensor detects the metal bed about 2-3 mm above it and acts as the sole z-endstop.  It was really simple to measure the offset and enter it into the firmware using M212.  I'm really impressed with this little printer.  I've since purchased another probe to install it on my bigger printer.  I'll let you know how it goes when I get it installed.


It would be interesting to see how repeatable it is.   Can you be talked into loading the M48 code and running the test?

Please check out:  http://3dprintboard.com/showthread.p...atability-code

----------


## KDog

I could be talked into it but my nozzle clogged last night so am out of business until then.  Brook stated somewhere that repeatability was 0.1 - 0.2mm and this sounds right from what I've seen on the prints I've made so far.

BTW, Brook is a really nice guy and very accessible.  I'm sure he would be very interested in your repeatability measurements and may even contribute to the cause.  If you don't know the Printrbot story take a look.  He did a 25K kickstarter a few years ago that turned into over 800K.  He has done nothing but design newer and better printers since then and still sticks to the open source philosophy.  It looks like he is selling over 50 of the printrbot metal simples a day now.

----------


## Roxy

> I could be talked into it but my nozzle clogged last night so am out of business until then.  Brook stated somewhere that repeatability was 0.1 - 0.2mm and this sounds right from what I've seen on the prints I've made so far.


Your printer doesn't have to be able to print to install and/or run the M48 test.      .2mm sounds too high to get reliable prints.   If you are getting good results, my guess is you have better repeatability than that.

----------


## KDog

lol...maybe it said 0.01 to 0.02...doh!

----------

