Native Arc and/or segment resolution choice

[movingimage]

I'd love to see a G2/G3 checkbox. Right now when printing curves, if I want them to be smooth, I can't go over 50mm/sec or every now and then my marlin-based printer will stutter and create ugly surfaces. I'd love to give native arcs a try. If it doesn't work, I'd just switch it off!

Alternatively - if I could tell S3D to make curves with fewer segments (realizing that at some point the print would look faceted)...I could probably find a happy medium between speed/stutter/detail.

Thanks for considering this!

[NitroXpress]

Hi,

unfortunately with .stl files, it makes no sense to use arcs.

In the past, I did some experiments to force a "high segment resolution" output with CURA, Slic3r, Skeinforge and S3D, slicing a high resolution 50mm diameter cylinder.

Skeinforge: max. 80 segments
Slic3r: max. 128 segments
S3D: max. 210 segments
CURA (older version): max. 320 segments

With CURA, the facetes were almost invisible.
For my controller, it is no problem to handle 0,1mm segments up to 250mm/sec.
But for a arduino driven printer, it is impossible to handle such a data flood.

So the best way would be, to have a adjustable "segment length" option...

See my youtube video printing a thin wall tube up to 390mm/sec https://www.youtube.com/watch?v=j_ATq9Rnghs

[movingimage]

Hi,

I'm glad your printer can handle it. Most common printers have issues.

If I understand your tests correctly, S3D creates a large number of segments compared to Skeinforge and Slic3r. SO, one option would be a segment resolution control.

Also - for .STL files, arcs do make sense. The software that has implemented them in the past does a best-fit routine, and then replaces the tightly segmented area with an arc. So, it actually modifies the .STLs input geometry.

Thanks for your thoughts,

J

[NitroXpress]

If the slicer do a best fit with arcs for segmented curves, you don't have a 100% control over the output.

Unforunately, there are three bottlenecks.
First, the G-Code interpreter and second the interpolation time/algorithm.
Third bottleneck is the output step frequence/resolution.

Sure, if you have G2/G3 arcs, the interpreter have less to do and the CPU can interpolate the x/y axis with maximum performance and resolution.
No problem with cylinders.

But what about freeform surfaces and narrow curves ?
How to tell the slicer which parts of a surface to interpret as arcs ?

At the end, the remaining bottleneck always is the power of the CPU...