Monday, March 6, 2017

Segment-less Delta Movement

This post comes from a post I originally made on the SeeMeCNC forum in December, 2015. I find myself referring to that post often and repeating it in multiple places so I'm adding it here where I can keep it updated.
updated 3/6/2017

Segment-less Delta Movement
A little know secret to most delta (and Cartesian) printer owners is that path movement for all firmware except David Crocker's dc42 RepRapFirmware is actually broken up into short straight segments. In other-words, a curve is actually "drawn" as a series of short lines and not a smooth arc like you might expect.

These other firmwares are interpolating movements into short line segments so, in theory, there is a negative impact on print quality. There are other factors at play too though - hence the reason for "in theory". By it's very nature, 3D printing starting with an STL file sacrifices some resolution depending on how the original CAD model was converted into an STL (most profound is the # of triangles in the final model). Here is an example of how this works...

Imagine you have a CAD drawing of a 20mm diameter sphere. The CAD tool uses sophisticated math to calculate the geometry and display it. It looks like a perfect sphere on screen. Now, let's run that perfect sphere through the meshing process to create STL versions. To demonstrate I am using 5 different resolutions that generate a low number of triangles to a high number of triangles. When you download an STL from Thingiverse, you have no control over this, the original author made the resolution choice for you. And frankly, most of the folks uploading to the shared services really don't know how to create high quality meshes. Anyway, back to the example - here I've meshed to create a "sphere" with 48, 224, 960, 16128 and 99856 triangles (from left to right). You can see that the far left sphere is course and the one on the far right is reasonably smooth.

Now to take this one step further, imagine your slicer creating g-code from these STL models. To illustrate, I created an imaginary slicing plane 12mm above the base that is .02mm thick and took a cross section of the model at that plane. This is the red line you see inside each model. I projected these slices up above the models so you can see them clearer (black). The 48 triangle model has a slice with 8 sides - pretty low resolution. You can see as you move left to right, each slice has more line segments. These will result in a finer/higher resolution print all things being equal. But they are not! In addition to the slicer converting curves into short line segments, the firmware also imposes its own line segmentation on top of that - that is all of them EXCEPT dc42 RepRapFirmware. dc42 draws each point along the way completely tracing the original path it was given. Smoothie, Repetier, Marlin and the others actually break the path up into short line segments and draw those. This does not always match the original path exactly.

As you can see, if the STL had a low triangle count, you are going to get a course print whether or not your firmware does segment-less movements. Increasing the triangle count will improve the print quality until you reach the segmentation threshold of the firmware, at which point, increased # of triangles won't have an effect and might actually make things worse. That is except dc42, which will faithfully trace each of the tiny line segments exactly point by point.

But, there are other factors that come into play like stepper resolution (1.8° vs 0.9° steppers) and a host of others. Will segment-less moves make all your prints look fantastic? No. But if you design your own parts and optimize output for high quality meshes, I assert you will be able to see the difference. This difference is minute and impossible to photograph, I've tried for over a year. But, parts in hand 10 out of 10 test subjects will pick the part printed with segment-less moves as the best quality part.

I posted Musings on Impact of STL Triangle Count in Jan, 2016 if you'd like to get more info.

No comments:

Post a Comment