[BUG] LCD Manual leveling - Z jogging limitation due to MIN_STEPS_PER_SEGMENT

[Tofoillote]

Bug Description

While manual probing with LCD bed leveling, acting on jog and changing value on LCD mean no Z value change. Z value are changing only 2 or 3 jog step : mean multiple value of MESH_EDIT_Z_STEP

My Configurations

Marlin.zip

Steps to Reproduce

1. place a µmeter on Z axis
2. start a bed leveling setting µmeter to 0
3. see Z heigh not changing while Z value is changing in LCD, continue until µmeter value change.

Expected behavior: each Jog step corresponding to MESH_EDITZ_STEP should change µmeter value the same way.

Actual behavior: µmeter value change only each 3 jog step (in fact close to 0.025 mm)

Additional Information

8 mm/turn Z screw with 0.9° stepper motor and 1/4 µ stepping should have close to Z 0.005 resolution

I've already have a check at #define SHORT_MANUAL_Z_MOVE 0.010 and tried several values with no success.

[boelle]

@Tofoillote still an issue?

[thisiskeithb]

@boelle: It'd probably be wise to start at the other end of the issue list. You're replying to relatively new issues in the queue.

[boelle]

@thisiskeithb i did start with the least recently updated first and then worked my way through them all

only took a few couple of hours with the the help from @sjasonsmith

[boelle]

Lack of Activity This issue is being closed due to lack of activity. If you have solved the issue, please let us know how you solved it. If you haven't, please tell us what else you've tried in the meantime, and possibly this issue will be reopened.

[Tofoillote]

Lack of activity ? seriously ? a 3 days left one ?

Solution somewhere ?

[boelle]

yes 3 days is enough to answer us

[Tofoillote]

so yes, probably still an issue, not yet have tested bugfix marlin about this.

[Tofoillote]

M2.0.5.3.zip

I combine the investigation about this ... searching for something the multiply or divide the jog step by 3 ... for instance.

no clues ...

Still can't Manually Bed Level below 0.03 mm accuracy.

https://youtu.be/diVuSKG6wVM

(can't also compile bugfix version ... falling in "avr-gcc file doesn't exist" loop ... 2.0.5.3 compiles a charm ...)

[boelle]

do you use vscode+platform.io to compile?

did you download from here: bugfix-2.0.x branch ?

[thinkyhead]

Sorry, this should not have been closed, and someone should have looked up the code to see what it's trying to do, and then asked you to try some things to see what happens. So let me now help you out.

First, you must test bugfix-2.0.x before posting a bug report. If you are working with that version, then the next question would be…

What kind of behavior do you see if you set an exaggeratedly large MESH_EDIT_Z_STEP value? The code simply does this:

const float z = current_position.z + float(int32_t(ui.encoderPosition)) * (MESH_EDIT_Z_STEP);

[Tofoillote]

do you use vscode+platform.io to compile?

did you download from here: bugfix-2.0.x branch ?

Nope, I'm using Aduino's IDE, (and notepadd++ with compare plugin) i'm familiar with, from the bugfix branch yes.

will give a try to platform.io

also wil try tremendous z values ...

[Tofoillote]

MESH_EDIT_Z_STEP 0.3 => 1 jog step = 1 move. MESH_EDIT_Z_STEP 0.05 => 1 jog step = 1 move. MESH_EDIT_Z_STEP 0.025 => 2 jog step = 1 move of 0.05 ...

[thinkyhead]

With ENCODER_PULSES_PER_STEP set to 4 and ENCODER_STEPS_PER_MENU_ITEM set to 1 you will get a certain kind of behavior. Try some other values.

[Tofoillote]

With ENCODER_PULSES_PER_STEP set to 4 and ENCODER_STEPS_PER_MENU_ITEM set to 1 you will get a certain kind of behavior. Try some other values.

ENCODER_PULSE_PER_STEP is inactivated, by default. it's the first thing I've tried to look for and tried 1, 2, then 4 pulse to obtain that menu works fine with ENCODER_STEPS_PER_MENU_ITEM set to 1.

the MBL weird behavior won't depend of it. assuming jog step and calculation are good on screen, it's the move that not correspond to requested value.

when I set MESH_EDIT_Z_STEP 0.01 there is only 1 move each 3 jog or 0.03 mm increment.

[Tofoillote]

I guess that there is something somewhere that rounded or modulus the value or have some 'minimal z move' (also I've set this to 0.01) before sending the electrical order to motor to move.

only occur in MBL to my knowledge.

[Tofoillote]

Yeah ! finally succeed to compile bugfix version from platformio !

so, gived a try with :

MESH_EDIT_Z_STEP 0.1 => 1 jog step = 1x0.1 move. MESH_EDIT_Z_STEP 0.03 => 1 jog step = 1x0.03 move. MESH_EDIT_Z_STEP 0.01 => 1 jog step = 0 move ... MESH_EDIT_Z_STEP 0.01 =>+1 jog step = 0 move ... MESH_EDIT_Z_STEP 0.01 =>+1 jog step = 1x0.03 move !

So, below 0.03 ... manual bed leveling refuse to work 1 jog = 1 move Marlin.zip

But why ?

[ellensp]

That is how our nema 17 stepper motors really work. You imagine that they move every micro step, but they don't.
In reality the steps are cumulative and it moves when it can. This is normally happening so fast you don't notice. This is why setting large micro stepping does not increase resolution.

[Tofoillote]

this is the reason why I'm using 0.9° stepper motor. so ... even with 1/1 step it should work at 0.02 resolution, and it is not. (if you read my initial post you'll see I have 8 mm screw with 400 mecanical step a turn) it was the reason why I created this post.

I don't agree with you, 1/4 micro steps should be handled correctly by steppers whatever marlin send as a 'step' to it, stepper is normally able to handle the microstep it have been jumpered for.

so, accordingly to my Z step / mm resolution, firmware should handle as low as 0.005 mm steps here.

[Tofoillote]

why are ABL capable to record 3 digit after coma so ?

[Tofoillote]

can someone reproduce this MBL behavior ?

[Tofoillote]

EUREKA !

HIP HIP HURRA !

Finally got this little [censored] working !

Explanations : whatever I do ... this will not move untill I reach at least 0.03 mm a move. while my printer can have 0.005 mm a micro step move ... so 0.03=6*0.005 .... was tinkering in 2.0.5.4 release for to have some test and see a defined variable : MIN_STEPS_PER_SEGMENT 6 (in configuration_adv.h)

then tried to compile with :

define MIN_STEPS_PER_SEGMENT 2 (in configuration_adv.h)

define MESH_EDIT_Z_STEP 0.01 (in configuration.h)

AND IT WORKS !

So this is no bug, it is just : [BUG] Manual probing with LCD bed leveling don't works as expected.

because of that MIN_STEPS_PER_SEGMENT is limiting its precision !

This has to be noticed somewhere. or make this limitation not used in MBL !

on the other hand now I just can't figure out what the MIN_STEPS_PER_SEGMENT is supposed to act while printing ? and what it is used for ?

[AnHardt]

MIN_STEPS_PER_SEGMENT purposely limits the minimum amount of steps per segment. Planing segments takes some time. If the segments are to short they are faster stepped than planned and the planner buffer cant fill up, leaving the segments unconnected - stuttering. Even with low speeds there is a limit required (at leas at the AVRs). All positions can be reached - just the positions less the MIN_STEPS_PER_SEGMENT radius away can't be reached directly. Then moving MIN_STEPS_PER_SEGMENT backwards and then to where you want will be spot on. (I admit, up to now no one has tried to implemented that for the rarely used manual probing. Using a kind of BABYSTEPPING would be an other approach. )

Are adjustment steps below 0.03 mm really useful here, or is this just academic? With M5 z-spindles i have never seen the problem.

[Tofoillote]

no academy at all. I have real serious 1st layer adhesion problem and never succeEd in while my bed is quite non planar. should have probably better replaced it with a new one, but money isn't that all solutions. I'm coming from mechanical machining, and I'm using cigarets paper to tangent my parts. when I discover manual bed leveling I was happy to think I should manually obtain a good and acurate measure of my bed without sensor as I need to print part to support it.

now I will have a look why this MIN_STEPS_PER_SEGMENT is activated cause it seem used only by Bezier curve Gcode, that I'm slicing STL file will never have the use of it !

By the way, activated or not, this shouldn't create issue with MBL.

[Tofoillote]

Can somebody tell if MIN_STEPS_PER_SEGMENT is Bezier curve gcode only ?

[AnHardt]

Yes, a simple search can. No!

[Tofoillote]

Yes, a simple search can. No!

owh, thanks for teaching me this was simple as is !

So, as in https://marlinfw.org/docs/configuration/configuration.html it is in Enhanced G-code G60/G61 Position Save and Return G2/G3 Arc Support

I was daring it was concerning only "arc support and bezier curve" as it should.

Now on, I'm still asking what it is considered while Manual Probing ? (or LCD probing as it seems renamed)

it have to logically be set to a minimum value in order to be used by enhanced gcode right ?

in fact it'll bug LCD probing while the value isn't set to 1 ! making it useless so ...

I wish I was a better coder to give an helping hand on this, I'm yet too noob sorry.

Even this is no bug it's a nasty side effect !

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label / comment or this will be closed in 5 days.

[Tofoillote]

yup ... don't know why this closed. is that corrected in firmware ?

[sjasonsmith]

@Tofoillote did you receive a notification when the bot placed the stale label? That should have informed you that it would be closed if nobody replied to it within 5 days. The intent is that issues go away if everybody has stopped caring about them.

[sjasonsmith]

Reading through all of this, I think the topic makes sense. When doing things like baby stepping or manual probing, it makes sense to want things responsive to the encoder, without playing "lift up then go back down" games.

It does seem like Marlin is working as designed, so I am going to mark this as a feature request. This would certainly be an improvement in some hardware configurations, even if not everybody would benefit.

[Tofoillote]

Thanks @sjasonsmith.

Yes Marlin is working as designed, this is why it may not be a bug, just that MBL musn't consider using MIN_STEP_PER_SEGMENT limitation in its process.

And MIN_STEP_PERS_SEGMENT should also be in use ONLY if :

define ARC_SUPPORT

define BEZIER_CURVE_SUPPORT

are activated.

which aren't in my configs.

That is the point I don't want this being closed yet (yes I did receive the stale message, but was having nothing new to say)

[sjasonsmith]

And MIN_STEP_PERS_SEGMENT should also be in use ONLY if :

define ARC_SUPPORT

define BEZIER_CURVE_SUPPORT

Why?

[Tofoillote]

1st because it's in advanced Gcode section in arc_support in marlinfw ... 2nd is supposed to "smooth" too small a radius. while mostly using STL where slicing never give a "radial" value, just segments. 3rd because it may be absolute nonsense using this elsewhere as it divide printer resolution by this value (maybe in shaggy section only) 4th it make only sense for people using handmade or special CNC gcode using curves.

So this should be triggered as an option.

[AnHardt]

A way out of the dilemma could be to make MIN_STEPS_PER_SEGMENT a variable and setting it to a smaller value when needed. For example when jogging. A automatism could be tried. For example when the block-buffer is empty, we are planing a first move, starting from zero speed, and if not immediately followed by an other move, ending at zero speed, that is a kind of unavoidable stutter. Then a a shorter MIN_STEPS_PER_SEGMENT does not matter.

[ManuelMcLure]

It is not in the Enhanced Gcode section. It’s its own section after Enhanced Gcode. Look at the indentation in the menu in the sidebar.

[Tofoillote]

A way out of the dilemma could be to make MIN_STEPS_PER_SEGMENT a variable and setting it to a smaller value when needed. For example when jogging. A automatism could be tried. For example when the block-buffer is empty, we are planing a first move, starting from zero speed, and if not immediately followed by an other move, ending at zero speed, that is a kind of unavoidable stutter. Then a a shorter MIN_STEPS_PER_SEGMENT does not matter.

Sounds overwhelmingly over engineered to me.

[AnHardt]

Until users stop to try printing in moves only a few steps long and then wonder why Marlin stutters, we need a limit for the shortest allowed distance. Forever.

[Tofoillote]

I agree with the point that marlin should use it at simplifying nurbs curves. I can't deal with the agrement that marlin will then "over interpretate" the gcode then.

bad gcode that stutter while printing should stay bad gcode that stutter !
It's no marlin fault that bad stl or bad slicer gcode production are poor.

Sounds like a "good will" to facilitate the use of 3D printing to knowledgeless people. Dumbproofing solution. Producing 3D print is a chain that Marlin is just one link that shouldn't try giving a solution for previous link missuse.

Now my question is MIN_STEP_PERSEGMENT used elsewhere as in smoothing curve ? and so, why ? (considering the stuttering thing as no meaning for a gcode interpreter)_

[ellensp]

@Tofoillote if you promise to handle every support request from now till you pass away from every user with stuttering axis. Then ill agree with out. Otherwise. No.

You have to consider the real world vs the ideal impractical mathematically precise world.

[AnHardt]

Now my question is MIN_STEP_PER_SEGMENT used elsewhere as in smoothing curve ? and so, why ?

https://github.com/MarlinFirmware/Marlin/issues/18369#issuecomment-671835130 https://github.com/MarlinFirmware/Marlin/issues/18369#issuecomment-657541521

We are running in circles now.

It's not a bug. Please rename the title to "[Feature Request] ..." or close.

[AnHardt]

In arcs and bezier-curves MIN_STEPS_PER_SEGMENT is just reused. MIN_STEPS_PER_SEGMENT is as old as planer.cpp (expand planer.cpp) - then the name was dropsegments - but it seems to be Marlin specific. GRBL instead uses if (block->step_event_count == 0) { return; } - but they don't have extruders and no temperatures and no ... to care about - so panning is much faster.