I posted part of this on the SeeMeCNC forum a few weeks ago as part of a discussion on the dc42 branch of RepRapFirmware's delta motion calculations vs other firmwares. Most mainstream firmwares (Marlin, Repetier, Smoothieware, MachineKit, etc) interpolate print moves as short line segments. The dc42 firmware calculates each and every point of movement. So, in theory, prints made with dc42 - all other factors being the same - should result in higher quality prints. To date, I have not seen any actual evidence that this is borne out in practice (*if you know of any examples, please let me know!). There are other factors at play that might obscure the benefit of dc42's precise calculations. I have converted all but one of my delta printers to dc42. Even though I can't definitively prove the printed parts are better, I do believe there is a subtle difference.

By it's very nature, a 3D print originating from an STL file is going to sacrifice some resolution due to the meshing (or tessellation) process that converts the mathmatically precise CAD model into a triangle mesh. Here's an example of a sphere drawn in a CAD application and an example mesh (which is what is saved in an STL file):

The higher the triangle count in the mesh, the more closely it represents the original sphere. But it's a tradeoff between file size and model accuracy. In practice, even with reasonably high triangle counts, the mesh is a close, albeit pretty good, approximation of the original.

Take a look at the image below of a 20mm diameter sphere converted to five meshes, each with differing triangle counts. The CAD tool uses sophisticated math to calculate the geometry and display it. It looks like a perfect sphere on screen. The image shows five different resolutions from a low number of triangles to a high number of triangles (left to right).

Imagine printing each of these meshes. The printed part from the mesh on the far left would not look very spherical at all. The printed part would look better from the 224 triangle mesh and best from the 99856 triangle mesh.

Back to the example - to take this one step further, imagine your slicer creating gcode from these meshed models. To demonstrate, I created an imaginary slicing plane at 12mm above the sphere's base that is .02 mm thick to represent a typical slicing layer. These are the red polygons circumscribing the meshes in the image above. I then projected these slices up above the models so you can see them more clearly (the black polygons "floating" above the meshes).

The 48 triangle model has a slice with 8 sides. It should be a perfect circle so this is a very low resolution slice. As you move left to right, each slice has more line segments to represent the circle. Higher segment counts to represent the circular cross section 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 within the resolution of the printer's mechanics. 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. 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.

To test if dc42's precise movement calculations have a positive effect, one would have to perform a side-by-side comparison using the same printer and filament, printing the same STL file (which was meshed with a high triangle count) once with a Smoothieboard running smoothieware and once with a Duet running dc42. I'm thinking about what the best test model should be to perform this test. If anyone has any suggestions or comments, please let me know.

By it's very nature, a 3D print originating from an STL file is going to sacrifice some resolution due to the meshing (or tessellation) process that converts the mathmatically precise CAD model into a triangle mesh. Here's an example of a sphere drawn in a CAD application and an example mesh (which is what is saved in an STL file):

left: CAD sphere right: triangle mesh |

Take a look at the image below of a 20mm diameter sphere converted to five meshes, each with differing triangle counts. The CAD tool uses sophisticated math to calculate the geometry and display it. It looks like a perfect sphere on screen. The image shows five different resolutions from a low number of triangles to a high number of triangles (left to right).

Effect of increasing triangle count (left to right) |

*NOTE: When you download an STL file from Thingiverse or another sharing service, you have no control over the mesh count. The original author made the resolution choice for you and depending on their level of sophistication, the resulting mesh may not be optimal.*Back to the example - to take this one step further, imagine your slicer creating gcode from these meshed models. To demonstrate, I created an imaginary slicing plane at 12mm above the sphere's base that is .02 mm thick to represent a typical slicing layer. These are the red polygons circumscribing the meshes in the image above. I then projected these slices up above the models so you can see them more clearly (the black polygons "floating" above the meshes).

The 48 triangle model has a slice with 8 sides. It should be a perfect circle so this is a very low resolution slice. As you move left to right, each slice has more line segments to represent the circle. Higher segment counts to represent the circular cross section 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 within the resolution of the printer's mechanics. 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. 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.

To test if dc42's precise movement calculations have a positive effect, one would have to perform a side-by-side comparison using the same printer and filament, printing the same STL file (which was meshed with a high triangle count) once with a Smoothieboard running smoothieware and once with a Duet running dc42. I'm thinking about what the best test model should be to perform this test. If anyone has any suggestions or comments, please let me know.

I do like the fact that " dc42 draws each point along the way completely tracing the original path it was given within the resolution of the printer's mechanics"

ReplyDeletein another post you are talking about your delta printer(lucky you), do you know if this feature is available in another form of printer?