Caution! - STL Resolution

DocTrucker

What was weird was that it wasn't showing up the full detail of the triangle, just these vertical features.

As it happens these were things I did the CAD work for and the file on the left shows the default settings for FreeCAD when you 'export as' STL (other triangular mesh file formats are available which are more robust, but same resolution issues!) straight from the Part Design workbench shape / body. To create the mash on the left I created a mesh in the mesh workbench to settings a tenth of the original and the Exported the mesh as an STL file.

It's just time for me to stomach longer gcode upload times!

deckingman

As anyone tried to print any large diameter cylindrical objects? Like say in excess of 300 mm diameter? When I've tried in the past, they always come out faceted regardless of what I set the resolution to in OpenScad. So I can set the segment size to say 0.5mm which takes forever to render and makes a huge STL file. But when I import that STL into Slic3R, it seems to discard much of what is in the stl and "do it's own thing" with segment sizes. In the past, I've tried a simple hollow cylinder then changing the segment size in OpenScad to a number of different sizes, then rendering and saving those stl files which obviously results in a number of different sized stl files. But I can then import them all one at a time into Slic3R, slice the object and end up with a number of gcode files which are all the same size. Maybe it's a "Slic3R thing". I've found a setting to reduce the resolution but nothing to increase it.

A Former User

Could Slic3R have a minimum feature or simplification function to avoid generating "too much" g-code?

I only use Fusion and S3D/Cura (or even UpStudio occationally), and limited to 120mm^2 on the printer but no problems making round things round enough to not have noticeable facets.

deckingman

@bearer said in Caution! - STL Resolution:

Could Slic3R have a minimum feature or simplification function to avoid generating "too much" g-code?

It does but I have it turned off.

Wallabear

I was also having issues with stl files. Firstley when I exported them from Solidworks I always maxed out the resolution which made for some pretty big file sizes, but really helped with the print rez. That is also the second was the file sizes were getting crazy big. I am now exporting my diles in .3mf format and I could not be happier. The file sizes are manageable and the print resolution for me is just as good if not better. If you have not trued out a .3mf file I would suggest you do. I sliced the same part in both formats and same print settings and the .3mf format still printed a better quality than the STL

EasyTarget

The flip side of this on Thingieverse: https://www.thingiverse.com/search?q=low+poly

And my extreme take on it:
https://www.thingiverse.com/thing:2964528

Sometimes I like the effect of low poly counts, but mostly it's a pita, as @deckingman says; it can be hard to get rid of them at big sizes. I do the occasional 250+mm diameter vases on my delta and need to look out for this, another area where Octoprint's gcode viewer comes in handy for seeing 'what you will axctually get' vs the preview in the slicer.

DocTrucker

There is certinally an art to good gcode. I've parsed some and found tones of sub mocron vectors which proportionally made the duet in to an expense delete key when the printed to ignored proportion of the file was considered!

Arc interpolation looks an interesting feature on Marlin, discussed in a tweet that the Duet3D account liked. Have we already got that or not?

DocTrucker

It would of course result in yet another tunable feature!

EasyTarget

@DocTrucker said in Caution! - STL Resolution:

Have we already got that or not?

https://duet3d.dozuki.com/Wiki/Gcode#Section_G2_G3_Controlled_Arc_Move

Whether any slicers are prepared to support it is a different matter. It's better suited to slicing from model files (Scad, etc) rather than from polygon based STL's where some, err, extrapolation would be required. Given how most slicers can get confused by straight edges I'm not optimistic they could extrapolate curves from polygons correctly

But.. Very handy for CNC users; though working out the maths has had me sitting with a pencil, a piece of paper, a calculator and a cold sweat.

droftarts

Surprised G2/G3 doesn't have a Z input; would make it great for vase prints. I'd think it would then be relatively easy to parse a vase gcode file to convert G1 moves and remove stl artefacts: from a given point, use the next G1 move as the intermediate point, and the subsequent point as the end point of the arc. Would have to parse for G2/G3 clockwise or anticlockwise moves.

Edit: doesn't quite work as above, but easy to calculate centre of circle from three points.

Ian

EasyTarget

@droftarts said in Caution! - STL Resolution:

Surprised G2/G3 doesn't have a Z input.

This is a whole topic in itself... Not a common CNC feature at all. On GRBL you get some planar support (pick any two axes, eg XZ, but not three).

Some controllers even implement a helix mode.. but no standards exist. My go-to reference bookmark for M2/3 is here: https://www.cnccookbook.com/cnc-g-code-arc-circle-g02-g03/

dc42

@droftarts said in Caution! - STL Resolution:

Surprised G2/G3 doesn't have a Z input; would make it great for vase prints.

It does, at least in RRF.

DocTrucker

As far as I understand it arc interpolation on Marlin is a look ahead on the gcode that recognises a sequence of short vectors with constant angle change as an arc, and path plans based on that rather than forcing the path of the vectors.

EasyTarget

@DocTrucker said in Caution! - STL Resolution:

path plans based on that rather than forcing the path of the vectors.

Ah! now that is different from G2/3; and sounds far more promising for smoothing objects. Thanks for explaining so succinctly.

T3P3Tony

@EasyTarget said in Caution! - STL Resolution:

And my extreme take on it:
https://www.thingiverse.com/thing:2964528