[bugfix-2.0.x] Z bump divisor ineffective and/or Z speed glitch, homing buggy (all axes)

[VanessaE]

Description

Commit b9418439b94d6d7ba1b700d16c78888e458d4102

During homing, the Z move "bumps" when my sensor triggers, like normal, but the speed of the second/bump move is definitely the same as the normal Z homing speed (900 mm/min)

Z speeds during G29 behave in a similar manner. My divisors:

#define HOMING_BUMP_DIVISOR { 4, 4, 8 }  // Re-Bump Speed Divisor (Divides the Homing Feedrate)`

(These are my normal settings, imported by hand from bugfix-1.1.x)

Steps to Reproduce? Beats me. Load my configuration and try it? :smiley:

[VanessaE]

now at commit ~~9b63430f~~... correction, ae15c5a

I'm putting this here to avoid cluttering the issue list, as I am not sure if this is a general 2.0.x bug:

I've run into an oddity:

Now homing is a bit... "harsh".  That is to say, acceleration seems to not be in use, at least not to the same degree.  It's especially evident when an endstop is triggered, the axis stops cold, pauses momentarily, then begins the reverse move for the "bump".  This happens on all axes (cartesian), and affects probing during `G29` also (all Z moves therein).

Sometimes, Z moves are super slow - if I had to guess, the speed dictated by my Z bump divisor -- for normal moves and for `G28` and `G29`.

Marlin configs:  [Marlin-configs-20180610.zip](https://github.com/MarlinFirmware/Marlin/files/2087896/Marlin-configs-20180610.zip)

[ejtagle]

Maybe your maximum feedrate is above the maximum achievable... In such case you will think divisor is not working, but, in fact, what is actually happening is that the speed is limited by hardware... Some improvements have been done in #10922, if you want to try them...

[VanessaE]

I highly doubt I'm hitting a speed limit, as my Z axis can run somewhat reliably at around 3000 mm/min (in theory, it can do twice that) with gentle acceleration. However, I home at 900, and do routine moves at 1800 during a print.

[VanessaE]

I note that #10922 just got merged. *updates*

I've set MAXIMUM_STEPPER_RATE to 500000 to suit my A4988 driver modules, and turned the new feature on this time. :stuck_out_tongue:

The bump divisor seems to be working. Maybe I misunderstood what I was seeing there.

However, the not-very-accelerated motion during homing and G29 is unchanged.

[ejtagle]

Well, i do not completely understand... When an endstop is hit, there will be a sudden and inmediate stop. No deacceleration, just a complete stop. This is expected, as the only way to deaccelerate is to have some space, and when the switch triggers, it is assumed you have reached the physical limits of your machine and any extra movement in that same direction will cause damage to it...

[VanessaE]

You're right, of course, but I'm talking about (the beginning and end of) the reverse move after the end stop has been hit, and the (beginning of the) bump move that follows it (or the few that follow the initial sensor trigger for each G29 probe move).

[ejtagle]

Basically, the begin and reverse moves should be respecting the maximum acceleration configured in your configuration.h file... Maybe it is just set too high ? (I would not worry about it if the motors are not losing steps, there is no need to lower it! )

[VanessaE]

The maximum acceleration? Should they not respect the current normal travel acceleration instead?

If I had to graph it, it would look something like this:

Time on the horizontal, speed on the vertical. The drop at "1" is the initial hit on the end stop. Reverse direction and accelerate to bump speed starting at "2", start back toward the end stop at "3", hit the end stop again at "4". Green is what I'm used to seeing, red is what it's doing now. The momentary pauses that happen now (at 2 and 3) are exaggerated here.

[ejtagle]

Seems it is accelerating way faster than before... Truth to be said, i never bothered investigating that... Now there are a ton of changes in the movement planner and stepper code of Marlin, so i have to figure out if the new behaviour is the correct, and the previous an incorrect one, or the opposite... :S

[VanessaE]

I won't worry about it as long as the speed it's moving when it hits the end stop is correct (and it's not losing steps) - it's just something that triggered my "this is way different, approach with caution" sense. :smile:

[ejtagle]

So many changes lately... I am sure there will be things that will change. The most important thing is to note if something stops working, or stops working reliably...

[VanessaE]

Right. That's why it stood out.

[thinkyhead]

…I am sure there will be things that will change…

This issue with the bump acceleration is certainly not limited to just the one place. Marlin has always been very brittle and inter-dependent, so various things are bound to break in hard-to-understand ways whenever code stabilized over months and years (by whatever means) is supplanted by fresh untested code. The bump acceleration issue is just a clue to a more fundamental flaw.

[ejtagle]

Pleaso, try PR #11098 and see if it fixes things for you...

[thinkyhead]

Now would be a good time to re-test the latest bugfix branches. Motion and endstops issues have been addressed, tested, and re-tested. This is one of the last issues we need to verify before we have full confidence.

[VanessaE]

Still the same behavior at e0ab8acf198648f731074f9b14f3562b55c5dd5a (referring to the way it accelerates, since the speed seems about right). It still works, though.

[thinkyhead]

@ejtagle — Might this be related to the current issue at https://github.com/MarlinFirmware/Marlin/issues/10446#issuecomment-401511959 where the change from infill to perimeter speed, combined with a change in direction, gives an unusual acceleration result?

[ejtagle]

It shouldn´t. To be honest, i have seen what @VanessaE refers. But, i did dump the movement blocks and there is no sudden acceleration... So it is a big mistery the cause...

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