Retraction Calibration

[prahjister]

Jeff Jiggens suggested I share a calibration process I have been working on and might want to integrate into your slicer.

https://github.com/prahjister/Calibration-Generator

I am preferring to go web based for cross platform compatibility but the bulk of code is available on github. I have only changed some defaults and formatting. I will push these Minor changes to github in a couple days.

You can check out web version here

prahjister.duckdns.org

I'm self hosting unless I can get enough donations to pay for it.

[supermerill]

Thank you. Your concept is good, but I can't integrate it as-is, as I don't generate gcode but a geometry. My dev version currently doesn't care for speed, as i think it should be put to the maximum speed the extruder can safely handle, what do you think of it?

[belm0]

I'm fairly interested in this topic and was intending to do some development work on it. (Currently I use PrusaSlicer.)

Observations:

• retraction is important yet hard to calibrate - much room for improvement in this space
• the "gcode generator" approach to retraction calibration doesn't work well in practice. I've tried both the calibration by prahjister and 3DOptimizer. When applying the results to an actual slicer and real prints, things don't work out as expected because each slicer has its own peculiarities with the retraction implementation, as well as complex wipe options that interact with retraction.
• with prahjister's version-2 calibration, the raft it was generating was significantly under-extruding and causing my printer to go haywire. It suggests that gcode generation should be left to slicers.
• on the other hand, as noted by SuperSlicer's author, slicers work from geometry, and it's difficult to generate forced retractions needed by calibration tests

My ideal calibration test would be something that can do many retraction iterations per layer (like the gcode generators) while varying any retraction-related slicer setting (including wipe options, etc.).

Options worth exploring:

• geometry which yields many retractions, yet can somehow support itself well for many layers
• hacking the path planner somehow

[belm0]

first attempt at some retraction calibration geometry

I tried to make something that would be a coherent piece and structurally sound like prahjister's calibration (as opposed to typical retraction test of isolated towers which is subject to breaking).

There is an inner perimeter for structure, and then the retraction segments are outside and adjacent to that perimeter. I needed to set the slicer to 1 perimeter wall, and "Slice gap closing radius" of 0.

Unfortunately the path planner is doing random things-- the retraction segments are not printing in the expected order.

next I'll try just the retraction segments + skirt

[belm0]

Using a skirt to provide structure seems promising-- it will always be printed first-- though obviously this puts the structural perimeter on the outside of the retraction segments. Just set skirt height to a large number and distance to 0.

I found it's necessary to set "detect thin walls" to generate simple segments that detract at one end and retract at the other. Otherwise the extrusion doubles-back so that the start and end points are the same.

However the problem with the path planning remains-- it seems random. I couldn't find any setting in PrusaSlicer that would affect it. It's odd that the planner doesn't continue with the nearest segment.

Without deterministic path planning it won't be feasible to vary the retraction settings for each segment in a layer.

Perhaps SuperSlicer has better path planning?

[supermerill]

Perhaps SuperSlicer has better path planning?

nop. I have idea to improve it, but i don't have time to implement it.

[belm0]

Rather than trying to make a general path planning enhancement to cover this case, how about adding a "simple mode" option which naively choses the nearest segment?

But even if this is done, I'm not sure how to vary the retraction settings during the layer. Perhaps it can be done by modulo retraction count, assuming that there a constant number of retractions per layer.

[supermerill]

how about adding a "simple mode" option which naively choses the nearest segment?

That should be the case. But the seam placement may shake it up a bit. And some restrictions in direction, again.

prusa created a more complicated algorithm that try to find the best chain, but it doesn't support no_sort and some other restrictions, so i can't use it.

[belm0]

I tried all the seam placement options, it didn't affect the path planning. In this geometry the perimeter is not a loop, so I don't think seam placement is related.

[belm0]

And some restrictions in direction, again.

Why is there direction restriction?

Indeed, it seems like planner tries to extrude in the same direction along the X and Y axis, even if the path is suboptimal.

[belm0]

v3 of retract geometry - simpler, single axis

However the tested move direction after retraction is limited: 180 and ~135 degrees. I would like to test 0 degrees (i.e. continue current path) but it doesn't seem possible due to the print origin and path planner's preferred extrusion direction.

maybe usage would be like this:

• primary variation (like retraction speed) is along long axis
• the pairs on short axis are duplicates
• optional secondary variation (like print speed, extruder temp) is in z dimension
• after print, cut one side of the skirt on short axis to get access to the interior for close inspection

note: PrusaSlicer path planner seems to depend on ordering of objects in the STL. So is it really doing any optimization?

[supermerill]

it is to a certain point, complexity is np so you can't go full steam.

[belm0]

another approach is to encode path order in the geometry somehow, and modify the planner to use it

For example, segments are drawn in oder of length. Or draw objects strictly in the order they appear in the STL.

But I tried reading the MotionPlanner code and it wasn't easy to follow-- at this point I can't judge how easy such changes would be.

[supermerill]

If i have to change it, i'll scrap everything and rewrite all of these.

My current approach in my dev retraction calibration is a dual tower (cylinders) with the retraction setting that increase every 2 layers.

[belm0]

doing the towers and changing settings by layer is so much simpler

I don't know if it would be worth all the development, but some advantages of changing settings within the layer:

• it's easier to see subtle differences between settings when they are side-by-side rather than sequential
  • especially for retraction, we want to see 1) how it looks on the last layer, and 2) any possible adhesion problems on the 1st layer. Changing settings within the layer makes these comparisons possible.
  • ability to have secondary variation in z, like print speed or temperature

[belm0]

@supermerill is a preview of your retraction calibration feature available?

[supermerill]

I'm unsure about the layer cooling time... does it is really needed? I now need to create multiple prints (one per temperature), and to fix a strange slicing bug.

[belm0]

Using ridges to mark the changes is interesting.

Is this focused only on retraction distance? I'm wanting to tune retraction and un-retraction speed, extra length on restart, wipe while retracting on/off (perhaps done as a separate pair of columns), and retract amount before wipe. (Of course, only one parameter can be tuned at a time.)

For layer cooling time, I would leave it to the slicer's default cooling handling, which I understand to slow down printing if the layer time is too fast.

[belm0]

This article emphasizes the high complexity of retractions, and the importance of retraction / detraction speed.

https://www.sublimelayers.com/2016/10/some-musings-on-retracts.html