I work closely with an ME group that is on Solidworks, and lately interchange has been an issue. Most of my deliverables in the past have been freeform OMLs (which did not cause any issues), but lately I’ve needed to hand off geometry that has a more mechanical modeling look and feel - simple planar features. The problem I’ve run into is that orthographic planar surfaces in Rhino aren’t recognized in SW as being planar to the standard front/top/side planes. This causes a huge headache on their part in that they essentially have to rebuild the model in SW. I was able to export the control points of some Rhino planar geometry into a CSV file, and I’ve noticed that when you export to 16 significant digits, the very last digit on the control points can be different. I typically use STEP 203 when exporting, that’s yielded the most trouble free interchange in the past. Has anyone else experienced this and found a solution? It’s odd that the simplest geometry seems to be causing the most problems, but here we are.
I guess the question one might ask is why Solidworks requires planarity out to 16 significant digits…? In an object that measures 1000mm (1 meter), a precision of 16 significant digits will be out to 1 billionth of a micron… (if I got that right). A picometer?
A further possibility would be to try to import to something like Plasticity in a free trial, which shares the same Parasolid kernel. This is a bit of a dumb test, but it would be interesting to see of it is a kernel-level problem, or a Solidworks problem.
I have had all sorts of issues to do with floating point errors in Solidworks, many years ago. And there was no graceful handling either.
Some constructions of planar faces, e.g., _PlanarSrf, and relying on edges and vertices to rotate or mirror geometry are common causes for planar faces to not be parallel to the World orthographic planes.
All the STEP schemas available in Rhino should export geometry the same.
If you create a _Box square to the WCS and export as STEP, the STEP file shows the surfaces for the faces are PLANEs with axes directions such as:
#131=DIRECTION('',(0.,0.,1.));
#132=DIRECTION('',(1.,0.,0.));
#134=DIRECTION('',(0.,-1.,0.));
So, SolidWorks should recognize the faces as being both planar and parallel to the World orthographic planes.
I figured that one out pretty quickly - don’t use PlanarSrf, but I’m even having some surfaces that are extruded in an ortho direction with the gumball and then trimmed showing up as non planar in SW.
@sgreenawalt pls share a model that shows this issue.
Is this regarding failing Mates in SolidWorks based on the Rhino surfaces?
I can generate parallel and coincident mates based on an imported Rhino planar surface mating with a SolidWorks constructed cube.