We thought getting into making castable resin jewelry parts would be easy…but this resin is incredibly hard to work with. Even at 25 microns we are getting horrible print problems. This is a brand new replacement printer, the glass is clean, the resin tank window has been printed on TWICE, and we even strained the resin to get all the gunky precipitate out of the bottom that had formed. Regardless of all that, we’re getting layer lines or laser printing issues showing up, the accuracy isn’t there, and our customer doesn’t want to work with us anymore because this keeps happening. Any ideas? This print is supposed to be completely smooth and flat- no striations at all.
Is that model a single object or is it made of multiple shapes stacked?
If it is made of multiple meshes and your software gives you trouble boolean union them as one clean shape then you can make sure the objects intersect a little bit and export out an obj instead of an stl. STL files with multiple meshes will cause problems where mesh bodies intersect because it will cause a void. OBJ format can contain multiple meshes in a single file that PreForm is able to merge.
Shapes that are laying against each other will have co-planer faces that can cause lines in the surface when the file is processed.
The reason I think it is the file and not the resin and/or printer is the lines would be on the supports and all the model if it was a mechanical problem.
1 Like
Ken makes an important point.
when the supports right alongside the model are flawless… then its time to suspect the geometry.
a LOT of 3D modeling apps produce ridiculously flawed geometry.
Make sure your model qualifies as a topological solid. ANY coplanar surfaces, coincident verticies, or geometry that is internal to the volume you intend to be solid can cause problems. Many models than can be CNC Milled will not print… because a mill only needs a surface… whereas a printer needs to identify a volume that is solid versus the volume that is not.
2 Likes
One thing to keep in mind when comparing flaws on the supports vs. the printed object: if the print is at 25 or 50, only the object will be printed at that resolution; the supports will still be printed at 100.
Anyway, another possibility for this is peel forces. If the object is oriented with its long axis parallel to the wiper, the peel might be causing a slight shift at each layer, yielding this stair-step. If you re-orient so that the long axis (e.g., the cross-bar) is perpendicular to the wiper, these artifacts may disappear (I’ve had success printing planar, vertically oriented objects this way before). Alternatively, try rotating the object 30 degrees X and Y, and 45 degrees Z, and reprinting.
That’s not totally correct. The supports UP TO where the model starts will be at 100, once the model starts, the supports are the same layer resolution as the model itself.
So if your base thickness is 2mm, and your height above base is 5mm, then the first 7mm will account for 70 layers, then there is a transition period of 3-10 layers depending on the set resolution, but once the actual model starts, the supports are printed at the same resolution as the rest of the model. So the supports right next to the model (not below it) are the same as the model.
1 Like
No matter what software you use always export triangles only when exporting obj if you intend to use that model for 3d printing. Quads work ok for getting the model into other applications for additional work and N-sided will almost always produce error especially with booleaned surfaces.
I mentioned that it is a geometry issue because I ran into this a while back:
triangulation alone is not sufficient for dependably good geometry.
The model must be a topological solid- which means that all vertices must be simply connected in both directions.
If just two vertices are not connected in both directions- then the model does not qualify as a solid and software can not determine what parts ought to be material and what part is not.
flipped normals also create holes in geometry and the reason quads are an issue is because if ONE vertice gets moved out of plane with the other three, then the polygon will have a normal that only shows one half of the polygon as surface, and the other half as a hole violating solidity.
Triangulated models can also cause printer errors if two points are perfectly coincident… if polygon segments have a length of zero, or two planes are co-planar in the same space… something that can occur, for example, when you SCALE a model down… in software that has its resolution set to a pretty low level… that it, if the software is set to round off xyz positions to, say, the nearest tenth of a mm, then two points that are 2 tenths of a mm apart in the original model will get averaged to the same location if scaled down to one third of that size…
add to these causes duplicate surfaces _ A model getting duplicated and the modeler not realizing it on export_ or errant points or polygons from incompletely deleted geometry or topology.
Surfaces that can not or are not stitched or the kind of errors that occur when converting 4 point geometry from a subD modeler, into STL triangulated geometry,… and there are all sorts of ways in which a model that RENDERS just fine is simply NOT a qualified solid.
SO Always suspect- and check- geometry… when the printer prints the support structure…but NO model…then that is almost always because the model has a hole in it somewhere and the printer can not determine a correctly enclosed volume in which to print,
The problem he has is similar to the one I had. This was from a stl file that had multiple meshes in the same file and surfaces were touching and not intersecting causing co planer faces on recessed surfaces.
If he moves the meshes so the intersect AND use obj format with triangles only then Preform should be able to correct the issue without any problems and it should print fine.
Been there, done that.
OR-- if you’re gonna be modeling for print, practice proper modeling technique and understand how geometry describes a solid.
Mathematically, the definition of a solid is that it has ONLY ONE SIDE. The OUTside. ( a hollow object may have a fully enclosed void…but mathematically speaking the void is just the same as a surface with only one side- its just connected in the reverse direction.
Understand the limitations of the software you are modeling in so that you can develop a workflow that compensates.
Number one- do not export intersecting surfaces at all… use a boolean operation to merge intersecting solids into a single volume with NO internal polygons or points that are not part of the print.
Trusting to Preform to fix what you produce is simply ASKING for failed prints, wasted resin, and tank burn in you can otherwise avoid.
IF you CAN’T merge the model parts… it will be because one or more of the parts is ALREADY not a solid. Find out what you are doing to violate solidity in your modeling and correct your technique. Are you modeling in surfaces and failing to stitch them into a solid before export or conversion? Does your app export good geometry as STL but NOT in OBJ?
Or- invest money and learning curve into a modeling app that does a better job of producing qualified solids.
Service bureaus running printers all complain about models provided by their clients having topological flaws, co-incident or internal unattached planes or points, and multiple intersecting volumes being the primary cause of print failures.
Even some of the best cad software will eventually have trouble with booleans so to generate clean continuous geometry is not always possible. Holes in geometry can be from the export and not necessarily visible or correctable with the application that you are working in ie some regions might be too small and faces will be ignored. This is why PreForm has the ability to fix these simple errors added to the program.
The error in this case is where there are co-planer faces (when 2 faces occupy the same space) and because one mesh face normal is facing in the opposite direction as the other, PreForm will fail to correct the error and generate lines on recessed areas until it hits an edge. This is why only the back faces has the error and not the rest of the geometry. Co-planer iteration is similar to the flickering faces you may see in video games and PreForm seems to parse the error in stripes parallel to the build platform.
In this case an stl format is not a good choice because stl only supports one named mesh within the file so intersecting surfaces will have negative space generating hollows in the model. These hollows are similar to composite paths in the vector world such as the case as text models of letters like A, O, P, B etc where there is a path inside to create the empty space.
OBJ format supports multiple meshes per file so intersecting meshes can be treated as solids and Added within Preform. However OBJ format won’t solve the lines if the faces are co-planer so it is best to intersect them by a tiny bit. I use atleast 25 microns or roughly .001" minimum. Not sure what the decimal run out for PreForm is so I keep it at least it’s minimum layer height.
Yes, the math of generating the slices for the printer can get pretty squirrely when shells have coplanar faces. The preferred thing to do in this case is to do a boolean union so that you’ve only got a single shell. Then it’s really clear to PreForm what your intent is.
If you can’t do that, then moving the shells so that there’s a tiny bit of overlap will usually be fine. The amount of overlap only needs to around 1/2 the layer height, but it’s not very sensitive to that number. It’s really just the exactly coplanar case that causes the ambiguities.
The multiple meshes that OBJ files provide probably aren’t going to make much difference here. PreForm’s import doesn’t weight that information very heavily when it’s trying to interpret edge cases like this. Go ahead and use OBJ if you’d like, but if that’s difficult with your CAD software, then STL should be fine.
1 Like
I did have the same problem with lines with the stl format even through the meshes were intersecting but that same file as obj solved the issue here. I am currently using OpenFL here because of some issues with updated versions a while back so I can’t speak for the latest version.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.