PrusaSlicer has a new feature: the ability to import a CAD model for 3D printing. Starting in version 2.5.0-beta1, PrusaSlicer can import STEP format 3D models. An imported STEP file is converted to a triangle mesh on import (making it much like a typical .stl or .3mf file) which means that slicing all happens as one would normally expect. This is pretty exciting news, because one is not normally able to drop a CAD format 3D model directly into a slicer. With this change, one can now drag .stp or .step files directly into PrusaSlicer for printing.
First, a brief recap. In the world of 3D models there are two basic kinds: meshes and CAD models. The two work very differently, especially when it comes to editing. 3D printing has a long history of using .stl files (which are meshes) but making engineering-type changes to such files is difficult. Altering the size of a thread or changing mounting holes in a CAD model is easy. On an STL, it is not. This leads to awkward workarounds when engineering-type changes are needed on STLs. STEP, on the other hand, is a format widely supported by CAD programs, and can now be understood by PrusaSlicer directly.
Perhaps this will help shift people more towards sharing the STEP files of any models they create, because access to the CAD file makes it so much easier for others to make modifications, and now the CAD file and the printable model don’t have to be two separate formats. While nothing was ever actually stopping folks from sharing their CAD models in STEP format, perhaps this will help normalize it more.
You may be wondering why it has taken so long for a slicer to get a feature like this. One reason is that the STEP format is difficult to implement. For one thing, entities (the elements defining the model) in STEP can be in any order, and can themselves freely reference other entities regardless of “where” any of them may appear in the file. This makes it impossible to read and parse a STEP file sequentially. STL format is, by comparison, almost trivial to implement. This has in part contributed to the inertia keeping STL as the format making the 3D printing world go round.
Want to try it out? Beta releases of PrusaSlicer can be safely run on a machine alongside production releases, and PrusaSlicer has support for many other printers (not just Prusa machines), so if you’re curious, give it a peek.
> Starting with this release, PrusaSlicer is able to import STEP files, which is a format widely used for 3D modelling data exchange. Note that the model is tessellated on import and the slicing algorithms operate on the resulting triangle mesh, i.e., the model is not sliced analytically.
I was excited with this update, but it actually just remove the intermediary step of converting to STL, all the rest is absolutely the same. No real G2/G3 for 3d printers yet.
Unfortunately many (most?) of them don’t implement G2 or G3 anyway, and if they do it’s a simple (and inaccurate) conversion to G1. Might as well do it in the slicer, and guarantee it is done with small enough segments to be accurate (I think version of Marlin that I’ve used on my printer uses 1 mm segments by default)
Chicken and egg problem. No reason to implement them in controllers by default if none of the slicers have the capability. Until someone pulls the trigger first, it’ll never happen. Prusa did. Now we move forward.
aren’t many using GRBL? it does implement G2/3
Absolutely this is the point. Another rung on the ladder.
Eventually yes…it breaks it down into discrete steps. Most of the firmware at least accept G2/G3 and handle it. The main benefit from using arcs in printing though overall is to prevent the very small steps being sent by the gcode stream. It tends to create stutters and slowdowns.
But depending on firmware the level of arc integration may be better/worse than other types.
This is where ArcWelder for OctoPrint comes in handy. Depending on geometry it can shrink the gcode size considerably
Yeah. It is handy for that. I have some concerns about potential for defects and artifacts…but I haven’t tested it. Another handy tool for tuning production though.
Wolfmanjm added a plugin for Smoopi (Smoothieware specific host) also that runs Arcwelder and he had good results. He has a test file that always needs to run on SD or faststream.py when sliced normally that worked very well I was told.
With smoothieware I have only had issues with the stutter/slowdown while printing over USB. If printed from SD or using the faststream.py I have never had the issues. Something related to the ACK…IIRC. Too many small commands to respond ok to them all fast enough via USB.
The faster controllers such as smoothieboard can break G2/G3 to short enough segments that the inaccuracy is really negligible. One can of course increase the resolution in STL conversion, but that increases the STL and G-code file speed very fast.
Yeah…Smoothieware default config is:
“mm_max_arc_error 0.01 Arcs are cut into segments ( lines ), This is the maximum error for line segments that divide arcs” but IIRC that isn’t the only thing to change (I haven’t played with it at all myself though).
Smoothieware also does the arcs in the Z direction…which last I heard Marlin did not. Haven’t looked into it since back when the arcwelder stuff came out.
Prusas support G2/G3 arcs and any printer running marlin, grbl, klipper, reprap firmware and I’ve probably left out something obvious can support arcs if it’s enabled in the firmware config. If course that requires manufacturers of cheap printers to bother turning in features above the absolute bare minimum for this to work out the box, or for some user intervention.
Yes never even having to think about artifacts from using curved surfaces directly in the g-code would be so nice. But I do think that at least it can eliminate two issues once this become widely used.
One is having to live with a low poly model of a downloaded model because the original author did like the look or didn’t care.
The other is making remixes and reuse of models more common.
Finally isn’t there even a bezier g code? Well then let’s convert subdivision surfaces to burbs and those to bezier segments. One can dream.
As is often the case a better or near optimal solution might not be used as long the current one is deemed good enough widely enough.
Octoprint has an ArcWeld add-in/extension that does this with uploaded Gcode.
It takes time to process a file, but it’s also an option.
Maybe I’m missing something, but I don’t understand why this is so huge. If you are modifying the step file, obviously you have a CAD program. Why wouldn’t you just export the model as an stl after you make the changes? I mean, that’s what I do with models I design in FreeCAD and I would assume that other CAD programs can do this as well, no?
I suppose it could encourage people to distribute as STEP instead of STL, because it can be directly printed.
But Derek’s point is just share the cad file. I always share my openscad files, for example. Anyone can change things easily, especially when I or others use variables. Sometimes I do, sometimes I don’t. Parametric design of complicated machinery is burdensome. Anyway, this is a good step in the right direction, but it’s more of an update as to a new format being accepted, rather than it being the first time it has happened.
@Derek Tombrello said: “Maybe I’m missing something, but I don’t understand why this is so huge. If you are modifying the step file, obviously you have a CAD program. Why wouldn’t you just export the model as an stl after you make the changes?”
Yes, you might be missing something. The original post says: “3D printing has a long history of using .STL files (which are meshes) but making engineering-type changes to such files is difficult… STEP, on the other hand, is a format widely supported by CAD programs (I add: STEP files are easier to make engineering-type changes to), and can now be understood by PrusaSlicer directly.”
Put in a slightly different way: The de-facto way 3D files were distributed today is via .STL files.[1] Making clean engineering-type changes to .STL files is difficult. But if all slicers could directly input STEP files [2] instead of .STL, then the de-facto way to distribute 3D designs should change from .STL, which are harder to cleanly modify in a CAD program, to STEP format which is easier to cleanly modify because CAD programs natively work with STEP files to begin with.
* References:
1. STL (Standard Triangle/Tessellation Language file format)
https://en.wikipedia.org/wiki/STL_(file_format)
2. STEP (ISO 10303 Standard for the Exchange of Product file format)
https://en.wikipedia.org/wiki/ISO_10303
Yes we get that. That’s the entire point though. PrusaSlicer is still converting that STEP file into an STL anyways. It’s not doing anything with the STEP file. You still need to export the model from your CAD software so instead of exporting it as an STL yourself you export it as a STEP. Then the slicer just converts that STEP into an STL anyways. I really don’t see all the fanfare over this. They just added a built in STL converter to PrusaSlicer.
Until PrusaSlicer can take that STEP file and slice it AS IS then this is all kinda “meh” honestly.
The fanfare is because step support opens up the possibility that all shared 3d models will be step files meaning end users may not ever have to edit a mesh again when needing to customize a part to suit their own use. The fact that the slicer does the conversion to mesh upon opening it means that from initial creation to final print, the model will stay in a clean mathematically precise format that is easily editable by everyone. This allows on the fly super accurate changes without having to fuss with a mesh editor, which is virtually impossible to be accurate on overly complex meshes. The example of needing to alter the shread on a threaded part is a great example. In a step file the thread is represented by a mathematical expression with variables that define it properties. Adjust the variables and the whole thread changes in a precise and predictable manor. In an stl/mesh on the other hand, editing that mesh is akin to sculpting with clay, no matter how hard you try it will never be as perfect as editing a mathematical expression.
Still best if the original model is shared in a native CAD format…
Person who started Cura here.
This is huge. It is one of those things that was on my wish list. The reasons are not that complex. First odd, no strange loss of quality or wrong edge counts for arcs. Most CAD software has really bad defaults for STL export. Next, it is way more professional, professional manufacturing uses step.
Actual arc prosessing to G2/G3 most likely own’t happen for a long time, as polygon clipping for curves is an unsolved problem. While it is solved for straight lines. And slicing depends a lot on polygon clipping.
I thought it was huge until I read this:
“Note that the model is tessellated on import and the slicing algorithms operate on the resulting triangle mesh, i.e., the model is not sliced analytically.”
So I will keep on tessellating the models myself in software where I have tons of options to do the best tessellation.
Great, but if you share files, consider sharing the .step of it so others can tessellate that model in their own software with their own options.
Can’t something be taken from standard CNC mill programming? They’re able to make perfect circles pretty effortlessly.
Really why not? I didn’t even know that 3D printers use some sub-optimal routines for arcs.
CNC mills use the same gcode as 3d printers use, since 3d printers started by using CNC mills as the starting point, with a lot of the same issues. For example, there are gcodes for making arcs, which some use, and some (usually cheaper or older controllers) just use lots of little straight lines. Well, on a CNC mill there’s the diameter of the head to take into account – that’ll tend to smooth things out a bit more than 3d printing.
Or you could do like me, a true masochist, and import STEP to edit it as a vertex model in Blender
Shared stl is a pain and the quality is variable some CAD software has a default and more tinkering than that requires additional licenses. It would be nice if Prusa prevented upload of STL to printables.com after this gets a production release to promote Step but I suspect that might be a little to far!
I HATE having to comment on a model “can you please upload a STEP file?” when I need to modify the part to suit my application.
Fusion360 now allows mesh conversion to parametric.
As a Fusion360 beginner who has had a hard time changing .stls I would like to ask: “How?”
Import stl as mesh. Convert mesh to face groups. Convert face groups to solid. It’s essentially 2 or 3 mouse clicks when you get it down. All the commands are with the mesh tools and workflow is described in the help file and online videos.
Kinda – it won’t (at least in the free version) reverse engineer the underlying CAD model. So it’ll take the mesh and turn it into a solid body, but it won’t be composed of geometric shapes, drawings, etc. There are tools that will attempt to do that, but they’re very expensive and aren’t perfect since they’re taking a mesh and trying to guess what geometry was used to generate the mesh, and thus won’t always be right, won’t have the geometric constraints, etc.
Question – Why was the STL chosen for 3D printing to begin with? Why take a solid model and turn it into a surface model with a bajillion triangles? I honestly don’t see the reason for that in the first place.
Secondly I don’t see this as such a big deal if the slicer is just converting the STEP to an STL internally anyways. It’s not actually doing anything with the native STEP file. The only plus I could see is the slicer has control over how fine the details are in the conversion rather than needing to set up these options in your CAD software for STL export which might be handy for beginners
STL was chosen because of it’s simplicity, and ease of deriving a layer pattern from in the slicer. Remember, outside of stratasys, 3d printing today still heavily leans on community-driven evolution from audrino, optical drives, and flatbed scanners.
This development is notable for 2 reasons: PrusaSlicer can parse STEP at all, and it means that models can be shared as STEP directly, instead of STL and it’s associated issues.
Because a list of triangles is much easier to parse and slice than a STEP model. That’s the only reason. For list of triangles, you just have to load them, sort in z direction and then check each layer for intersections. With step, you first have to parse it into some intermediate model which you can actually slice, it typically contains many flat or curved surfaces with parametric boundaries which need several different algorithms to slice them (PrusaSlicer will actually currently convert into mesh anyway). It’s not VERY hard, but implementing this takes several weeks instead of a weekend.
Cool, we can now encounter the problems of the STEP format instead !
Right, keep in mind that STEP is a small subset of what modern CAD programs actually use, so when you export a design as a STEP file, you lose a lot of information. It’s a bit like saving a spreadsheet as a CSV file, it’ll work, but you might lose the underlying equations that drive the design. So it’s still better than exporting the spreadsheet as a bitmap image, but it’s not giving you the original design with full ability to modify it, it’s just a better starting point than nothing.
I hope this leads to easily adjusting slicing parameters based on feature, like adding extra wall thickness around holes that need threaded inserts or will be clamped under a bolt head. It’s clunky to manually define custom regions around every bolt hole when they’re already defined in the STEP file.
Even better would be the ability to script the handling of different features based on metadata from CAD, so bolt holes are automatically reinforced while other holes are not.
If I need to edit the part I’ll do it in CAD, I only want the slicer to handle the manufacturing details.
Well done Prusa Research for trying to push the 3D printer and slicers technology forward all the time.
One thing that STEP files can handle way better than STL is different bodies and surface colors in models. I guess this makes multi color or multi material prints way easier to get from CAD to slicer if you don’t have to split them in seperate STLs, and realign everything in the slicer again.
3MF, essentially a modernized version of STL, gives you that – you can have one 3MF file that can contain multiple bodies, aligned, in a single file. Great for multi-color printing, if your CAD can export the whole design as a 3MF.
Nice
I am getting some ripples in the surface importing with step file… Can bet better results with an dense STL. Is there a setting or variable to increase the density of Prusa’s internal resolution with STEP files?
Now we just need the 3MF files to include STEP objects instead of mesh objects. That will allow the person slicing to create gcode to decide how accurate they want their print to be.
No more triangles! No more triangles!