Jump to content
Ultimaker Community of 3D Printing Experts
antiklesys

Weird Z height issue with UMO Marlin

Recommended Posts

have this function to home the printer and set the bed at a specific height for laser cutting.

This is in ultralcd.cpp

 

static void laser_home(){   enquecommand_P(PSTR("G28 X0 Y0"));   enquecommand_P(PSTR("G28 Z0"));   enquecommand_P(PSTR("G1 Z85 F12000"));}

 

So far all works well, but I wanted to change it, so I could set the Z height manually from the screen and adjust it to different values.

I changed this function in:

 

static void laser_home(){   enquecommand_P(PSTR("G28 X0 Y0"));   enquecommand_P(PSTR("G28 Z0"));  char buffer[32];  float laser_offset = 80;  sprintf_P(buffer,PSTR("G1 Z%i F12000"), laser_offset);  enquecommand(buffer);}

 

As you can see, laser offset is a float that for testing has been set to a fixed value of 80.

Additional note: my printer homes at the bottom.

Now what is weird to me, is that when I run the first code (the old one at the top), the printer homes and then puts the bed at Z85. This is good.

When I run the second function instead (the newer one), the printer homes and then surpasses Z85 and crushes the bed in the head (attempts to do it, as I switch it off before this happens).

Any clue on what I'm doing wrong here?

All help is welcome

Share this post


Link to post
Share on other sites

The next question would be related to a similar behavior happening with

zprobe_zoffset item in Marlin

In ultralcd.cpp I have:

 

#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, 0.5, 50);#endif

 

Now it seems this distance is negative as per Marlin_main.cpp

 

     #ifdef ENABLE_AUTO_BED_LEVELING       if((home_all_axis) || (code_seen(axis_codes[Z_AXIS]))) {         current_position[Z_AXIS] += zprobe_zoffset;  //Add Z_Probe offset (the distance is negative)       }     #endif

 

This means that whatever I set in this variable will cause the head to go below Z 0 is this correct?

Meaning if I home at Z0 and i have an offset of 3, the head will go at Z-3 and consider that Z0?

If so I would need a way to use a signed Z offset rather than a negative one, this would allow me to choose wether to have a positive or negative distance based on the situation / head mounted.

Any help to point me in the right direction to fix this too? :)

Share this post


Link to post
Share on other sites

The offset is not per say negative, it is the fact that you add it to the current position that places your zero more towards the negative direction.

This offset is a float, so it signed by definition and can have any value you like...

Edited by Guest

Share this post


Link to post
Share on other sites

So it should allow me to go in the other direction by changing this?

 

static void lcd_control_motion_menu(){   START_MENU();   MENU_ITEM(back, MSG_CONTROL, lcd_control_menu);#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, 0.5, 50);#endif

 

into this?

 

static void lcd_control_motion_menu(){   START_MENU();   MENU_ITEM(back, MSG_CONTROL, lcd_control_menu);#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, -10, 50);#endif

 

Share this post


Link to post
Share on other sites

Tested by changing the line into:

 

#ifdef ENABLE_AUTO_BED_LEVELING   MENU_ITEM_EDIT(float32, MSG_ZPROBE_ZOFFSET, &zprobe_zoffset, -10, 10);#endif

 

The first issue I encounter is graphical.

While the value stays within positive numbers, the display shows it correctly during the adjustment (for instance it shows : "Z Offset: 000.02")

As soon as I go below 0 with the encoder, it shows on the display "Z Offset: --*.,("

Thus not allowing me to correctly set a negative value.

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

  • Our picks

    • Taking Advantage of DfAM
      This is a statement that’s often made about AM/3DP. I'll focus on the way DfAM can take advantage of some of the unique capabilities that AM and 3DP have to offer. I personally think that the use of AM/3DP for light-weighting is one of it’s most exciting possibilities and one that could play a key part in the sustainability of design and manufacturing in the future.
        • Like
      • 3 replies
×

Important Information

Welcome to the Ultimaker Community of 3D printing experts. Visit the following links to read more about our Terms of Use or our Privacy Policy. Thank you!