New TMC docs: don't use hold_current; avoid interpolate #4977
Conversation
docs/TMC_Drivers.md
Outdated
| shown an increase in positional deviation of nearly a full-step when | ||
| using stealthChop mode (for example, on a printer with 40mm | ||
| rotation_distance and 200 steps_per_rotation, position deviation of | ||
| constant speed moves increased by ~0.160mm). |
There was a problem hiding this comment.
Very interesting! This seems to be really a lot. And on paper, it looks like the motor is close to skipping a step. So, the question is, is it a random deviation, or a position lag? And if it is a lag, is it velocity- and current- and microstepping-dependent? Any available data would be very helpful. Basically, if the lag comes from internal processing in TMC driver, and not from the loss of torque, it might be a useful recommendation to set the same parameters for the drivers of all moving axes (e.g. same microstepping, and enabling stealthChop for all of them) so that the lag is consistent and reduces de-synchronization between the linear motion of different axes and the extruder, for instance. And if it is due to torque, it indicates, in general, a potentially unsafe operation (but if this lag exists during the constant velocity moves, the resistance to motion should be fairly small, and thus such motion should not require much torque?).
Then a separate question is Z axis, could this introduce a backlash effect and introduce systematic issues with the first layers (and further layers if Z hop or bed meshing is enabled).
|
Is spreadCycle mode supposed to make quite a ear scratching screetch specially when not moved or on very little movement? |
|
If your stepper is making a loud noise your switching frequency is too low. Trinamic has calculation sheets for their drivers where you plug in motor parameters and they give you back some good starting points for chopper configuration. Especially relevant if the chopper noise is audible is decreasing TOFF and potentially TBL as well. |
is there a more in depth guide on how to do the tuning? |
|
Hi @dmbutyugin
In this case, I was referring to the "stepper lag" we discussed in #4560 . It's a reproducible position lag during constant velocity moves. I reran some tests for comparison purposes. Current 1amp, 128 microsteps, interpolation off, spreadCycle:
Seems not. Changing velocity only has a minor impact, changing current only has a minor impact, changing interpolation doesn't seem to have an impact (at least when at 128 microsteps), and the microsteps are already quite high (128).
It does seem that way to me.
FWIW, I don't see how this would help. The lag seems to be a distance and not a time. I'd expect the X, Y, and E steppers to typically move with different velocities - so, a constant distance deviation will result in a notably different effective time lag. Thus I don't see a benefit in trying to synchronize the distance lag.
I'm not seeing an issue like that. I can still move the steppers at 200mm/s and still see similar amounts of lag with 0.5amps, 1.0amps, and 1.5 amps. I didn't see anything that indicates steps would be lost. (To "lose a step", the stepper would need to lag two full steps.)
This is a good point. Indeed, I fear that translations like bed_mesh may not interact well with stealthChop. Alas, I don't have an angle sensor on this printer's Z axis, and it's not immediately easy for me to add one. It might be possible to put together a test on the XY axes (which do have angle sensors), but I suspect a good test should include the impact of gravity.
I reran some tests today. Current 1amp, 128 microsteps, interpolation off, spreadCycle: The graphs above were generated using: The runs are all using this gcode file: The move.gcode is unchanged from the discussion in PR #4560, so the data files there with various spreadCycle settings should still apply. I can run additional tests if you have something in mind. This printer (a Voron Zero) has an adxl345 on the toolhead and angle sensors on X, Y, E. Thanks, |
|
I'm all in for accuracy, but regarding the removal of My point is that I can see some users complaining about Klipper stopping due to the motors overheating and thus prefer to use |
If your motors are overheating, then your run_current is too high. |
|
@KevinOConnor, yes, I remember that conversation, now I understand that you were referring to it.
Yes, I understand. I believe that this lag definitely exists. It is just that magnitude of this lag is somewhat surprising and counter-intuitive, is all. Unfortunately, I don't have angle sensors and therefore I cannot test how it looks like on my printer. ADXL345 isn't necessarily helpful here. I am also confused about the amount of lag. I've been using StealthChop2 mode on my Ender3 pretty much from the very start, and I never had issues with clearances, including walls not parallel to X and Y axes (so the typical achievable tolerances were 0.1 mm or 0.15 mm). If that lag were to develop, I'd probably be running into some clearance problems with connecting parts once in a while.
This part seems counter-intuitive to me. Basically, the fact that there is no proportionality between the lag and the current or velocity. However, if the lag was due to some physical processes in the system, I'd expect it to decrease with current (if it was due to lower torque or stepper dead zones), or increase with velocity (the friction should increase linearly or super-linearly, e.g. quadratically, with velocity). This does not happen however.
Perhaps. But it would look like it is some almost fixed part of the rotation between the phases. It is unclear to me what kind of buffering or delayed processing would result in this, given that the amount of lag, and therefore delayed microsteps, is quite large.
Oh, yes, true.
The stepper needs to 'lag' two full steps. But if I am not mistaken, the torque rises when the lag increases from 0 to 1 full step, and then drops when the lag continues to increase from 1 to 2 full steps, right? Then if the external force exceeds the motor torque at 1 full step lag, it would immediately skip by 2 full steps, because the torque only decays afterwards (well, strictly speaking, if the external force decays faster than the torque, then the stepper won't skip and can operate with a lag more than 1 full step; but I'm not sure how frequently that can happen in practice). Then, the fact that lag does not decrease with an increase of current, likely indicates that this is not torque-related. At least, if the stepper driver does not artificially limit the current during operation. But you can check the latter by touching the stepper - at high currents, it is expected to get more hot. BTW, I was reading TMC2209 and TMC5160 datasheets about StealthChop2 operation, and nothing there indicates some current adjustments like that. Unless CoolStep is enabled, but Klipper does not use that. In fact, StealthChop2 seems to be a voltage PWM mode, which uses simple proportional regulator to adjust the current (with pwm_autoscale = 1 and pwm_auto_grad = 1). The datasheets were not clear about any averaging for the regulator, but there is probably something in place, cause PWM frequency is 58.5kHz by default in Klipper? In any case, I'd be surprised to learn that the stepper driver introduces some significant lag here of more than 75% of the full step due to PWM regulation. There is only one thing I can think of that is suboptimal in Klipper w.r.t. StealthChop2 autotuning: "Just two steps have to be respected by the motion controller for best results: Start with the motor in standstill, but powered with nominal run current (AT#1). Move the motor at a medium velocity, e.g. as part of a homing procedure (AT#2)." (from the datasheet). But I think Klipper does not respect the initial standstill during homing (> 130 ms). Or does it? But I doubt this has any effect on the lag in question.
I can think of 2 tests:
But in any case, it is worthwhile to warn the users about this potential large lag, even if we don't understand its origin. So, this discussion shouldn't block the PR itself. |
Thanks for the feedback. My high-level understanding is that It's hard to make general statements about 3d printers, because there are tons of different printers out there, and behavior can vary from print to print. However, with the current default settings of TPOWERDOWN and IHOLDDELAY on a tmc2209, a power reduction would only start after 633ms of idle time - and likely only reach the requested hold current after about 800ms or so. For XY motors, I suspect very few moves would involve one of the steppers inactive for that amount of time. Given that most people set the hold_current to around 75% of the run_current anyway, I'd guess using a hold_current provides marginal cooling. The timings/defaults are similar for other TMC drivers. I expect the extruder to have a similar pattern. If bed_mesh or bed_tilt is used, then the Z stepper wont idle and wont see a benefit to hold_current. I have no plans to remove the hold_current capability. So, if people want to use it, they certainly can. From a documentation point of view, though, I think we can provide a clear and simple message - if you haven't investigated hold_current and know what its limitations are, then don't use it. I suspect a lot of people enable hold_current today, because "oh that sounds useful", and my recent investigation has led me to believe that sentiment isn't really accurate. Cheers, |
|
Ive been running my corexy (TMC5160s) like this on all motors since this was posted and my motor temps are the same as before. |
FWIW, I'm not sure the lag would show up as a dimensional error. I'd guess the toolhead is mostly following the commanded path, just not with great extruder synchronization and maybe with some minor dimensional issues for diagonal moves. It might show up as minor blobbing issues; and it's possible people are tuning some of that out with PA and flow_rate calibration. Admittedly, I'm "hand waving" a lot here. The data from the angle sensor is pretty convincing though.
FWIW, I've spent a lot of time parsing the TMC specs, and I feel they are equal parts "hand waving", "technical information", and "marketing product brochure". Often when I read them I end up with more questions than when I started. So, take what I say "with a grain of salt". I didn't get the impression that there is any kind of "command buffering"- I'd guess it's more about a systemic lag developing from its prediction system. If I understand stealthChop correctly, it measures how quickly it can push current through the coils, just as spreadCycle does. However, it doesn't use those measurements to directly control current, but instead uses them to make future predictions on how long to enable power to the coils. As a wild guess, its prediction system is generally accurate (after all, it is ultimately moving from point A to point B with the requested velocity), but is inducing some kind of lag?
Well, my read of the specs (for what that's worth) is that stealthChop is always in a "tuning mode" and thus it's not really important that the pause comes before the homing move or vice-versa. So, I don't think there is a practical issue, as there will be a pause (and a healthy mix of moves at various speeds) leading up to the print.
Okay, if I get a chance, I'll try to put something together. Thanks. |
Can confirm the same findings with my Ender-3 V2 with an SKR2 running TMC2209s. |
If the move is, say, at 30 degrees to X axis, and the lag is 0.15 mm on X and Y stepper of a Cartesian printer, that should manifest itself as as a line being offset from its intended position. If I didn't mess up the calculation, the offset = lag * (cos(alpha) - sin(alpha)) ~= 0.055 mm in such case. OK, TBH, it is not that much, and perhaps can go unnoticed.
That is fair. It is likely the case that Trinamic is protecting their IP, so they refrain from revealing too much of details about StealthChop operation.
If I read the available data correctly, the tuning process tries to find the optimal values for PWM_OFS_AUTO and PWM_GRAD_AUTO parameters. These values are then used in a proportional regulator to adjust PWM_SCALE_AUTO value. That scale (with PWM_OFS_AUTO) is multiplied by the target sine wave value in order to determine the actual PWM duty cycle. So, unlike SpreadCycle chopper, which regulates the current during each chopper cycle (on, slow decay, fast decay), here the cycles are not regulated individually, but instead the duty cycle is slowly adjusted in a hope to get the requested sine amplitude (and IRMS). Given that the PWM duty cycle is determined as PWM_SUM * sin(t), it is not likely that the system develops significant lag trying to 'push' the current through coils. It always pushes a proper sine wave, but if PWM_SUM is insufficient, it may lead to lower amplitude sine wave through the coils and thus lower torque of the stepper. However, I'd expect that PWM_SUM stabilizes during the constant velocity operation, and thus the lag be reduced similar to SpreadCycle. But it stays constant pretty much throughout the whole constant velocity moves. So, a mystery.
Ah, you are right: "Automatic tuning adapts to changed conditions whenever AT#1 and AT#2 conditions are fulfilled in the later operation." |
|
FYI, I ran an additional test on the Zero. I used the following macro to test moves and pauses largely in the same direction: SpreadCycle mode (1amp, 128 microsteps, interpolation off): In general, it looks to me that different acceleration levels don't notably impact the lag. There is a small measurable and repeatable inaccuracy when stopping at different microstep positions. That inaccuracy is similar between stealthChop and spreadCycle. StealthChop continues to show a repeatable high distance lag during moves.
I'm not seeing how one would calculate that. FWIW, the X, Y, E motors in this machine are https://www.omc-stepperonline.com/download/14HS20-1504S.pdf and I see the following from DUMP_TMC after the above stealthchop test: Raw data: -Kevin |
|
@KevinOConnor Thanks! Sorry, I meant more like a test (e.g. starting from X=0, Y=0) So, there are consecutive accelerations of the same magnitude in the same direction. As for the parameters, from the datasheets (I assume 24 V PSU): PWM_OFS = 374 * R_COIL * I_COIL / V_M = 374 * 2.8 (Ohm) * 1 (Amp) / 24 (Volt) = 43.6 (44?) This is called PWM_AMPL in TMC2209 datasheet by mistake in one place I assume (should have been PWM_OFS). PWM_GRAD = C_BEMF * 2 * pi * f_CLK * 1.46 / (V_M * MSRP), Combining together, and assuming 12MHz internal clock being used by the driver (is it?), PWM_GRAD = 0.4 (N*m) / (2 * 1.5 (A)) * 2 * 3.14 * 12e6 (Hz) * 1.46 / (24 (Volt) * 25600) = 23.88 (24?) This mode requires setting pwm_autoscale = 0. |
|
Wow. I was playing with the graphs and noticed this in the stealthChop data: The blue line (which is a calculated derivative on the raw angle data) shows jitter near the places where the orange line (which is a calculated derivative on the raw step pulses sent) shows jitter. The orange line has jitter due to step compression - the Klipper host code is allowed to move a step pulse time around within a window of 25us in order to reduce bandwidth. Zooming in we can see an even closer correlation: This is a bit off topic here (and I don't think it has any relevance to the main findings in this PR), but I was a bit stunned that the angle sensors could pick up the impact of step compression. This is timing differences in a handful of microseconds! -Kevin First graph produced with: EDIT: FYI, it's also possible to overlay the requested stepper velocity with something like: |
I'm not sure I understand. The test does move the head in the same direction - it moves thorough these positions:
Ah, I must have missed that - do you have a pointer to the datasheet and its location? Yes, 24V.
Yes, the tmc2209 should have a nominal clock of 12Mhz. -Kevin |
Yes, different velocities without any pauses. *Yeah, provided was just an example, naturally for corexy it should be diagonal moves.
Yes, TMC2209: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC2209_Datasheet_rev1.06.pdf TMC5160: https://www.trinamic.com/fileadmin/assets/Products/ICs_Documents/TMC5160A_Datasheet_Rev1.15.pdf
Oh, well. I knew about this optimization, but I didn't put the magnitude into perspective previously. Actually, the time between steps at 128 microstepping at 200 mm/sec with 1.8 steppers with 40 mm rotation distance can be 0.2 mm / 200 mm/s / 128 = 7.8 us if I didn't mess the computations. So, this is noticeably less than the 'optimization window'. I wonder if this could affect microstepping accuracy? With 16 microstepping the time between steps is 62.5 us in this case, but now we start recommending to disable interpolation and use high microstepping values if possible. I wonder if the optimization should account for the time between consecutive steps? Or maybe it does already? Separately, I think this could negatively affect StealthChop regulator. I imagine that in the automatic mode, it may still be using |
|
Thanks.
Yes - the window is the lower of 25us or half the time since the last step. I also noted the high step frequency last night and tried reducing this check to an 8th: --- a/klippy/chelper/stepcompress.c
+++ b/klippy/chelper/stepcompress.c
@@ -91,7 +91,7 @@ minmax_point(struct stepcompress *sc, uint32_t *pos)
{
uint32_t lsc = sc->last_step_clock, point = *pos - lsc;
uint32_t prevpoint = pos > sc->queue_pos ? *(pos-1) - lsc : 0;
- uint32_t max_error = (point - prevpoint) / 2;
+ uint32_t max_error = (point - prevpoint) / 8;
if (max_error > sc->max_error)
max_error = sc->max_error;
return (struct points){ point - max_error, point };It showed a minor improvement, but there was clearly still an interaction with step compression.
I agree. I also noticed that the vibrations are showing up on the toolhead accelerometer ( I also tried going down to 16 microsteps with interpolation enabled - alas that seems to show reproducible lost steps in the 10K accel part of the test. So, clearly not an improvement in general (though I don't know if it's related to step compression or not). -Kevin |
|
@dmbutyugin - FYI, I ran a few more tests. I added the following to both the stepper_x and stepper_y tmc sections: At a glance, it didn't seem to have a noticeable impact. I also created a new "variable speed" macro: Which does seem to show some quirky results ( Raw logs (stealthchop; no customization): -Kevin |
|
Typo in your gcode? And a question behind: how does DEDGE influence the measurement? |
|
Have you thought about bringing your findings to Trinamic's attention? |
|
After upgrading to Klipper 0.10.0 my steppers started making a high pitch squealing noise if not moving, so I specified a hold current. SKR Pro and TMC5160's. Before the upgrade I had hold current the same as run current for all but Z axis (hold current was specified but same). I had them all in spreadcycle but a mix of interpolate on and off. I have been experimenting with stealthchop but just turned off stealth chop and interpolate on all axes and now no squealing. On my SKR Pro, I have been running 0 for the step pulse on all steppers for a long time, never had any issues, though one user reported layer shifts. Doing this allows a higher microstep setting for the same speeds before Klipper throws an error. Going from 2 to 0 roughly doubled the print speed I could go, or doubled the possible microstep setting. This would make up some of the difference in loosing interpolate. |
|
If I may add following to this discussion. There are a couple of observations I whish to share:
As one can see the deviation in positional error can be quite substantial. Max error in this case is 9, which means that when using a 32mm pully ( 16 theeth gt2 ) the print error for this motor is 0.045mm without load.
my 5 cents |
|
@djamu Thanks a lot for sharing your data, this is indeed very interesting!
Typical positional accuracy on many stepper datasheets is +/-5% (non-accumulating), which would give +/-That is up to +/- 13 msteps / step, or +/- 0.01 mm with 20 teeth pulley on the full steps, and likely more in the intermediate positions. So, that looks very believable and likely more or less in line with the expected accuracy of a stepper motor.
I likely don't fully understand all details here. Do you mean that the StealthChoppers for two coils are not synchronized and can affect each other?
In general, the issue with SpreadCycle is that it, technically, requires some tuning. There are recommended starting parameters, but they may not work well for all stepper motors. StealthChop2 (on TMC2209 and TMC5160, at least) pretty much works fully autonomously and auto-tunes its parameters. So, if we suggest users to switch to SpreadCycle, it would be beneficial to suggest a tuning procedure. There are some suggestions from Trinamic, e.g. "Quick Configuration Guide" chapter in the TMC2209 and TMC5160 datasheets, and |
Yes. Good catch. Thankfully it doesn't impact the test results.
Not at all as far as I'm aware.
FWIW, I hadn't thought about that. Thanks, |
|
@djamu - interesting, thanks. I too see the same cyclical behavior on my steppers. If looking at the top graph at #4977 (comment) :
One can see that the angle sensors report readings that vary over a range of about 20um when the stepper is moving. If one were to "zoom into a smaller time range" then the graph would show that "noise" pattern is actually a repeating cyclical pattern not unlike your graph.
It's not angle sensor noise - the noise from the sensor itself is about 5um - as can be seen at the end of the test when the motor isn't moving. These graphs were generated after angle sensor calibration, and the waves during movement correlate well with vibrations picked up by the accelerometer on the toolhead. FWIW, in addition to the sources of error you've pointed out (imbalances in windings, magnets, teeth) I suspect detent forces in the stepper also lead to some of the recurring position errors. (That is, the permanent magnet in the rotor pulls toward the iron teeth in the stator - and that force varies depending on the requested position of the stepper motor.) FWIW, it may be possible to tune the sine wave function on the tmc2130/tmc5160 drivers to account for some of these errors. -Kevin Graph is from |
FWIW, I've tried tuning spreadCycle a few times (on a few different printers) and I've never been successful in measuring a mechanical improvement over the default settings. I suspect that the trinamic docs may be orientated at big industrial motors and common small 3d printer steppers may not require active configuration.
I did attempt to do just that. Much of the results I've posted here were actually found during my attempt to come up with a mechanism to tune spreadCycle. Alas, no matter how badly I mis-tune the spreadCycle settings on this particular test printer, I've been unable to measure an induced mechanical jitter. (My goal was to measure mechanical jitter as a proxy for a current probe / oscilloscope.) Neither the angle sensors nor the accelerometer show a strong signal when changing FWIW, I can measure a strong audio signal using the "spectroid app" on my android phone with varying -Kevin |
|
With my E3D 0.9 degree 48mm steppers, TMC5160, VM at 24V, SKR 1.3, I was able to see a significant improvement in surface quality by changing HSTRT and HEND to 3 and 3. I also observed a less "sickly" sound to the motor movement, and my printer is now able to reach higher speeds without skipping steps. (It's not any quieter, though. I'm also unable to use these motors in StealthChop mode; it has terrible resonance and reduced torque, and I've not been able to get it to work correctly by tuning it. Not that I really know what I'm doing... The datasheet makes for some heavy reading for a hobby.) The attached model is a slightly conical cylinder (smaller at the top) that is 2 full steps of movement smaller at the top, assuming 32mm rotation distance. Slice it as a shell or in vase mode. The model is 40mm tall, but in my case, the difference was so stark that I'd need only 5mm or so of the height to see it. |
You said that you're running a V0 at 128 microsteps, aren't you missing some inbetween microsteps between full steps due to a lack of torque? Or are you running some beefy NEMA17 or? |
Thank you for this info Kevin. Coincidentally I recently spent a bit of time trying to fine tune the TMC2209 chopper parameters on my heavily modified CR-10S Pro. The printer is equipped with Moons' 0.9 steppers throughout, except the extruder is currently Moons' 1.8. The MCU is Duet 3 Mini 5+. My observations generally align with yours where the only parameter that made any perceptible difference is I set-up the initial chopper parameters using the TMC2209 spreadsheet with two goals in mind: (1) reducing the idle noise to minimum & (2) reducing or eliminating a rather strong resonance during Y stepper movement that occurs only at approximately 2200 mm/min (36.667 mm/s). Adjustments in I have not yet spent any time with an oscilloscope looking at the waveforms since it is an old analogue Tek 2465A and a bit of a challenge to use for this purpose. |
|
I bit unrelated, but I have been wanting to try linengineering Z417
steppers as they claim to have no detent torque. I have an FT6 with 766mm
in x direction and I get resonances in belts above 120mm/s, 600mm/s travel
speed ok though.
https://www.linengineering.com/products/stepper-motors/hybrid-stepper-motors/z417-series
It would be great to try and tune my TMC5160s some to help as is now
though. So if in spreadcycle, which parameters are worth tuning, and what
process if any to try different settings? It seems many parameters are
stealthchop specific and not necessary to tune for spreadcycle (which ones
would these be for reference?) Thanks!
…On Sun, Dec 12, 2021, 8:09 AM Peter ***@***.***> wrote:
In general, the issue with SpreadCycle is that it, technically, requires
some tuning.
FWIW, I've tried tuning spreadCycle a few times (on a few different
printers) and I've never been successful in measuring a mechanical
improvement over the default settings. I suspect that the trinamic docs may
be orientated at big industrial motors and common small 3d printer steppers
may not require active configuration.
Those are a bit involved and require an oscilloscope, for instance. But I
wonder if this tuning can be assisted with a help of an accelerometer
and/or an angle sensor?
I did attempt to do just that. Much of the results I've posted here were
actually found during my attempt to come up with a mechanism to tune
spreadCycle.
Alas, no matter how badly I mis-tune the spreadCycle settings on this
particular test printer, I've been unable to measure an induced mechanical
jitter. (My goal was to measure mechanical jitter as a proxy for a current
probe / oscilloscope.) Neither the angle sensors nor the accelerometer show
a strong signal when changing driver_TBL or driver_HEND. If I get further
time, I may also try running the results through a FFT to see if that can
pick up a signal. However, I suspect the low resistance steppers on this
printer may operate fine even at the most aggressive tmc settings.
FWIW, I can measure a strong audio signal using the "spectroid app" on my
android phone with varying driver_TOFF. Which was nice to see. However,
there is a bit of a "myth" that one can make spreadCycle quiet with tuning.
In my experience, if spreadCycle mode is loud with the default settings
then it's likely to be loud with all settings. It depends on the type of
noise - if one is directly hearing the chopper frequency - which sounds
like a pure musical note - almost like a note played on a flute - then it
is possible to tune that away. I suspect it is unlikely one would get that
with the default settings though. In contrast, if one is hearing a
"warbling hissing sound" then it seems that is a "secondary resonance"
created by the chopper and I've not seen success in tuning that away. It
seems some printer frames/steppers/electronics don't have the issue - for
example, my Voron2 is basically silent with spreadCycle mode, while my
delta and the makergear m2 were incredibly loud. YMMV.
-Kevin
Thank you for this info Kevin. Coincidentally I recently spent a bit of
time trying to fine tune the TMC2209 chopper parameters on my heavily
modified CR-10S Pro. The printer is equipped with Moons' 0.9 steppers
throughout, except the extruder is currently Moons' 1.8. The MCU is Duet 3
Mini 5+. My observations generally align with yours where the only
parameter that made any perceptible difference is driver_TOFF.
I set-up the initial chopper parameters using the TMC2209 spreadsheet with
two goals in mind: (1) reducing the idle noise to minimum & (2) reducing or
eliminating a rather strong resonance during Y stepper movement that occurs
only at approximately 2200 mm/min (36.667 mm/s). Adjustments in
driver_TOFF definitely influenced the stand-still noise level and noise
"signature" of the steppers and I was able to slightly reduce this noise.
Adjusting the other parameters made no difference thus far and I was not
yet able to influence the Y resonance in any way.
I have not yet spent any time with an oscilloscope looking at the
waveforms since it is an old analogue Tek 2465A and a bit of a challenge to
use for this purpose.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#4977 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSE2TOL25M3NH25A6TTUQSNIFANCNFSM5I7SJUJQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
KevinOConnor
force-pushed
the
work-tmctuning-20211128
branch
2 times, most recently
from
e486646
to
22ab8cc
Compare
Changing motor current may itself introduce unwanted motor movement. As such, document that specifying a hold_current is not recommended. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Now that the documentation recommends that hold_current not be set, update the example config files to not specify a hold_current. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
…modes Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
There is no reason to explicitly set the interpolate flag to true in the example configs as that is already the default. Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
…ivers.md Signed-off-by: Kevin O'Connor <kevin@koconnor.net>
KevinOConnor
force-pushed
the
work-tmctuning-20211128
branch
from
22ab8cc
to
323268e
Compare
Yes that is correct, it's like crosstalk, chopping frequency / duty cycle is affected by supply voltage and impedance, the on/off time of both coils overlap less/at different times, velocity changes the impedance by back-emf... Long story, synchronised choppers work better IMHO if one doesn't mind some noise....
Yes of course, detent torque and latent magnetism also play a part. @dmbutyugin @KevinOConnor This will only work for MCU's/drivers that support hardware SPI (preferably with dma). There's 2 idea's
My favorite ;-) A. any mechanical / measured motor offset can be compensated by offsetting that pointer with an offset table, ( 2 offset tables, 1 cyclic 1 global ).... but then you need feedback to measure that.... this is closed loop only I'm affraid ( essentially freq modulation ).... B. Similair to pressure advance, one can use a variable which represent mass / torque to offset the same pointer during acc/dec phases, the result is zero lag ( torque related ) as the magnetic field will run in advance of the actual stepper position/acc , nullifying lag when correctly applied, this is easy can be used both in open / closed loop... is a constant multiplied by the current acc factor. C. Boosting torque, I use a very high fixed run current of 2.4A on my TMC2130's which is normally enough to both fry your motor and driver but use amplitude modulation of the sine wave to change the actual current. D. High speed, during high velocity travels one can up the amplitude to counter for back-emf ( and optionally drive motors with a square wave ( full wave ). Open-loop will never achieve stable 2400RPM @15v but 1600-1800RPM is possible.. This is because cool motors can generate higher torque ( magnets don't like heat ), but ball bearings will wear out faster, have no doubt... Can't this be implemented using the step/dir interface?, yes sure.... But no not nowhere near as good as with SPI. The acc/dec prediction generates a lot of pulses, you can't just invert polarity on 2 coils on a whim, as you'd have to step thru the table, this generates lag on it's own.... I'm pretty sure you're made well aware of this problem while writing the pressure advance code.... pulse horror / blocking code..... Started using Klipper a while ago, ( great stuff btw). I have some questions though... Klipper code question: For sake of completeness, some graphs to prove my point, how well this all works... blue: is position as received by stepper driver. This is a fragment of formentioned plot, horizontal is time, vertical is position If we normalise this to zero, (intended position becomes zero), you see the actual deviation of the motor relative to it's postion. What you see here is the actual postional error, what's interesting here is the frequency, this is the actual frequency a motor self-resonates ( I've ran it through a FFT tool), you can clearly see the motor swing around it's course, the scale is 32usteps... ( ringing ;-) Same plots, but with all of the above activated. dif I'm interested to see how this would work with input shaping, might aswell conflict or complement as they do basically the same,one modifies the input, the other modifies the ouput... let's see what happens. The proposed changes will tax ones printer to the max when you up the acc, bearings will wear out much faster, I'm not sure everybody actually want this (9000mm/s2), but it will still work fine with normal settings. and a stepper motor @ 2500RPM 10/-10 / 100/-100 revolutions (that would be 4 travels of 320,320, 3200, 3200 mm with a 32mm pulley ) later |
|
Thanks everyone for the feedback. I went ahead and committed this PR as it looks like the core discussions around There seems to be a bunch of interest in tuning spreadCycle. If I get time I'll try to clean up the test code I've written and start a topic on Klipper Discourse to discuss it further. -Kevin |
|
@djamu - interesting. You might want to open a new topic on Klipper Discourse to discuss it, as I suspect it will get more exposure than on this PR. Some random tips/pointers: Klipper calculates the step times in the host, compresses that schedule of events, transmits it to the micro-controller, and then the micro-controller schedules "software timers" to trigger at each scheduled step time. So, it's not a fixed frequency handler. There's some info in the scheduling logic at https://www.klipper3d.org/Code_Overview.html . In testing of the "mechaduino", I have implemented a fixed-frequency handler in the mcu code - #1038 . Cheers, |
|
@KevinOConnor any chance if you do decide to clean up the test code and start the tuning topic on Discourse that you could post something here on Github that you did so? |
It might be. SpreadCycle has a few parameters TOFF, HSTRT, HEND, and TBL that control SpreadCycle at low-level. TBL tuning is only useful in case of high capacitance applications. TOFF, HSTRT and HEND control the hysteresis and indirectly the chopper frequency. According to the datasheet, improper settings could lead to reduced microstep accuracy, more power dissipation, and more chopper noise. Probably, the worst that could happen for 3d printing applications is high-pitch noise from steppers if the chopper frequency drops to audible range.
ADXL345 has a sampling rate of 3200 samples/sec, so it is likely too slow to pick up noise from SpreadCycle chopper. Not sure about angle sensor, but probably deviations are also too small to be noticeable.
I'm not sure what 'warbling hissing sound' you mean, but if it is high-pitch hissing, I have the following recent experience (though with StealthChop, surprisingly) that I can share. I've installed a different stepper on Y axis recently - 17HS16-2004S1. And in StealthChop mode with TMC5160 it was producing high-pitch hissing at standstill. Not while moving though. When I set PWM_OFS and PWM_GRAD manually (also disabling autograd), that sound went away. So it seems it was some issue with the regulator that would change the chopper parameters all the time, and that effect was audible. In general, in case of SpreadCycle reducing the hysteresis should help with its sound (by increasing the frequency and making it non-audible). Then there is a sound of the stepper motors themselves (from their stepping), which can be picked up by accelerometer: In the chart we can see the lines that correspond to full stepper steps of 0.2 mm (40 mm rotation distance / 200 (steps/rotation)) that go up to 1000 Hz (200 mm/sec / 0.2 mm), double of full steps (up to 500 Hz), quadruple of full steps (up to 250 Hz), and half of full steps (0.1 mm, partially visible above the 0.2 mm line). There is also a faint line for 2mm GT2 belt (goes up to 100 Hz). These ones can be heard with StealthChop and seem to be magnified with SpreadCycle. And tuning SpreadCycle won't reduce this noise. TBH, I was a bit surprised to see the frequency of quad steps (corresponds to 0.8 mm distance), but it may be from some peculiarities of hybrid stepper motors construction.
I think that's largely a myth: there could be some small dependency of the max torque when changing microstepping, but nothing that dramatic. FWIW, after the recent optimizations with the step scheduling in Klipper, I've been running my Ender 3 Pro at 256 microstepping on all axes, and moving bed did not give me any issues or missed steps. FWIW, I've previously tried to use TMC5160 sine table to reduce the noise from the stepper motors. I've had some relatively promising results. The problem was generally a lack of good data to tune the 'sine' function, so I made a test to move the axis at some constant velocity, and then used accelerometer data to iteratively try to optimize that function in different parts and choose the better candidates that would reduce the amplitude of vibrations at specific frequencies (dependent on the test velocity). Unfortunately, that would take hours to converge. But the end result was noticeable noise reduction in a wide range of speeds, though not on all speeds. I didn't send a PR or publish it for testing at the time though. I agree that the sine table can only do so much to reduce the vibrations and increase the precision of microstepping. It also is available only on TMC2130 and TMC5160. But with recent Klipper improvements in microstepping, we could also do a similar adjustment differently and for all TMC drivers. Currently, the steps Klipper sends are 'equidistant'. But we could change that by adding a function for the stepper steps calculation that would add non-linearity to the stepper steps. At high microstepping resolution (128, 256 msteps) it will have an effect similar to adjusting the sine table, but we would not be limited by specifying 90 degrees of the sine wave: we could make it span several full steps, or even 2mm GT2 pitch. Also, with much improved timing of adxl345 measurements now we could use it to accurately map acceleration readings to the microsteps. Then, by measuring a constant speed movement over a long distance, averaging acceleration and mapping it to the microsteps, we would get a useful signal to adjust the nonlinearity function to reduce the vibrations. All I am saying is that it may not be necessary to program stepping over SPI, and use the already available tooling and standard dir/step interface to achieve the effect with most TMC drivers. Separately, we should indeed move this conversation to Discourse :) |
as mentioned in Klipper3d/klipper#4977 "Don't use hold_current."
|
FYI, I did not get a chance to update my TMC tuning branch. However, I have published it (in all its broken glory). There's more info at https://klipper.discourse.group/t/motion-analysis-by-stepper-phase/1876 -Kevin |
This updates the TMC_Drivers.md document to make two notable recommendations:
hold_current.interpolate: False.Details are in the proposed document: https://github.com/Klipper3d/klipper/blob/work-tmctuning-20211128/docs/TMC_Drivers.md
These documentation changes are the results of tests I've been running with the magnetic angle sensors and the accelorometer.
Both of the settings above introduce a positional error that is very small (a handful of microns), but there doesn't seem to be a compelling reason to pay a penalty, as there are alternative configurations available.
As part of this PR, I considered changing the
interpolatedefault from True to False. However, I fear doing so may increase the audible noise of printers to the point that some users switch to stealthChop mode. That would be a net loss, as the positional error introduced by stealthChop mode is significantly larger then the penalty from interpolation (eg, 25x). So, the default remainsinterpolate: Trueafter this PR.Comments?
-Kevin