Here are my first results of stretching via gcode postprocessing to compensate for arc.
I hope to be able to be integrable with cura generated GCode too.
http://blog.pcedev.com/2015/06/02/arc-compensation-reprap/
Those are all severely overextruded, and with the example prints, looks like trying to correct the wrong thing at the wrong spot; ultimately leaving things broken where they matter.
yes, I recently switched filaments and didn’t polish the diameter width setting hence the overextrusion.
The outer XY dimensions still remain in the target range (within 0.02mm and 0.04mm of the stl model) so it shouldn’t have impacted too much the hole sizing.
In worst case, it means that a less aggressive stretching would be enough to compensate properly for hole dimensions.
If you’re over-extruding, but your outer dimensions look correct, you should expect your holes to be way too small because you’re almost certainly printing the objects too small, trying to adjust for a surface tolerance error (an additive error) by adding a scaling error (a multiplicative error).
Would it be possible to support arc gcodes? I know that smothieboard supports it.
This is great.
@Whosa_whatsis I’m slicing right now the part with a reduced feedrate to try to get quickly a nicer top finished part to use as reference. It should require a lesser stretch strength to correct hole size.
@Tiago_Vale That should be doable. The most tricky part is finding out a point normal. in the case of arc gcode, it’s easy to find (previous move + current arc opcode should be enough I think) but when mixing arcs and segments in a perimeter, the segment normals might be harder to determine.
@Brad_Hopper Thanks a lot
I hadn’t clicked through (just responding to the previous comments), but it looks like what you’re trying to do is port the old skeinforge Stretch plugin as a post-processing script for Cura? Are you doing anything about the extra material being extruded into the same space as your new outline path? I believe Stretch operated before infill for an important reason.
Really, with proper use of polyholes in a design, I don’t really see a need for the Stretch plugin anymore in almost all cases (certainly not for creating circular holes). Perhaps selective application of an extrusion-width-based resolution-limiting function (you’d need to make it move the vertices to maintain the lines rather than doing the opposite, easier function, which would constrict the holes) could effectively create appropriate polyholes while slicing when an object wasn’t built with them.
yes, I’m porting skeinforge stretch plugin to be usable as cura or slic3r postprocessor.
As you say, in skeinforge stretching happened before any extrusion was computed, so I had to reduce extrusion to accommodate the new points location. Basically, I reduce edge width as I move the point outside of the hole.
Polyholes indeed fix stretching issues but for more complex shapes, it’s not that obvious to account for the post printed result at design stage.
As you mentioned, stretching or polyhole conversion could also useful for models built initially without polyholes.