Caution! - STL Resolution
-
@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.
-
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
-
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:2964528Sometimes 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.
-
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?
-
It would of course result in yet another tunable feature!
-
@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.
-
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
-
@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/
-
@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.
-
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.
-
@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.
-
@EasyTarget said in Caution! - STL Resolution:
And my extreme take on it:
https://www.thingiverse.com/thing:2964528