Z axis callibration using Z_MAX endstop + recorded z_max_length

[felipesanches]

this is code for callibrating the z axis in a way similar to what makerbot does:

• you first position the nozzle tip in the position you consider to be z=0
• then you send M111 which will make the printer home z in the ZMAX endstop direction.
• It calculates the distance effectivelly travelled during homing and sets z_max_length with this value.
• It also stores it in EEPROM so that you dont have to callibrate the z axis everytime.

The benefits of this approach is that you dont need to mechanically adjust the endstop. The callibration procedure is completely done in software (logically), so it is more reliable and easier to callibrate.

[midopple]

Hi,

Nice idea but i have a big problem with 3 lines code. --> effective_travel[X_AXIS] = current_block->steps_x / axis_steps_per_unit[X_AXIS]; effective_travel[Y_AXIS] = current_block->steps_y / axis_steps_per_unit[Y_AXIS]; effective_travel[Z_AXIS] = current_block->steps_z / axis_steps_per_unit[Z_AXIS];

This lines will calculatet at every stepper step (ISR routine)

Normal the ISR take 20 µs and wenn the new move is load he takes 60-70 µs So it works up to 30000 steps / sec

second ISR is the UART, at 250 kbaud the ISR is called every 40 µs.

So if the ISR had to do 3 float division it takes longer then 80 µs and the UART ISR lost bytes and the max steprate is not possible.

[midopple]

There is a variable --> virtual_steps_z this varibale count up if the endstop is hit.

So i will make a move like Z200 with slow feedrate. then command st_synchronize(); after the move calc val = 200 - virtual_steps_z/steps_per_mm so no homing function change, no ISR change, ..

the hole cal is doing in the M111 function

[felipesanches]

great! I can fix that and commit again. Is it OK to use M111 for this feature, or would you prefer a different code value?

[midopple]

Is there a firmware which use this function ? If yes use the same code or look at http://reprap.org/wiki/Gcode

[midopple]

Question: Why useing template instead of template

[felipesanches]

I got build errors with template class but it compiles ok with template typename. I'm not sure why. Any idea?

[felipesanches]

This is the Makerbot callibration script:

(* Thing-O-Matic calibration script ) (** _) ( This script will guide you through **) (_ calibrating the start position ) (** on your Thing-O-Matic. ***)

M18 (This disables the stepper motors.) M01 (Move the build platform until the nozzle lies in the center, then turn the threaded rod until the nozzle just touches the surface without pressing into it. Then, press yes to continue.) G92 X0 Y0 Z0 A0 B0 (Declare the current position to be (0,0,0,0,0)) G162 Z F500 (Home Z axis maximum; go until reaching the end stop.) G161 X Y F2500 (Home X and Y axis minimum; go until reaching the end stop.) M131 X Y Z A B (record the current coordinates to the motherboard)

M00 (Congratulations, your coordinates are now saved! To tweak them, use the 'Motherboard Onboard Preferences' dialog in the Machine menu.
Note: You will need to re-generate your gcode files using a new profile in order to use these saved settings.)

[felipesanches]

As you can see, Makerbot uses a combination of M162 (home z max) and M131 (store coordinates to eeprom) to do something similar to the future discussed in this pull request.

M162 and M131 are not listed in the RepRap G-Code reference page.

M111 is already used, so we must choose another Mcode. I am not aware of any RepRap firmware with such feature so maybe we can simply define the standard.

[midopple]

I mean code like this, so homeing,ISR need no change and float effective_travel[3] = {0,0,0}; is also not need

  #if Z_HOME_DIR == 1
  case 111: // M111 - callibrate Z axis using Z_MAX and report detected z_max_length

//Set Z to zero
plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], 0, current_position[E_AXIS]);
destination[Z_AXIS] = 250;
feedrate = homing_feedrate[Z_AXIS] / 2;
    prepare_move();
st_synchronize();

    z_max_length = 250.00 - (virtual_steps_z / axis_steps_per_unit[Z_AXIS]);

    EEPROM_write_setting(z_max_length_address, z_max_length);

    showString(PSTR("z_max_length: ")); Serial.println(z_max_length);

    current_position[Z_AXIS] = z_max_length;
    current_position[Z_AXIS] += add_homing[Z_AXIS];

    plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);
virtual_steps_z = 0;

    break;

endif

[felipesanches]

OK. So the last thing left to decide is a proper M code for this routine, I think.

[felipesanches]

Since (a) this feature is not available in other reprap firmware (as far as I can tell) (b) M111 is already specified for something else and (c) it is not yet specified in the reprap gcode reference, then I decided to pick up an arbitrary Mcode = M204 (which is close to the correlated and deprecated M203 command) to use for this new feature. I hope it's good.

[jmgiacalone]

You should not use M204, it's already defined in Marlin, and I have just added it to the RepRap wiki's Gcodes page reprap.org/wiki/GCodes

Pick a(nother) number then add it to the wiki.

[felipesanches]

I picked M207 and documented it at that wikipage ( http://reprap.org/wiki/G-code#M207:_calibrate_z_axis_by_detecting_z_max_length ).

Please let me know if there's anything else needed to get this merged.

[felipesanches]

Please dont pull it yet. I'm dealing with a bug in this feature and I haven't yet figured out a good solution. I'll open a pull request again later.