Z offset cannot be set to some values.

[KevMags]

This is not a big deal and probably just a number rounding fluke. Using RCBugFix downloaded March 20 (where do I find the exact build number?). When attempting to set the Z offset I cannot get it to allow some numbers even with the encoder steps set ridiculously high. These are some of the numbers that it will not allow: 5,10,15,20,23,27,30,40,43,46,49,54,60....... I have encountered this with 2 completely different setups, both using Ramps 1.4, Arduino (knock-off), Reprap full graphics controller (Sintron, the other display is inaccessible) compiled with Arduino 1.6.13.

[mperdue]

I've been meaning to mention this problem. It's not a huge problem but it is a little irritating.

[ghost]

Does M851 work for you?

[Roxy-3D]

Can you attach your configuration.h files? You will have to change the .h to .txt

[mperdue]

If I read the Z offset from the LCD on the printer it says -1.59. M851 return -1.60

configuration_h.txt

[KevMags]

Here is my configuration.h file. Configuration.txt

[Roxy-3D]

If I read the Z offset from the LCD on the printer it says -1.59. M851 return -1.60

Yes... And probably the real number is something like -1.5973 The SERIAL_PROTOCOL() functions that output that number are rounding it to the specified number of decimal places.

[mperdue]

If the value is carried out to 4 decimal places and it's just a round off error you would think that you'd be able to hit just about any number using the dial. How much does the value change for each step of the dial?

[KevMags]

I have change the setting from the range of 2-5 clicks (steps) on the encoder to change the value. You can count the clicks until the next number comes up. With the encoder set to 2 steps you can feel 2 clicks and then it goes up one value, when a number is skipped it takes 4 clicks for the value to change to the next number (or this may make more sense. When you get to 4 and give it 2 more clicks, no change, 2 more clicks (4 total) and the value goes up to 6).

Edit: When I saw the sequence from 5-20 it was looking like it missed all multiples of 5 but later in the sequence it blew that theory all to hell.

[Roxy-3D]

With UBL's interactive mesh editor (G29 P3 R) I have the opposite problem. Depending on how the user has the Encoder Wheel clicks setup... Some times you have to hold the Encoder Wheel between detents to get the right .005 mm increment while you click. The good news is... You don't really need to set Mesh Points to .005 mm accuracy.

[thinkyhead]

where do I find the exact build number?

We don't do that. (You can just refer to the commit number.)

Anyway… There do seem to be some general quirks with value editing on the LCD currently. Sometimes it gives the appearance that the value was changed by the encoder but not displayed. Sometimes it gives the appearance of rounding. (That's a general problem with float anyway. In float world 4.99999999 == 5.0.)

So, I'll see about fixing these soon.

[tcm0116]

If you have BABYSTEP_ZPROBE_OFFSET enabled in Configuration.h, then the resolution of the Z Offset will be determined by the steps per mm of the Z axis. This is because the steps per mm of the Z axis represents the minimum amount of distance that the Z axis can move at any given time, so trying to set a Z Offset that is not aligned with that distance would be unachievable and could lead to compounding errors.

[Roxy-3D]

We have a whole bunch of Z-Axis micro-stepping issues. We need people to figure out the right steps so we can have a universal manual probe type that can co-exist with a real Z-Probe. Everyone of the Auto Bed Leveling systems would benefit from having that solution in place. Proposals and discussion are very welcome.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.