Add speed range exclusion to mitigate "bad" (high resonance/vibration) ranges in print speed to maximize quality and speed

[nexus665]

Hi,

each motion system has certain resonance ranges in the print speed spectrum where it does not perform great, as can be heard by increased noise and measured with accelerometers.

It would be great to have an advanced option to exclude these resonance-heavy print speed ranges. This could be done with a table like small area flow compensation as far as UI goes, does not need to be very smart. If a print speed inside the exclusion range is selected, choose a replacement from this table.

Workflow: figure out resonance areas with external tools (klippain-shaketune and/or chopper-resonance-tuner, for example). Define print speed exclusion ranges, see the attached PNG - in this example, 3 ranges that have low vibrational energy (0-68.8mm/s, 115-157mm/s, 163-200mm/s) should be used, speeds in the worst range (69-110mm/s) should be avoided (though the peak at ~160mm/s is pretty negligible compared to the others).

So, create a 3-column csv-style table to define either exclusion or inclusion ranges, and a switch "lower/higher than requested" inside your printer profile motion system definition.

This should suffice to make sure the printhead never extrudes at these speeds to minimize VFA and maximize print quality while not sacrificing more speed than necessary.

I have not looked at the codebase in detail yet and my C++ skills are only rudimentary, though I would like to contribute if someone could point me at the relevant source files...

[igiannakas]

This is pretty straight forward to do - I have started implementing this in the past and then stopped doing further work on it - there are two ways to do this:

1. Implement a speed clamp in GCode.cpp -> ie when the gcode is first generated. You can do this by amending / overriding the extrude functions in gcode.cpp: std::string GCode::extrude_loop, _extrude, extrude_path etc. The speed value is passed as a parameter so it can be clamped there. However with this approach when slowdown for layer time is applied the speed values will be overridden (slowed down) so you'll hit those speeds again. So there is limited benefit there, if the user has setup their profiles well.
2. Implement it as a post processor after the last gcode processing task is run. this is similar to how the adaptive PA code is written (take a look at my PR and you'll see the gcode processors (adaptivePA processor): https://github.com/SoftFever/OrcaSlicer/pull/5609/files - scan each line of the file, find the speed change gcode, and if it falls within a speed range, clamp it up or down, depending on the value's proximity. This is dead simple to do and it solves the problem of speed changing by the layer time calculations after the gcode has been generated in option (1) above. It's literally step through each gcode line, regex match the F parameter and replace it with a new calculated value. The code from the adaptive PA geocode post processor should be almost a good template for this as I am doing line parsing and replacing in there too.

However the reason I stopped development on this was as below:

1. Changing speeds abruptly within layer results in micro variations in the extrusion consistency. These show as minor artefacts on the walls. Imagine going from 200mm/sec to 40mm/sec instantly.
2. After I've implemented the "dont slow down outer walls for layer time" feature (here: Enhancement: Do not slow down external perimeters to meet minimum layer time #5148) I've found that if you set your speeds appropriately on a per feature basis you shouldn't get any long stretches where a resonant speed is hit. Eg. set your external perimeter speed to be away from resonances and set an aggressive slowdown curve for overhangs which are by nature localised so vibrations shouldn't be excited much.
3. Also I've found that upgrading my TMC drivers to the 2240's from the old 2209s improved resonance control of the motors immensely -
   

So in the above profile for example I print external walls at 140mm/sec or at 60, with the overhang speeds being like below:

or

With the above changes it became a non issue so I stopped doing further dev work on it :) Your machine has a very well controlled resonance profile, so you just need to avoid a single speed range. The above settings (plus dont slow down outer walls for layer time) should get you there.

Hope this helps you and provides you with some guidance if you want to have a go at trying to implement this :)

[nexus665]

Wow, thank you for such a detailed response and for doing my work for me ^^

Great to see that the community here is bristling with ideas and implementations. I agree that hard speed changes are quite awful, so the "dumb" version of this would not work too well, I guess (even with the help of extrusion rate smoothing).

Still, food for thought, and thanks also for pointing me at the code!

I will have a go and post about it here should anything interesting develop.

[igiannakas]

Extrusion rate smoothing is also applied as a post processor. So maybe applying the speed clamp post processor before ERS runs would mitigate the sudden speed shifts.