Marlin: [BUG] SKR 1.3 babystepping always rising Z axis, even when going to negative values

Created on 17 Jun 2019  路  18Comments  路  Source: MarlinFirmware/Marlin

Description

Hi guys, and thanks for this awesome project, it really makes tinkering super fun, and simple. This is the first time I'm reaching out for help and I hope the issue will be no batch for Marlin gurus :).

I have a Prusa 3D printer clone (DIY) rocking SKR 1.3 and Marlin 2.0 and I have TMC2130 in SPI mode with sensorless homing and it's working great except the fact that I can't use babystepping at all.

Below is attached video of the issue but it's quite simple to explain: No mater if I turn babysteps to + or - value the Z axis is always rising.

I had the same behavior on a month old Marlin 2 and on the latest version downloaded yesterday (June 16th 2k19) so this is not fixed (at least for me) in the latest build.

Z motors are attached to a single Z stepper driver (with z-axis stepper splitter adapter, parallel connection) and the Z stepper driver is set to 800mV (default marlin config).

I thought the issue might be in the knob of the reprap full gprahic smart controller I have so I swaped it with another I had laying around, and it was performing exactly the same.

Steps to Reproduce

  1. Let the print start
  2. Access babystepping to get the perfect first layer
  3. Adjust babystepping by turning it up/down

Expected behavior:
Babysteps are moving the Z axis both up and down

Actual behavior:
Babysteps are moving the Z axis only up, even when turning steps to a negative value

Additional Information

Confirmed !

All 18 comments

I just rebased my Ender 3 config on top of 8e23e9b, and babystepping is working fine in both directions for me.

To clarify, this is an Ender 3 running on an SKR 1.3.

I've put all this on pause (didn't have luck with resolving the issue) as i think i might have a bad board (I hope i'm wrong but seems to be like that as i can't find anyone with the same issue, so it's definitely me :D)... I'm waiting for 2 new boards from AliExpress and will re-test this once they arrive so I'll update the issue once i have more info.

We are experiencing the same.
The babystepping will only go in the direction that the previous Z move was in (up or down).
We suspect a timing problem for some stepper drivers
Maybe related to #14898 and the long running #11047

I have the same issue on my SKR 1.3
I'm using bltouch for leveling and after homing doesn't matter which direction I rotate the Z probe offset its's just rising or sometimes only lowering.

I tried everething with babystepping but no results:

#define BABYSTEPPING
#if ENABLED(BABYSTEPPING)
  //#define BABYSTEP_WITHOUT_HOMING
  //#define BABYSTEP_XY                     // Also enable X/Y Babystepping. Not supported on DELTA!
  #define BABYSTEP_INVERT_Z false           // Change if Z babysteps should go the other way
  #define BABYSTEP_MULTIPLICATOR  10         // Babysteps are very small. Increase for faster motion.

  #define DOUBLECLICK_FOR_Z_BABYSTEPPING  // Double-click on the Status Screen for Z Babystepping.
  #if ENABLED(DOUBLECLICK_FOR_Z_BABYSTEPPING)
    #define DOUBLECLICK_MAX_INTERVAL 1250   // Maximum interval between clicks, in milliseconds.
                                            // Note: Extra time may be added to mitigate controller latency.
    #define BABYSTEP_ALWAYS_AVAILABLE     // Allow babystepping at all times (not just during movement).
    //#define MOVE_Z_WHEN_IDLE              // Jump to the move Z menu on doubleclick when printer is idle.
    #if ENABLED(MOVE_Z_WHEN_IDLE)
      #define MOVE_Z_IDLE_MULTIPLICATOR 1   // Multiply 1mm by this factor for the move step size.
    #endif
  #endif

  //#define BABYSTEP_DISPLAY_TOTAL          // Display total babysteps since last G28

  #define BABYSTEP_ZPROBE_OFFSET          // Combine M851 Z and Babystepping
  #if ENABLED(BABYSTEP_ZPROBE_OFFSET)
    //#define BABYSTEP_HOTEND_Z_OFFSET      // For multiple hotends, babystep relative Z offsets
    #define BABYSTEP_ZPROBE_GFX_OVERLAY   // Enable graphical overlay on Z-offset editor
  #endif
#endif

I also tried to play with driver delays, unfortunately still no effect.

/**
 * Minimum delay after setting the stepper DIR (in ns)
 *     0 : No delay (Expect at least 10碌S since one Stepper ISR must transpire)
 *    20 : Minimum for TMC2xxx drivers
 *   200 : Minimum for A4988 drivers
 *   400 : Minimum for A5984 drivers
 *   500 : Minimum for LV8729 drivers (guess, no info in datasheet)
 *   650 : Minimum for DRV8825 drivers
 *  1500 : Minimum for TB6600 drivers (guess, no info in datasheet)
 * 15000 : Minimum for TB6560 drivers (guess, no info in datasheet)
 *
 * Override the default value based on the driver type set in Configuration.h.
 */
#define MINIMUM_STEPPER_DIR_DELAY 650

/**
 * Minimum stepper driver pulse width (in 碌s)
 *   0 : Smallest possible width the MCU can produce, compatible with TMC2xxx drivers
 *   0 : Minimum 500ns for LV8729, adjusted in stepper.h
 *   1 : Minimum for A4988 and A5984 stepper drivers
 *   2 : Minimum for DRV8825 stepper drivers
 *   3 : Minimum for TB6600 stepper drivers
 *  30 : Minimum for TB6560 stepper drivers
 *
 * Override the default value based on the driver type set in Configuration.h.
 */
#define MINIMUM_STEPPER_PULSE 2

/**
 * Maximum stepping rate (in Hz) the stepper driver allows
 *  If undefined, defaults to 1MHz / (2 * MINIMUM_STEPPER_PULSE)
 *  500000 : Maximum for A4988 stepper driver
 *  400000 : Maximum for TMC2xxx stepper drivers
 *  250000 : Maximum for DRV8825 stepper driver
 *  200000 : Maximum for LV8729 stepper driver
 *  150000 : Maximum for TB6600 stepper driver
 *   15000 : Maximum for TB6560 stepper driver
 *
 * Override the default value based on the driver type set in Configuration.h.
 */
#define MAXIMUM_STEPPER_RATE 250000

We fixed this with latest bugfix2.0
And by setting the X, Y and Z pulses to true

define INVERT_X_STEP_PIN true

define INVERT_Y_STEP_PIN true

define INVERT_Z_STEP_PIN true

define INVERT_E_STEP_PIN false

will close as its fixed, we can reopen if needed

Awesome guys, thanks a lot! I'll actually test this today and will let you know if it's still happening.

@boelle confirming this one is fixed 馃憤

I've been running into the same issue with 2.0.1 I will try the above solution.
https://github.com/MarlinFirmware/Marlin/issues/13484#issuecomment-569456369

will close as its fixed, we can reopen if needed

Hi there, the issue is there again with marlin 2.0.1 stable, skr 1.3 and TMC2209.

define INVERT_X_STEP_PIN true

define INVERT_Y_STEP_PIN true

define INVERT_Z_STEP_PIN true

define INVERT_E_STEP_PIN false

I did this and it seems to be fine BUT the first opposite move does not make any effect.
If for example I turn the knob down twice, then when I do it up the first times won't make any effect. Next ones will. And so on it is always the same.

Same issue here, running Marlin 2.0.1 with SRK 1.4 and TMC2209 steppers. The head only moves closer to the bed, no matter if i turn CW or CCW in babystepping.

@Zappa55555 @bkopanja is there an issue in bugfix 2.0.x ?

@boelle nope i don鈥檛 have this issue anymore as already confirmed in my comment above

Not fixed.

this still works for us in bugfix 2.0.x
for those that have problems also try some sane values for:

define MINIMUM_STEPPER_POST_DIR_DELAY 5000

define MINIMUM_STEPPER_PRE_DIR_DELAY 5000

define MINIMUM_STEPPER_PULSE 6

define MAXIMUM_STEPPER_RATE 80000

will close as both @bkopanja and @maukcc report its working

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

heming3501 picture heming3501  路  4Comments

modem7 picture modem7  路  3Comments

spanner888 picture spanner888  路  4Comments

Kaibob2 picture Kaibob2  路  4Comments

Anion-anion picture Anion-anion  路  3Comments