I don't really like that STL files are limited to flat faces and straight lines.
I should qualify that: I don't like when STL files are often offered as "CAD files", because information in the original design is lost, changes are difficult, and, as a triangulation of a curved surface is necessarily an approximation, you're stuck with the accuracy chosen by the creator of the STL file. The way I see it, a STL file is an intermediate step between the CAD file (whatever format) and the machine commands (e.g. G-code), so it's part of the CAM process. STL files do have the merit of being understood by a lot of applications, but that does not compensate for their shortcomings as a source distribution format. By all means, offer the STL files in addition to the source CAD files, but not
instead of the CAD files.
bdring wrote:I have found that rounding a sharp corner can keep the speed up on a print and give a better quality edge. The rounding is actually a lot of little line segments. It appears that if you get too many short lines in the given space the controller starts to stutter a bit on those areas. It probably has something to do with the look ahead count.
Looking at Marlin code, I found that even if the G-code specifies an arc, Marlin breaks it down in little segments and that's what goes in the planner. So it would stutter even with arcs, it doesn't really matter where they get broken down into segments. Generating G-code with arcs converted to line segments gives the CAM program more control over the precision of the approximation; generating G-code with arcs as G2/G3 arc commands gives this control to the firmware, and "real" controllers can probably deal with it better, as they "know" the machine better.
Of course, the latter is not possible starting with STL files, unless the CAM application can identify what segments used to be part of an arc and undo the approximation. That, in principle, sounds like going at it backwards. Why lose the information about a feature being round in the first place? That's an objection to using STL even as an intermediate in the CAM process. Again, the ubiquity of STL support goes a long way to compensate for its shortcomings, and my objections to using them during CAM are much weaker than my profound dislike of them as a source distribution format (when not accompanied by the
source source CAD file).
Edit: Bart, I'm sorry. Now that my rant is over, I re-read your post and I saw that I was a little off-topic. My point that Marlin breaks down arcs into segments before they go into the planner is somewhat relevant, though.