RUG/Pennsylvania/State College/Software/CAD/STL

From RepRap
Jump to: navigation, search

Project: STL Formatting

The issue: STL files are integral to any reprap functions. Models are all saved as STL files, and then programs like Skeinforge, Repsnapper, etc. will use the STL files to generate G-code to run the machines. However, it seems that not all STL files are created equal. Some files can be imported directly into Solidworks as an editable solid object while the same procedure with another STL may result in a surface object bearing no physical properties within Solidworks. Other STL files will remain in the viewing area of RepSnapper even after being removed and replaced by the user. It seems that there is some difference, which we aim to discover and solve in order to ensure that all STL files are equal.

History: STL, or stereolithography, is a file that uses large quantities of triangles to define the surface of an object. When I say large quantities, we're talking about thousands of triangles depending on the complexity and size of the object. When you open an STL file, the software reads the positions of the triangles and assembles them into the model. The data contained in an STL file looks like the following:

 facet normal 0.0 0.0 1.0
   outer loop
     vertex 43.467169 15.697621 8.15
     vertex 39.874121 19.290669 8.15
     vertex 38.981956 18.694544 8.15
   endloop
 endfacet

This data can be broken up into its components to easier understand what it all means. Facet normal represents the quantification for a unit vector pointing away from the object. The most important (and to be honest most relevant) information contained are the numbers following the word "vertex". The numbers following each of these instances denote the Cartesian coordinates (x,y,z) of each of the vertices of the triangles. The small bit of data above represents the information for one triangle, and this patter of sequences will be repeated until all triangles are represented by the numbers.


Theories: I took a look at a lot of different STL files and they were extremely simple. There was no extra data, meaning there was very little that could differ between files that could cause some to cooperate and others not to. The one noticeable difference (besides the unique coordinates for each vertex) was the formatting. By messing with the spacing on a properly formatted file, I was able to disrupt it to the point where it would not open as an editable solid object in Solidworks. This led me to the conclusion that the formatting was critical to properly opening an STL.

Solution: The files with incorrect formatting mainly come out of Google SketchUp, and they have the correct data but there is no spacing before the qualifiers (outer loop, vertex, etc.) in each line. To solve this for the 17,000+ lines for the specific part, I had a friend write a program (found below) that will analyze the STL file (opened as a .txt file) and provide the proper spacing for each line depending on what data it contains. Initial tests of the changes didn't provide the desired results, but we plan to modify the program and do more research in order to make the program clean up any STL code.