Jump to content
Ultimaker Community of 3D Printing Experts
  • Sign Up
neotko

Idea. New location for Z limit on UMO+

Recommended Posts

Posted · Idea. New location for Z limit on UMO+

Babystepping is about adjusting the Z on the fly while printing -- it has per say nothing to do with bed leveling.

(And with the old UMO I have been trained to do hardware babystepping -- manually turning the Z axis 8) )

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

@neotko, are you brave enough to beta test my latest firmware?

My printer homes at the top, and I would like feedback from somebody homing at the bottom.

I guess this is what you should set in the builder:

5a33267271459_ScreenShot2017-01-23at17_59_02.thumb.png.e64368c7a3d0ff7574412b4080d28230.png

(Be prepared to pull the plug if it goes pear shaped!)

5a33267271459_ScreenShot2017-01-23at17_59_02.thumb.png.e64368c7a3d0ff7574412b4080d28230.png

  • Like 1

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Will do, but can't until weekend, got some stuff to finish very important this week.

  • Like 1

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Hi Amedee,

I can test it out, I have modified my printer similarly to Neotko.

Also on 3dprintingforum.us i published a few links to my github in which I added the bottom homing as per Neotko's mod and a few bug fixes (issues with negative numbers in the display)

If you check those, I can assure you they were fully tested by me and working :)

  • Like 1

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

I don't have any issue with negative numbers in my build, it all works.

I am not saying there are no problems, but I am not going to fix problems I don't have :p

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited) · Idea. New location for Z limit on UMO+

Looking at your code, you should be able  to repro the issue I'm describing by inserting this code in one of your menus and trying to edit the value in a negative number.

MENU_ITEM_EDIT(float32, "Z offset", &add_homeing[Z_AXIS], -30, 10);

Edited by Guest

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Yeah...

The problem is that the encoder is unsigned and then suddenly they want to use it as signed, but not all the road...

That simple fix works as well

 

@@ -1379,10 +1381,10 @@ static void lcd_action_menu()        if ((int32_t)encoderPosition > maxEditValue) \            encoderPosition = maxEditValue; \        if (lcdDrawUpdate) \-            lcd_implementation_drawedit(editLabel, _strFunc(((_type)encoderPosition) / scale)); \+            lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition)) / scale)); \        if (LCD_CLICKED) \        { \-            *((_type*)editValue) = ((_type)encoderPosition) / scale; \+            *((_type*)editValue) = ((_type)((int32_t)encoderPosition)) / scale; \            lcd_quick_feedback(); \            currentMenu = prevMenu; \            encoderPosition = prevEncoderPosition; \@@ -1395,10 +1397,10 @@ static void lcd_action_menu()        if ((int32_t)encoderPosition > maxEditValue) \            encoderPosition = maxEditValue; \        if (lcdDrawUpdate) \-            lcd_implementation_drawedit(editLabel, _strFunc(((_type)encoderPosition) / scale)); \+            lcd_implementation_drawedit(editLabel, _strFunc(((_type)((int32_t)encoderPosition)) / scale)); \        if (LCD_CLICKED) \        { \-            *((_type*)editValue) = ((_type)encoderPosition) / scale; \+            *((_type*)editValue) = ((_type)((int32_t)encoderPosition)) / scale; \            lcd_quick_feedback(); \            currentMenu = prevMenu; \            encoderPosition = prevEncoderPosition; \

 

I'll commit something wen i have merged my pending stuff...

(On the later fix I don't see why he absolutely wants to cast everything to float, that does not make too much sense to me)

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Hi Amedee,

The later fix is not needed as per se, but I included it for two reasons:

1- It doesn't hurt :)

2- It fixes other issues that may arise going forward when/if we decide to port more features from Marlin RC to our version of Marlin.

Also note that in the second fix they renamed "scale" to "_scale", as it refers to a more advanced version of the firmware, so you have to implement it by changing it back to "scale".

So in the end it's not a fix, it's prevention :D

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

I am old school: if it works don't fix it :p

And I am not sure that one fixes anything, on the opposite: it forces float arithmetic when you just handle integers. To me, that one looks more a shot in the dark than anything else -- as usual I can be wrong, but I can hardly find a use case for that.

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Hi Amedee,

There's another bug with this code, not sure if "reset firmware to failsafe" helps to fix it or not, as I haven't yet tested that part out.

The way the issue works is as per the below repro steps:

1- Enable Neotko's mod and have the UMO home at the bottom

2- Flash the firmware with the mod

3- Adjust the Z offset to the value it should be. In my case this is 19.7

4- Print - everything works fine

5- Flash another firmware disabling Neotko's mod and have the UMO home at the top

6- Print - the printer will home and then it will move the bed down by 19.7 when printing, so the print will basically have layer 0 at 19.7+layer height

I'm not sure that resetting to failsafe might help after point 5, as the Z offset wasn't defined to 0 as failsafe setting anywhere (I may be wrong on this).

The poor man's workaround would be to change this line of code (in your firmware as well as in mine), from :

 

#ifdef SOFT_Z_ALIGN   MENU_ITEM(submenu, MSG_ZA_ADJUST, lcd_z_align_menu);#endif // SOFT_Z_ALIGN

 

to:

 

   MENU_ITEM(submenu, MSG_ZA_ADJUST, lcd_z_align_menu);

 

basically removing the requirement for SOFT_Z_ALIGN to be defined in order to tweak the offset. I know this is not an elegant solution tho :D

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Thank you for this feedback.

Now the homing offset is not something we made up, it is part of standard Marlin. I think we just need to document it.

You can easily revert to the default behaviour by either resetting the firmware as you mention, or just clear the value with 'M206 Z0' (and 'M500' to save it).

But it is worth mentioning it as the particular case of end-stop at the top the offset raises the bed, so it will crash in the head!

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

In my defense I'm hardly a programmer XD I did a quick dirty fix to use the endstop on the bottom.

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

Thank you for this feedback.

Now the homing offset is not something we made up, it is part of standard Marlin. I think we just need to document it.

You can easily revert to the default behaviour by either resetting the firmware as you mention, or just clear the value with 'M206 Z0' (and 'M500' to save it).

But it is worth mentioning it as the particular case of end-stop at the top the offset raises the bed, so it will crash in the head!

No, in my case it will not crash in the head, but it will lower the bed and print mid-air.

I don't think there's a crash risk, just a missprint risk.

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

I get that, just saying that if you home on top like I do, then there is a crash risk.

As you say, no real danger when you home at the bottom.

Share this post


Link to post
Share on other sites
Posted (edited) · Idea. New location for Z limit on UMO+

I get that, just saying that if you home on top like I do, then there is a crash risk.

As you say, no real danger when you home at the bottom.

Hi Amedee,

No. There should be no crash risk even at the top.

If you read my repro steps at step 1 i do home at the bottom, but then at step 5 i disable the mod and home again at the top.

Are you instead talking about a crash risk if you ALWAYS home at the top?

In that case there may be a "more touching of the head on the bed" but then the risk should still be mitigated by the top endstop.

Edited by Guest

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

@neotko, are you brave enough to beta test my latest firmware?

My printer homes at the top, and I would like feedback from somebody homing at the bottom.

I guess this is what you should set in the builder:

5a33267271459_ScreenShot2017-01-23at17_59_02.thumb.png.e64368c7a3d0ff7574412b4080d28230.png

(Be prepared to pull the plug if it goes pear shaped!)

 

I was going to try a build, but I dont see the options shown here at https://bultimaker.bulles.eu/ ?

Share this post


Link to post
Share on other sites
Posted · Idea. New location for Z limit on UMO+

np, we all are ;)

I am confident about the 'top homing', as I use it without any problem, but I haven't test bottom homing.

I still need to make a short youmagine page as well with my very simple sensor holder and quick instructions...

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...