The control we have over infill (pattern, density, etc.) is great - but I think it would be quite cool if it was possible to take the gcode of a sliced model and import it into a CAD package. I realize I might be in a minority of typical printer users by having access to Solidworks premium, but being able to take a file that corresponds to how the model was printed (in terms of internal structure, density and infill type) and run finite element simulations to see how the strength of the part is affected by different infill levels would be amazing
How hard would it be to generate an .stl from gcode? I realize I could manually try and capture the infill geometry and adjust my model… but that would be time consuming. I’d like a script that takes in gcode, and prints to file an .stl of what a printer would create.
I have pondered on gcode to stl, for sake of quality assessment of the slicer job (outline correctness, volume accuracy).
What you head for means you would have to actually render the extruded plastic as polyhedron and make an assumption how close they bond. What is the input format to do the finite element analysis? STL really? If an open source visualization package is there doing the same, I guess there would be demand for people to test their gcode accordingly.
an .stl is definitely not the ideal format, but solidworks has some pretty clever import routines that should be able to create native geometry that can be handled in its simulation package. As you mention, a true simulation would consider the bonding between print layers, and that might be feasible if each layer of gcode was an individual file, then they were put into an assembly, when the simulation was run the bonding conditions could be set. This is a lot more work, and I’m not sure if it would make a world of difference to the end result, as long as the part is designed to handle the loads intelligently. Overall, if either @Stephanie_A ,@Rene_K_Mueller , or anyone else have an idea on how I could start approaching this, I’d be interested!
I am busy right now with http://openjscad.org/, but I coded a few weeks ago https://github.com/Spiritdude/GCodeToolbox which deals with gcode, and I render png (e.g. for documentation) and there I thought to do gcode to stl - if I find some spare time the next week, I take a look, I would create JSCAD, in OpenJSCAD I have rectangularExtrude({h: layerHeight, polygon: 2Dpolygon}); - perhaps it can be done rather quickly, but you gonna have a lot of data as STL finally.
@Anthony_White It would require some research and testing, but I wonder if there is any significant molecular alignment when the plastic is extruded from the hot end. If so, the extrudate properties may differ between the axial direction and radial direction.
Also I know that the slicer accounts for the fact that the extrudate is not going to have a perfectly round cross section but more oval or elliptical. I bring this up because I don’t think the cross section is explicitly indicated in the gcode but rather implied by the layer height and flow rate etc. Maybe some way of simulating this effect before importing into Solidworks would be needed, or using the gcode path as a weldment path and then sweeping the cross sections.
For the immediate future I’m over thinking this, but to get a more accurate simulation I think these points would eventually need to be addressed.
good point @Ben_Malcheski - I forgot that in gcode displays the filament seems to be more circular then it obviously comes out of the nozzle. At least I think that’s what you mean
In order for SolidWorks Simulation tools to know where the thread interfaces are, each thread would have to be imported as a separate part. Then it will have to be told that each neighboring thread is bonded. You’ll want to find a way to do that programmatically, obviously. You might be able to make do with doing whole layers instead of threads, but then you won’t capture the bonding between infill and shells.
After all that, you will need great gobs of RAM and lots of time, because this will be insanely complex geometry for all but the simplest parts. The analysis you are talking about is roughly as complex as simulating composite structures, and that pretty much requires specialty tools. Time would be much better spent printing test parts and physically testing, because analysis time will be more than print time.
I see your point @Dale_Dunn , but I wasn’t looking for that degree of accuracy in a simulation. I’m more interested in just have the rough representation of the internal infill, and being able to get a feel for the density and type of infill best suited for a particular load. Not exactly simulating the printed part - that is definitely a time where real world testing makes the most sense.
Much better, but that will still be compute intensive with the tiny elements you’ll need. I don’t think it will take longer than printing the real thing and trying it, but it will still try the patience.
I don’t see what tiny elements you mean - although the mesh will surely be more complex then treating the part as a solid… I’m imagining parts printed at low infill, on the order of hexagonal at 10-15%. I usually print and test, but this idea was motivated by the desire to predict weights and roughly chose infill %s.
as STL finally.