Doesn't goes up after and before homing cycles during Mesh Leveling

[soswow]

RC7, freshly cloned today. My full config is here: https://gist.github.com/soswow/cdb4c36e5c2d3c8fba5e4326d3e39899/6798c3ebdec263ad7e5b4e8052eb064c6c295cbb

I use full graphics display to do mesh manual. When homing is done I click to got to the first point Z steppers do loud noise (as in when you try to set high speed momentarily) and then it start moving to the first point. Right away. Without actually lifting it. At the point there was loud sound again (where it suppose to go down). I think same happened when I last point was measured.

I've left some debug just in place in around // For the initial G29 S2 make Z a positive value (e.g., 4.0) line and it showed that indeed current_position[Z_AXIS] was 10. Shouldn't there be something like line_to_current_position(); stepper.synchronize(); to actually move it? (I just see this is in the case in other places, where current_position[Z_AXIS] is being changed.

[thinkyhead]

@soswow RC7 is over a month old, even when freshly cloned today. If you're looking to test the most recent code, please check out RCBugFix. If you're coming from an earlier version of Marlin, be aware that acceleration has been fixed, so the values in your old configuration may be too high for the repaired code.

You can see that there is a raise of the Z axis. It's in the _mbl_goto_xy function. It tries to use the homing feedrate. If you find that Z can't raise at that speed, try lowering the Z feedrate, homing feedrate, acceleration, and/or jerk values and see if any of those changes help. It would be good to re-tune your Z speeds generally for the updated firmware.

[soswow]

Yes, I am coming from RC6, and yes, I am on RC branch. Will try to use RCBugFix and play with speed variables. + I know where exactly it suppose to go up. Just checking: if my homing works well, doesn't it mean my homing feed rate is all right? My Z_HOMING_HEIGHT is 4 so it goes up and down quite substantially and it moves with normal speed.

[thinkyhead]

@soswow Presumably it should work if your homing works. Are you using Z_HOMING_HEIGHT (formerly Z_RAISE_FOR_HOMING) to do a Z raise before homing XY?

If you do continue to see issues with RCBugFix then we should look at the code and make sure the movement rates are all being set correctly. In any case the Z movement rate should be constrained by the max feedrate settings.

[soswow]

Are you using Z_HOMING_HEIGHT (formerly Z_RAISE_FOR_HOMING) to do a Z raise before homing XY?

Yes, it is 4 in my case. I've updated config due to move to RCBugFix branch. https://gist.github.com/soswow/cdb4c36e5c2d3c8fba5e4326d3e39899

I still have an issue. It does homing well still.

[soswow]

As I understand there is one _mbl_goto_xy for manual via screen, and manual via console. They quite different. Interesting why it's so. The console one has code like

float old_feedrate_mm_s = feedrate_mm_s;
feedrate_mm_s = homing_feedrate_mm_s[X_AXIS];

But screen one doesn't have this.

[soswow]

I think I found it. LCD's _mbl_goto_xy uses MANUAL_FEEDRATE which is in adv. config and I haven't seen it (nether changed) will see how it goes.

[soswow]

Confirmed. I wasn't aware of this setting. Curious why it's separate ....

[thinkyhead]

MANUAL_FEEDRATE should only apply to manual moves initiated from the LCD controller, so I'm not sure why it was chosen for MBL, except that often MBL is done using the controller. But a new feedrate setting for movement between probe points, XY_PROBE_SPEED, was introduced more recently and was just never applied to it. So I'll change it to that.

[Roxy-3D]

But a new feedrate setting for movement between probe points, XY_PROBE_SPEED, was introduced more recently and was just never applied to it. So I'll change it to that.

Does MANUAL_FEEDRATE serve a purpose any more? Are you saying that you will consolidate everything to use XY_PROBE_SPEED?

[thinkyhead]

MANUAL_FEEDRATE applies specifically to the "Move Axis" options on the LCD controller.

[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.