-
-
Notifications
You must be signed in to change notification settings - Fork 19.2k
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
Comments
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 🥇 |
Thanks, will try it out on my next print. I wonder if this is also affected by the longer delay. #17481 |
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. |
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 |
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. |
@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. |
See #17323 This makes babystepping more reliable and may improve Trinamic motion overall. Co-Authored-By: chgi <chgi@users.noreply.github.com>
I had issues with babystepping with TMC2130. Setting both DIR delays to 100 helped. I did not test lower values. |
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... |
This applies also for TMC2208. The datasheet states 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 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,5Hz: 42,67micro seconds) dominate. |
See MarlinFirmware#17323 This makes babystepping more reliable and may improve Trinamic motion overall. Co-Authored-By: chgi <chgi@users.noreply.github.com>
See MarlinFirmware#17323 This makes babystepping more reliable and may improve Trinamic motion overall. Co-Authored-By: chgi <chgi@users.noreply.github.com>
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. |
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:
Method for testing (using pronterface):
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 silentM290 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 thatM290 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 to20
by default for Trinamic.I enabled
INTEGRATED_BABYSTEPPING
again and set the delays both to200
.Babystepping worked again.
Now did a binary search for the point where it stops working.
For
MINIMUM_STEPPER_{PRE,POST}_DIR_DELAY
50
: platform moves, but stepper makes (a little) noise in the up direction.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.The text was updated successfully, but these errors were encountered: