I’m working with an engineer who is using Solidworks and am looking to streamline our data exchange. There is a good post here that advises using STEP format. While this sort of works, there are a few problems. Anybody figured out an ideal workflow?
My experiences going from various Solidworks formats into Rhino:
STEP: Pros: Imports quickly and parts are watertight.
Cons: All data comes in on a single layer, which I need to then weed through and put on different layers as desired. Also, blocks are retained which then need to be individually deleted (it would be great if Rhino had a “delete all blocks” feature!) in order to edit the geometry.
IGES: Pros: Imports quickly and retains layers.
Cons: Objects are often no longer watertight (maybe there is a tolerance setting in SW that can be tweaked?) and many surfaces are flipped.
Solidworks Format: Per the link above, apparently in Rhino4 there is a plugin to import this format which retains layers, etc. However, it is apparently very slow and only works in Rhino4. Have not tried this. If Rhino5 had this ability (and was fast) this would really help facilitate collaborations with SW users.
I always use the SolidWorks format directly for both parts and assemblies.
It’s very reliable and fast. In Rhino v5 you can read SolidWorks files up to 2014.
STEP files support layers. If you export to step from Rhino, then read the result back in, the layers are preserved. Layer colors are not, since I don’t see a way to attach a color to a layer in a step file. but the layer color is transferred to the object color on export where appropriate.
This means that either Solidworks is not exporting layer information or it is doing it in a way not recognizable by Rhino. If it is the latter, that can be fixed. If someone can post or send me a simple STEP file from Solidworks that you think should come into Rhino with layers, I can figure it out.
I guess the first, easiest test, though, would be for you to read your STEP file back into Solidworks and see if the layers show up there. It would also be interesting to know if the layers from an exported Rhino file show up in Solidworks. @pascal If you have a chance, can you try all this?
Thanks, Chuck. My engineer is sending me a few screenshots with the options available for STEP export from SW 2015. He does not use Layers; instead, he is using multiple Components to create an Assembly. Thus, the challenge to solve (if possible) is whether or not there is a way to have the various Components converted into Layers when going into Rhino via STEP (or other).
As for the IGES export not being watertight from SW, my engineer indicated there was no tolerance option on his IGES export, so I’m not sure why a STEP export is watertight, but IGES isn’t, when coming into Rhino. Seems odd.
Will post screenshots of SW 2015 export options and the files when I get them from my engineer.
OK, that makes sense. This has come up before. Since components of an assembly correspond to blocks in Rhino, that’s the way we have to read them in. Pascal’s script is the way to go.
@chuck This has been discussed several times in the past but maybe the STEP import could do this more efficiently than the script.
Running the script can be very long and you could add some intelligence to the process in regard to the process of importing/arranging repeating parts/sub-assemblies/assemblies.
For what it’s worth, here are the options from SW2015 for exporting STEP and IGES. Shown are the defaults (I believe).
With Pascal’s script working for STEP exports (in Windows Rhino) to get components into separate layers, I guess the remaining question is why IGES isn’t watertight when it comes into Rhino. Should other options be selected in SW for IGES export, or is that just the nature of the beast coming from SW?
I see. I don’t know what are the features supported by the STEP standard.
From CATIA and SolidWorks, the recent experience I had, everything comes in blocks, usually 4 or 5 levels deep.
To work with these I don’t see other options than to explode everything.
Typically, the layers are of no use to me. I’d rather have the parts in the assembly. And making only blocks of identical parts that are placed in different locations and rotations. I’m not sure that Rhino needs to check all objects against each other; I would expect their names to be embedded in the file. ( Not that I have checked )
Hi Marc, Wim - should the exploding to layers stop at some point? Say, as an over simplified example, the assembly consists of two identical assemblies in two locations - what would you want to do here? Should the top level assembly be split into the two sub assemblies and stop there, leaving the potentially very complex sub-assemblies as blocks? My guess is this is probably not very useful… so I think we’d need to have some ‘granularity’ control, somehow, if the goal is to keep some repeats as blocks. Am I seeing this clearly, or did I miss the point…?
Yes, I think you’ve got the main problem. Where to stop exploding?
Maybe the problem is not blocks themselves but their limited usefulness.
If we had a readily-available (not a modal window) way to act on blocks and see their structure.
Like the Layers window, a tree with branches, that would be reactive enough to do some real-time editing (drag-and-drop components between branches for example).
The current Block Manager is really slow ans cumbersome so I prefer to explode everything.
I’m with Marc on this. I tend to explode all levels but at times I’m guessing that if I could (as in ‘achieve within reasonable time’) block-ify identical bolts, nuts, washers, and fittings I might gain some performance in the display. I suppose that theoretically there is a point where a certain number of objects are better managed as a block than as individuals but that probably depends on the complexity of the object. If Rhino cannot find that balance within a fraction of a second, perhaps the user could input a number to decide how many identical object there need to be to become a block.
)