Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Babystepping and MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY on TMC2209 #17323

Closed
chgi opened this issue Mar 29, 2020 · 10 comments
Closed

Babystepping and MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY on TMC2209 #17323

chgi opened this issue Mar 29, 2020 · 10 comments

Comments

@chgi
Copy link
Contributor

chgi commented Mar 29, 2020

I want to share a datapoint regarding babystepping and MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY.

TLDR:
I think the timings for TCM2209 are too aggressive.
Set MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY >= 60 for TMC2209.

Long version:

My configuration:

  • SecKit SK-Go
  • Marlin 2.0.5.2
  • BTT SKR 1.3
  • TMC2209 (UART, StealthChop, 1/8 microstepping)
  • complete config

Method for testing (using pronterface):

G28 ;home
G29 L2 A ;load mesh
M290 Z2 ;lower the platform, with eyes to the stepper pulley and ears listening closely
M290 Z-2 ;raise platform

Babystepping didn't work at first (don't remember exactly).
Then I tried enabling INTEGRATED_BABYSTEPPING and it worked.

Then, somewhere in the 2.0.4.* cycle (I think), it stopped working again.

Definition of not working from here on means:

  • M290 Z2 ==> the platform moves down as expected, stepper is silent
  • M290 Z-2 ==> the pulley moves erratically (looks like random walk) and makes noise. The platform hardly moves.

I tried to disable INTEGRATED_BABYSTEPPING and it worked again, in the sense that
M290 Z-2 moved the platform up and looked OK, but the stepper was noisier than in the opposite direction. I assume that means that some steps were missed or went in the wrong direction.

I started investigating deeper and found MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY and that they seem to be set to 20 by default for Trinamic.

I enabled INTEGRATED_BABYSTEPPING again and set the delays both to 200.
Babystepping worked again.

Now did a binary search for the point where it stops working.

For MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY

  • both 50: platform moves, but stepper makes (a little) noise in the up direction.
  • both 60: platform moves, stepper is silent in both directions.

I didn't search further because I think there is no sense in cutting it too close.
I will probably set mine in the 80-100 region, just to be safe

Conclusion/Conjecture:
The TMC2209 works at around 12MHz I think. That makes one clock cycle 83.3ns.
I don't know how exact the delay timings of the LPC1768 are or what other delays come into play,
but it seems reasonable to assume that the TMC2209 needs one clock cycle before/after direction change.
Setting MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY to 60, together with other instructions before actual step is issued might just get the the delay over 83ns while a setting of 50 is too short at least some times (race condition) and leads to some babysteps in the wrong direction which would cause the stepper noise.

@phazei
Copy link

phazei commented Apr 26, 2020

Woot! This worked for me :D Awesome find!

There are a bunch of open babystep tickets this could potentially help with, as either a fix or workaround for whatever else might be causing some issues. I've just been trying to use the z-probe-offset menu item to tune my z, but that ties into all the babystep stuff and I've only been able to move one direction.

There's still an issue where it just stops working entirely, which is some shutdown thing I saw in a ticket, but before that happens it only would turn in one direction, which this solves 🥇

#17685
#16828
#16617

@spattinson
@thinkyhead

@hamster65
Copy link

Thanks, will try it out on my next print. I wonder if this is also affected by the longer delay. #17481

@gbrlallison
Copy link

gbrlallison commented May 8, 2020

Thank you for debugging this issue, I’ve been trying to figure out why my printer has been acting this way until I found this open issue.

I will try your fix when I can and report back.

Edit: I just tested this fix and it seems to be working wonderfully so far. Thank you.

@thinkyhead
Copy link
Member

Should the same thing apply to the TMC2208? For now the patch is just this:

  #elif HAS_DRIVER(A4988)
    #define MINIMUM_STEPPER_POST_DIR_DELAY 200
+ #elif HAS_DRIVER(TMC2209)
+   #define MINIMUM_STEPPER_POST_DIR_DELAY 60
  #elif HAS_TRINAMIC_CONFIG || HAS_TRINAMIC_STANDALONE
    #define MINIMUM_STEPPER_POST_DIR_DELAY 20

@thinkyhead
Copy link
Member

It would also be possible to add extra delays that apply just for babysteps, while leaving other step pulses as they are. However, the extra delay might be useful for direction changes. Although, if you're changing directions you're also changing to a new block, which means lots of extra nanoseconds between pin change events. So, again, maybe just adding extra delay on the babystep routines is enough.

@thinkyhead
Copy link
Member

@teemuatlut — Do you think that 60ns is an unusually conservative amount of delay around DIR changes? If it actually improves motion and doesn't hinder higher step rates then I think it is worth testing out. Anything that reduces the likelihood of lost steps is a good thing, and generally speaking changes in DIR are not too clustered.

thinkyhead added a commit that referenced this issue May 10, 2020
See #17323

This makes babystepping more reliable and may improve Trinamic motion overall.

Co-Authored-By: chgi <chgi@users.noreply.github.com>
@hamster65
Copy link

I had issues with babystepping with TMC2130. Setting both DIR delays to 100 helped. I did not test lower values.

@chgi
Copy link
Contributor Author

chgi commented May 13, 2020

I am glad this has gotten some attention and helped some people. I just wish I had something better than my ears to detect missed steps. My wife always tells me they aren't very good...

@Snagi0
Copy link

Snagi0 commented May 14, 2020

This applies also for TMC2208. The datasheet states
DIR to STEP setup time: typical 20ns
DIR after STEP hold time: typical 20ns
Internal DIR and STEP RC filters need additional "STEP and DIR spike filtering time": (rising and falling edge) max 30ns (this assumes full input logic level swing, otherwise it increases).

Based on this, I would say that MINIMUM_STEPPER_POST_DIR_DELAY and MINIMUM_STEPPER_PRE_DIR_DELAY should be at least 50ns.

I don't know how these drivers work in detail, but there is also a timing for
"STEP and DIR sampling relative to rising CLK" (used internal clock is 12MHz: clock cycle 83.3ns) that is the same as filtering time (30ns). Maybe this should be taken in account also (if the STEP/DIR signal is sent right after stepper clock pulse?

While we are at it, we should also change MINIMUM_STEPPER_PULSE to 1(microsecond), based on "STEP input minimum low/high time": typical 100ns, to make sure we satisfy this and as there is no finer resolution for this setting.

And also MAXIMUM_STEPPER_RATE is set too high (5 000 000Hz) in some circumstances. This must be based on "step frequency" (at maximum microstep resolution): ½ fCLK (6MHz) timing. But when lower than 256 microstepping settings are used "fullstep frequency": fCLK/512 (23 437,5‬Hz: 42,67micro seconds) dominate.

vgadreau pushed a commit to vgadreau/Marlin that referenced this issue May 29, 2020
See MarlinFirmware#17323

This makes babystepping more reliable and may improve Trinamic motion overall.

Co-Authored-By: chgi <chgi@users.noreply.github.com>
jmp0x0000 pushed a commit to jmp0x0000/Marlin that referenced this issue Aug 7, 2020
See MarlinFirmware#17323

This makes babystepping more reliable and may improve Trinamic motion overall.

Co-Authored-By: chgi <chgi@users.noreply.github.com>
@github-actions
Copy link

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.

@github-actions github-actions bot locked and limited conversation to collaborators Aug 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants