One document or many?

david_brophy

I'm starting the process of converting a large project from Fusion 360 to Onshape. It's a model of an expedition vehicle, and has hundreds of interrelated sub-assemblies:

Exterior: https://a360.co/3Erkaxp
Interior: https://a360.co/3RgXEuy

It's just me working on the CAD design, so no need to do any heavy collaboration during the design stage, but I will probably need to share the design with fabricators once we get to the build stage.

The basic self-paced courses leave the option open to arrange everything in the same document, or split the project over several documents. What would you recommend?

It feels like documents provide a unit of sharing, mostly to facilitate collaboration... so if I'm not working in a team, adding everything to the same document might be simpler... But does Onshape scale well with huge documents with hundreds of assemblies?

S1mon

I still struggle with this question after having spent a fair amount of time with Onshape. 

Some thoughts:

1. 100% agree with @tim_hess
2. If a subassembly will be reused in another project, it probably wants to be in its own document (maybe not from day 1, but long term).
3. Off the shelf stuff definitely wants to be in document(s) outside of the custom stuff (again, maybe not from day 1, but long term).
4. You can move tabs out of (or into) other documents. However, this is the one place where I've found that Onshape's fairly bulletproof ability to go back to any time in history and undo/restore anything can get a little more messy. This is not to say that you should never do it, just be careful.
5. Once stuff is split into multiple documents, it can get tedious to update documents. The fine grained control is great, but like Tim said, it requires a bit more work.
6. Branching and merging works per document. You probably don't want to take some random part(s) along for that ride, so think carefully about what stuff is intimately related when grouping things in a document.
7. Similarly, configurations are per part studio or assembly. Don't put too many things in a part studio and then decide to add a configuration which really only affects a couple parts. 
8. Depending on how you want to drive a top down design process, part studios, variable studios, derived parts/sketches, and in context features can all be used. When you have several complex parts which need to fit together (say injection molded housing parts for something) - those might benefit from being in single part studio, although derived parts/sketches might work well too. Variable studios can be good for much larger assemblies or complex mechanisms where there are a bunch of things that need to work together, but might not be so intimately connected. Assembly contexts are useful for things where something can be in multiple positions and they all need to drive the shape of one or more parts. All of this sort of top down stuff updates more easily during development when it's in the same document, but long term, you may choose to split things up.

david_brophy

Awesome thanks for the valuable insights. I’ve decided to split things up into multiple documents.

I’m currently working on a structure for the project and I’ll post it here for feedback shortly.

tim_hess

For sharing - the new publications feature is probably the way to go. 

The common themes I've gathered from other users here are:

1. Keeping more things grouped together in a document can be good for early exploration when you switch back and forth between parts/assembies/sub-assemblies often since everything in the same workspace will keep in sync. The downside is that the history for all of your edits for every single part is rolled up into the same history tree. This brings us to #2. (Also, I think there may be some performance impacts as well, especially with large "part studios", but this is dependent on lots of factors.)
   
2. Once your design is more mature and you need more control over what gets updated and when it gets updated, splitting parts into their own documents makes sense. When split up, the history for each part/assembly/sub-assembly is kept separate and you have to manually create a version of that document and force related documents to update when you're ready. Updates will not propagate from part to assembly automatically. So, you have more control over the version of everything, at the expense of a little more work. 

S1mon

I still struggle with this question after having spent a fair amount of time with Onshape. 

Some thoughts:

1. 100% agree with @tim_hess
2. If a subassembly will be reused in another project, it probably wants to be in its own document (maybe not from day 1, but long term).
3. Off the shelf stuff definitely wants to be in document(s) outside of the custom stuff (again, maybe not from day 1, but long term).
4. You can move tabs out of (or into) other documents. However, this is the one place where I've found that Onshape's fairly bulletproof ability to go back to any time in history and undo/restore anything can get a little more messy. This is not to say that you should never do it, just be careful.
5. Once stuff is split into multiple documents, it can get tedious to update documents. The fine grained control is great, but like Tim said, it requires a bit more work.
6. Branching and merging works per document. You probably don't want to take some random part(s) along for that ride, so think carefully about what stuff is intimately related when grouping things in a document.
7. Similarly, configurations are per part studio or assembly. Don't put too many things in a part studio and then decide to add a configuration which really only affects a couple parts. 
8. Depending on how you want to drive a top down design process, part studios, variable studios, derived parts/sketches, and in context features can all be used. When you have several complex parts which need to fit together (say injection molded housing parts for something) - those might benefit from being in single part studio, although derived parts/sketches might work well too. Variable studios can be good for much larger assemblies or complex mechanisms where there are a bunch of things that need to work together, but might not be so intimately connected. Assembly contexts are useful for things where something can be in multiple positions and they all need to drive the shape of one or more parts. All of this sort of top down stuff updates more easily during development when it's in the same document, but long term, you may choose to split things up.

david_brophy

Awesome thanks for the valuable insights. I’ve decided to split things up into multiple documents.

I’m currently working on a structure for the project and I’ll post it here for feedback shortly.