I have been importing surfaces originally produced as solids in Solidworks. Sections thro the IGES surface in Rhino5.0 do not agree with sections that someone else has taken using Cobalt from the same IGES file. I then tried importing the same surface via STEP and sections taken are identical to those from Cobalt. Is there a known problem with IGES surfaces? The error is around 2mm in places. I have tried adjusting model tolerance but makes no difference.
Rhino is usually very accurate in handling both IGES and STEP, so have you tried reimporting the IGES back into Solidworks?
I’ve had the same problem in the past with IGES surfaces, so now I tend to rely on STEP as I find it more reliable. IGES is a bit old-hat afterall…
the other party say they have imported the IGES file into Cobalt without the apparent error we get in Rhino, so it appears that the IGES file is ok and it is reading it into Rhino that is creating a deviation in the geometry.
That’s odd and I am sure McNeel would like to take a look at the file.
I too uses STEP if I need to choose between the two, STEP also supports solids and that can be a timesaver too.
I use SW with Rhino regularly. What version of SW ? You can import SLDPRT files directly into V5 so long as it isn’t newer then 2014. It reads sldprt and sldasm files very clean. As for step and iges I have no problems reading them from SW. I use SW 2012.
I’ve seen differences between IGES and STEP but never anything like 2mm. I always prefer STEP if available, the geometry usually comes in cleaner with fewer naked edges. If I need to make a water tight part, I’ll often ask for all the formats I can get, very often naked edges in a STEP won’t be naked in an IGES and vice versa. Same is true of SLDPRT files.
Some imported geometry won’t come in cleanly no matter what you do. I’ve had to recreate an imported surface as a native Rhino surface more than once. I guess it’s just a translation issue and it’s never going to be prefect.
It’s a pipe dream, but a universal file format for all CAD would be nice.
Remember this as well:
STEP is a solid format which includes edge joining information. Edges that are out of tolerance can be “forced” together in software like SW and Rhino by either using too low modeling tolerances or other trickery such as “JoinEdge” in Rhino. Thus they will export/import as “solid”.
IGES on the other hand does not have joining info and the edges you see are the real edge trims that have not been forced out of place by joining. So essentially it is not lying to you about how closely surfaces might fit.
You can test this out by exploding your “solid” STEP, running RebuildEdges on the results and see if the edges move to correspond with the shapes found in the IGES file.
Here is an example of the above… An IGES and STEP export of the same “cube” object from Rhino. Re-import them and have a look. The Step will tell you it’s good and closed. But the edges are actually out of tolerance by up to 1mm.
Cubish.stp (8.7 KB)
Cubish.igs (4.4 KB)
I tried reading in SW file but did not read anything in, probably SW2015.
thanks for all the comments, very helpful. The worry is when you have small errors that can easily be missed without any error messages or warnings. not so bad when it is something really obvious and also had a few of those. Following more checks it looks like the step file does read in ok, so now ok.
Thanks for that insight, Mitch. It explains some of the odd behaviour I’ve experienced when working with imported geometry in the past. I’ve had edges move unexpectedly and I didn’t understand why - now I know.
Rebuild edges isn’t a command I was familiar with before. There’s always more to learn.
Thanks for sharing your expertise.