-
-
Notifications
You must be signed in to change notification settings - Fork 19.5k
Fixed point smooth linear advance (makes it available to all 32 bit boards) #27818
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
Fixed point smooth linear advance (makes it available to all 32 bit boards) #27818
Conversation
(cherry picked from commit a06e1a3)
Note I'm using different positions for the fixed point in different variables to maximize decimal resolution depending on the magnitude of the numbers that they store. |
If necessary, it could be optimized a bit more by:
But that would require a lot of care to avoid overflows and I think it wont really make such a big difference, just a couple of cycles per multiplication. |
Printing as I type on an Anycubic Predator delta with STM32F103 (no FPU). |
(cherry picked from commit 6e1e42c) # Conflicts: # Marlin/src/gcode/feature/advance/M900.cpp # Marlin/src/module/planner.cpp # Marlin/src/module/planner.h
I'm doing some test prints to compare floating point vs fixed point branches. There is a slight (but visible) loss in quality in fixed point. This may be the lower time resolution of the less frequent ISR. May have to increase it back. |
(cherry picked from commit ab7d10a)
@rq3 Can you try again? the version you tried above had an overflow that worsened quality. |
Yes indeed. Just need to mod the files, recompile, and print. Give me a few hours. |
could have |
Printed with no issues at all. The accelerometer on my print bed claims the g forces on x and y were slightlyed higher than "normal", but subjectively the extruder behavior seemed more "civilized", and it appeared that I could actually see and hear the extruder "anticipating" what was coming. That could certainly be my imagination, but the results are excellent. |
Glad to hear! |
I've been starting to re-calibrate my printer using this new mode and the results are pretty promising. However, it seems I can't change the input shaping frequency while printing - any attempt (whether via g-code or the LCD menu) causes the printer to freeze and reboot. Wondering if it has to do with the Input_Shaping_E_Synch option (which is enabled). Any way to g-code to disable that function without reflashing the board? (I use manual mesh leveling so it's a pain to recal every time I flash) |
You can output existing mesh with G29, and make g-code file creating mesh back also with G29. By a way, what is link between input shaping calibration and LA? Aren't IS parameters depend on mechanical properties only? |
That’s helpful, thank you.
The Smooth_Lin_Adv feature includes a connection with input shaping, i
don’t understand it well but there is a line to enable/disable that
particular feature in configuration_adv.
I am recalibrating my input shaping after installing the new firmware just
to be thorough with all the new settings.
Edit: I reflashed with LIN_ADV and SMOOTH_LIN_ADV disabled, and am now able to adjust input shaping during printing. Not sure which is more directly related, or if it's even just some sort of buffer issue. Should I submit a bug report?
…On Fri, May 16, 2025 at 11:20 PM Vovodroid ***@***.***> wrote:
*vovodroid* left a comment (MarlinFirmware/Marlin#27818)
<#27818 (comment)>
@grizzleeadam <https://github.com/grizzleeadam>
I use manual mesh leveling so it's a pain to recal every time I flash
You can output existing mesh with G29, and make g-code file creating mesh
back also with G29.
By a way, what is link between input shaping calibration and LA? Aren't IS
parameters depend on mechanical properties only?
—
Reply to this email directly, view it on GitHub
<#27818 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A6SRTTWN4UNJYS76QQSXV7L263IJBAVCNFSM6AAAAAB35JKNZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBYGEZDQNZTGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I noticed that yesterday too. Interestingly the crash doesn't happen if input shaping parameters are changed via gcode. I assume the difference is that the menu doesn't synchronise with the planner and the internal shaping params (like delay and factor) are changed while in use. That must be causing ludicrous extrusion speeds which make the firmware spend 100% of the time in the stepper interrupt, starving the watchdog and eventually resulting in halting. In short: a bug in e-synch |
But why recalibrate IS itself? |
Recalibration shouldn't be necessary |
I rushed my calibration when I did it the first time over a year ago (haven't tinkered much since), was just doing it as a reassurance - not because this commit needed it.
For me, the crash was happening with both gcode and with the menu. I tried adding a 100ms dwell before and after the gcode and it was still crashing at the first M593 command. I suppose I could try disabling the E sync and see if it still does it for me. I'm on a SKR E3 Mini v1.2, bit of an older setup. |
That would be a good test, please post the result. Maybe gcode didn't fail for me is just because I made a frequency sweep from low to high. So the delay between echos got always shorter and the algorithm never had to look at an unset value of the lookback buffer. |
I think I know what the problem is. Since E-SYNCH doesn't check if shaping is enabled, and disabling it sets frequency to zero, it also creates the same problem, but worse: the delay is -1 in uint, so a very large value. |
@tombrazier: by default SHAPING_MIN_FREQ is the minimum of the freqs set at build time, but the menu allows going below them. Doesn't that make the input shaper break? |
PR to fix that: #27862 |
What about the manual override for the min frequency? I have that commented
out by default - should that be set to something?
…On Sat, May 17, 2025 at 6:45 AM David Buezas ***@***.***> wrote:
*dbuezas* left a comment (MarlinFirmware/Marlin#27818)
<#27818 (comment)>
PR to fix that: #27862
<#27862>
—
Reply to this email directly, view it on GitHub
<#27818 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A6SRTTWO4NHRTRQUMZRLSYT2644QJAVCNFSM6AAAAAB35JKNZWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOBYGQYDINBYGY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
You can also set it, the issue is that Marlin allows you to then set a lower frequency and that. |
No, it just reduces the effectiveness of IS at higher speeds, as explained in the comment above the input shaping section of the config. |
I tried the following, one at a time, using latest 2.1.x-bugfix:
I'll repeat the same with your new PR linked above. |
With your PR 27862: SMOOTH_LIN_ADV enabled, INPUT_SHAPING_E_SYNCH enabled; M593 worked. However, the stepper motor started making some ugly sounds as the speed increased. |
Most likely you had set a frequency below SHAPING_MIN_FREQ. I'll continue the discussion in the open pr, thanks for the reports! |
This looks to potentially have caused a new error in DWIN PROUI:
|
Oh, I've been slow testing this on 8 bit! It compiles for me but uses about 6% of my RAM and I get stack overflows. Maybe leave the 32 bit sanity check in place! |
Port smooth linear advance to fixed point arithmetic.
Followup to #27710
There is still one float calculation inside the ISRtarget_adv_steps_q13 = lookahead(t) * (Planner::extruder_advance_K[0]*(1UL<<13));// todo keep k in q format
I'll later put extruder_advance_k behind a getter setter where also a fixed point version in q18.13 format will be kept up to date for use inside the isr.Opening the PR early because it may be already fast enough for tests in boards without an FPU.Also changed to more conservative initial values for tau (20ms instead of 10) and smooth advance isr frequency (1kHz instead of 5kHz)
Smooth linear advance should now work in any 32 bit board and maybe (just maybe) in an 8 bit one.