More Accurate Retraction Calibration Model and Process

[MxBrnr]

Is there an existing issue for this feature request?

• [X] I have searched the existing issues

Is your feature request related to a problem?

Current retraction calibration method is time and material consuming, with less accurate and generally difficult-to-interpret results than other options.

Which printers will be beneficial to this feature?

All

Describe the solution you'd like

Replace the current single-function retraction calibration model with a combined retraction distance/speed tower similar to that found at http://www.retractioncalibration.com/

Describe alternatives you've considered

No response

Additional context

This allows the user to test and see the close relationship between retraction distance and speed, and to compare the combined results side-by-side to that of other pairs of retraction settings, all done in a single print test model.

[Ergonomicmike]

My 2 cents: I've printed the retractioncalibration test in the past. (For fun.) I can't tell you why it is, but I've found that the "normal" retraction tower test gives much more real world results. (And this is on a Bowden printer, the worst case for stringing.)

That is, I can use lower retraction settings (always a good thing) based on a retraction tower test to eliminate stringing, as opposed to the higher settings based from retractioncalibration.

It might be that the many variables involved in retraction nowadays (mainly PA, but perhaps others, like wiping?) aren't triggered by the retractioncalibration test?

I dunno. But I know empirically that the retractioncalibration test is overkill for me. (Albeit fascinating.)

And while speed of retraction makes some difference, it seems to be a 2nd order effect, retraction distance making the most difference.

P.S. I use a loop to view the results of a retraction tower test because there are some subtleties that can only be seen upon magnification. But if the primary goal of using a retraction test is to eliminate stringing, then, for me, the tower test meets that goal.

[MxBrnr]

My experience with it has been opposite, I now use it for tuning retraction on all machines and filaments that I use, and I have gotten for more accurate real-world results because of how it allows exactly what I mentioned in the original post.

Not sure what you mean by "higher settings based from retractioncalibration" being that all the parameters can be individually customized. Granted, I have found the instructions on the website are rather misleading (i.e. it mentions starting with 0.5mm retraction distance and increments of 0.25, but many tests have best retraction at 0.3-0.4mm and in 0.1 increments). As with any calibration testing, if a person is not seeing results/differences within the default parameters, they should change the parameters.

I envision that an implementation of this tool into Orca would allow for setting at least all the same parameters as are currently provided for in the online tool, as well as the ability to verify/set the various other affecting parameters (such as PA, jerk, etc.) sliced from the software - like you mentioned - that the online tool does not provide for. In my case, I currently make sure those other settings are taken into account for the test via programming them through my firmware. Integrating this tower tool into the slicer would eliminate that need, so then the test could be run using all the slicer settings, providing for even more real-world accuracy than both the online tool and the current Orca test account for. The combined tower test has the potential to help everyone get the best tuning possible, even if many users would opt to not bother with it, but that is still better than providing a lesser alternative, as is currently in use.

[Ergonomicmike]

Interesting that we have opposite experiences.

My main point, as you acknowledged, is that the retractioncalibration test is (I believe) hardcode gcode, bypassing any enhancements provided by Orca or the printer's firmware. (e.g. Klipper.)

So while it's true that if one can print the retractioncalibration test without stringing, then one should not have stringing when the slicer and firmware are involved. But it might not be necessary to use, say, 5 mm of retraction (overkill) to pass the test when 2.4 mm retraction will work fine when the slicer and firmware are involved.

But a model like the retractioncalbiration test, sliced in Orca, might be interesting. (Althoug I wonder how one forces the extremes of the test via an stl.)