[FR] ADAPTIVE_STEP_SMOOTHING Breaks down with 256 microsteps SKR PRO TMC5160 #18003
Comments
|
linear advance and s-curve doesn't play along nicely,... try disabling s-curve.. |
|
There is the new experimental feature within linear advance that enables
s-curve. But I noticed layer shifts steadily with accel at 3000. So I am
turning that off for now.
…On Sat, May 16, 2020 at 2:28 AM chiragkrishna ***@***.***> wrote:
linear advance and s-curve doesn't play along nicely,... try disabling
s-curve..
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#18003 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSHLNTMMFNJ4GGCCZGLRRYXAXANCNFSM4NCQ4YYQ>
.
|
|
It seems like EXPERIMENTAL_SCURVE does nothing. |
|
I have tested s-curve acceleration with linear advance and they do not work together on a 32 bit board. Would love to see this fixed both features offer advantages. |
|
The jerk limiting+linear advance+adaptive step smoothing is still usable. |
|
Have you tried with actual 256 micro stepping on z, the extruder and 64 on
x and y?
…On Sat, May 30, 2020, 6:09 PM Kursat Uvez ***@***.***> wrote:
The jerk limiting+linear advance+adaptive step smoothing is still usable.
I am using it now.
S-curve has apparently other problems , by looking at the issues.
Regardless, s-curve acceleration is a bit ill designed.
The slicer and g-code (as an movement expression) mechanisms should have
taken care of that.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#18003 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSDZICG6QMSGPDG67RDRUF73LANCNFSM4NCQ4YYQ>
.
|
There is nothing to fix. Regardless of how fast the processor is, you can always find settings, needing more power. About ADAPTIVE_STEP_SMOOTHING Here the FPU in the F4 could be the problem. In general it speeds up floating point calculations (that's good) but it does that sometimes on cost of saving more (FPU-)registers to the stack when entering a interrupt (that's bad). In the guessing calculations, how long the stepper interrupt may last, this is not considered. For a test you could try to switch off the FPU. If that works, the fix is to add (guessing) up to ~500ns (168MHz) to the calculation if a FPU is present. |
|
I wonder if with 256 micro-steps this was enabling multi-stepping in the stepper ISR, which then caused In general I would not advise using 256 micro-steps, but if you are interested in testing something you could try defining You may need to also apply the fix AnHardt suggested here, to avoid ADAPTIVE_STEP_SMOOTHING completely saturating your CPU: #18598 (comment) |
|
@DroneMang you haven't commented on this in a while. Is this something you are still working with? |
|
No I haven't worked with that for a while. I just turned adaptive step
smoothing off. I ended up with microstepping at 64 on X and Y and 128 on E
but Z does fine with 256. 0.9° steppers on X and Y, 1.8° steppers on E and
Z. Thanks.
…On Fri, Sep 11, 2020, 5:10 PM Jason Smith ***@***.***> wrote:
@DroneMang <https://github.com/DroneMang> you haven't commented on this
in a while. Is this something you are still working with?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#18003 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AIZZJSENPVUHLAJNQES5RITSFKG53ANCNFSM4NCQ4YYQ>
.
|
|
A few months ago we discovered that Given that we have reason to believe the behavior has improved, and you are no longer actively pursuing this, I'm going to close this feature request. |
|
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. |
Hi,
I have been maxing out the capabilities of the SKR PRO. I have increased the microsteps as high as possible without stuttering grinding etc. I found the next step up in microsteps for X and Y, 128, I cannot do travel moves fast enough 200mm/sec and above, plus I plan to try 0.9 degree steppers soon. At 64 microsteps on X and Y I cannot instigate any stuttering at all even at very fast travel speeds 400 mm/sec and up. In increasing the microsteps on the extruder, its sound changed from that of a radiation detector to more of a squeak. So interpolation does not have the same effect as truly increasing the microsteps.
In changing this, I noticed the brim would print very choppy, as in it would do many short accels and stops and the extruder would extrude and retract aggressively during round corners. I have tried with s-curve off and on and the new s-curve feature to enable it with linear advance works well. I tried turning off adaptive step smoothing and the brim behavior is better. So with adaptive step smoothing off and s-curve on is the best so far.
So the request is to review s-curve acceleration, linear advance, firmware retract, adaptive step smoothing, and how these features would be affected by increasing the actual microsteps to the values below and to ensure the planner and other calculations can keep up with this, and identify any other issues. With the new 32-bit boards coming out, these kinds of concerns will probably become more prevalent.
Also, I am looking for a method to ensure that the SKR PRO cannot be maxed out in terms of generating steps for all the steppers, and it would be nice to have a test that you can run that will run all steppers at different rates at the same time to ensure they do not skip steps. Thank you.
Marlin-bugfix-2.0.x-11-5160.zip
I have s-curve , linear advance, firmware retract enabled.
INTERPOLATE true
X_MICROSTEPS 64
Y_MICROSTEPS 64
Z_MICROSTEPS 256
E0_MICROSTEPS 256
E1_MICROSTEPS 256
The text was updated successfully, but these errors were encountered: