Idea. New location for Z limit on UMO+

neotko · August 9, 2016

V4 Version update 24th August

The original idea didn't work, but all the Firmware changes (most of them) do work with this (I think final) version V4 that places the Endstop on the bottom. This mod make's you loose 10mm of Z print area, but for me it's worth.

You will need this printed part to hold the endstop on the bottom

https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo'>https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo'>https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo'>https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo

Also you will need new firmware with changes:

LIST of changes to the firmware to make this work

Configuration_adv.h#define X_HOME_RETRACT_MM 7 // Same values UM2 uses#define Y_HOME_RETRACT_MM 7 // Same values UM2 uses#define Z_HOME_RETRACT_MM 7 // Same values UM2 uses

Configuration.h#define X_HOME_DIR -1#define Y_HOME_DIR -1#define Z_HOME_DIR 1

ultralcd.cpp// New definitionsstatic void lcd_init_z_adjustment();static void lcd_prepare_info_z();static void lcd_prepare_adjust_z();// At the end of the menu. Edit. The 'prepare menu' static void lcd_prepare_menu()   MENU_ITEM(submenu, "Realign Z Offset", lcd_init_z_adjustment);// Content of new definitions/* OFFSET BED ALIGN */static void lcd_init_z_adjustment(){   Config_RetrieveSettings(); // reset to the stored settings   add_homeing[Z_AXIS] = 0;   // Reset Offset to 0 to prepare adjustments   enquecommand_P(PSTR("G28 Z")); // Move to Z bottom endstop   menu_action_submenu(lcd_prepare_info_z); // 1 - Show basic info and jump to lcd_prepare_info_z}static void lcd_prepare_info_z(){   enquecommand_P(PSTR("G1 Z30")); // Move to Z to A safe 30mm height This shouldn't hit um2 or umo+ hotend and could be 20 probably   lcd_implementation_draw_line(0, PSTR("- Redefine Z 0.00 -"));   lcd_implementation_draw_line(1, PSTR("Move the bed until"));   lcd_implementation_draw_line(2, PSTR("Kisses the nozzle"));   lcd_implementation_draw_line(3, PSTR("- Push to start -"));   // wait for Click to continue   if (LCD_CLICKED)   {       // clean screen to continue         lcd_implementation_draw_line(0, PSTR(""));         lcd_implementation_draw_line(1, PSTR(""));         lcd_implementation_draw_line(2, PSTR(""));         lcd_implementation_draw_line(3, PSTR(""));         lcd_quick_feedback();         menu_action_submenu(lcd_prepare_adjust_z);  // 2- Jump to lcd_prepare_adjust_z   }}static void lcd_prepare_adjust_z(){   if (encoderPosition != 0)   {       refresh_cmd_timeout();       current_position[Z_AXIS] += float((int)encoderPosition) * 0.02;       encoderPosition = 0;       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);       lcdDrawUpdate = 1;   }   if (lcdDrawUpdate)   {       lcd_implementation_drawedit(PSTR("Z Ooffset"), ftostr31(current_position[Z_AXIS]));       lcd_implementation_draw_line(3, PSTR("Push to Continue"));   }   if (LCD_CLICKED)   {       // set's current Z position as the 0       add_homeing[Z_AXIS] -= current_position[Z_AXIS];       // store all settings (including the new z-offset)       Config_StoreSettings();       // important: tell the printer that we are at z=0 now       current_position[Z_AXIS] = 0;       plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);       // move z down a few mm       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], 5.0f, current_position[E_AXIS], homing_feedrate[Z_AXIS]/60, active_extruder);       // important: inform the printer about the new position       current_position[Z_AXIS] = 5.0f;       // return to the previous menu       lcd_quick_feedback();       currentMenu = lcd_prepare_menu;       encoderPosition = 0;   }}

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

OLD IDEA & OLD TEXTS FROM HERE

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

Been thinking a lot about changing the z endstop to something more like um2, so I could redefine the z offset by firmware instead of hardware, since it's a bit pain in the arse to have to change it manually (yeah I know there are printed parts that allow you to screw up/down the endstop).

What do you guys think of this (specially @amedee).

By changing the endstop we could have a physical fixed point, but since it's on a non obstructive way, it would allow on umo+ to refit the z offset by firmware without the need of touching the hardware anymore.

On a perfect world that could allow to have a calibration UI like um2.

Edit: Also umo+ has extra holes (for a second extruder) to fit a printed part that would allow to do this quite easy.

EDIT: Idea almost done! Thanks & !

https://ultimaker.com/en/community/22120-idea-new-location-for-z-limit-on-umo?page=1&sort=#reply-153756

EDIT: Adapter to fully secure the new endstop location:

https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo

Edited August 26, 2016 by Guest

Dim3nsioneer · August 9, 2016

To be honest, I have no idea what you're talking about... could be me, sorry (on the other hand: what's the current temperature in Madrid...? )

I assume the labelled part is supposed to be the bed, correct? That top endswitch doesn't exist on an UM2, just one at the bottom...

Anyway, an endswitch has a proper direction to be pushed which should noch be changed as the switch itself could block before switching.

Edited August 9, 2016 by Guest

neotko · August 9, 2016

Indeed. The problem on umo+ it's that it physically limits the movement. While rotating the endstop the bed could still move beyond the limit. By changing the endstop to this position the bed would hit the endstop but it's movement won't be block by it, therefore it would be posible to redefine the offset by firmware.

Madrid today weather it's fantastic, only 31C

Edit. Yeah that's the bed shape:

Dim3nsioneer · August 9, 2016

Hmm. Simply making the longholes longer would do the job too, wouldn't it? Made that on my UMO. I'm actually more worried that one day the bed could miss the lever. Adding a spacer there is not possible due to the x-block. Btw. you should be aware that you are at a different height with the UM2+ head compared to a standard UMO+.

I think I now what you mean. You want to drive the z axis further despite the z endswitch being hit. That's too dangerous IMHO. The endswitch should make the axis stop. Anyway the movement would be too unprecise as the hit point would be somewhere else each time.

neotko · August 9, 2016

Will try to run some test this days. I think it's doable, but indeed the impression could instantly kill this idea.

IRobertI · August 10, 2016

Could you not do the same thing as on the UM2 in that case? Just move it to the bottom and software calibrate the end point?

But I think your idea could work as well. The only thing is that the amount of bed movement vs lever movement increases quite a bit I think. Not sure if that's a problem though.

neotko · August 10, 2016

Sure, it could be done and flip the z with the amedee firmware. But there's a catch. Not all umo+ are the same. Some beds have the hole for the z stop and some beds have the aluminium part 'sliced'. So isn't compatible for all the umo+. Also it would require some drilling on the box (that I'm up to do) but I wanna see if this works. I wasn't able to sit on the computer much today but I think I'll make an adapter and check 100 hommings by gcode to check if it can land the same z with the home on a side. I think the trick will be the distance so the endstop doesn't bend but also touches the endstop always at the same time.

neotko · August 10, 2016

Well it works quite well.

(Boring video)

Weirdly enough the position to set the endstop it's very easy using the holes fot the second extruder it just needs to be vertical and on the down corner.

Also using 'Move Z' (that somehow ignores the endstop) it can go up passing the endstop without intrusions.

I did a fast firmware changing the z min stop but it doesn't work that way because I'm just a marlin noob. Either way I think it's a 30secs mod. No need for anything printed and the relocation of the endstop it's very easy to find.

Also the amount the z needs to move back while it's already touching the home menu be increased by 5-10, not a very hard change on the firmware.

Edited August 10, 2016 by Guest

neotko · August 13, 2016

Bye bye Z endstop, you served me well.

Well today before arranging a new series of test I just broke my umo+ Z endstop, and the spare part endstops I have all are from umo so non of them have the lenght for the normal Z endstop...

So, nothing better to prove a mod than the 'need to mod'.

Did some M206 Z22 (so the endstop location would be at 22mm) and then after checking that all was ok did G28 Z0 to home the Z endstop and then G1 Z0 to move the bed to the 0 position that's actually beyond the endstop. Ofc I had to build a custom firmware with the z endstop limit disabled, and also changed the Z_HOME_RETRACT_MM to 30 because once the bed it's touching the endstop it must 'disengage it' to be able to touch the limit again. That's why on this video the bed moves 30mm down after hitting the endstop and then it moves slowly to hit it again.

So basic changes:

Endstop arranged horizontally on the slot for the second extruder:

Very easy to find this spot, since it's just the very corner.

Changes on marlin:

#define Z_HOME_RETRACT_MM 30

Also I had to do a M206 Z22 to redefine the new location of the Z endstop at 22mm (that's just because I use um2 hotend, for umo+ would be 10mm lower probably) and then did a M500 to save the new Z

So to finish this what I need... The ability to redefine the M206 Z by the ulticontroller. So far I can work with this (because my endstop died)

VERY BORING VIDEO of me doing G28 Z (to home the endstop) and then G1 Z0 to move the bed to the 0 position. It works, and it works quite well, and this would allow on UMO+ to be able to redefine the Z by the ulticontroller without touching the screws ever again (that's how I broke mine, but ofc I been playing with this endstop a lot all this year and a half with all the hotend changes I did)

So... @amedee Pretty please? <3

Edited August 13, 2016 by Guest

neotko · August 14, 2016

Did a quick tuning on the firmware and got this solved, no need to edit M206 Z by USB anymore (but it's a dirty fix)

Edited the lcd_prepare_move_z on the ultralcd.cpp

And added one line

static void lcd_prepare_move_z()

{

if (encoderPosition != 0)

{

refresh_cmd_timeout();

current_position[Z_AXIS] += float((int)encoderPosition) * 0.05;

encoderPosition = 0;

#ifdef DELTA

calculate_delta(current_position);

plan_buffer_line(delta[X_AXIS], delta[Y_AXIS], delta[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);

#else

plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);

#endif

lcdDrawUpdate = 1;

}

if (lcdDrawUpdate)

{

lcd_implementation_drawedit(PSTR("Z"), ftostr31(current_position[Z_AXIS]));

add_homeing[2] = current_position[Z_AXIS];

}

if (LCD_CLICKED)

{

lcd_quick_feedback();

currentMenu = lcd_prepare_menu;

encoderPosition = 0;

}

By doing this, Now I can push the bed manually to 0, open this 'Move Z' (that I have renamed to MOVE Z OFFSET) then I move it pass the endstop and slowly up until it hits the endstop, that generates a Z OFFSET that fits like a glove on the M206 Z value (add_homeing[2]) so I only need to hit store settings, and voila!

Now I can redefine the Z with this. Not quite elegant indeed, but I can rewrite the offset without connecting the computer at anytime

neotko · August 14, 2016

Anyone can give me a fast C++ hand?

Been thinking about this mod, and I think it could be easily finished.

It would need that when pressing this changed option, it would move to HOME, then you readjust the distance, that would be a negative value, and then you convert from negative to positive the value and insert it on the add_homeing[2] variable. That would make a perfect fast Z relevel right?

I'm right about this?

Would as easy as making a sequence, first the bed goes touch the endstop, then I do a simple add_homeing[2] = -current_position[Z_AXIS];

Should that work to convert the negative into positive?

tinkergnome · August 14, 2016

Would as easy as making a sequence, first the bed goes touch the endstop, then I do a simple add_homeing[2] = -current_position[Z_AXIS];

Should that work to convert the negative into positive?

Well, i see an analogy to the method that is used on the UM2, it should work.

If i were you... - i would move the final assignment into the LCD_CLICKED part and reset the current position - just in case you want to move the z-axis without re-homing afterwards.

Something like this:

...if (lcdDrawUpdate){   lcd_implementation_drawedit(PSTR("Z"), ftostr31(current_position[Z_AXIS]));}if (LCD_CLICKED){   lcd_quick_feedback();   add_homeing[Z_AXIS] -= current_position[Z_AXIS];   current_position[Z_AXIS] = 0;   plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);   currentMenu = lcd_prepare_menu;   encoderPosition = 0;}...

BTW:

Are you not concerned about the homing precision, if you hit the endstop lever at this steep angle? Does it actually work (precisely enough)?

Why not going the complete way and place the endstop on the bottom (like on the UM2). Are there mechanical factors that cannot be solved?

neotko · August 14, 2016

Wow thanks @tinkergnome !

The only issue I see on moving the endstop to the bottom it's

a) It needs drill on the wood frame for the endstop

b) If you reuse the screw on the bed of umo+ You find that some umo+ bed have that screw 'sliced' so you can't put the screw that would touch the endstop like um2 (on some you could on some you couldn't).

Precision wise it works and works and keeps working. Did it today on the second printer and runned the gcode 1000 times. No errors !

But indeed it might not be perfect. I will do that code change thanks alot men!

I pushed this mod forward because one endstop died, but the ability to change z so fast it's quite nice.

tinkergnome · August 15, 2016

I pushed this mod forward because one endstop died, but the ability to change z so fast it's quite nice.

Just to be sure... if i understood you right, you want to implement a simple z-adjustment function using the add_homeing offset. To be honest - i have no clue how this is done on an unmodified UMO... physically moving the endstop, if i'm right?

You should make a copy of the "lcd_prepare_move_z" function and add your stuff as a separate menu entry. I assume that you want to use the unmodified "move_z" at some point in time...

And i think you need some more steps before you switch to your new menu entry (i'm not sure if you've already done this):

- set add_homeing[Z_AXIS] to zero

- home all axis, the z-axis should stop at the endstop and current z-position is at zero now (that's important!)

- move the printhead to a proper position (X/Y center)

- and/or disable the x/y steppers and you can move the printhead manually

After that: move the z-axis further upwards until the nozzle (nearly) touches the buildplate. After pushing the encoder knob, set the add_homing offset and go back to the "Prepare" menu. That's what "lcd_prepare_move_z" does now.

And finally:

- store the settings to eeprom if you're satisfied

- move the z-axis down a bit?

You can put this also in the LCD_CLICKED part, if you want.

Is this (sort of) a workflow that you have in mind?

Edit:

This line moves the axis by 0.05 on every encoder step:

current_position[Z_AXIS] += float((int)encoderPosition) * 0.05;

I would try to reduce this value, this will lead to a slower movement but a more precise offset adjustment possible.

Edited August 15, 2016 by Guest

neotko · August 15, 2016

physically moving the endstop, if i'm right?

Exactly. Umo+ has a free slot where it fits perfectly rotated 90degrees, also it's a very easy place to find since it's on a sharp corner.

You should make a copy of the "lcd_prepare_move_z" function and add your stuff as a separate menu entry. I assume that you want to use the unmodified "move_z" at some point in time...

That's actually a fun part. The Move Z it's redundant since the same menu has a Move axis/z/y/z/e down on the list.

And i think you need some more steps before you switch to your new menu entry (i'm not sure if you've already done this):
- set add_homeing[Z_AXIS] to zero

- home all axis, the z-axis should stop at the endstop and current z-position is at zero now (that's important!)

- move the printhead to a proper position (X/Y center)

- and/or disable the x/y steppers and you can move the printhead manually

Indeed, that the idea of a sequence for this Z offset. No need to disable x/y steppers since (at leadt on umo+) the motors do disable after a full g28 homing for x/y but not z.

After that: move the z-axis further upwards until the nozzle (nearly) touches the buildplate. After pushing the encoder knob, set the add_homing offset and go back to the "Prepare" menu. That's what "lcd_prepare_move_z" does now.

And finally:

- store the settings to eeprom if you're satisfied

- move the z-axis down a bit?

You can put this also in the LCD_CLICKED part, if you want.

Is this (sort of) a workflow that you have in mind?

Edit:

This line moves the axis by 0.05 on every encoder step:
current_position[Z_AXIS] += float((int)encoderPosition) * 0.05;
I would try to reduce this value, this will lead to a slower movement but a more precise offset adjustment possible.

Indeed that would be a full leveling system. Since I know very little I would focus on what I can do. I want to make the z offset button to home, set that to 0, then move the z with the dial until the point, press to set new offset and the idea of moving the z down a bit looks good indeed, also a call to store settings, but that I'm not sure since on umo+ its more normal to just move to the option store settings, but indeed making it all on a button on that order would make it automagically and much easier.

Thanks men!!

neotko · August 15, 2016

I suppose I could do something like this (dirty coding sorry in advance)

    if (LCD_CLICKED)   {       add_homeing[2] -= current_position[Z_AXIS];       enquecommand_P(PSTR("M500"));       enquecommand_P(PSTR("G1 Z5"));       current_position[Z_AXIS] = 5;       lcd_quick_feedback();       currentMenu = lcd_prepare_menu;       encoderPosition = 0;   }}

The think I don't know where to add it's a Home Z before I can use the encoder and that only activates once, out of the 'if' loop.

If I set the homing Z just before the first IF, it should only be executed once? Or should I make an external 'thingy' ?

static void lcd_prepare_move_z(){   enquecommand_P(PSTR("G28 Z0"));

Edited August 15, 2016 by Guest

tinkergnome · August 15, 2016

If I set the homing Z just before the first IF, it should only be executed once? Or should I make an external 'thingy' ?

I see, you're becoming a programmer at heart... are you ever sleeping?

There's no "lcd_prepare_move_z" at the sources from Ultimaker. What firmware sources are your basis?

Anyway - i can make an educated guess...

Edit: found it - i was on the wrong branch... (rookie mistake... )

If it is used like all the other menu functions, the whole function "lcd_prepare_move_z" is called from the main loop many times a second.... Or shorter: yes: the preparation has to be done as a separate step.

I assume, that "lcd_prepare_move_z" is called somewhere from "lcd_prepare_menu()" with a line like that?

MENU_ITEM(submenu, MSG_..., lcd_prepare_move_z);

I would make an additional function like this:

static void lcd_init_z_adjustment(){   // reset to the stored settings   Config_RetrieveSettings();   // reset the z-offset   add_homeing[Z_AXIS] = 0;   // home z   enquecommand_P(PSTR("G28 Z0"));   // immediately switch to the next menu   menu_action_submenu(lcd_prepare_move_z);}

and replace the call of lcd_prepare_move_z with the name of the new function:

MENU_ITEM(submenu, MSG_..., lcd_init_z_adjustment);

This way the new function "lcd_init_z_adjustment" is called only once as an initialization step and the control is passed down to the former menu function afterwards.

I suppose I could do something like this (dirty coding sorry in advance)

Nearly..., but the sequence of the steps is important. In my opinion the function should look like that:

static void lcd_prepare_move_z(){   if (encoderPosition != 0)   {       refresh_cmd_timeout();       current_position[Z_AXIS] += float((int)encoderPosition) * 0.01;       encoderPosition = 0;#ifdef DELTA       calculate_delta(current_position);       plan_buffer_line(delta[X_AXIS], delta[Y_AXIS], delta[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);#else       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);#endif       lcdDrawUpdate = 1;   }   if (lcdDrawUpdate)   {       lcd_implementation_drawedit(PSTR("Z"), ftostr31(current_position[Z_AXIS]));   }   if (LCD_CLICKED)   {       // store all settings (including the new z-offset)       add_homeing[Z_AXIS] -= current_position[Z_AXIS];       Config_StoreSettings();       // important: tell the printer that we are at z=0 now       current_position[Z_AXIS] = 0;       plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);       // move z down a few mm       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], 5.0f, current_position[E_AXIS], homing_feedrate[Z_AXIS]/60, active_extruder);       // important: inform the printer about the new position       current_position[Z_AXIS] = 5.0f;       // return to the previous menu       lcd_quick_feedback();       currentMenu = lcd_prepare_menu;       encoderPosition = 0;   }}

That's also quick and dirty and not tested in any way...

Edited August 15, 2016 by Guest

neotko · August 15, 2016

That's perfection men!

Ahh you can call the storesettings function directly, super!

Well I never programmed much, more like quick patching stuff from others. Never learned properly

That's fantastic @tinkergnome !, I think I could make this to look good with some basic prompts on the screen.

tinkergnome · August 15, 2016

I think I could make this to look good with some basic prompts on the screen.

I'm confident!

neotko · August 15, 2016

Perfect. All it's working !

Basic code changes, done using the @Amedee Marlin Build

https://github.com/AmedeeBulle/Marlin/tree/Marlin_UMO_Unified

(I used the experimental to keep PID bed)

The thinks to add/change on ultralcd.cpp

#ifdef ULTIMAKER_HBKstatic void lcd_init_home_z_offset();static void lcd_init_z_adjustment();static void lcd_prepare_info_z();static void lcd_prepare_move_z();#endif

Some changes on the Prepare menu

static void lcd_prepare_menu(){   START_MENU();   MENU_ITEM(back, MSG_MAIN, lcd_main_menu);#ifdef SDSUPPORT   #ifdef MENU_ADDAUTOSTART     MENU_ITEM(function, MSG_AUTOSTART, lcd_autostart_sd);   #endif#endif   MENU_ITEM(gcode, MSG_DISABLE_STEPPERS, PSTR("M84"));#ifdef ULTIMAKER_HBK   MENU_ITEM(function, MSG_AUTO_HOME, lcd_home);#else   MENU_ITEM(gcode, MSG_AUTO_HOME, PSTR("G28"));#endif   //MENU_ITEM(gcode, MSG_SET_ORIGIN, PSTR("G92 X0 Y0 Z0"));#if TEMP_SENSOR_0 != 0 #if TEMP_SENSOR_1 != 0 || TEMP_SENSOR_2 != 0 || TEMP_SENSOR_BED != 0   MENU_ITEM(submenu, MSG_PREHEAT_PLA, lcd_preheat_pla_menu);   MENU_ITEM(submenu, MSG_PREHEAT_ABS, lcd_preheat_abs_menu); #else   MENU_ITEM(function, MSG_PREHEAT_PLA, lcd_preheat_pla0);   MENU_ITEM(function, MSG_PREHEAT_ABS, lcd_preheat_abs0); #endif#endif   MENU_ITEM(function, MSG_COOLDOWN, lcd_cooldown);#if PS_ON_PIN > -1   if (powersupply)   {       MENU_ITEM(gcode, MSG_SWITCH_PS_OFF, PSTR("M81"));   }else{       MENU_ITEM(gcode, MSG_SWITCH_PS_ON, PSTR("M80"));   }#endif   MENU_ITEM(submenu, MSG_MOVE_AXIS, lcd_move_menu);#ifdef ULTIMAKER_HBK   MENU_ITEM(submenu, "Realign Z Offset", lcd_init_z_adjustment);   MENU_ITEM(function, "Move to Z Offset", lcd_init_home_z_offset);#endif   END_MENU();}

And this it's how the functions are atm, they work, quite nice

#ifdef ULTIMAKER_HBK/* OFFSET BED ALIGN */static void lcd_init_home_z_offset(){   enquecommand_P(PSTR("G28 Z0")); // Move to Z endstop   enquecommand_P(PSTR("G1 Z0")); // Move to Z OFFSET   lcd_quick_feedback();}static void lcd_init_z_adjustment(){   Config_RetrieveSettings(); // reset to the stored settings   add_homeing[Z_AXIS] = 0;   // reset the z-offset   enquecommand_P(PSTR("G28 Z0")); // Move to Z endstop   menu_action_submenu(lcd_prepare_info_z); // Show basic info}static void lcd_prepare_info_z(){   lcd_implementation_draw_line(0, PSTR("- RESET Z OFFSET -"));   lcd_implementation_draw_line(1, PSTR("ADJUST UNTIL THE"));   lcd_implementation_draw_line(2, PSTR("NOZZLE KISS THE BED"));   lcd_implementation_draw_line(3, PSTR("- CLICK TO START -"));   // wait for Click to continue   if (LCD_CLICKED)   {         lcd_implementation_draw_line(0, PSTR(""));         lcd_implementation_draw_line(1, PSTR(""));         lcd_implementation_draw_line(2, PSTR(""));         lcd_implementation_draw_line(3, PSTR(""));         lcd_quick_feedback();         menu_action_submenu(lcd_prepare_move_z);   }}static void lcd_prepare_move_z(){   if (encoderPosition != 0)   {       refresh_cmd_timeout();       current_position[Z_AXIS] += float((int)encoderPosition) * 0.01;       encoderPosition = 0;       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS], manual_feedrate[Z_AXIS]/60, active_extruder);       lcdDrawUpdate = 1;   }   if (lcdDrawUpdate)   {       lcd_implementation_drawedit(PSTR("Z OFFSET"), ftostr31(current_position[Z_AXIS]));       lcd_implementation_draw_line(3, PSTR("CLICK TO SAVE & EXIT"));   }   if (LCD_CLICKED)   {       // store all settings (including the new z-offset)       add_homeing[Z_AXIS] -= current_position[Z_AXIS];       Config_StoreSettings();       // important: tell the printer that we are at z=0 now       current_position[Z_AXIS] = 0;       plan_set_position(current_position[X_AXIS], current_position[Y_AXIS], current_position[Z_AXIS], current_position[E_AXIS]);       // move z down a few mm       plan_buffer_line(current_position[X_AXIS], current_position[Y_AXIS], 5.0f, current_position[E_AXIS], homing_feedrate[Z_AXIS]/60, active_extruder);       // important: inform the printer about the new position       current_position[Z_AXIS] = 5.0f;       // return to the previous menu       lcd_quick_feedback();       currentMenu = lcd_prepare_menu;       encoderPosition = 0;   }}#endif

I'm sure there's a better way to code this, but hey it works !

Note for the new user that just read this without reading the other posts:

OF COURSE THE MOST IMPORTANT THINK TO DO FIRST IT'S TO ACTUALLY MOVE THE ENDSTOP TO THE NEW POSITION

EDIT: Also it need's on configuration_adv.h to change the Z_HOME_RETRACT_MM from 5 to 30, so the home movement releases the endstop before fixing the home position (without this if the endstop it's activated already it won't know where the home it's)

#define Z_HOME_RETRACT_MM 30

Edited August 15, 2016 by Guest

neotko · August 17, 2016

Printed part to make the repetition even better (didn't had problrms but I see that without this simple addon it might tilt someday). The position it's very firm and the bed hits the endstop without problems. It works with small and long endstops from umo/umo+

Having this bed calibration by firmware it's amazing, today did some test printing over a tall polymer for a customer and being able to refit the z this fast and easy it's just super. Also the default z endstop wouldn't let me use a gab this big without playing with the gcode.

Adapter to fully secure the new endstop location:

https://www.youmagine.com/designs/new-z-endstop-limit-location-for-calibration-a-la-um2-on-umo

EDIT: Uploaded V2 of the endstop adapter. The other design without a third point to fix could tilt so slightly and create a slight error on the z, this it's now fixed.

Edited August 18, 2016 by Guest

neotko · August 19, 2016

I have observed a sligh (very very slight) anomaly on the Z position. But I think it's related to the repetition but my gut tells me that it might be the 0.01 adjustment by firmware when doing the Z adjustment. Will run more tests, worse case scenario I will do a simple adapter to place the endstop on the bottom.

Back to square one (hopefully not...)

I mean this line

    if (encoderPosition != 0)   {       refresh_cmd_timeout();       current_position[Z_AXIS] += float((int)encoderPosition) * 0.01;

Because when doing the Z adjustment some points the Z doesn't move at all, probably related to decimal points being dismissed on the process. UMO+ Z motor just doesn't move after each 0.01 change, but it does each 0.02, that makes sense since that's supposed it's minimum resolution. I think that it's making a decimal point that it's screwing repetition. Ofc this doesn't make much sense but I'll run more tests with that change and a Gauge Dial indicator to see if there's true perfect repetition.

tinkergnome · August 20, 2016

Because when doing the Z adjustment some points the Z doesn't move at all, probably related to decimal points being dismissed on the process. UMO+ Z motor just doesn't move after each 0.01 change, but it does each 0.02, that makes sense since that's supposed it's minimum resolution.

I'm afraid that i don't understood what kind of "anomaly" you noticed, but i have an explanation for this "0.01-behavior".

It's probably the planner:

Everything with less than 5 steps will be ignored as move and joined with the next movement.

Actually (on z-only moves) this are 0.025mm.

The UM2 has also 200 steps per mm for the z-axis and the firmware uses a move of 0.05mm for every encoder step during the bed leveling wizard. It seems to be not necessary to adjust the nozzle distance more accurate than this...

(yes - i know- the 0.01 was a suggestion from me... i take it back )

neotko · August 20, 2016

I'm afraid that i don't understood what kind of "anomaly" you noticed, but i have an explanation for this "0.01-behavior".

It's probably the planner:

Everything with less than 5 steps will be ignored as move and joined with the next movement.

Actually (on z-only moves) this are 0.025mm.

The UM2 has also 200 steps per mm for the z-axis and the firmware uses a move of 0.05mm for every encoder step during the bed leveling wizard. It seems to be not necessary to adjust the nozzle distance more accurate than this...

(yes - i know- the 0.01 was a suggestion from me... i take it back )

Lol no, you helped a lot!!

But yeah it seems that since the value it's stored with decimals it rounding the number and sometimes it's a bit lower/higher. Depends much on where it starts to home which makes me think that that's the issue, but since it's a weird place to set the endstop I will do double check by changing the value and using a gauge dial to confirm that it can/can't work.

Thanks men!

neotko · August 22, 2016

Well this idea it's dead. It works for me because I can realign the bed fast but it clearly misses to hit the same spot. The error it's around 0.05-0.08 on both directions. So, I'll move the endstop to the bottom, make an adapter to avoid cutting holes and voilà.

Idea. New location for Z limit on UMO+

Recommended Posts

neotko 1,417

Link to post

Share on other sites

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Popular Posts

neotko

Posted Images

Dim3nsioneer 557

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

Dim3nsioneer 557

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

IRobertI 520

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

tinkergnome 927

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

tinkergnome 927

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

tinkergnome 927

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

tinkergnome 927

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

neotko 1,417

Link to post

Share on other sites

tinkergnome 927

Link to post

Share on other sites

neotko 1,417

Link to post