[BUG] baby stepping only moves z axis in one direction

[spattinson]

Bug Description

Z axis only moves nozzle down regardless of which way encoder turns. The lcd display goes up and down numerically, the nozzle only goes down. M851 actual and recorded differ

My Configurations

SKR Pro
Marlin-bugfix-2.0.x - pulled around 7pm GMT 10/02/20
Reprap discount smart display
BLTouch
#define BABYSTEP_ALWAYS_AVAILABLE
#define BABYSTEP_ZPROBE_OFFSET
Universal bed leveling

Steps to Reproduce

G28
G0 Z0.3
double click encoder
turn encoder to calibrate with piece of paper between nozzle and bed.

Expected behavior: z axis moves up or down depending on direction encoder is turned and the correct measurement changes displayed on the LCD and also changes z offset (M851)
Actual behavior: numbers go up and down in the lcd display, but z-axis lowers nozzle regardless of direction of encoder. The offset M851 has is therefore incorrect.

Additional Information

My bed leveling gcode, done some time prior to this in case its relevant:

M190 S70
G28
G29 P1
G29 P3 T1
G29 T
G29 S1
G29 F 5.0
G29 A
M420 C
M500
M190 S0
M104 S0
M18
G27

output of M503:

echo:  G21    ; Units in mm (mm)
echo:  M149 C ; Units in Celsius
echo:Filament settings: Disabled
echo:  M200 D1.75
echo:  M200 D0
echo:Steps per unit:
echo: M92 X80.00 Y80.00 Z2560.00 E140.00
echo:Maximum feedrates (units/s):
echo:  M203 X300.00 Y200.00 Z4.00 E25.00
echo:Maximum Acceleration (units/s2):
echo:  M201 X1500.00 Y1500.00 Z100.00 E10000.00
echo:Acceleration (units/s2): P<print_accel> R<retract_accel> T<travel_accel>
echo:  M204 P1500.00 R1000.00 T1500.00
echo:Advanced: B<min_segment_time_us> S<min_feedrate> T<min_travel_feedrate> J<junc_dev>
echo:  M205 B20000.00 S0.00 T0.00 J0.02
echo:Home offset:
echo:  M206 X0.00 Y0.00 Z0.00
echo:Unified Bed Leveling:
echo:  M420 S1 Z5.00
Unified Bed Leveling System v1.01 active
Active Mesh Slot: 1
EEPROM can hold 155 meshes.
echo:Material heatup parameters:
echo:  M145 S0 H180 B70 F0
echo:  M145 S1 H235 B70 F0
echo:PID settings:
echo:  M301 P22.30 I1.47 D84.73
echo:  M304 P63.36 I11.82 D226.41
echo:Z-Probe Offset (mm):
echo:  M851 X27.00 Y1.00 Z-1.42

conf.zip

[thinkyhead]

See if #16833 helps at all. If so, then we'll merge that and continue exploring other techniques to improve babystep handling.

[bill-orange]

Is his problem present in 2.0.1? If so It would explain some of my ( usually self-inflicted) Z-offset probems.

[spattinson]

That didn't fix it. I am not conversant with git so I followed that link to #16833 looked at the commit then navigated to stepper.cpp and applied it to my build env.

I also tried a fresh clone of bugfix-2.0.x that didn't work either

I have a copy of the MultiSPI branch that @LinoBarreca worked on, so I tested that, I can't get to babystepping by double clicking but if I go via menus to adjust z offset it works as expected. I pulled that on Jan 23, IDK when he forked it but babystepping was working properly

@bill-orange My usual method of babystepping is to do it at the beginning of a print during 1st layer, sometimes using a brim. I was having trouble with that method, so I try static method above, so I cant say for sure when this bug appeared, though its probably recent otherwise someone else would have reported it. For now I will avoid babystepping and just do G28 Z, G0 Z..., make calculation M851 Z.... repeat.

[spattinson]

For reference this is stepper.cpp from MultiSPI fork that works with babystepping, I can see that a lot of changes have been done since it was forked.
stepper.cpp.gz

[thinkyhead]

See if this is working at all… #16829

[spattinson]

Not working at all now with #16829 . The number changes in the LCD display but Z axis does not move at all, up or down. I did a fetch today, so I got whatever other updates too. There's no urgency on this, I am getting consistent z offset between prints so don't have to adjust it much. Just let me know when you want me to test again. Thanks.

[thinkyhead]

Not working at all now with #16829.

Well, it is quite experimental, and just a starting point. A deeper integration of babystepping is possible, but that will be a bigger project.

numbers go up and down in the lcd display, but z-axis lowers nozzle regardless of direction of encoder.

As for the OP, all we can do is have you experiment with the timing code around babystepping and see if it gets that DIR pin set up correctly for you. Sounds like the DIR pin is simply not getting set by the babystep method.

[bill-orange]

I retested babystepping on version 2.0.4.4 and the problem still exists on my Melzi board.

Steps to Reproduce

Start a print too far from the bed.

On the LCD go to TUNE -> Z-offset

Adjust Z-offset down -- No change in first layer height will occur.

Stop print and set Z-offset with gcode to the same value as above.

Restart print and notice corrected z-offset.

Is there a fix in work for this? Should this be opened as a new issue?

[spattinson]

@bill-orange Sounds the same as what I am seeing now, the original issue symptoms have changed from only moving in one direction to not moving at all in newer releases. Probably if you have #define BABYSTEP_ZPROBE_OFFSET // Combine M851 Z and Babystepping
it will correct itself after the next Z home as you are seeing.

[thinkyhead]

Adjust Z-offset down -- No change in first layer height will occur.

From the babystepping screen? There are a couple of options for that now which you might try. See if disabling BABYSTEPPING_EXTRA_DIR_WAIT (hidden in stepper.cpp) helps. And see if using INTEGRATED_BABYSTEPPING both with and without BABYSTEPPING_EXTRA_DIR_WAIT makes any difference.

Babystepping is a hack, so it is bound to come up against some oddities.

To make sure you're only testing babystepping and not interactions with other things, be sure to turn off everything extra before flashing. And of course, always test with bugfix-2.0.x because we are constantly getting patches.

[bill-orange]

Will do. It looks like to turn INTEGRATED_BABYSTEPPING on, I need to uncomment #define INTEGRATED_BABYSTEPPING somewhere. I could not find it. Can you tell me the approximate location? Alternatively to I need to add the line #define INTEGRATED_BABYSTEPPING to my configuration_adv.h? Perhaps what you are suggesting is that I change #define BABYSTEPPING to #define INTEGRATED_BABYSTEPPING ?

[MoellerDi]

INTEGRATED_BABYSTEPPING

is in the configuration_adv, see link below.
https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/Configuration_adv.h#L1449

if it's not in yours, add the line "#define INTEGRATED_BABYSTEPPING" as shown in the link

[bill-orange]

Added, Done!

…

Sent from my iPhone

On Feb 29, 2020, at 11:37 AM, MoellerDi ***@***.***> wrote:  INTEGRATED_BABYSTEPPING is in the configuration_adv, see link below. https://github.com/MarlinFirmware/Marlin/blob/2.0.x/Marlin/Configuration_adv.h#L1449 if it's not in yours, add the line "#define INTEGRATED_BABYSTEPPING" as shown in the link — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[bill-orange]

@thinkyhead @MoellerDi With both "#define INTEGRATED_BABYSTEPPING" added and "BABYSTEPPING_EXTRA_DIR_WAIT" disabled, babystepping now works. I did not test the two changes individually.

[phazei]

I'm having this same issue, I tried most thing suggested here to no avail. INTEGRATED_BABYSTEPPING didn't help at all for me. (I did not comment out BABYSTEPPING_EXTRA_DIR_WAIT, it's remained default on)

I filed a ticket before I realized this was almost the same.
#17685
I was just trying to use z-probe-offset to calibrate which uses the same babysteps.

I then found #17323 and it seems to have fixed the babysteps going in both directions. It eventually stops working entirely unless I home again, but at least it now functions mostly.

[spattinson]

#17323

[github-actions]

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.