Marlin: SBase: Baby stepping not working at all

[b3nn0]

Description

Hi,
I had baby stepping running properly in the past, but about a month ago, when I upgraded to the latest bugfix-2.0.x version, it stopped working. I already tried several combinations of settings, like LEVELING_FADE_HEIGHT, etc. But to no avail.
The problem can be seen in this video:
https://cloud.batzill.com/index.php/s/Ckf9rYYJswtDjKb

Steps to Reproduce

Configure baby stepping via double click, try to use it.

Expected behavior: The nozzle moves up/down

Actual behavior: The nozzle doesn't move at all

Additional Information

Config:
config.zip

[thinkyhead]

Please test with the current bugfix-2.0.x branch to see where it stands. If the problem has been resolved then we can close this issue. If the issue isn't resolved yet, then we should investigate further.

[b3nn0]

Sorry, should have said that before. This is the latest bugfix-2.0.x version as of today.
What I wanted to say above is, that the issue existed in earlier versions aswell, I first observed it about a month ago, but didn't find the time to report it. It did, however, work in versions around late 2017, if I remember correctly.

[thinkyhead]

Does increasing MINIMUM_STEPPER_PULSE make any difference?

[b3nn0]

Ah, I tried that before, but now in a more structured way.
I now tried 2 (default), 4, 6 and 8. None of them works. Is it worth trying even higher? (how much?).
And can you confirm that what I'm doing in the video should actually work? i.e. executing the bed leveling, then long-press for babystepping and turning the wheel? I do not need to be in a print, right?

Btw, I'm a C++ developer myself, so I don't mind fiddling in source files, if you have a decent hint for me about where to look - i'm not too familiar with the codebase.

[thinkyhead]

Actually, right, BABYSTEPPING as a feature only works when you're in an active print job or have a set of moves queued in the planner. So if it's coming up on the LCD with a long-press at other times, that's an error.

[thinkyhead]

The bugfix branches are now patched so that babystepping won't open on a long press unless it's possible to actually babystep.

[b3nn0]

Alright, that makes testing a little bit more work then. However, the bug report still seems to be valid.
I first noticed it, of course, because it didn't work during a print.
Here is a new video, showing that it still doesn't work. The Z-couplings don't move at all:
https://cloud.batzill.com/index.php/s/TfyJd2jwb4RYnyb

EDIT: And tried again with MINIMUM_STEPPER_PULSE=8 during printing -> doesn't work either.
I created a simple gcode file that simulates printing, so I can test without heating up etc:

G28
G29
G0 X50 Y100 Z2 F2000
G0 X170 Y100 Z2 F2000
... couple hundred repetitions of the last 2 lines ...

I guess that should be enough to make it work, right?

[b3nn0]

Can this be reopened? See comment above.

[b3nn0]

Alright, I just found the commit that is responsible for this:
3c58ca181c3a07b46c442ffdacdb7bb122186b2d
With the one before that, it works, after applying this, it doesn't.
Setting STEPPER_TIMER_PRESCALE back to 1.0 for the LPC HAL fixes it in the most recent git version. However, I have no idea what else this does.

[thinkyhead]

Although that change fixes the issue, the real problem might still reside elsewhere.
But this puts us on the trail, anyway.

[thinkyhead]

We've done a patch to fix stepper pulses during babystepping on 32-bit platforms. Please test the latest bugfix-2.0.x to see if it works better now.

[b3nn0]

Yes, looks like that solved it! Working correctly now, thank you. Great work you guys are doing on Marlin!

[tcm0116]

Actually, right, BABYSTEPPING as a feature only works when you're in an active print job or have a set of moves queued in the planner.

@thinkyhead Are you sure about this? I can adjust the Z-offset using babystepping via the Control/Motion menu with no movements planned. Babystepping is performed in the temperature ISR, which runs all the time. The only limitation I can find that would prevent babysteps from occurring is in Temperature::babystep_axis() where it checks to see if the axis is in a known position.

The bugfix branches are now patched so that babystepping won't open on a long press unless it's possible to actually babystep.

I think the change that was made was too drastic and should be reverted. A compromise could be to only show the the babystepping menu on a long press if the Z axis is in a known position.

[thinkyhead]

Are you sure about this?

The "Tune" menu doesn't show when the machine is idle, and the double-click is filtered by…

else if (screen == lcd_status_screen
      && currentScreen == lcd_main_menu
      && PENDING(millis(), doubleclick_expire_ms)
      && (planner.movesplanned() || IS_SD_PRINTING)
)

However, M290 is not filtered.

[tcm0116]

The "Tune" menu doesn't show when the machine is idle, and the double-click is filtered by…

Right. The (planner.movesplanned() || IS_SD_PRINTING) is an unnecessary limitation on being able to access the Z babystepping screen by double pressing the encoder as the babysteps can be applied even if no moves are planned.

I use the Z offset babystepping all the time to fine-tune my Z offset while the printer is otherwise stationary.

[thinkyhead]

@AnHardt — Can you remind us why we don't allow baby-stepping when the machine is idle?

[AnHardt]

Hi @thinkyhead
At first i asked me, why you are asking me about BABYSTEPPING. Me, the single one here who disgusts the concept of BABYSTEPPING because it's so NOT CNC. Putting in some uncounted, unregistered steps is too far away from programing (pedeterming) the result, for me. But i admit - it's useful - sometimes.
But you are right, you, me and boelle are the long term regulars here - and i wouldn't ask boelle anything - our thinking is to different. Sadly i can't remember the introduction of BABYSTEPPING, it was already there when i took my first deeper look into Marlins codebase. But i have looked it up, and can feel in.

Bkubicek introduced BABYSTEPPING with commit "Add the socalled "Babystepping" feature" in late 2013. His commit message set into the context of that time, plus his code, tells enough to answer your question.

In a time where the only way to change Z was either a g-code or the move-menu, Bernhard introduced a feature able to adjust Z live, during the print is already running. If the print wouldn't run he could have used move-menu or g-codes. While the print runs these would have queued at the end of the cues, so executed much delayed. Too delayed for impatient humans when searching for the perfect squich of the layer. BABYSTEPPING had no feedback, neither a number nor a real movement of the z-motors (single microsteps -> ~32000 steps / rotation). All the feedback you got, and needed, was the changing shape of the extrusion.

Concussion:
BABYSTEPPING was neither usable nor needed, nor intended to be used when not printing - so the "tune-menu" was the perfect place.
Technically there is no reason why BABYSTEPPING should fail when not printing/moving/extruding/... (at least not in the original code - did not look up the current) when made usable.

[tcm0116]

BABYSTEPPING was neither usable nor needed, nor intended to be used when not printing

I disagree with this statement. I find Z babystepping extremely useful when dialing-in my Z offset prior to ever starting a print. My typical process is to home the printer with a nominal Z offset and then command it down to Z=0. At that point, I'll use Z babystepping to adjust the nozzle to the right height. It's a lot better than starting a print and having the nozzle drag through my PEI or floating above spewing molten filament everywhere.

In any case, the Z offset can currently be adjusted while NOT printing via the Control/Motion menu. As such, the limitation of not displaying the Z babystepping menu when no moves are queued is completely artificial and unnecessary. Seeing as that limitation was added in a failed attempt to resolve this issue, I would like to recommend that https://github.com/MarlinFirmware/Marlin/commit/f07260c33fbc7f5aaf3c57f5bfcf8587a7c77ae2 be reverted.

[AnHardt]

Maybe I should have have emphasized the was. Meaning "when BABISTEPPING was invented". That may have changed since then. All your possible use cases have not been there then!

I was asked why it is as it is. I did not judge about if that makes sense totay.

[Roxy-3D]

I disagree with this statement. I find Z babystepping extremely useful when dialing-in my Z offset prior to ever starting a print.

I also believe Z-BabyStepping would be useful to be available at all times. Right now, the only reason I'm hearing is the stepper motors might be turned off. That is simple to fix. The logic that bumps the BabyStep counts can also turn the stepper motors back on prior to bumping the count.

My vote is we take out the logic that keeps the user from getting to the Z-BabyStep screen if the machine is not printing. And then add a couple lines of logic to make sure the Stepper motors are active if we are feeding them BabyStep pulses....

[thinkyhead]

In fact, as I recall we did add logic to enable the steppers (and turn on the PSU if needed) in response to a babystep. I'll double-check that. If that's the only legacy consideration, great. I see no reason why Babystepping shouldn't be available at all times.

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