Design paradoxes in 3D modeling

Asher_Edwards

Does anyone ever feel the need that to design a specific group of parts they must model one part that at some point needs to rely on measurements of a later part?

The easiest way I would describe it is a design paradox. Like those time travel ideas, the initial part relies on a later part to function, but the later part was designed based off the initial part, and it seems to be an infinite cycle to us humans. This could also be compared to quantum entanglement, though I'm not sure how comparable that is.

I have tried and failed on more complex models with this idea. What I end up doing is going back and forth with the rollback bar, trying things until a part matches up with a later designed part.

I realize that at some point this would break Onshape (or any other CAD program), since almost nobody can deal with or design in time paradoxes like this. The closest I've found to a paradox with Onshape involve Assembly Contexts. Contexts capture an assembly design at a specific time, but they mostly remain untouched unless someone manually updates the context (and breaks the model).

I am wondering if people have any tips or ideas related to this.

tim_hess

I think you should think about these things like parametric equations. You can drive both of your parts from a new independent variable that you control through a stand-alone variable, configuration, or variable studio. 

alnis

One area that helps with this a lot is the philosophy of top-down design. Fortunately, there's a good built-in course for it in Onshape: https://learn.onshape.com/learn/learning-path/top-down-design

In short, it helps to first create layouts using sketches & other skeleton geometry, then create interfaces between parts, and finally add the finishing details.

For the paradoxical issues you describe, you can often find a way to set the problem up at a high level with a layout sketch, and use the sketcher's solver to rein in parameters and determine the layout so things fit together.

There isn't a silver bullet to doing this type of design in general, but you'll get the hang of it over time.

Also, a pro tip: something that helps solidify your understanding of new modeling strategies is to go back to old models and re-make them using new approaches you've learned, emphasizing a model that is easy to work with and self-explanatory. Revisiting your old work to improve it is a great way to build familiarity with CAD, solidify your understanding of (& practice application) of more advanced modeling techniques, and gives a confidence boost when you see how far you've come!

Finally—remember that CAD is a means to an end. Your ultimate goal is (probably) a working product, not a beautiful CAD model, so don't fret about having some hacky/manually bodged stuff once in a while, as long as it's not making a negative impact on future iterations & product functionality

I'll get off my soapbox now

Asher_Edwards

Thank you for pointing that out. I ended up taking the course on top down design, and found it very helpful. It makes sense now to have something high level and avoid having interrelated parts trying to reference each other for everything.

S1mon

I often describe top down design as capturing everything that is shared by multiple parts in one place. Complex ID surfaces, clearances, mounting locations, etc. which are used by more than one part are good to put in a part studio. You may drive multiple parts in a single part studio or you might use the derive feature and do detailed design of parts in their own part studios. If the parts aren't too complex, doing them all in a single part studio can be really convenient. Some downsides: if you need to configure some parts but not all of them it adds complexity/confusion; rebuild times and editing can get slow and painful. 

With variable studios you can capture some of this kind of info in one place, but it's not visual or spatial. Variables are good for highlighting things like overall sizes, key dimensions of important parts/features, nominal wall thickness, draft, etc.

Assembly contexts are well done in Onshape, but I would still only use them when they are critical for things like clearances for mechanisms which have multiple positions.