Could we make a modified model as in Solidworks by Grasshopper

Dear all,

I work in membrane structure company.

We have many typical connection design (just need to adjust size of bolts, base plate, diameter of pipe, radius of bracket etc. to match to specific projects. Just change the size, same design)

As Rhino is very strong in form finding and Solidworks is easy to create and modify detail.

Therefore, my way of making 3D model for entire project is:

1. Rhino for structure axis, form finding membrane

2. Modify each connection type in Solidworks (according to Rhino frame) and import them back to Rhino file.

This way takes me lots of time to export/import when I need to revise some connections.

I try to find the way making all stuff by Rhino Grasshopper.

My target is:

1. Making structure frame in Rhino (curves)

2. Using grasshopper to generate all type of connections from those curves.

Please advise me which document should I read?

P/s: Attached file for your references.

1. sw-1: is a simple base plate. This one I made by Solidworks, all dimensions as shown could be modified.

2. GRASS-1: my target.

Really appreciate your help.

Regards,

Attachments:

sw-1.jpg, 55 KB
GRASS-1.jpg, 311 KB

Replies to This Discussion

Permalink Reply by peter fotiadis on September 10, 2015 at 2:27am

Hmm ...

1. See these: https://www.google.com/url?q=http://www.grasshopper3d.com/forum/top...

2. It's a classic puzzle about how a feature driven MCAD app (SW) can communicate (or take benefit from) with a graphic editor (GH) hosted in a CAD app that has primitive assembly/component capabilities and/or feature driven ops (Rhino). Did I've mentioned that Rhino is a surface modeler? (meaning the obvious).

3. Imagine a "seed" collection of assemblies related with various membrane components made in SW. Say: geometry (prior solid ops) and parameters (the feature driven part of the equation, in most of cases managed with some RDBMS). You should port these to GH (a variety of ways exist for that) and create the bare minimum of "solids" in GH as instance definitions. There's 2 main reasons to do that: (a) effectively communicating back on an assemply/component schema (via STEP) and ... (b) achieving manageable collections when in GH. These are critical for clash detection (when outlining some topology in GH, therefore NEVER work just with "curves") and "variation" control of some sort (up to a point). Of course for high class designs (where the devil hides in the details) this is NOT the best imaginable solution ... you'll need CATIA for such an integrated (all in one) procedure. On the other hand many could (wrongly) argue that CATIA is expensive (rather naive argument if a company has a certain turnover).

4. So, in general I would strongly suggest to use instance definitions of items in some sort of "intermediate state" of detail (an 100% undoable task without code) structured in such a way (classic assembly/component MCAD mentality blah, blah) that SW could take benefit of a possible modified "base topology" and proceed by finishing variations of the given assembly (feature driven stuff as usual).

5. Then export (STEP 214) back portions of the assemblies (and parameters used) to R/GH if and when this is required (for instance for BIM disciplines ... but Rhino is not a BIM app, nor it would ever be).

6. If you are familiar with code matters ... start thinking the whole puzzle that way, if not my advise is to find someone to design such a "procedure" (say an "app") using solely code, but this is not a task for the inexperienced by any means.

best, Peter

Permalink Reply by peter fotiadis on September 10, 2015 at 3:49am

BTW: Here's an old "integrated" (all-in-one: meaning using Generative Components and Microstation/AECOSim - not my style anymore, I've switched to CATIA for similar things) brief example from here (parametric 2d profiles destined to feature driven solid components):

to there (one variation of some membrane combo):

See attached zipped images that "explain" (kinda) the assembly/component mentality used on that old thing. Spot clash detection issues on some membrane tensioner components (meaning a required interaction between "abstract" parametric topology exploitation(s) and ... er ... that ugly thing [i.e. real-life]).

Attachments: