Marlin: Problems with functions BABYSTEPPING

[Sanitar777]

Hello!

My printer have the H-Bot kinematics. I am using Marlin RC7 + last RCBugFix firmware.

The problem is occurs when I use the function BABYSTEPPING.
Table height is changed only in one direction when I make any change at the LCD encoder.
The gap between the nozzle and the table is only increasing.
I can't reduce this gap.

Thank you for your work!

[thinkyhead]

I don't think BABYSTEPPING is yet compatible with Core / Hbot kinematics. I'll try to patch that tonight.

[Sanitar777]

This is a very handy feature. Would be very grateful to you.

[thinkyhead]

Please test when you have a chance. The code is at
https://github.com/thinkyhead/Marlin/tree/rc_core_babystepping

[Sanitar777]

Sorry. Unchanged. Not working.
In addition, checked the movement in BABYSTEPPING on the X-axis. In one direction all right, but in the other direction moves the Y-axis

Sorry, I did not specify my preferences.

// @section machine

// Uncomment one of these options to enable CoreXY, CoreXZ, or CoreYZ kinematics
#define COREXY //777
//#define COREXZ
//#define COREYZ

// Babystepping enables the user to control the axis in tiny amounts, independently from the normal printing process
// it can e.g. be used to change z-positions in the print startup phase in real-time
// does not respect endstops!
#define BABYSTEPPING
#if ENABLED(BABYSTEPPING)
  #define BABYSTEP_XY  //777 not only z, but also XY in the menu. more clutter, more functions
                       //not implemented for deltabots!
  #define BABYSTEP_INVERT_Z false  //true for inverse movements in Z
  #define BABYSTEP_MULTIPLICATOR 40 //777 faster movements
#endif

[thinkyhead]

@Sanitar777 I probably just got the maths incorrect. I'll take a closer look.

[Sanitar777]

Thank you. And forgive me to bother you for nothing.

[thinkyhead]

Apparently the code already supports Core kinematics, but at a higher level, so I've reverted that branch and am trying something else…

Incidentally, is this a CoreXY, CoreXZ, or CoreYZ?

Also, on the LCD display, is the displayed Z babystep value going up and down appropriately?

[Sanitar777]

My settings is: CoreXY
On the second question: Yes. On the LCD everything is displayed correctly.

[thinkyhead]

Ok, so I did one thing: made the stepper pulses slightly longer in the babystep handler. Try that branch again when you have a chance.

[thinkyhead]

Oops, forgot to git push. Should be good now.

[Sanitar777]

[Sanitar777]

Nothing has changed

[Sanitar777]

Config options unrelated to BABYSTEPPING

###  //#define DEFAULT_AXIS_STEPS_PER_UNIT   {(400*16)/(2.0*16),(400*16)/(2.0*16),400*16/4,325.0}  //777 default steps per unit for 3D Printer S
#define DEFAULT_AXIS_STEPS_PER_UNIT   { 200, 200, 1600, 325 } //777

/**
 * Default Max Feed Rate (mm/s)
 * Override with M203
 */
#define DEFAULT_MAX_FEEDRATE          { 300, 300, 15, 150 } //777

/**
 * Default Max Acceleration (change/s) change = mm/s
 * Override with M201
 *
 * Maximum start speed for accelerated moves: { X, Y, Z, E }
 */
#define DEFAULT_MAX_ACCELERATION      { 1500, 1500, 50, 15000 } //777

/**
 * Default Acceleration (change/s) change = mm/s
 * Override with M204
 *
 *   M204 P    Acceleration
 *   M204 R    Retract Acceleration
 *   M204 T    Travel Acceleration
 */
#define DEFAULT_ACCELERATION          1000    //777 X, Y, Z and E acceleration for printing moves
#define DEFAULT_RETRACT_ACCELERATION  10000    //777 E acceleration for retracts
#define DEFAULT_TRAVEL_ACCELERATION   1000    //777 X, Y, Z acceleration for travel (non printing) moves

/**
 * Default Jerk (mm/s)
 *
 * "Jerk" specifies the minimum speed change that requires acceleration.
 * When changing speed and direction, if the difference is less than the
 * value set here, it may happen instantaneously.
 */
#define DEFAULT_XJERK                 10.0
#define DEFAULT_YJERK                 10.0
#define DEFAULT_ZJERK                  0.5
#define DEFAULT_EJERK                 20.0

[Sanitar777]

The X-axis and Y-axis also do not work correctly in BABYSTEPPING.

[thinkyhead]

On CoreXY the Z axis is your normal axis, so let's focus on that one. The normal axis being messed-up implies that babystepping would be broken on any machine, whether Core or not. So I've made the step pulse twice as long again. Give that branch another try and see if it makes any difference at all.

By the way, what kind of stepper drivers are you using?

[Sanitar777]

ok

[Sanitar777]

Nothing has changed. Does not work properly.

TB6600

And I use the RepRapDiscount FULL GRAPHIC Smart Controller

[thinkyhead]

And otherwise the XYZ motion works ok? You can print without any issues?

[Sanitar777]

No problem.

[thinkyhead]

@adamfilip Do you also see problems with BABYSTEPPING on your Core machine?

[Roxy-3D]

Do you also see problems with BABYSTEPPING on your Core machine?

I'm not sure what he has loaded at the moment, but Adam has been running the UBL code some of the time. And I've messed with things to make QUICK_ACCESS_TO_Z_BABYSTEPPING available. So that might not be a valuable data point.

Incidentally.... I finally have the "Press and Hold" functionality ready to turn on Z-BabyStepping.

[adamfilip]

My CoreXY has been converted to DuetWifi so i can't test on it anymore with Marlin (until Marlin 32bit is released)
when it was running Marlin, I dont recall a specific Babystepping issue. quick access i couldnt use at the time. it either came up immediately when booted and then wouldnt go away and i couldnt get the kill button to bring it up

i still have a i3 Rambo based printer, Havent used it in a few weeks. But i can load up with the fresh Bugfix is needed

[Roxy-3D]

quick access i couldnt use at the time. it either came up immediately when booted and then wouldnt go away and i couldnt get the kill button to bring it up.

I'm not sure you saw the resolution of that issue. It turns out some of the Kill buttons are noisy on some of the controllers. They seem to trigger even with nobody pressing the switch. I ended up adding some 'debouncing' logic and so far, that has taken care of the problem. Now, I've got the "Press and Hold" working, but I have do some QA testing and make sure everything is as it should be.

[Sanitar777]

I understand that now I say is not entirely correct, but still... I just tested Repetier-Firmware on my CoreXY kinematics. Working correctly. The reasons are not in the kinematics and hardware. Sorry.

[thinkyhead]

The reasons are not in the kinematics and hardware.

Surely. I'm requesting more data samples from other CoreXY users to understand the nature of the software problem. Whether it could be pulse length or if it is indeed a bug in the code that applies babysteps to Core kinematics.

When using Repetier-Firmware, what did you use for your DRIVE_SYSTEM setting? Is it possible your H-bot is not COREXY, but the reverse, COREYX?

Anyway, since your non-hbot axis (Z) is failing to move in two directions, it seems like BABYSTEPPING is broken generally with your setup, and this is not related to it being an H-bot.

You may also try Marlin 1.0.2-2 to see if BABYSTEPPING is also broken in that version.

[Sanitar777]

When using Repetier-Firmware, what did you use for your DRIVE_SYSTEM setting? Is it possible your H-bot is not COREXY, but the reverse, COREYX?

My CoreXY configuration in Repetier:

You may also try Marlin 1.0.2-2 to see if BABYSTEPPING is also broken in that version.

I can't test this version:

#define BABYSTEPPING //777
#ifdef BABYSTEPPING
  #define BABYSTEP_XY  //not only z, but also XY in the menu. more clutter, more functions
  #define BABYSTEP_INVERT_Z false  //true for inverse movements in Z
  #define BABYSTEP_Z_MULTIPLICATOR 2 //faster z movements

  #ifdef COREXY
    #error BABYSTEPPING not implemented for COREXY yet.
  #endif

  #ifdef DELTA
    #ifdef BABYSTEP_XY
      #error BABYSTEPPING only implemented for Z axis on deltabots.
    #endif
  #endif
#endif

I'm so sorry, I forgot to say that on the Z axis, I have two motors and two endstops in MAX. Maybe in this case?

[thinkyhead]

Aha. It's true that full Core support is pretty new.

Ok, so you're using the standard CoreXY setup. In that case, I think my maths are correct. And, as mentioned, the normal axis (Z) doesn't do anything special. It should work, just as it does on the typical Cartesian.

Feel free to play with these lines in temperature.h until you get it to work properly for your machine:

case CORE_AXIS_1: // X on CoreXY and CoreXZ, Y on CoreYZ
  babystepsTodo[CORE_AXIS_1] += distance * 2;
  babystepsTodo[CORE_AXIS_2] += distance * 2;
  break;
case CORE_AXIS_2: // Y on CoreXY, Z on CoreXZ and CoreYZ
  babystepsTodo[CORE_AXIS_1] += distance * 2;
  babystepsTodo[CORE_AXIS_2] -= distance * 2;
  break;
case NORMAL_AXIS: // Z on CoreXY, Y on CoreXZ, X on CoreYZ
  babystepsTodo[NORMAL_AXIS] += distance;
  break;

[ruggb]

I didn't read all the posts but for babystep_Z to work with my CoreXY config I disabled the babystep_xy
//#define BABYSTEP_XY //777 not only z, but also XY in the menu. more clutter, more functions
//not implemented for deltabots!
It isn't useful to me anyway
Z babystepping has worked for a long time on CoreXY if xy babystepping is disabled. I have not tried xy babystepping since thinkyhead indicated it was fixed months ago. I don't need it.

[Sanitar777]

ruggb
Thank you very much!
Now It is work correctly! Only at one Z-axis.

[ruggb]

@thinkyhead
hey Steve Scott - we did this a couple times. I'm old and allowed to forget things - maybe you should add a comment in the code so you don't reinvent the wheel every time it comes up.

[ruggb]

@Sanitar777 & @thinkyhead
you may also want to look a issue #5217

[Sanitar777]

Oh! Thank you. Yeah, fun idea.

[thinkyhead]

I do like #5217 and will likely merge it soon. Disappointed, though, that I can't get CoreXY babystepping correct. It shouldn't be so tricky.

[ruggb]

you are referring to babystepping a corexy in the x and/or y direction - correct?
The z direction works just fine with X/Y disabled.
Is there really a need for x/y on a corexy machine? That said, the first thing I would look at is why enabling x/y interferes with z. They should be totally separate functions, right?

[thinkyhead]

@ruggb Exactly. They shouldn't interact. So, yeah, it would be a good start to figure that out.

Maybe XY babystepping isn't needed generally, but as long as we've got it for regular Cartesian, it seems like it would be more "complete" to have it for Core too.

[boelle]

@ruggb any news?

[ruggb]

@boelle not sure what news you are looking for, but #5217 says a lot about babystepping. However, as to why it does not work for XY on a core machine - no clue. I am not a programmer. Fortunately, IMHO, I don't think there is much use for it unless someone has X or Y defined as the height. Hopefully #5217 gets into RC7.

[thinkyhead]

I'd be the one to try to figure this out, if anyone, since I did the implementation. I've looked at it till my eyes crossed, and haven't been able to perceive the exact cause. So for now it's just not supported to use XY babystepping on CoreNN machines.