Idea. New location for Z limit on UMO+

[antiklesys 3]

What about enabling babystepping in Marlin instead?

[amedee 349]

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) )

[amedee 349]

@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:

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

[neotko 1,417]

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

[antiklesys 3]

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

[antiklesys 3]

Also, please add the following in your code or when you switch to negative numbers you'll have issues

https://github.com/Antiklesys/Marlin-1/commit/2d411460e75fb5020d0cd20dc658659a12f4c083

[amedee 349]

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

[antiklesys 3]

Well it's weird...mainly because my build is a fork of yours and also this same issue was fixed in the main Marlin branch

Here's the source:

https://github.com/MarlinFirmware/Marlin/pull/1153

https://github.com/MarlinFirmware/Marlin/issues/5310

[antiklesys 3]

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 January 23, 2017 by Guest

[amedee 349]

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)

[antiklesys 3]

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

[amedee 349]

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

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.

[antiklesys 3]

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

[amedee 349]

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!

[neotko 1,417]

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

[antiklesys 3]

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.

[amedee 349]

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.

[antiklesys 3]

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 January 25, 2017 by Guest

[amedee 349]

Whatever...

[amedee 349]

Eventually made a video on the subject

 

[antiklesys 3]

Nice, glad to see you integrated the 3 points leveling in it

[catohagen 41]

@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:

(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/ ?

[amedee 349]

It is still in the 'experimental' branch, until i get enough positive feedback

https://bultimaker.bulles.eu/experimental

[neotko 1,417]

It is still in the 'experimental' branch, until i get enough positive feedback

https://bultimaker.bulles.eu/experimental

 

Sorry so busy lately!

[amedee 349]

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...